This is Prog-01.gz in view mode; [Up]
From: rbraver@ohww.norman.ok.us Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5abtqo$82k@newman.pcisys.net> Date: 1 Jan 1997 02:27:46 GMT Control: cancel <5abtqo$82k@newman.pcisys.net> Message-ID: <cancel.5abtqo$82k@newman.pcisys.net> Sender: root@bytewarecafe.com Spam cancelled. Notice ID: 19970101.11. See news.admin.net-abuse.announce or http://spam.ohww.norman.ok.us/spam_notices/19970101.11.html for complete report. Original Subject: 32meg 70ns 72pin EDO simm for $140
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 31 Dec 1996 19:31:03 -0700 Organization: Primenet Services for the Internet Message-ID: <AEEF1D90-1BB56@198.68.42.210> References: <5abtee$mk9@news4.digex.net> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >The harsh reality is that ms word, the >biggest wp on the mac, pukes with gx often enough that gx is removed >at universities. Period end of story. That you constantly ignore >these facts seems to indicate you don't care about the reality >users face. > (like taking candy from a baby) But YOU are the one who claimed that MS applications produce lousy PS code. Isn't it within the realm of possibility that MS also does shanky non-standard things with Mac print drivers? --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: rbraver@ohww.norman.ok.us Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5abtqn$82k@newman.pcisys.net> Date: 1 Jan 1997 02:29:34 GMT Control: cancel <5abtqn$82k@newman.pcisys.net> Message-ID: <cancel.5abtqn$82k@newman.pcisys.net> Sender: root@bytewarecafe.com Spam cancelled. Notice ID: 19970101.11. See news.admin.net-abuse.announce or http://spam.ohww.norman.ok.us/spam_notices/19970101.11.html for complete report. Original Subject: 32meg 70ns 72pin EDO simm for $140
From: help@spry.com Newsgroups: comp.sys.next.programmer Subject: FREE EDUCATIONAL VIDEO/CDs Date: 1 Jan 1997 03:16:41 GMT Organization: Self Help Corp Message-ID: <5ackup$5g3@chile.earthlink.net> FREE ACCESS: WORLDS LARGEST COLLECTION OF SELF-HELP, EDUCATIONAL, INSRUCTIONAL,AND INFORMATIONAL VIDEO TAPES AND CD ROMs. http://www.totalmarketing.com "IMPORTANT" ACCESS CODE FOR SITE IS "69589" (69589) PLEASE MAKE A NOTE OF THIS ACCESS CODE, AS YOU WILL NOT BE ABLE TO USE SITE WITHOUT IT. " LEARN AT HOME "
From: marcel@cs.tu-berlin.de (Marcel Weiher) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 1 Jan 1997 04:54:15 GMT Organization: Technical University of Berlin, Germany Message-ID: <5acqln$e5r$1@news.cs.tu-berlin.de> References: <5aamn8$27s$1@news.cs.tu-berlin.de> <AEEEC433-DB8A@198.68.42.248> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit "Lawson English" <english@primenet.com> writes: >Marcel Weiher <marcel@cs.tu-berlin.de> said: >>>a) shouldn't apply unless you are talking about convenient units that >need >>>more than what is available under a range of 0 to ffff.ffff. >> >>Let's take a CAD application that uses PS-points (72dpi/screen resolution) >>as its base coordinate system. Now you want to draw an aircraft carrier >>and you have just overflowed the range of the coordinate system. Of >>course you still have lots of precision left, so you _could_ have >>rescaled everything. But maintaining two sets of coordinates is really >>too much of a hassle. >> >I'm sorry. Do you REALLY think that PS doesn't switch between float and >integer internally, as needed? I was talking about the application. What PS does internally is of no concern to me. >>>b) might be a problem. I am not familiar with "nesting documents." >> >>Application A generates an EPS E, which is included by Program P >>into illustration I (also saved as EPS) which is then imported >>into Layout App L. Etc. >That is an issue for a GhostScript interpreter. We're talking *output* >here. How things are stored internally in an interpreter is entirely a >different matter. Well, yes, I forgot. You can't really do that with GX. Darn. Regards, Marcel
From: rbraver@ohww.norman.ok.us Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5ackup$5g3@chile.earthlink.net> Date: 1 Jan 1997 05:29:15 GMT Control: cancel <5ackup$5g3@chile.earthlink.net> Message-ID: <cancel.5ackup$5g3@chile.earthlink.net> Sender: help@spry.com Spam cancelled. Notice ID: 19970101.35. See news.admin.net-abuse.announce or http://spam.ohww.norman.ok.us/spam_notices/19970101.35.html for complete report. Original Subject: FREE EDUCATIONAL VIDEO/CDs
From: quinlan@sfu.ca (Brian Quinlan) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 1 Jan 1997 06:13:05 GMT Organization: Simon Fraser University Message-ID: <5acv9h$qfd@morgoth.sfu.ca> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> John Kheit <jkheit@cnj.digex.net> writes: >There is no other perspective. DPS and PS printers use the same >code. GX does not. Period. End of story. This is not always true. Sometimes you will have to print to a device with an aspect ratio that is different that that of your window. That may mean that you have to generate different PS code. >The FUD has turned into pure fantasy on your part. There is one >BIG difference you fail to note. I print on a DPS system, it >PRINTS. Period. No problems. The same is not true of GX. Every >PS file I pumpt to DPS prints...the same is not true of GX. That >is the harsh reality. The harsh reality is that ms word, the >biggest wp on the mac, pukes with gx often enough that gx is removed >at universities. Period end of story. That you constantly ignore >these facts seems to indicate you don't care about the reality >users face. The most likely probably is that Microsoft is ignoring Apples printing guidelines. >See, under DPS and NeXTSTEP, it isn't a function of the app. All >apps just print. Period. No problems. Your using absolutes when you shouldn't. I'll be you $10 that I can write a app that doesn't print under NeXTStep. Or are you arguing that all NeXTStep apps that you know of print correctly? That would be irrelevant since Word doesn't run under NeXTStep. -- Brian Quinlan "Never ask what sort of computer a guy drives. If he's a Mac quinlan@sfu.ca user, he'll tell you. If not, why embarrass him?" - Tom Clancy
From: "Gregory H. Anderson" <greg@afs.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Another UI suggestion - since we're at it Date: Wed, 01 Jan 1997 04:22:42 -0500 Organization: Anderson Financial Systems Inc. Message-ID: <32CA2CE2.1B04@afs.com> References: <852072602.2258@dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mark@oaai.com wrote: > Inspectors should try harder to accommodate multiple selections than they > typically do. If I click on one file in the Workspace Manager and inspect > it, I see its properties. If I click on two files, I see the properties > of neither - the panel displays "Multiple Selection" > instead. This is by far the most important advancement in Delphi's Inspector over NEXTSTEP's. The problem is, NeXT is very dependent on making individual attributes settable through special graphic widgets. Delphi simply builds a two-column matrix with the list of attributes and their current settings. When the objects are not all of the same class, the list of attributes in intersected to show only those which apply to all objects in the selection. Very slick. Greg
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 1 Jan 1997 13:36:55 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5adp9n$p84@bias.ipc.uni-tuebingen.de> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <5acv9h$qfd@morgoth.sfu.ca> Cc: quinlan@sfu.ca In <5acv9h$qfd@morgoth.sfu.ca> Brian Quinlan wrote: > John Kheit <jkheit@cnj.digex.net> writes: > > >There is no other perspective. DPS and PS printers use the same > >code. GX does not. Period. End of story. > > This is not always true. Sometimes you will have to print to a device > with an aspect ratio that is different that that of your window. That > may mean that you have to generate different PS code. > No. Obviously you do not understand the concepts behind PS. > >See, under DPS and NeXTSTEP, it isn't a function of the app. All > >apps just print. Period. No problems. > > Your using absolutes when you shouldn't. I'll be you $10 that I can > write a app that doesn't print under NeXTStep. Or are you arguing that > all NeXTStep apps that you know of print correctly? That would be > irrelevant since Word doesn't run under NeXTStep. > What he is trying to say it NeXTSTEP do not need a driver in the sense of the MacOS world. The extra step of converting (do not argue... GX has a different representation than PS) is not needed... you'll get the real McCoy. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 1 Jan 1997 12:35:03 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF00D6C-14601@198.68.42.207> References: <5acqln$e5r$1@news.cs.tu-berlin.de> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >>That is an issue for a GhostScript interpreter. We're talking *output* >>here. How things are stored internally in an interpreter is entirely a >>different matter. > >Well, yes, I forgot. You can't really do that with GX. Darn. Touche. But you *could* convert it to GX with no problem and obtain all the accuracy that you needed... --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: cwood41@maine.maine.edu (Christopher Wood) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Thu, 02 Jan 1997 01:39:13 -0500 Organization: University of Maine System Message-ID: <cwood41-ya023080000201970139130001@news.caps.maine.edu> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5abtee$mk9@news4.digex.net>, jkheit@cnj.digex.net wrote: > The FUD has turned into pure fantasy on your part. There is one > BIG difference you fail to note. I print on a DPS system, it > PRINTS. Period. No problems. The same is not true of GX. Every > PS file I pumpt to DPS prints...the same is not true of GX. That > is the harsh reality. The harsh reality is that ms word, the > biggest wp on the mac, pukes with gx often enough that gx is removed > at universities. Period end of story. That you constantly ignore > these facts seems to indicate you don't care about the reality > users face. I don't think anyone would disagree that Apple's handling of GX so far has been pretty terrible... It's a pain to install, it takes up too much memory, it forces you to convert all your Type 1 fonts (and keep uncoverted copies handy for when you decide to remove GX -- in my experience about 2 - 3 hours after you first install it. And then to add insult to injury there are few mainstream applications that take advantage of it, and far too many that are downright incompatible with it. But all these problems could have been fixed if Apple had continued any serious devolopment on GX. The technology is sound and offers more than any other imaging architecture that I'm aware of. (Issue 15 of develop has a terrific intro to GX for programmers. I think Apple has a copy on their developer web site.) GX's failure isn't due to any inherent flaws in the technology, but to (the old) Apple's lack of will and discipline to develop a new technology beyond the demoware stage. (But maybe they're starting to see the light: I've heard that Apple is working on a new version of GX. And consider what they're doing with Cyberdog, aggressively updating it and (gradually) fixing what's wrong with it and adding what it needs. Is this the same Apple?) Anyway, although I think that GX is the better technology, I'd rather see Apple ship the new OS with DPS and ship it on time, than have a GX-based OS a year late. Besides, it might not be a bad idea for Apple to be getting on Adobe's good side, considering that Adobe's support is going to be critical to the success of the new OS. Just a thought, but would it be possible to layer the GX API (or a subset of it) on top of DPS? Just for the first version(s) of the new OS, I mean. The essential parts of the API would be there, and developers wouldn't have to worry about it becoming obsolete in the immediate future; and as Apple replaced the underlying engine, the overhead of going from GX to DPS would disappear and the additional features of GX would become available. --Chris -- Christopher Wood cwood41@maine.maine.edu D'ohh! <-- in the manner of Homer Simpson
From: lutzray@9bit.qc.ca (Raymond Lutz) Newsgroups: comp.sys.next.programmer Subject: sound from NXRecordStream? Date: 1 Jan 1997 21:13:47 GMT Organization: SPC Message-ID: <5aek2b$t90@wagner.spc.videotron.ca> Hello all I want to play a sound freshly recorded by a NXRecordStream. How? The NXRecordStream passes me a pointer with the soundStream:didRecordData:(void *)data datasize:forBuffer delegate method, what can I do with this pointer? If I allocate a soundStruct, how do I stuff the data in? Do I mess with soundStruct->dataLocation ? If I instanciate a sound, [sound data] will *give* me a pointer, but I want to give a pointer *to* the sound object! 8^| PS: I don't simply use SNDStartRecording() because I want peak information, as [NXSoundDevice getPeakLeft:right:] gives. By the way, what's the difference between (void *) and id ? All those questions probably unveil my C ignorance... 8^) Should I wait MacStep to code all this in QuickDraw GX ? -- Raymond Lutz, lurker extraordinaire and dilettante programmer.
From: younghoon KIL <ppai@soback.kornet.nm.kr> Newsgroups: comp.sys.next,comp.sys.next.misc,comp.sys.next.software,comp.sys.next.programmer,comp.sys.next.marketplace Subject: Re: Calendar and scheduling apps Date: Thu, 02 Jan 1997 17:04:31 +0900 Organization: KORNET Message-ID: <32CB6B8F.4F69@soback.kornet.nm.kr> References: <5af43n$8bu@ralph.vnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7bit To: timothy@acm.org Timothy R Mills wrote: > > What kind of calendar/schedule/group scheduling software exists for > NEXTSTEP? What are the features and costs? Is there anything besides > PencilMeIn? daily planner application - Chronographer 0.85 Dwight Everhart everhart@alterlife.com ftp://ftp.next.peak.org/pub/next/demos/productivity/Chronographer.0.85.NIHS.b.tar.gz ftp://peanuts.leo.org/pub/comp/platforms/next/Tools/calendars/Chronographer.0.85.NIHS.b.tar.gz group scheduling - Pencil Me In http://www.sarrus.com/PencilMeIn.html http://www.sarrus.com/FTP.html
From: quinlan@sfu.ca (Brian Quinlan) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 01:29:14 GMT Organization: Simon Fraser University Message-ID: <5af31a$m2b@morgoth.sfu.ca> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <5acv9h$qfd@morgoth.sfu.ca> <5adp9n$p84@bias.ipc.uni-tuebingen.de> frank@this.net (Frank M. Siegert) writes: >No. Obviously you do not understand the concepts behind PS. I may understand more than you think. I am saying that, in cases where you are not doing WYSIWYG printing (for example, you will need to use different PS commands for DPS and for your printer. That means that it is possible for an application to display on a screen correctly but not to print correctly. The original poster claimed that it was absolutely impossible to print incorrectly under NeXTStep. That claim is false. >What he is trying to say it NeXTSTEP do not need a driver in the sense of the >MacOS world. The extra step of converting (do not argue... GX has a different >representation than PS) is not needed... you'll get the real McCoy. You do not need a driver, obviosly, because your printer understands the same PS code as DPS. I am arguing, however, that the problem with GX does not lay with Apple's GX -> PS conversion but Microsoft's non-standard use of Apple's imaging API. -- Brian Quinlan "Never ask what sort of computer a guy drives. If he's a Mac quinlan@sfu.ca user, he'll tell you. If not, why embarrass him?" - Tom Clancy
From: "Nick Nallick" <nallick@winternet.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: NextStep & Mac Frameworks Date: 1 Jan 97 09:45:23 -0600 Organization: StarNet Communications, Inc Message-ID: <AEEFE2B6-491909@204.246.66.19> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit nntp://news.winternet.com/comp.sys.mac.oop.powerplant, nntp://news.winternet.com/comp.sys.next.programmer Apparently in a year or so Apple is going to have an object-oriented API via NextStep/OpenStep. As an established Mac frameworks person I haven't had the chance to use the NeXT software, but I'm curious about what level of function it provides. Perhaps the following questions can be answered by someone who has developed for a NeXT system and a Macintosh framework. Does it still make sense to have an application framework such as MacApp or PowerPlant on top of OpenStep, or does OpenStep provide all of those functions? For example, how rich is the view system? Is there an application/document model? Would a port of MacApp or PowerPlant be likely to make it easier to move an application written in one of these frameworks to the new Apple OS? Thanks, Nick Nallick
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 09:50:59 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ag0e3$a2r@news4.digex.net> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <5acv9h$qfd@morgoth.sfu.ca> quinlan@sfu.ca (Brian Quinlan) wrote: > Your using absolutes when you shouldn't. I'll be you $10 that I > can write a app that doesn't print under NeXTStep. Or are you > arguing that all NeXTStep apps that you know of print correctly? > That would be irrelevant since Word doesn't run under NeXTStep. True, nothing in life is absolute. I've used perhaps close to every app under NeXTSTEP... All of them print w/o problems b/c they use the standard print mechanisms that gives them much if not all printing fucntionality for free. If you actually set out TRYING to make something not work, I'm sure you'll succeed...though under NeXTSTEP you'd have to try a bit harder... I have no doubts ms is up to that task however ;) -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 09:55:03 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ag0ln$a2r@news4.digex.net> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <cwood41-ya023080000201970139130001@news.caps.maine.edu> cwood41@maine.maine.edu (Christopher Wood) wrote: > Just a thought, but would it be possible to layer the GX API (or > a subset of it) on top of DPS? Just for the first version(s) of > the new OS, I mean. The essential parts of the API would be there, > and developers wouldn't have to worry about it becoming obsolete > in the immediate future; and as Apple replaced the underlying > engine, the overhead of going from GX to DPS would disappear and > the additional features of GX would become available. Yes, I think this is reasonably doable... Put much of the GX api in a framework for OpenStep and have DPS do the basic drawing... Likely the quickest way to go... -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: Timothy R Mills <timothy@acm.org> Newsgroups: comp.sys.next,comp.sys.next.misc,comp.sys.next.software,comp.sys.next.programmer,comp.sys.next.marketplace Subject: Calendar and scheduling apps Date: 2 Jan 1997 01:47:35 GMT Organization: Vnet Internet Access, Inc. Message-ID: <5af43n$8bu@ralph.vnet.net> Keywords: calendar, schedule What kind of calendar/schedule/group scheduling software exists for NEXTSTEP? What are the features and costs? Is there anything besides PencilMeIn? Please email me with any details and contacts. Thanks. Timothy -- --------------------------------------------------------------------- Timothy R. Mills 2500 Innsbrook Road timothy@acm.org Charlotte, NC 28226 (NeXT/MIME/ASCII) phone: 704-442-1141 ---------------------------------------------------------------------
From: ehutch@hypnos.norden1.com (E. Hutchinson) Newsgroups: comp.sys.next.programmer,misc.jobs.offered,chi.jobs,ill.jobs Subject: NEXTSTEP/Career Position/ILL Date: 2 Jan 1997 13:44:20 GMT Organization: Norden 1 Communications Message-ID: <5age3k$l2q@tofu.alt.net> Programmer/analyst/developer NEXTSTEP--------------------Commercial experience Objective C----------------Commercial experience EOF-----------------------A Plus Career Position----------Excellent benefits,working conditions & opp Area--------------------The Greater Chicago Area To Be Considered-------Fax resume or mail a hard copy. -- ehutch@norden1.com (419) 893-6367 [fax] Omni Search (419) 893-6334 [voice] 1310 Craig Maumee, Ohio 43537
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 09:46:30 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ag05m$a2r@news4.digex.net> References: <5abtee$mk9@news4.digex.net> <AEEF1D90-1BB56@198.68.42.210> "Lawson English" <english@primenet.com> wrote: > >The harsh reality is that ms word, the biggest wp on the mac, > >pukes with gx often enough that gx is removed at universities. > >Period end of story. That you constantly ignore these facts > >seems to indicate you don't care about the reality users face. > (like taking candy from a baby) > But YOU are the one who claimed that MS applications produce > lousy PS code. Isn't it within the realm of possibility that MS > also does shanky non-standard things with Mac print drivers? Well regardless of how crappy their PS code is, it does still manage to PRINT! I absolutely agree with you that ms is poop, however, apple knowing that ms might be doing the equivelent of sabotaging their platform...since it is the most widely used wp on the platform might have GX 'spoof' word by turning itself off for compatibility sake... Have GX init allow the user add apps to have GX disable itself for compatibility sake...that way I can have it installed all the time and apps that do take advantage great... but it would still let me use my main apps... BTW, just try and take some candy from me...you'll get what a baby might leave, just in bigger doses :) -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: stes@wolfram.com (David Stes) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 2 Jan 1997 16:07:47 GMT Organization: Wolfram Research, Inc. Distribution: world Message-ID: <5agmgj$6md@dragonfly.wolfram.com> References: <AEEFE2B6-491909@204.246.66.19> "Nick Nallick" <nallick@winternet.com> writes > > Does it still make sense to have an application framework such as MacApp > or PowerPlant on top of OpenStep, or does OpenStep provide all of those > functions? For example, how rich is the view system? Is there an > application/document model? > There are two different frameworks. OpenStep's framework, and the NextStep application kit. The latter is discussed in a book like e.g. Pinson & Wiener's "Objective C - Object-Oriented Programming Techniques". It's based upon a very well thought-out trio of objects, "View", "Window" and "Application". Clipping, coordinate transformations etc. are all handled very elegantly by a "chain of Views". Centered around this architecture, there are all sorts of Control classes, Font support, PrintPanel etc. It's good stuff. There is no Document object (there is a WhatsUpDoc mini-example nevertheless), but I recall a posting of William Parkhurst in 1991 about adding "generalized document handling" perhaps to future versions of the appkit (if I recall correctly, thread-safe operation, a document architecture etc. were a few of the items he mentionned at a BaNG meeting, as possible extensions of the appkit). But it didn't really happen yet (except for WhatsUpDoc), I think. -- David Stes E-mail: stes@wolfram.com
From: Clifford T. Matthews <ctm@ardi.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Faster emulators and modern kernels Date: 02 Jan 1997 11:46:49 -0700 Organization: ARDI Sender: ctm@ftp.ardi.com Message-ID: <ufsp4jgbja.fsf@ftp.ardi.com> References: <rbarris-ya023280002612961417480001@news.quicksilver.com> <ufengc4gby.fsf@ftp.ardi.com> <5a9ifu$586@usenet.rpi.edu> <5abd7o$921@cerberus.ibmoto.com> In-reply-to: tim@apple.com's message of 31 Dec 1996 15:58:48 GMT >>>>> "Tim" == Tim Olson <tim@apple.com> writes: In article <5abd7o$921@cerberus.ibmoto.com> tim@apple.com (Tim Olson) writes: Tim> In article <5a9ifu$586@usenet.rpi.edu> Garance A Drosehn Tim> <gad@eclipse.its.rpi.edu> writes: >> This touches upon a topic that I did not think of until >> recently. For this emulation stuff to work, Apple is going to >> need to emulate PowerPC code as well as 680x0 code. Does >> Executor have any hooks for that? Tim> PowerPC emulation would only be required if you weren't Tim> running natively on a PowerPC processor. In a "compatibility Tim> box" scenerio, you need to virtualize the machine, not Tim> necessarily the processor. Right. For example, Executor/NEXTSTEP/680x0 uses the native 680x0 to do its work, for instance (but it, like other Executor 2 instantiations, doesn't run any PPC specific code). For Apple's flagship product, a PPC based system running a NEXTSTEP derived OS, there's no need for additional processor emulation and little, if any, need for any work that ARDI's done. The compatibility box would be constructed so that the native PPC processor handles the PPC code, and the existing 68k emulator for the PPC would be used for the 68k emulation. OTOH, NEXTSTEP already runs nicely on Intel based computers, and that's where the technology that ARDI uses in Executor could be useful. The synthetic CPU that's shipping in Executor 2 only emulates 68k, but Mat Hostetter has already done much work on a successor that could emulate 68k and PPC simultaneously, although it's not clear that such capability would ever be needed. *If* Apple embraces the multi-architecture nature of NEXTSTEP, then software written for the new OS will be "fat" and not need to run under emulation. So that leaves the question of what to do about PPC compatibility on non-PPC machines in the interim. One possible answer would be "nothing". After all, people are getting along fine now without the ability to run PPC based apps on Intel based machines. PPC based machines are cheap enough and contribute to Apple's bottom line enough for it to make sense to just point people in that direction when they absolutely need a PPC specific app. Tim> -- Tim Olson Apple Computer, Inc. (tim@apple.com) --Cliff ctm@ardi.com
From: Jeff Hoekman <jeffh@dnai.com> Newsgroups: comp.sys.next.programmer Subject: need NumToString( ) equivalent Date: Thu, 02 Jan 1997 07:47:48 -0800 Organization: DNAI ( Direct Network Access ) Message-ID: <32CBD897.5E82@dnai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anyone know an easy way to convert integers or floating point number to character strings? Thank you, Jeff Hoekman
From: "Georg Tuparev" <gtupar@ctp.com> Newsgroups: comp.sys.next.programmer Subject: Python for NS.4.x Date: 2 Jan 1997 18:08:11 GMT Organization: Cambridge Technology Partners, Inc. Message-ID: <5agtib$n3b@concorde.ctp.com> Folks! Does anybody already compiled Python 1.4 on NS 4.x? Tnx -- ------- /\/\ Georg Tuparev <georg_tuparev@ctp.com> / /_ \ Cambridge Technology Partners \ / / Apollo House, Apollolaan 15 \/\/ 1077 AB Amsterdam, The Netherlands Tel: +31(20)575-0492 Fax: +31(20)575-0500 WWW: http://www.ctp.com
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Thu, 2 Jan 1997 14:51:52 -0500 Organization: phenix@interpath.com Message-ID: <19970102145152369323@roxboro-169.interpath.net> References: <AEE5CE60-15EFA@198.68.42.189> <5a476h$1el@precipice.fdn.fr> <rex-ya023080002912960750350001@nntp.ix.netcom.com> <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <AEEF1D90-1BB56@198.68.42.210> <5ag05m$a2r@news4.digex.net> John Kheit <jkheit@cnj.digex.net> wrote: ] "Lawson English" <english@primenet.com> wrote: ] > >The harsh reality is that ms word, the biggest wp on the mac, ] > >pukes with gx often enough that gx is removed at universities. ] > >Period end of story. That you constantly ignore these facts ] > >seems to indicate you don't care about the reality users face. ] ] > (like taking candy from a baby) ] > But YOU are the one who claimed that MS applications produce ] > lousy PS code. Isn't it within the realm of possibility that MS ] > also does shanky non-standard things with Mac print drivers? ] ] Well regardless of how crappy their PS code is, it does still manage ] to PRINT! I absolutely agree with you that ms is poop, however, ] apple knowing that ms might be doing the equivelent of sabotaging ] their platform...since it is the most widely used wp on the platform ] might have GX 'spoof' word by turning itself off for compatibility ] sake... Have GX init allow the user add apps to have GX disable ] itself for compatibility sake...that way I can have it installed ] all the time and apps that do take advantage great... but it would ] still let me use my main apps... It DOES do this, but you have to install the QuickDraw(tm) GX Helper system extension. This will add a menu under the apple (and under the about menu) which says Turn Desktop Printing Off - which turns of GX for the frontmost application. -- John Moreno
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 13:02:02 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF16545-980EB@198.68.42.189> References: <cwood41-ya023080000201970139130001@news.caps.maine.edu> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Christopher Wood <cwood41@maine.maine.edu> said: >Just a thought, but would it be possible to layer the GX API (or a subset >of it) on top of DPS? Just for the first version(s) of the new OS, I mean. >The essential parts of the API would be there, and developers wouldn't have >to worry about it becoming obsolete in the immediate future; and as Apple >replaced the underlying engine, the overhead of going from GX to DPS would >disappear and the additional features of GX would become available. > That would be doable, but I would suspect it to be dog-slow. You'd have the GX to DPS overhead, PLUS the DPS over head, PLUS the loss of all the optimizations (there are many) of GX. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 2 Jan 1997 13:03:03 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF165A8-997F6@198.68.42.189> References: <5ag0ln$a2r@news4.digex.net> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John Kheit <jkheit@cnj.digex.net> said: > >Yes, I think this is reasonably doable... Put much of the GX api >in a framework for OpenStep and have DPS do the basic drawing... >Likely the quickest way to go... Or the slowest, depending... --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: xinwei@leland.stanford.edu (Sha Xin Wei) Newsgroups: comp.sys.next.programmer Subject: Re: EOF2.0 and Oracle-DB Date: 2 Jan 1997 21:29:31 GMT Organization: Stanford University Message-ID: <5ah9br$nhg@nntp.Stanford.EDU> References: <59delc$6dn@iese.iese.fhg.de> In article <59delc$6dn@iese.iese.fhg.de> flege@iese.fhg.de (Oliver Flege) writes: > > after upgrading from EOF1.1 to EOF2.0 it's no longer possible > for me to connect to my Oracle-DB. EOModeler displays the login > panel for the DB, but after filling it in as usual everything I > get is an Alert-panel: > "Unable to connect to server: Oracle error 6107" > We discovered that you should leave the server-host field empty. ______________________________________________________________________ Sha Xin Wei (415)725-3152 Human-Computer Systems Architect xinwei@stanford.edu Maths & Scientific Visualization www.stanford.edu/~xinwei Stanford University Sweet Hall 415/Stanford,CA 94305-3090 ______________________________________________________________________
From: jsamson@istar.ca (Jean-Paul C. Samson) Newsgroups: comp.sys.next.programmer Subject: Re: need NumToString( ) equivalent Date: 2 Jan 1997 21:16:03 GMT Organization: iSTAR Internet Incorporated Message-ID: <5ah8ij$u5@news.istar.ca> References: <32CBD897.5E82@dnai.com> In-Reply-To: <32CBD897.5E82@dnai.com> On 01/02/97, Jeff Hoekman wrote: >Does anyone know an easy way to convert integers or floating point >number to character strings? Of course, the ANSI C function "sprintf" does this. For example: ----- char myString[256]; int myInteger; (void)sprintf(myString, "%d", myInteger) ----- This converts the integer "myInteger" into a C (i.e. char*) string entitled myString. If you are looking for something OpenStep specific, use the NSString class cluster. For example: ----- id myString; int myInteger; myString = [NSString stringWithFormat: @"%d", myInteger]; ----- This creates a temporary (i.e. it is destroyed at the completion of the current iteration of the event loop) NSString object. You should use an "alloc" message followed an "initWithFormat" to create a permanent string. (e.g. myString = [ [NSString alloc] initWithFormat: @"%d", myInteger]) Perhaps others will have better solutions. -- -===================================================================- Jean-Paul C. Samson -=- jsamson@istar.ca -=- NeXTmail & MIME welcome -============- http://www.cs.ualberta.ca/~jeanpaul/ -=============- -===================================================================-
From: nextusr@sleepy.ponyexpress.net (The Woodsman) Newsgroups: comp.sys.next,comp.sys.next.misc,comp.sys.next.software,comp.sys.next.programmer,comp.sys.next.marketplace Subject: Re: Calendar and scheduling apps Date: Thu, 02 Jan 1997 17:10:20 -0500 Organization: PonyExpress Net Message-ID: <nextusr-0201971710200001@ponyexpress-5-port-15.ponyexpress.net> References: <5af43n$8bu@ralph.vnet.net> The best I have found is also the cheapest. That is Cassendra. It can be found on most NeXT FTP sites. Hope this helps. NeXTusr In article <5af43n$8bu@ralph.vnet.net>, timothy@acm.org wrote: > What kind of calendar/schedule/group scheduling software exists for > NEXTSTEP? What are the features and costs? Is there anything besides > PencilMeIn? > > Please email me with any details and contacts. > > Thanks. > Timothy > -- > --------------------------------------------------------------------- > Timothy R. Mills 2500 Innsbrook Road > timothy@acm.org Charlotte, NC 28226 > (NeXT/MIME/ASCII) phone: 704-442-1141 > --------------------------------------------------------------------- -- Windows 95 - Got it... Tried it... Dumped it!
From: MWRon@metrowerks.com (MW Ron) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.os.ms-windows.programmer.tools.misc,comp.sys.be,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.tools,comp.sys.mac.programmer.games,comp.sys.next.programmer Subject: Metrowerks Announcement Listserver Date: Thu, 02 Jan 1997 17:28:22 -0500 Organization: Metrowerks Message-ID: <MWRon-0201971728220001@208.137.76.139> The Metrowerks WorldWide announcement server! Did you miss registering in time for an update? Have you been looking for a patch only to find it was released 3 weeks ago? Are you wondering when the next Update will be released? For these reasons and others, we have set up a list server that you can sign onto in order to receive Metrowerks announcements. This is Not a High-Traffic Discussion list or a Spam-Fest This is not a discussion list server. It is a one-to-many list, which means that you will not receive mail from anyone but Metrowerks and you will not receive mail unrelated to Metrowerks products and services. Your email address will be kept Metrowerks confidential and will not be sent to anyone outside of Metrowerks. Easy Come-Easy Go There are simple instructions to get on this list server and equally simple instructions to get off the list. The only thing you need is an email account. To subscribe send an email message to <majordomo@announce.metrowerks.com> with the following commands in the message body: subscribe mw-announce (your full name) Your address will be added to the list of subscribers. You will then receive periodic announcement messages from Metrowerks. For more information check out the following URL < http://www.metrowerks.com/news/listserver.html > Ron -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
From: dekorte@intrepid.suite.com (Steve Dekorte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 2 Jan 1997 23:49:59 GMT Organization: OnRamp Technologies; ISP; Dallas/Ft Worth/Houston, TX USA Message-ID: <5ahhj7$cal@news.onramp.net> References: <AEEFE2B6-491909@204.246.66.19> "Nick Nallick" wrote: > Does it still make sense to have an application framework such as MacApp or > PowerPlant on top of OpenStep, or does OpenStep provide all of those > functions? No. > For example, how rich is the view system? Very good, but only 2d. > Is there an application/document model? Yes. > Would a port of MacApp or PowerPlant be likely to make it easier to move an > application written in one of these frameworks to the new Apple OS? Don't know. -- Steve Dekorte - OpenStep Developer - Anaheim, CA "...All eyes have turned to Apple and NeXT..."
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Q: "a.out" with PB, or MAB with "> cc"? Date: 3 Jan 1997 02:24:17 GMT Organization: MHPCC Message-ID: <5ahqkh$j5v@kaopala.mhpcc.edu> I would like to create a Multi-Architecture binary shell-executable file from a plain C program. I would normally compile it in a Shell with a command line: > cc -O program.c I gather that I could do this either: 1) through ProjectBuilder, if I knew how to make it compile plain C progams into shell-executables (which is not self-evident from NeXT documentation); or 2) through a Shell command, if I knew the right cc flags. Any answers to these questions will be greatly appreciated. Thanks. -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: plsuh@goodeast.com (Paul L. Suh) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Thu, 02 Jan 1997 22:56:46 -0500 Organization: UPenn Grad Econ Distribution: inet Message-ID: <plsuh-ya023680000201972256460001@news.gslink.com> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5abtee$mk9@news4.digex.net>, jkheit@cnj.digex.net wrote: > I haven't seen an example yet. Again, these are all minor issues > dwarfed by the fact GX routinely pukes printing basic documents; > and furthermore that may be all together taken care of by DPS3. FYI, there is a poorly publicized bug in QDGX v1.1.3 and earlier affecting PCI-based PowerMacs, which causes crashes when attempting to print. It is apparently transmission-speed dependent, as I (using LocalTalk) have had consistent crashes while other people I have corresponded with (using Ethernet) have not had these crashes. According to other sources, this should be fixed in QDGX 1.2, to be released with System 7.6. See Apple's Tech Info Library for more details. <http://cgi.info.apple.com/cgi-bin/read.wais.doc.pl?/wais/TIL/Macintosh!Soft ware/QuickDraw!GX/QD!GX!Prtng!Issues!on!PCI!Mac> --Paul
From: rsmgm@minyos.its.rmit.EDU.AU (Greg McPherson) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 3 Jan 1997 08:39:15 GMT Organization: Royal Melbourne Institute of Technology, Melbourne, Australia. Message-ID: <5aigjj$72u$1@aggedor.rmit.edu.au> References: <AEEFE2B6-491909@204.246.66.19> Nick Nallick (nallick@winternet.com) wrote: : Does it still make sense to have an application framework such as MacApp or : PowerPlant on top of OpenStep, or does OpenStep provide all of those : functions? For example, how rich is the view system? Is there an : application/document model? : : Would a port of MacApp or PowerPlant be likely to make it easier to move an : application written in one of these frameworks to the new Apple OS? : : Thanks, : Nick Nallick To me this is a very important question. More important than the C++ vs Objective C debate going on. Will I be able to port my MacApp programs to NeXT? If I can't, and I have to write things from scratch, it will be time to decide whether or not to move on to the world of Windows. I suspect many folks will be in a similar position. Greg
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Q: "a.out" with PB, or MAB with "> cc"? Date: Fri, 3 Jan 1997 12:27:50 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E3FMME.D7L@cam-ani.co.uk> References: <5ahqkh$j5v@kaopala.mhpcc.edu> In article <5ahqkh$j5v@kaopala.mhpcc.edu> altenber@acpub.duke.edu (Lee Altenberg) writes: > I would like to create a Multi-Architecture binary shell-executable file from > a plain C program. I would normally compile it in a Shell with a command > line: > > cc -O program.c cc -arch i386 -arch m68k -arch sparc -arch hppa -O program.c (etc) $an
From: comm@sci.fi (Juha Tuominen) Newsgroups: comp.sys.next.programmer Subject: Audio problem after upgrading 3.2 -> 3.3 Date: 3 Jan 1997 13:33:26 GMT Organization: Scifi Communications International Oy, http://www.sci.fi/, helpdesk@sci.fi, (931)3186277 Message-ID: <5aj1r6$mu6@tron.sci.fi> I updated a customer's Intel NeXTstep system from 3.2 to 3.3. Their audio program began acting weird after the update. When recording a sound and stopping the recording with stop button (sends stop: message to sound object) the audio driver receives the stop message and it stops recording, but sound object fails to send didRecord: message to delegate object and the sound object stays empty. This doesn't happen every time, only once in awhile. Too often anyway. I checked the 3.3 release notes and didn't find any modifications on DriverKit nor SoundKit. Any ideas what might cause such a behaviour? -Juha -- My wife ran off with my best friend and I still miss him.
Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc From: simpson@post.drexel.edu (Homer Simpson) Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Message-ID: <simpson-ya023680000301970848570001@xavier.noc.drexel.edu> Date: Fri, 03 Jan 1997 08:48:57 -0500 References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <5acv9h$qfd@morgoth.sfu.ca> <5adp9n$p84@bias.ipc.uni-tuebingen.de> Organization: Drexel University Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit Personally all I care about is speed. How fast is DPS when compared to GX for display purposes only. How fast can I blit an entire screen at 24bit, a 6 or 7 ms? How fast can QuickTime movies play using masks? Can I easily and quickly do sprite movements of irregularly shaped objects? Can my display update in realtime? In a drawing program with say 1000 different shapes with many different colors sizes and transperency levels can the screen update the entire window? Because DPS is based on "real numbers" and not integers I highly doubt that a well optimized integer based display archtecture couldn't beat the pants off of an interpreted real number based display engine. One simple example of accelaration is performing simple divisions and multiplies by 2 using the bit shift operators instead of the actual multiply command. BTW does DPS support RAVE accelaration? I personally could careless at this point about printing, since I print fewer than 5 pages of information in a given week. BTW if PS is so great on NS and PS is used in print houses as the defacto standard of printing, why is the Mac the perferred platform? Secondly why are people who are migrating from the Mac switch to Windows NT or 95 and not NS? I would think that as a pre-press shop it would make sense to use a tool that works so well with printing.
From: betti@erols.com (Mike Betti) Newsgroups: comp.sys.next.programmer Subject: NeXT OS: Porting a UNIX app ? Date: Fri, 03 Jan 1997 15:29:41 GMT Organization: Erol's Internet Services Message-ID: <5aj8p3$rer@boursy.news.erols.com> I know nothing about NeXT - but I've been asked to find out about the NeXT OS - so I thought I'd go straight to the experts.... What would it take to port UNIX daemon processes to the NeXT OS ? Is the NeXT OS UNIX-like, VMS-like, or what ? Any help would be appreciated. I'd like to be able to answer these questions somewhat intelligently. Mike
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Fri, 3 Jan 1997 15:43:33 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E3FvoM.Dun@cam-ani.co.uk> References: <5aigjj$72u$1@aggedor.rmit.edu.au> In article <5aigjj$72u$1@aggedor.rmit.edu.au> rsmgm@minyos.its.rmit.EDU.AU (Greg McPherson) writes: > Nick Nallick (nallick@winternet.com) wrote: > : Would a port of MacApp or PowerPlant be likely to make it easier to move an > : application written in one of these frameworks to the new Apple OS? > : > : Thanks, > : Nick Nallick > > To me this is a very important question. More important than the C++ vs > Objective C debate going on. OK... I've never actually USED MacApp, but as I understand it, it's very simlar _in_principle_ to the AppKit. A port of MacApp threfore DOESN'T make sense, because the AppKit provides the same basic functionality, but in a more complete, and standard way - all NeXT apps (with very few exceptions) use the AppKit. > Will I be able to port my MacApp programs to NeXT? you will be able to _PORT_ them. The MacApp structure will move onto the AppKit architecture quite happily - far better than those apps based on polling the toolbox (which can be done under NeXTStep, but only just). MacApp people will be very happy under NeXTStep once they've moved over - those still writing "old style" programs will have far more problems. Thats not to say that there won't be signifgant work involved - all the objects are different, and the "toolbox" is very different, but the fundamental approach to building apps is the same, so there will be little restructuring. $an
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 16:31:09 GMT Organization: Netcom Distribution: world Message-ID: <5ajc8d$430@dfw-ixnews10.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> rsmgm@minyos.its.rmit.EDU.AU (Greg McPherson) wrote: > Will I be able to port my MacApp programs to NeXT? > If I can't, and I have to write things from scratch, it will be time to > decide whether or not to move on to the world of Windows. I suspect many > folks will be in a similar position. I don't know what the merged OS will be like, but if OPENSTEP object frameworks are used, then your apps will run under Windows NT today with support for 95 not far away. So you can continue to produce Mac apps that are source-code compatible with Windows versions. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Michael D. Rossetti <rossetti@apple.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 16:31:05 GMT Organization: MacApp Engineering Distribution: world Message-ID: <5ajc89$r1s@nntp1.apple.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Nick Nallick, nallick@winternet.com writes: >Apparently in a year or so Apple is going to have an object-oriented API >via NextStep/OpenStep. I'm not sure this is _apparent_. Perhaps we'll know better when a more complete announcement is made next week, and perhaps not. But right now it's not apparent; we can only make guesses. >Does it still make sense to have an application framework such as MacApp or >PowerPlant on top of OpenStep, or does OpenStep provide all of those >functions? To which Steve Dekorte, dekorte@intrepid.suite.com replies: >No. I'm not sure that this reply makes sense. Which part of Nick's question are you answering: the first part (it doesn't make sense to have MacApp or PowerPlant) or the second part (OpenStep provides all of those functions)? Assuming that you are answering the first part of the question the reply is not based upon any knowledge of Apple's strategy (assuming there is one) regarding the Next acquisition. I can think of about a thousand reasons why it would make sense to retain MacApp for many years even if Apple were to decide that a switch to OpenStep was warranted and new developers were to be encouraged (or even required) to develop using OpenStep. Would any of you thousand or so developers out there with existing MacApp applications like to comment on this? >Would a port of MacApp or PowerPlant be likely to make it easier to move an >application written in one of these frameworks to the new Apple OS? I've wondered this myself. MacApp is somewhat better abstracted than PowerPlant so it would be more straightforward to adapt to a different API. But I'm not losing much sleep over this matter right now. I'm more concerned about the language issue: will we have to switch to Objective C in order to take full advantage of the new API? If so then I think we've likely made a really big mistake. Mike R. [Speaking for myself and not for Apple] MacApp Engineering
From: cwood41@maine.maine.edu (Christopher Wood) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Fri, 03 Jan 1997 11:58:11 -0500 Organization: University of Maine System Message-ID: <cwood41-ya023080000301971158110001@news.caps.maine.edu> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <cwood41-ya023080000201970139130001@news.caps.maine.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit >Could you please outline the 'additional features of GX'? >I know nearly anything about DPS but nearly nothing about GX. > >I just had a look at 'GX versus PostScript: A Comparison' >found at www.apple.com. In this list only the chapter about >the 'Drawing modes' made some impression on me. Transparency >is available with DPS on NextStep, though not in such a >sophisticated way. > >Guenther Hi Guenther, From my perspective, the best things about GX that no other imaging technology has (at least not so far as I know) are its line layout features. GX brings a new level of typography to the desktop -- fonts kern themselves intelligently and have extensive sets of ligatures, ornamental characters, and swash characters. Because they're implemented at the OS level, these features are invisible to applications. That means that you could use all those nice 'fi', 'fl', 'ffi', and 'ffl' ligatures, as well as others, and the OS (and individual applications) would still recognize them for their constituent letters. And the system is smart enough to break up a ligature if it needs to add space for justification. The bottom line is that people could create documents with great-looking typography without even thinking about it. Hope I've answered your question (at least in part)... Tschues! --Chris -- Christopher Wood cwood41@maine.maine.edu D'ohh! <-- in the manner of Homer Simpson
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Fri, 03 Jan 1997 12:02:55 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CD3BBF.1750@exnext.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael D. Rossetti wrote: > > Nick Nallick, nallick@winternet.com writes: > >Apparently in a year or so Apple is going to have an object-oriented API > >via NextStep/OpenStep. > > I'm not sure this is _apparent_. Perhaps we'll know better when a more > complete announcement is made next week, and perhaps not. But right now > it's not apparent; we can only make guesses. What, exactly, did they spend $400 million for? Alternately, what's the MacApp cross-platform strategy? > > >Does it still make sense to have an application framework such as MacApp or > >PowerPlant on top of OpenStep, or does OpenStep provide all of those > >functions? > > To which Steve Dekorte, dekorte@intrepid.suite.com replies: > >No. > > I'm not sure that this reply makes sense. Which part of Nick's question > are you answering: the first part (it doesn't make sense to have MacApp > or PowerPlant) or the second part (OpenStep provides all of those > functions)? > > Assuming that you are answering the first part of the question the reply > is not based upon any knowledge of Apple's strategy (assuming there is > one) regarding the Next acquisition. > > I can think of about a thousand reasons why it would make sense to retain > MacApp for many years even if Apple were to decide that a switch to > OpenStep was warranted and new developers were to be encouraged (or even > required) to develop using OpenStep. Would any of you thousand or so > developers out there with existing MacApp applications like to comment on > this? If I recall correctly, part of the reason Copland's development was being measured in geologic time was the attempt to maintain API compatability. Keeping MacApp seems like a continuation of this effort. Is the architecture of MacApp such that it could easily be ported to run on top of OpenStep? Or are there fundamental differences between OpenStep and MacOS that have resulted in significant differences in architecture? > > >Would a port of MacApp or PowerPlant be likely to make it easier to move an > >application written in one of these frameworks to the new Apple OS? > > I've wondered this myself. MacApp is somewhat better abstracted than > PowerPlant so it would be more straightforward to adapt to a different > API. But I'm not losing much sleep over this matter right now. > > I'm more concerned about the language issue: will we have to switch to > Objective C in order to take full advantage of the new API? If so then I > think we've likely made a really big mistake. NeXT's OpenStep API is in Objective-C. (Sun's is C++, I believe.) Changing it to C++ would take quite a while, unless you buy Apple's implementation. Before you decide that Objective-C is a mistake, have you used Objective C? -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: Fri, 3 Jan 1997 16:32:54 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E3Fxyv.E3K@cam-ani.co.uk> References: <5aj8p3$rer@boursy.news.erols.com> In article <5aj8p3$rer@boursy.news.erols.com> betti@erols.com (Mike Betti) writes: > What would it take to port UNIX daemon processes to the NeXT OS ? All the standard ones are already there. because... > Is the NeXT OS UNIX-like, VMS-like, or what ? NeXTStep _IS_ Unix. it's 100% compatable (even to a BINARY level - I used to occasionaly run Sun binaries) with 4.3BSD. It does have the odd quirk - much like any Unix, but basically it's what you'd expect (but with a nice UI). It'll be no harder than any other Unix (and much easier than some). $an
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Fri, 03 Jan 1997 11:52:58 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CD396A.3DC@exnext.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael D. Rossetti wrote: > > Nick Nallick, nallick@winternet.com writes: > >Apparently in a year or so Apple is going to have an object-oriented API > >via NextStep/OpenStep. > > I'm not sure this is _apparent_. Perhaps we'll know better when a more > complete announcement is made next week, and perhaps not. But right now > it's not apparent; we can only make guesses. If they don't use the OpenStep API's, why would they bother buying NeXT? > >Does it still make sense to have an application framework such as MacApp or > >PowerPlant on top of OpenStep, or does OpenStep provide all of those > >functions? > > To which Steve Dekorte, dekorte@intrepid.suite.com replies: > >No. > > I'm not sure that this reply makes sense. Which part of Nick's question > are you answering: the first part (it doesn't make sense to have MacApp > or PowerPlant) or the second part (OpenStep provides all of those > functions)? > > Assuming that you are answering the first part of the question the reply > is not based upon any knowledge of Apple's strategy (assuming there is > one) regarding the Next acquisition. > > I can think of about a thousand reasons why it would make sense to retain > MacApp for many years even if Apple were to decide that a switch to > OpenStep was warranted and new developers were to be encouraged (or even > required) to develop using OpenStep. Would any of you thousand or so > developers out there with existing MacApp applications like to comment on > this? If I recall correctly, part of the reason Copland was taking so long was the effort to maintain API compatability. Staying with MacApp seems like a continuation of that. > >Would a port of MacApp or PowerPlant be likely to make it easier to move an > >application written in one of these frameworks to the new Apple OS? > > I've wondered this myself. MacApp is somewhat better abstracted than > PowerPlant so it would be more straightforward to adapt to a different > API. But I'm not losing much sleep over this matter right now. > > I'm more concerned about the language issue: will we have to switch to > Objective C in order to take full advantage of the new API? If so then I > think we've likely made a really big mistake. The OpenStep API from NeXT is Objective-C based. Sun apparently did it in C++. As to whether it's a mistake, have you used Objective-C? -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: mdros@aol.com (MDROS) Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: 3 Jan 1997 17:57:28 GMT Organization: AOL http://www.aol.com Message-ID: <19970103175500.MAA20412@ladder01.news.aol.com> References: <5aj8p3$rer@boursy.news.erols.com> nExt os IS bsd4.3 UNIX. If you ever worked with pre-solaris Suns, you will feel at home.
From: stes@wolfram.com (David Stes) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 17:07:36 GMT Organization: Wolfram Research, Inc. Distribution: world Message-ID: <5ajeco$dnd@dragonfly.wolfram.com> References: <E3FvoM.Dun@cam-ani.co.uk> Ian Stephenson writes > > A port of MacApp threfore DOESN'T make sense, because the AppKit > provides the same basic functionality, but in a more complete, and > standard way - all NeXT apps (with very few exceptions) use the AppKit. > I think it WOULD (or could) make some sense. You could try to implement MacApp classes in terms of the Appkit, and then that would make it a lot easier to port all the applications that are based upon _MacApp_. Then you don't have to convert the MacApp programs. This makes sense because there's perhaps dozens of MacApps programs, all sharing one common base, so it's useful to port the _base_, instead of converting/modifying/rewriting all the programs. And then _later_ you can start taking advantage of Appkit specifics. And another advantage is that you would have for a while just one set of sources (the MacApp sources) for both MacOS and NextStep. -- David Stes E-mail: stes@wolfram.com
From: Jeff Hoekman <jeffh@dnai.com> Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <32CBD897.5E82@dnai.com> Control: cancel <32CBD897.5E82@dnai.com> Date: Thu, 02 Jan 1997 23:33:01 -0800 Organization: DNAI ( Direct Network Access ) Message-ID: <32CCB628.703E@dnai.com> References: <32CBD897.5E82@dnai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message was cancelled from within Mozilla.
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan3.140054.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> Date: Fri, 3 Jan 1997 19:00:54 GMT In article <32CD3BBF.1750@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: > If I recall correctly, part of the reason Copland's development > was being measured in geologic time was the attempt to maintain > API compatability. Keeping MacApp seems like a continuation of this > effort. If Apple plans to retain the Macintosh look-and-feel, then using MacApp makes sense in order to isolate any changes required by OS enhancements (leaving them inside MacApp). If Apple does not plan to retain the Macintosh look-and-feel, then switching to Delphi would be in order since it already runs on the only platform you will need for the future - MS Windows. Regardless of how good the NeXTstep user interface might be, the consuming public will not stand for having it forced down their throats, and would desert Macintosh in droves if Apple were to insist on changing the interface. That does not say that NeXTstep's UI could not be a "personality" available at end-user option. Larry Kilgallen
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Fri, 03 Jan 1997 14:40:20 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CD60A4.2E59@exnext.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> <1997Jan3.140054.1@eisner> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Larry Kilgallen wrote: > Regardless of how good the NeXTstep user interface might be, > the consuming public will not stand for having it forced down > their throats, and would desert Macintosh in droves if Apple > were to insist on changing the interface. They already have deserted in droves, and it's still the same interface. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
Newsgroups: comp.sys.next.programmer Subject: ncurses Message-ID: <1997Jan3.125029.25890@roper.uwyo.edu> From: nor@panoramix.uwyo.edu (norbert pirzkal) Date: 3 Jan 97 12:50:28 MST Distribution: world Is there a version of ncurses that compiles under NeXTSTEP 3.3/4.0 ??? Where can I get it? Thanks Nor -- Norbert Pirzkal http://faraday.uwyo.edu/grads/npirzkal P.O. Box 3905 Physics & Astronomy Department University Station Laramie, WY, 82071
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan3.154332.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> Date: Fri, 3 Jan 1997 20:43:32 GMT In article <32CD396A.3DC@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: > If they don't use the OpenStep API's, why would they bother buying > NeXT? Memory protection, an OS kernel, scheduling, ... I can think of many components of an operating system which can be well hidden behind a variety of APIs. Also don't forget ... People. Certainly the NeXT folks have been down the design road before and know some of the pitfalls. > If I recall correctly, part of the reason Copland was taking so > long was the effort to maintain API compatability. Staying with > MacApp seems like a continuation of that. The innards of MacApp could be modified to match an arbitrary API which was capable of delivering the same look-and-feel as System 7. An arbitrary API change, however, would decimate the ranks of current non-MacApp developers, which would not be in Apple's best interest (Do I win the understatement award? Do I? Do I?). > As to whether it's a mistake, have you used Objective-C? _Requiring_ any particular language due to OS limitations is a mistake. Let a thousand flowers bloom. Larry Kilgallen
From: rbraver@ohww.norman.ok.us (Robert Braver) Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5ajp8k$i8i@newsfep3.sprintmail.com> Date: 3 Jan 1997 21:44:06 GMT Control: cancel <5ajp8k$i8i@newsfep3.sprintmail.com> Message-ID: <cancel.5ajp8k$i8i@newsfep3.sprintmail.com> Sender: tccs@sprintmail.com Spam cancelled. Autocancel spam type: CDRMEDIA Original Subject: CD-R Media for Sale
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan3.164343.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> <1997Jan3.140054.1@eisner> <32CD60A4.2E59@exnext.com> Date: Fri, 3 Jan 1997 21:43:43 GMT In article <32CD60A4.2E59@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: > Larry Kilgallen wrote: > >> Regardless of how good the NeXTstep user interface might be, >> the consuming public will not stand for having it forced down >> their throats, and would desert Macintosh in droves if Apple >> were to insist on changing the interface. > > They already have deserted in droves, and it's still the > same interface. You, sir, do not have a feel for true _droves_. :-) Actually on balance, I don't think there are statistics to show net defections from Macintosh. Apple has lost plenty of market share on new sales, meaning they are not getting a large piece of new users as they have in the installed base. There are plenty of shock stories such as sombody at NASA ordering wholesale replacement of Macintoshes, but there is less publicity about the subsequent visit from the Inspector General looking into costs :-) Larry Kilgallen
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Fri, 03 Jan 1997 17:06:46 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CD82F6.488@exnext.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Larry Kilgallen wrote: > > In article <32CD396A.3DC@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: > > > If they don't use the OpenStep API's, why would they bother buying > > NeXT? > > Memory protection, an OS kernel, scheduling, ... There's nothing special about NeXT's kernel. They could just as well have used Be, or NuKernal. (In fact, it's not clear they won't.) > I can think of many components of an operating system which can be well > hidden behind a variety of APIs. > > Also don't forget ... People. Certainly the NeXT folks have been down > the design road before and know some of the pitfalls. True. But they could have gotten key people much cheaper than $400 million. > > If I recall correctly, part of the reason Copland was taking so > > long was the effort to maintain API compatability. Staying with > > MacApp seems like a continuation of that. > > The innards of MacApp could be modified to match an arbitrary API > which was capable of delivering the same look-and-feel as System 7. > An arbitrary API change, however, would decimate the ranks of > current non-MacApp developers, which would not be in Apple's best > interest (Do I win the understatement award? Do I? Do I?). > > > As to whether it's a mistake, have you used Objective-C? > > _Requiring_ any particular language due to OS limitations is a > mistake. Let a thousand flowers bloom. It's not an OS limitation. It's an API decision. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: bmunn@lighthouse.com (Beth Munn) Newsgroups: comp.sys.next.programmer Subject: JOB: Lighthouse Design/Sun Microsystems Date: 3 Jan 1997 22:01:20 GMT Organization: Lighthouse Design, a Sun Microsystems business Message-ID: <5ajvjg$d0c@nntp1.best.com> Lighthouse Design (a Sun Microsystems business) 2929 Campus Drive San Mateo, Ca. 94403 415.570.7736 http://www.lighthouse.com Founded in 1989, and acquired by Sun Microsystems in July of 1996, Lighthouse Design is one of the industry's most experienced developers of applications for purely object-oriented environments. Lighthouse offers the exciting and fast paced environment of a small company, while being able to provide "big company" benefits. JavaPlan, the newest product from Lighthouse Design is the industry's first enterprise devlopment platform for the analysis, design, and generation of sophisticated Java applications. Lighthouse is also the premiere provider of productivity applications for the OpenStep and Solaris environments. We are looking for individuals who can demonstrate excellence in Object-OrientedTechnology, GUI Design, Software Engineering Management, and Application Development. Your skills should include: Java, Objective-C, Smalltalk, C++, OpenStep, Solaris, Windows NT, RDBMS, OODBMS, and OO A/D, "off the shelf" application development, The following positions are currently open: JAVA DEVELOPMENT MANAGER APPLICATIONS ENGINEERS JAVAPLAN ENGINEERS SALES ENGINEERS TRAINERS/CURRICULUM DEVELOPERS OPERATIONS MANAGER .....and others!! Lighthouse is a leader in the Object-Oriented software industry, come and work with some of the best people in the business. For more informaiton please contact or send your resume to: Beth Munn 415-570-7736 bmunn@lighthouse.com For other opportunities, please see our web site at: www.lighthouse.com
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 16:31:20 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ajtr8$nha@csugrad.cs.vt.edu> References: <AEEFE2B6-491909@204.246.66.19> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> In article <1997Jan3.154332.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) wrote: > > As to whether it's a mistake, have you used Objective-C? > _Requiring_ any particular language due to OS limitations is a > mistake. Let a thousand flowers bloom. Objective-C isn't required "due to OS limitations". It is required because the OpenStep framework is more powerful with it than it would be with C++. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 23:30:44 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ak4r4$9je@news3.digex.net> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> rsmgm@minyos.its.rmit.EDU.AU (Greg McPherson) wrote: > To me this is a very important question. More important than > the C++ vs Objective C debate going on. > Will I be able to port my MacApp programs to NeXT? If I can't, > and I have to write things from scratch, it will be time to decide > whether or not to move on to the world of Windows. I suspect > many folks will be in a similar position. I heard there were some commercial port utilities comming out. And I certainly understand your concern... One thing I might point out though... That _IF_ apple does the right thing, and lets you develop/design/compile one piece of source code for Apple NewOS/win95/winNT/Solaris then this is still the place to be. Current NeXT development tools allow you to do so, actually to do so for multiple hardware for each of the OS platforms (for Mach OS you can compile to Intel, Sparc, HPPA, and soon PPC, and maybe 040 hardware...)... That kind of single code base/cross development is a powerful reason to use the new development platform... -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 3 Jan 1997 23:32:51 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ak4v3$9je@news3.digex.net> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <5acv9h$qfd@morgoth.sfu.ca> <5adp9n$p84@bias.ipc.uni-tuebingen.de> <simpson-ya023680000301970848570001@xavier.noc.drexel.edu> simpson@post.drexel.edu (Homer Simpson) wrote: > I personally could careless at this point about printing, since > I print fewer than 5 pages of information in a given week. BTW > if PS is so great on NS and PS is used in print houses as the > defacto standard of printing, why is the Mac the perferred > platform? Secondly why are people who are migrating from the Mac > switch to Windows NT or 95 and not NS? I would think that as a > pre-press shop it would make sense to use a tool that works so > well with printing. Price and lack of apps. They'd love the DPS part. Furthermore, b/c YOU personally could care less about printing doesn't change the reality that the Mac's last strong market is the DTP market, which does require printing. -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 3 Jan 1997 23:50:27 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ak603$9je@news3.digex.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> <1997Jan3.140054.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) wrote: > Regardless of how good the NeXTstep user interface might be, the > consuming public will not stand for having it forced down their > throats, and would desert Macintosh in droves if Apple were to > insist on changing the interface. Again and the citation for this absolute truism? It taint necessarily so. Apple was planning on 'shoving' a new UI down the throats of mac users anyway, the only difference is this UI wasn't invented there.... Funny, the company isn't doing the "not invented here" thing anymore. -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: Les Novell <les@datamirage.com> Newsgroups: comp.sys.next.programmer Subject: Where do I start? Date: Fri, 03 Jan 1997 17:26:11 -0500 Organization: DataMirage Software Message-ID: <32CD8783.D2F@datamirage.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, The recent Apple/NeXT merger has been exciting news for myself and other software contractors and small independent software vendors. I have one simple question: Where do I start? I realize that Apple won't have the operating system available until mid-'97 or later. Meanwhile, I would like to get a head-start by installing NeXTStep for Intel on my P166 including the important developer resources. Can anyone tell me which products and documentation to purchase, and possibly estimate cost? I've spent an hour or so browsing NeXT's site, but they don't seem to have a "Getting Started" package for developers. Worse, they don't really explain what developers will need or should have. I called NeXT's customer service and explained that I needed a basic development package, and they recommended I purchase WebObjects 3.0 Enterprise. Funny, I never once told them I needed a package to do client-server web content. Hum... Replies by email, please. Thanks, Les Novell DataMirage Software
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <luomat@peak.org> Message-ID: <199701031437.GAA13384@PEAK.ORG> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Timothy J Luoma <luomat@peak.org> Date: Fri, 3 Jan 97 09:37:38 -0500 Subject: Compiling ZSH QuadFat for NeXTStep Organization: Princeton Theological Seminary I'm rather new at this still, but I'm perplexed by this. I've been able to compile programs quadfat by adding this: CFLAGS = -arch m68k -arch i386 -arch hppa -arch sparc to the Makefile. So I can ./configure on zsh.3.0.2, and the Makefile has CFLAGS = -Wall -Wno-implicit -Wmissing-prototypes -O2 so I change it to CFLAGS = -arch m68k -arch i386 -arch hppa -arch sparc -Wall -Wno-implicit -Wmissing-prototypes -O2 and set 'make' on its merry way The make seems to have exited fine, (make 4238.55s user 324.42s system 88% cpu 1:25:45.59 total) and the .o files are all QuadFat builtin.o hist.o loop.o subst.o zle_main.o zle_vi.o compat.o init.o math.o text.o zle_misc.o zle_word.o cond.o input.o mem.o utils.o zle_move.o exec.o jobs.o params.o watch.o zle_refresh.o glob.o lex.o parse.o zle_bindings.o zle_tricky.o hashtable.o linklist.o signals.o zle_hist.o zle_utils.o but ZSH is not QuadFat, it is only m68k. Does anyone know why this happened and what I can do to get ZSH to compile QuadFat? thanks! TjL -- Tj Luoma (luomat@peak.org) http://www.next.peak.org/~luomat Awaiting Apple's NeXTStep
From: drelson@ic.net (David Relson) Newsgroups: comp.sys.next.programmer Subject: NSThread startup problem Date: Sat, 04 Jan 1997 04:18:56 GMT Organization: ICNET... Your Link To The Internet... +1.313.998.0090 Message-ID: <32cdd943.4845099@news.ic.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit NSThread start problem Using NeXTSTEP 3.3 running on a Pentium, I'm using [ NSThread detachNewThreadSelector:toTarget:withObject: ] to start the threads of a multi-threaded application. Fairly often the application crashes (while starting threads) with the following message: Program generated(1): Memory access exception on address 0x0 (protection failure). 0x50085c9 in NXHashGet () Dumping the stack ( via 'where' ) gives me: #0 0x50085c9 in NXHashGet () #1 0x7826d20 in -[NSPort initWithMachPort:] () #2 0x7833dac in forkFunction () #3 0x5026b09 in cthread_body () I have disassembled initWithMachPort: enough to know that it uses two instances variables - the first (at location 0x4700d20) is a lock and the second (at 0x4 700d24) is the address of the hash table (sent as the first argument to NXHashGet()). Looking at these two locations ( via 'x/2x 0x04700d20' ) gives me: 0x4700d20 <_NSGlobalRetainLock+60>: 0x00000000 0x00203810 Some debugging tests indicate that the hash table address is 0x0 when it fails and is not 0x0 when startup succeeds. The same tests show that the lock is always 0x0. Anybody know what's going on here? My guess is that I need to send a special message to get the lock to be initial ized. Anybody know what that message is? Please respond via e-mail. Thanks. David David Relson relson@laa.com Lynn-Arthur Associates 313-995-5590 Ann Arbor, MI
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 3 Jan 1997 21:42:11 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF330C7-12D6B@198.68.42.190> References: <5ak4v3$9je@news3.digex.net> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John Kheit <jkheit@cnj.digex.net> said: >Price and lack of apps. They'd love the DPS part. Furthermore, >b/c YOU personally could care less about printing doesn't change >the reality that the Mac's last strong market is the DTP market, >which does require printing. Actually, the Mac's market is all over the place: education, DTP, multi-media publishing, home... The only one for which DPS important is DTP. This might sell high-end, high-margin machines, but GX is a much better deal for multi-media and so on. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan3.235329.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> <1997Jan3.140054.1@eisner> <5ak603$9je@news3.digex.net> Date: Sat, 4 Jan 1997 04:53:29 GMT In article <5ak603$9je@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> writes: > kilgallen@eisner.decus.org (Larry Kilgallen) wrote: >> Regardless of how good the NeXTstep user interface might be, the >> consuming public will not stand for having it forced down their >> throats, and would desert Macintosh in droves if Apple were to >> insist on changing the interface. > > Again and the citation for this absolute truism? It taint > necessarily so. Apple was planning on 'shoving' a new UI down the > throats of mac users anyway, the only difference is this UI wasn't > invented there.... Funny, the company isn't doing the "not invented > here" thing anymore. No, the announced Apple plan was to allow various personalities to the UI, one of which would be the current one. Having another one be NeXTstep is fine too. I have no inner need to force some interface that I like onto someone else who has something they already like. Larry Kilgallen writing this in TECO on VMS -- VTEDIT is for wimps :-)
From: rex@mit.edu (Eric King) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 04:10:24 -0500 Organization: Netcom Message-ID: <rex-ya023080000401970410240001@nntp.ix.netcom.com> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5abtee$mk9@news4.digex.net> <cwood41-ya023080000201970139130001@news.caps.maine.edu> <5ag0ln$a2r@news4.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5ag0ln$a2r@news4.digex.net>, jkheit@cnj.digex.net wrote: )Yes, I think this is reasonably doable... Put much of the GX api )in a framework for OpenStep and have DPS do the basic drawing... )Likely the quickest way to go... Either you have interesting definitions for 'reasonably' and 'quickest' or you *really* don't have a concept of just how complex GX is. I mentioned it before but really all Apple has to do initially is let one assign a GX viewport to an OpenStep window or view object. This is *NOT* hard. All GX Graphics needs is a buffer to draw in and some clipping/obscuration info, that's *it*. Since the printing architecture would no longer need to patch the OS to work (The source of 'its' instabilities), all it needs are access to a serial or ethernet port. It doesn't have to interact with DPS or the OpenStep print system at all, it'd just be another background process running like the GX Graphics library. In addition by allowing a GX Viewport to be assigned to an OpenStep window Apple immediately has a convenient and safe place for Quickdraw 3D to render, i.e. one of the options for specifying a rendering location in QD 3D right *now* is a GX viewport. Furthermore Apple's going to have to figure out a good and fast way of drawing directly to the screen in the new OS for Quicktime. It might be a wise idea to just make all of QTML use GX viewports for rendering in the new OS. That way Apple only has to worry about integrating one piece of technology with the OpenStep windowing system. (and even then it doesn't need to do much) It also requires the least amount of change for all of the technology involved and developers could start moving their QTML code over right now and even retain *some* common source code across platforms. All together this would probably take around an order of magnitude less time to accomplish than reproducing GX's functionality in OpenStep. It'd also be much faster and more efficient plus DPS would still work as it does now. As for the new Mac-style GUI elements Apple would probably be wise to choose GX to render them because GX has some very powerful functions in it that are just made for widget implementation. (Also I doubt DPS or any other imaging system is used to print out scrollbars and buttons very often) GXHitTestPicture for instance which not only tells you which picture shape was hit but which sub-picture shapes or other types shapes of shapes were hit to a specified level or depth, further it tells you what parts of the geometry of those shapes were hit and where in those parts they were hit. You can even adjust the tolerance so that the user only has to click near something. Just the kind of things you need to *constantly* do in writing a GUI widget. This one function has personally saved me hundreds of hours of work. (If you want to get really sneaky you store a reference to the actual object that shape represents in a tag object for that shape, thus cutting out the need for a complex dispatch. :) Been doing that in my Prograph app's GUI, makes creating new kinds of interface elements a *lot* easier.) There are a some other things that are very handy for GUI implementation but I'm rather curious about how the Appkit analog to all of this works. (I'm assuming that since DPS is not object-oriented that hit-testing is carried out by the AppKit.) How does one tell which shape was hit and where in the collection of PS calls and entities that define a GUI widget's geometry? Is there a hierarchical shape storage and hit-testing system? How much info does it give during a hit-test? -Eric -- )>GX Enthusiast and 3D Programmer.
From: rex@mit.edu (Eric King) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 06:15:07 -0500 Organization: Netcom Message-ID: <rex-ya023080000401970615070001@nntp.ix.netcom.com> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5a9jba$mk0$1@news.cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5a9jba$mk0$1@news.cs.tu-berlin.de>, marcel@cs.tu-berlin.de (Marcel Weiher) wrote: )Hmm...I am probably being totally moronic here, but converting )between different graphics formats usually involves a lot more )than just fixed/floating point conversions. Not doing any )conversion at all will always be the optimum for maintaining )fidelity, no matter what. True, but DPS is a superset of PS Level 2 and no one has PS Level 3 printers yet. So it's transparency and compositing functions won't get rendered if sent, i.e. it needs a non-trivial translation. One that GX does automatically. )Also, fixed number formats start running into problems when you )have (a) applications that scale the coordinate system to have )convenient units and All problems are easily overcome because GX primitives are objects with persistent data about their state. GX picture shapes, mapping properties and transform objects can handle all of the necessary scalings and transformations automatically. It's an extra step for the developer but a small one. I suppose the easiest way would be to encapsulate the very large or very small entity in a picture shape. (Not a bad idea anyway, it offers a lot of flexibility) Once there the entity's private transform object would scale the shape to its needed precision and the picture shape's transform object would scale it back to actual size. All told two function calls: GXScaleShape(), and surprise GXScaleShape() :) Because the transform objects are intrinsically bound to the two shapes, these calls only need to be made once. When converting to Postscript GX will combine the transforms and make the appropriate scaling and conversions into floating point. This is not rocket science folks... Incidentally GX provides a pretty extensive fixed-point math library with support for 64bit (32.32), 32bit (16.16), 32bit (32.0) and 32bit (0.32) formats. )(b) documents with scaled coordinates are )nested. Let's face it, any fixed limit is one someone will )run into, someday (can you say 'millenium bug'?). Can you say inefficiency for 99.99% of a user's work. Screen devices only accept integer coordinates. On a PPC it takes ~7 cycles to convert a float to an int. (This *must* be done to draw to the screen) To convert from a fixed to an int takes 1. To scale a fixed to any needed precision takes 1 cycle. It'll really be interesting to benchmark DPS vs. GX on the new OS. From my limited explorations with Acrobat PDFs, GX renders them faster (after conversion) than Acrobat does. -Eric -- )>GX Enthusiast and 3D Programmer.
From: gherman@NMR.EMBL-Heidelberg.DE (Dinu Gherman) Newsgroups: comp.sys.next.programmer Subject: Re: Python for NS.4.x Date: 4 Jan 1997 15:51:05 GMT Organization: EMBL Heidelberg Distribution: world Message-ID: <5alu99$p80@lion.embl-heidelberg.de> References: <5agtib$n3b@concorde.ctp.com> In article <5agtib$n3b@concorde.ctp.com> "Georg Tuparev" <gtupar@ctp.com> writes: > > Does anybody already compiled Python 1.4 on NS 4.x? Seems like people are eventually using good stuff at your place ;-) Well, if you don't need absolutely a 4.x compile, you can download python-1.4.NIHS.b.tar.gz for NS 3.3 from ftp.nmr.embl-heidelberg.de in /pub/next/submissions/ Maybe it will make its way sometime from there to /pub/next/Developer/Languages ... I guess it works w/ no headaches on 4.x systems. I am using it only casually on 4.0, but I cannot report any problems so far. -- Dinu C. Gherman mailto:gherman@embl-heidelberg.de voice:49.6221.387-456 fax:49.6221.387-517 http://www.nmr.embl-heidelberg.de/gherman/ EMBL http://www.embl-heidelberg.de/ Heidelberg http://www.germany.eu.net/shop/Heidelberg.info.cvb/ ---
From: mmunz@inconnect.com (Mark Munz) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 4 Jan 1997 16:40:49 GMT Organization: Puppy Dog Software Message-ID: <mmunz-0401970934100001@slc-dial-45.inconnect.com> References: <5ak4v3$9je@news3.digex.net> <AEF330C7-12D6B@198.68.42.190> In article <AEF330C7-12D6B@198.68.42.190>, "Lawson English" <english@primenet.com> wrote: >Actually, the Mac's market is all over the place: education, DTP, >multi-media publishing, home... > >The only one for which DPS important is DTP. This might sell high-end, >high-margin machines, but GX is a much better deal for multi-media and so >on. The Macintosh market is everywhere - education & home are big markets that continue to grow at a higher rate than DTP. To stay competitive with Microsquish, they have to make their machines/software as affordable as possible. NextStep sold/is selling for some $800 a copy. That's OK for corporate markets, but end users would never pay this. You can assume that part of that price is due to DPS royalties. That means there is a good financial reason not to use DPS (Apple needs to do everything it can to reduce the price of NextStep). Add that to some of the cool technological things GX has and you have a good argument for GX over DPS. Just my two cents. Mark Munz
From: chrisf@chesapeake.net (CF Publishing) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.nsc.32k,comp.sys.palmtops,comp.sys.powerpc.advocacy,comp.sys.powerpc.misc,comp.sys.powerpc.tech,comp.sys.psion.misc,comp.sys.sgi.admin,comp.sys.sinclair,comp.sys.sun.admin,comp.sys.sun.hardware,comp.text.tex,comp.unix.admin,comp.unix.advocacy,comp.unix.aix Subject: We Create Web Pages! Date: 4 Jan 1997 18:30:51 GMT Organization: CF Publishing Message-ID: <5am7kr$drl@tommy.chesapeake.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII Do you or your company want to be seen by millions of people via the Internet but not have the ability to accomplish this by yourself? A lot of people have this yearn, but do not have the means of achieving this. The solution to this problem is simple. I will publish your web page for you, and put it up on a web server of your choice. There, with proper advertising, it can be seen by millions! Your page will be complete with graphics, frames, and the text that you want. All you need to do is send me the ideas you have for your page, any text you would like to see there, and I will create it for a minimal fee. This is a great way of letting your friends and family worldwide keep in touch with you, or let your business be seen! Many businesses have pamphlets or brochures that they create to keep their customers informed. With your own web page, we can publish your pamphlets or brochures online so your customers can view them with ease. We can even set up forms to allow them to mail in their orders securely! We guarantee that our pages that we create will please you, and if they do not, there is no charge to you. Our guarantee can not be beat. We will publish your pages for you, and them show them to you for your approval. You may then suggest any changes that you wish to be made. If these changes do not make you absolutely happy, you will not be billed for our services. We do not want our customers to be unhappy with any of our services, so we will continue to make changes to keep the pages we create closest to the pages you originally showed us. Our prices for web publishing can not be beat. We will beat any other written estimate you may have. If you are interested in any of our services, simple email us at chrisf@chesapeake.net, or call us at (301) 855-9902. Thank you for your interest in our services.
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 14:25:41 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CEAEB5.3BA@exnext.com.nonsense> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5a9jba$mk0$1@news.cs.tu-berlin.de> <rex-ya023080000401970615070001@nntp.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Eric King wrote: > > In article <5a9jba$mk0$1@news.cs.tu-berlin.de>, marcel@cs.tu-berlin.de > (Marcel Weiher) wrote: > > )Hmm...I am probably being totally moronic here, but converting > )between different graphics formats usually involves a lot more > )than just fixed/floating point conversions. Not doing any > )conversion at all will always be the optimum for maintaining > )fidelity, no matter what. > > True, but DPS is a superset of PS Level 2 and no one has PS Level 3 > printers yet. So it's transparency and compositing functions won't get > rendered if sent, i.e. it needs a non-trivial translation. One that GX does > automatically. You can't say for certain that this functionality will require a PS Level 3 printer. Level 3 may well handle printing transparency to Level 2 printers. Then again, if you print from a DPS box to a non-postscript printer, the issue's moot, since the DPS will handle it. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 14:28:36 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CEAF64.7F39@exnext.com.nonsense> References: <5ak4v3$9je@news3.digex.net> <AEF330C7-12D6B@198.68.42.190> <mmunz-0401970934100001@slc-dial-45.inconnect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Munz wrote: > > In article <AEF330C7-12D6B@198.68.42.190>, "Lawson English" > <english@primenet.com> wrote: > > >Actually, the Mac's market is all over the place: education, DTP, > >multi-media publishing, home... > > > >The only one for which DPS important is DTP. This might sell high-end, > >high-margin machines, but GX is a much better deal for multi-media and so > >on. > > The Macintosh market is everywhere - education & home are big markets that > continue to grow at a higher rate than DTP. To stay competitive with > Microsquish, they have to make their machines/software as affordable as > possible. Education and home might be big growing markets, but they're not growing with the Macintosh. The Mac simply doesn't have a compelling advantage over Win95. Right or wrong, that's the way people are voting with their dollars. > NextStep sold/is selling for some $800 a copy. That's OK for corporate > markets, but end users would never pay this. You can assume that part of > that price is due to DPS royalties. That means there is a good financial > reason not to use DPS (Apple needs to do everything it can to reduce the > price of NextStep). Add that to some of the cool technological things GX > has and you have a good argument for GX over DPS. The academic discount price for NeXTSTEP is $295. The DPS license is not a big deal. Add in the time required to replace DPS with GX, and you've got a good argument for DPS over GX. Apple has money. They don't have time. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: PROPOSAL: how to implement Mac in Nextstep Date: 4 Jan 1997 21:32:21 GMT Organization: Vienna University of Technology, Austria Message-ID: <5ami95$ol3@news.tuwien.ac.at> PROPOSAL: How to implement resource forks, file types, and file creators in NeXTstep so that the user interface works like the Macintosh. Currently Nextstep uses the 'wrapper' to get the same (and more) functionality than the resource fork of the Macintosh. A wrapper is a directory that contains multiple files that are never visible to the normal user. Only if a user really wants to see these files he can open the wrapper as a directory using a special command from the Workspace (aka Finder). The Workspace recognizes a wrapper by its extension, i.e by the text behind the last '.' in the filename. Other than both WinNT and Win95, the mapping from file extension to file type is done automatically by the Workspace, based on all the applications present in the system (or at least in the Workspace launch paths). These mappings are regenerated each time a user logs in. The Workspace also associates a default application with each file type. This default can be set by the user, and can be overridden when opening a file; it is not stored with the file, but in the *per user* mapping data base of the Workspace. In order to make current Macintosh files work on the Next Apple OS, it is therefore necessary to map each Mac file into a directory containing the data and resource forks as seperate files. This directory can be made to have the original Macintosh file type field as extension, thus making it recognizable for the workspace. For some filetypes, however, this is not the desired behaviour. Tiff-files, Gif-files, C-sources, aso. are filetypes which are frequently accessed by standard UNIX tools (and other powerful UNIX applications like for instance a WWW-server). These tools would cease to work when presented with directories instead of files. For this reason the mapping database of the Workspace could be extended to know about the nature of these files, and not map them to directories if macintosh disks are mounted. The only drawback to this approach is, that the resource fork of these files is lost. We think this is acceptable, since the usability of these filetypes does normally not depend on the presence of the resource fork. The majority of file types of "big" productivity applications are mapped as wrappers and will retain all their information (e.g. ".photoshop", ".pagemaker", ".freehand", will all be extensions of directories containing a resource fork, a data fork, and maybe even additional files). The icons that are displayed by the Next Finder will be primarily derived from the file type. Each application that accepts a file type provides a common icon for all files of that type. The icon displayed by the Next Finder, is the one of that application that is designated to open it. In order to facilitate the Macintosh functionality of custom icons for each file of a specific type, it is possible to put an icon into the wrapper of the file in question. This overrides the default icon. Currently the Nextstep GUI exposes the file extension (aka file type) to the user. It would not be very difficult to add a switch to the (user specific) system preferences that hides them from view for consistency with the current Macintosh user interface. Apart from the file type there is another field present in each Macintosh file: the Creator code. While the original meaning was literal, it now encodes the preferred application with which to open the file in question. While on a single user machine, like the macintosh, this can be stored directly with the file, we think that in a multiuser environment like the Next Apple OS, this is a user specific feature. For this reason the Creator code should be stored in a *per user* data base that associates the preferred application with each file for which the user would like to override his personal default for that file type. This makes it possible for multiple users to access the same file, and still use different default applications and/or preferred applications on that file. This data base is stored on a per volume and per user basis, such that the associations are kept when the user copies a file to a different volume (the only application that needs to maintain the database is the Next Finder, thus the functionality is nicely concentrated). For diehard CLI fanatics it is possible to provide an "Apple" command line copy/move that maintains the associations when moving/copying a file (a-mv, a-cp, a-rm that could even be aliased if desired). We think that these proposals will maintain most of the macintosh functionality while preserving the clean Nextstep implementation of these features. Comments are welcome. Robert F. Tobler & Alexander Wilkie ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
From: piercej@m4.sprynet.com Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sat, 04 Jan 1997 17:11:10 +0000 Organization: Sprynet News Service Message-ID: <32CE8F2E.1A12@m4.sprynet.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: jonathan_pierce@seagram.com John Kheit wrote: >>That _IF_ apple does the right thing, and lets you >>develop/design/compile one piece of source code for Apple >>NewOS/win95/winNT/Solaris then this is still the place to be. I agree. >>Current NeXT development tools allow you to do so, actually to do >>so for multiple hardware for each of the OS platforms (for Mach OS >>you can compile to Intel, Sparc, HPPA, and soon PPC, and maybe 040 >>hardware...)... That kind of single code base/cross development >>is a powerful reason to use the new development platform... Code developed using the NEXT development tools and frameworks is still OS dependant. Like the Next development tools, the Metrowerks tools allow you to compile a single code base and target multiple processors (68K, PPC, x86). This does not eliminate the need for an OS-independant cross-platform framework. -Jonathan
From: news@cmc.net Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.nsc.32k,comp.sys.palmtops,comp.sys.powerpc.advocacy,comp.sys.powerpc.misc,comp.sys.powerpc.tech,comp.sys.psion.misc,comp.sys.sgi.admin,comp.sys.sinclair,comp.sys.sun.admin,comp.sys.sun.hardware,comp.text.tex,comp.unix.admin,comp.unix.advocacy,comp.unix.aix Subject: cmsg cancel <5am7kr$drl@tommy.chesapeake.net> Date: 4 Jan 1997 22:26:35 GMT Control: cancel <5am7kr$drl@tommy.chesapeake.net> Message-ID: <cancel.5am7kr$drl@tommy.chesapeake.net> Sender: chrisf@chesapeake.net (CF Publishing) Spam cancelled by news@cmc.net
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 4 Jan 1997 22:28:18 GMT Organization: Vienna University of Technology, Austria Message-ID: <5amli2$ol3@news.tuwien.ac.at> PROPOSAL: How to modify the Workspace manager to behave like the Finder Currently the Nextstep Workspace manager presents one or more windows called "File Viewers" to the user, that consist of three parts: * The shelf: This is a place to store commonly accessed files and directories in a way similar to aliases on the Desktop of the Macintosh. * The icon path: This displays the location of the selected file by showing the complete path from the root of the main disk to the file, in the form of an icon sequence containing each directory. * The browser: This part of the viewer can be used in three different modes, one of them is the mode which shoes the contents of each directory in the icon path as a column, the second one shows the icon of each file in the current directory, and the third one shows a list of all files in the current directory with all the additional fields like owner, creation date, aso. Double-clicking a directory will show the directory in the current file viewer without opening a new window. The Workspace manager supports the functionality of opening a directory in a new file viewer window, if the user wants it (using a Menu, a command shortcut Cmd-Shift-O, or Alt-Double-Click). It also stores the mode of the browser in each directory that was opend with its own file viewer window. In order to change the Workspace manager to behave like the finder, a small number of changes are necessary: * Make it possible for a file viewer to contain only the shelf, or only the browser. This should be user selectable. * Add to the icon mode of the browser, the functionality to (optionally) store the location of each icon in each directory. * Add the option to always create a new "File Viewer" window for each directory that is double-clicked. * Add to the shelf the functionality of arbitrary icon placement; currently icons can only be placed in a grid. Using these three features, the Next Finder can be implemented this way: * Make a shelf-only window that has the size of the screen and resides below all other windows. This will be the Next Apple Desktop. * Set the defaults of the Next Finder to always create a new "Viewer" at each double click, and to be in icon mode per default. Using these defaults there are some differences to the original Macintosh Finder, e.g. the Desktop contains only "aliases", never real files. But I think the overall user expierence in such a customizable Next Finder, could be made very close to the current Finder, so that Macintosh users will still be able to efficiently use the Next Apple OS with only *very little* changes to their accusomed habits. This proposal makes the user interface changes from the current Finder to the Next Findersmall enough to be even less than the changes made from system 6.x to system 7.0. The proposed changes in the implementation of the Workspace manager are small enough to be finished and tested even within the timeframe for the first Developer release, so if Apple/Next chooses, they can cater to the current Apple customers even in the very first release of the Next Apple OS. Comments are welcome. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system From: dnelson@netcom.com (Nelson ) Subject: Re: PROPOSAL: how to implement Mac in Nextstep Message-ID: <dnelsonE3I984.CEp@netcom.com> Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <5ami95$ol3@news.tuwien.ac.at> Date: Sat, 4 Jan 1997 22:31:16 GMT Sender: dnelson@netcom7.netcom.com How about just emulate the Mac and convert apps to Objective-C and Openstep.
From: John 'kzin' Rudd <jrudd@cygnus.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sat, 04 Jan 1997 22:29:10 -0800 Organization: Cygnus Solutions Inc. Message-ID: <32CF4A36.28A1@cygnus.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit piercej@m4.sprynet.com wrote: > > John Kheit wrote: > > >>That _IF_ apple does the right thing, and lets you > >>develop/design/compile one piece of source code for Apple > >>NewOS/win95/winNT/Solaris then this is still the place to be. > > I agree. > > >>Current NeXT development tools allow you to do so, actually to do > >>so for multiple hardware for each of the OS platforms (for Mach OS > >>you can compile to Intel, Sparc, HPPA, and soon PPC, and maybe 040 > >>hardware...)... That kind of single code base/cross development > >>is a powerful reason to use the new development platform... > > Code developed using the NEXT development tools and frameworks is still > OS dependant. > > Like the Next development tools, the Metrowerks tools allow you to > compile a single code base and target multiple processors (68K, PPC, > x86). > > This does not eliminate the need for an OS-independant cross-platform > framework. > > -Jonathan Which is what Openstep is. Writing code for Openstep for Mach, as long as you stay within the Openstep frameworks, is portable to Openstep for NT. It should also be portable to Openstep for Solaris. There is soon to also be an Openstep for Win95. There was an announcement at one time that there would be an Openstep for Digital Unix, as well. There is a subset of Openstep on HP/UX (everything except the GUI frameworks) from what I've read. All of these Openstep are supposed to be 100% source code compatable. Asside from the HP/UX, Digital Unix, and Solaris ports (which were done by the native OS company, and not NeXT) I'm quite sure it's true. So, once there is a PPC version of Nextstep/Openstep-for-Mach that is "the new Apple OS", you'll be able to use NeXT's tools to write a completely functional GUI application that will work/run on all of the Nextstep/Openstep-for-Mach hardware platforms, Windows NT, and Windows 95. One code base for Mac and Wintel and probably a few of the more popular Unices.
From: John 'kzin' Rudd <jrudd@cygnus.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: Sat, 04 Jan 1997 22:38:46 -0800 Organization: Cygnus Solutions Inc. Message-ID: <32CF4C76.1EBF@cygnus.com> References: <5amli2$ol3@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert F Tobler wrote: > > * Add to the shelf the functionality of arbitrary icon placement; > currently icons can only be placed in a grid. > > > * Make a shelf-only window that has the size of the screen and resides > below all other windows. This will be the Next Apple Desktop. > This is sort of what Fiend.app's Shelf is. It's a next desktop where you can put any file (application, folder/directory, other files, etc). You can choose whether to have it snap to a grid or not. Fiend also allows you to set a background image, handles the standard nextstep screen saver modules (backspace.app is the original 'standard' for this.. and is included as a free demo from NeXT), and create a virtual dock that can be anywhere on the screen and more than just a vertical collumn of icons. If you were to close the File Viewer shelf, and just use Fiend's desktop Shelf, you'd already have this "apple like desktop". :-) Or you can have both shelves by keeping the File Viewer shelf open.
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 4 Jan 1997 23:05:46 GMT Organization: Vienna University of Technology, Austria Message-ID: <5amnoa$ol3@news.tuwien.ac.at> References: <5amli2$ol3@news.tuwien.ac.at> <32CF4C76.1EBF@cygnus.com> John 'kzin' Rudd <jrudd@cygnus.com> wrote: > > > > * Make a shelf-only window that has the size of the screen and > > resides below all other windows. This will be the Next Apple > > Desktop. > > > > This is sort of what Fiend.app's Shelf is. It's a next desktop where > you can put any file (application, folder/directory, other files, etc). > You can choose whether to have it snap to a grid or not. I know about Fiend, but this *needs* to be in the Next Finder, and be the default setup, in order to cater to current Macintosh users. Shareware programs that provide the same functionality are not enough, since they will not be available on preinstalled systems, and only a fraction of the total user base knows about them. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
From: marke@nwlink.com (Mark Eaton) Newsgroups: comp.sys.next.programmer Subject: Re: Speculation about OS/NT's future, anyone? Date: Sat, 04 Jan 1997 15:30:49 -0800 Organization: Northwest Link Message-ID: <marke-0401971530490001@ip029.mu3.nwlink.com> References: <59p564$o2l@sjx-ixn9.ix.netcom.com> <1996Dec26.004354.2389@seer.demon.co.uk> In article <1996Dec26.004354.2389@seer.demon.co.uk>, Paul_Lynch@griffin.plsys.co.uk wrote: > In article <59p564$o2l@sjx-ixn9.ix.netcom.com> aisbell@ix.netcom.com (Art > Isbell) writes: > > > It seems that Mac developers would like to be able to develop Mac > > software using OPENSTEP that is nearly 100% source-code compatible with > the > > Windows version of the same software. Just think of the increased > market > > without much additional effort. Seems like a big win to me. > > > > > The NeXT/Apple thing brings something to either parties that each > other > > > need: Hardware to NeXT, software to Apple. Whatever concerns Intel > boxes > > > isn't of Apple's concerns. > > FWIW, I endorse Art's opinions. It seems to me that some of the > statements from Ellen Hancock would seem to back this up. If Apple can > persuade developers (even if only vertical market developers) to write for > OpenStep for portability reasons, then this is a powerful attractant to > support third party applications on (the future) MacOS. The MacApp team have been rumbling for a couple years about a Windows version of MacApp. There is actually some demand for this. OpenStep would be an even better solution. -Mark -- ---> marke@nwlink.com
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sat, 04 Jan 1997 18:43:20 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CEEB18.16A7@exnext.com.nonsense> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit piercej@m4.sprynet.com wrote: > > John Kheit wrote: > > >>That _IF_ apple does the right thing, and lets you > >>develop/design/compile one piece of source code for Apple > >>NewOS/win95/winNT/Solaris then this is still the place to be. > > I agree. > > >>Current NeXT development tools allow you to do so, actually to do > >>so for multiple hardware for each of the OS platforms (for Mach OS > >>you can compile to Intel, Sparc, HPPA, and soon PPC, and maybe 040 > >>hardware...)... That kind of single code base/cross development > >>is a powerful reason to use the new development platform... > > Code developed using the NEXT development tools and frameworks is still > OS dependant. Only if you write OS-dependant code. The Openstep framework should allow a very high level of OS-independant coding. > Like the Next development tools, the Metrowerks tools allow you to > compile a single code base and target multiple processors (68K, PPC, > x86). > > This does not eliminate the need for an OS-independant cross-platform > framework. The openstep framework is what you want. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: marke@nwlink.com (Mark Eaton) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sat, 04 Jan 1997 15:44:05 -0800 Organization: Northwest Link Distribution: world Message-ID: <marke-0401971544050001@ip029.mu3.nwlink.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> In article <5ajc89$r1s@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: > I can think of about a thousand reasons why it would make sense to retain > MacApp for many years even if Apple were to decide that a switch to > OpenStep was warranted and new developers were to be encouraged (or even > required) to develop using OpenStep. Would any of you thousand or so > developers out there with existing MacApp applications like to comment on > this? Hi Mike! It's good to see you in the NeXT programming group. I would like to see my MacApp apps easily moved to OpenStep. I think it would be ideal if, where MacApp and OpenStep overlap, MacApp simply provide a thin layer between my code and OpenStep. But where MacApp provides richer functionality, as in the case of TDocument, the MacApp manage things under OpenStep. However, I would rather Apple encouraged developers to do _new_ projects in the native OpenStep framework. Make it richer where necessary, but more importantly make it _simple_ for OpenStep developers to deploy on W95/NT. > I'm more concerned about the language issue: will we have to switch to > Objective C in order to take full advantage of the new API? If so then I > think we've likely made a really big mistake. I'm not so concerned about this. NeXT development already includes the capability to mix ObjC and C++. And Metrowerks is promising C++ compilers that target the ObjC dynamic runtime. Thanks for participating, Mike. -Mark -- ---> marke@nwlink.com
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 4 Jan 1997 17:11:02 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF442C2-706D3@198.68.42.158> References: <32CEAF64.7F39@exnext.com.nonsense> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jonathan W. Hendry <jon@exnext.com.nonsense> said: >Education and home might be big growing markets, but they're not >growing with the Macintosh. The Mac simply doesn't have a >compelling advantage over Win95. Right or wrong, that's the >way people are voting with their dollars. Funny, I could swear that the K-12 marketshare for the Mac was bigger in 196 than it was in 1995... Sold more units, too! And Wind95's compelling advantage over the Mac boils down to marketing: MS has spent more money promoting Wind95, than Apple has spent acquiring NeXT. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 4 Jan 1997 17:29:01 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF446E1-7FE87@198.68.42.183> References: <32CEAF64.7F39@exnext.com.nonsense> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jonathan W. Hendry <jon@exnext.com.nonsense> said: >The academic discount price for NeXTSTEP is $295. The DPS license >is not a big deal. > Typical markup rule-of-thumb is that you charge the customer 3x what you paid for something. If the DPS license costs $10, that adds $30 to the standard price. Hardly peanuts when Apple sells System 7.5.5 for $99. >Add in the time required to replace DPS with GX, and you've >got a good argument for DPS over GX. Apple has money. They >don't have time. Time to replace DPS with GX is a confusing issue: *Do you mean, replace the DPS engine with the GX engine at the fundamental level? That would break all existing apps. *Do you mean create a GhostScript server that would use GX for its primitive graphics engine? That would be very slow until a LOT of optimizations were done. *Do you mean replace the DPS calls for the OpenStep GUI with GX calls? That would take time to do properly, but would almost certainly result in a significant speedup for drawing of windows, etc. It would also give the UI designers a much speedier and more flexable library to deal with when designing new/different interface elements. *Do you mean replace DPS with GX as the graphics library of choice? That would happen for most Macintosh-oriented applications as soon as GX became available. I'm pretty sure that most NeXT applications programmers would prefer to deal with GX, also. The underlying design of GX is a better fit for most kinds of non-DTP applications. While DTP systems are very lucrative PER UNIT, Apple makes more money total off of high-end home and education systems, and GX provides a much better graphics model (with a more convenient printing model) for this market than DPS does. I mean, how well does DPS support animation, not by using dedicated graphics routines working with bitmaps or the screen directly, but by using the standard DPS calls to do all drawing, with or without blitting? GX will handle a reasonably wide range of animation needs due to its more efficient nature, and applications like PaceWorks' Object Dancer can render GX text directly into QuickTime movies *as* GX calls, and not just as bitmaps, and you get a decent playback speed. It is such an obvious thing to do that I wonder: has anyone ever created a NeXTtime CODEC for DPS? What is the playback frame-rate on specific machines for simple text animation? Any numbers available? Any dedicated text animation apps out there for DPS? --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 19:42:40 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CEF900.200@exnext.com.nonsense> References: <32CEAF64.7F39@exnext.com.nonsense> <AEF442C2-706D3@198.68.42.158> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawson English wrote: > > Jonathan W. Hendry <jon@exnext.com.nonsense> said: > > >Education and home might be big growing markets, but they're not > >growing with the Macintosh. The Mac simply doesn't have a > >compelling advantage over Win95. Right or wrong, that's the > >way people are voting with their dollars. > > Funny, I could swear that the K-12 marketshare for the Mac was bigger in > 196 than it was in 1995... Sold more units, too! And the home market? > And Wind95's compelling advantage over the Mac boils down to marketing: MS > has spent more money promoting Wind95, than Apple has spent acquiring NeXT. This is true. But the end result is the same. Home computer buyers are buying PC's. Their partially marketing generated perception is that the Mac and Windows are essentially the same. Then their kids see all the PC games, and they buy a PC. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 19:45:31 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CEF9AB.54A9@exnext.com.nonsense> References: <32CEAF64.7F39@exnext.com.nonsense> <AEF446E1-7FE87@198.68.42.183> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawson English wrote: > > Jonathan W. Hendry <jon@exnext.com.nonsense> said: > > >The academic discount price for NeXTSTEP is $295. The DPS license > >is not a big deal. > > > > Typical markup rule-of-thumb is that you charge the customer 3x what you > paid for something. If the DPS license costs $10, that adds $30 to the > standard price. Hardly peanuts when Apple sells System 7.5.5 for $99. Maybe so, but the Mac market is far larger than the NeXTSTEP market. Adobe can charge less per unit but make far more in total. It's also very much to their advantage to make sure it's cheap. > >Add in the time required to replace DPS with GX, and you've > >got a good argument for DPS over GX. Apple has money. They > >don't have time. > > Time to replace DPS with GX is a confusing issue: The person I responded to felt DPS should be replaced by GX. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.nsc.32k,comp.sys.palmtops,comp.sys.powerpc.advocacy,comp.sys.powerpc.misc,comp.sys.powerpc.tech,comp.sys.psion.misc,comp.sys.sgi.admin,comp.sys.sinclair,comp.sys.sun.admin,comp.sys.sun.hardware,comp.text.tex,comp.unix.admin,comp.unix.advocacy,comp.unix.aix Subject: Re: We Create Web Pages! Date: 4 Jan 1997 14:43:17 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.852417619@idiom.com> References: <5am7kr$drl@tommy.chesapeake.net> chrisf@chesapeake.net (CF Publishing) writes: [most of the spammer's ad deleted] >estimate you may have. If you are interested in any of our services, simple >email us at chrisf@chesapeake.net, or call us at (301) 855-9902. Guys, this is a rare chance to slam a spammer but good. I just tried the number above, and it's live. It appears to be his home number. Call him up, and tell him why it's wrong to spam usenet newsgroups!!! >Thank you for your interest in our services. Yeah, good luck getting a clue, dipshit. -jcr
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 5 Jan 1997 01:19:22 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5amviq$cgd@brachio.zrz.TU-Berlin.DE> References: <AEF446E1-7FE87@198.68.42.183> In article <AEF446E1-7FE87@198.68.42.183> "Lawson English" <english@primenet.com> writes: > GX will handle a reasonably wide range of animation needs due to its more > efficient nature, and applications like PaceWorks' Object Dancer can > render GX text directly into QuickTime movies *as* GX calls, and not just > as bitmaps, and you get a decent playback speed. > > It is such an obvious thing to do that I wonder: has anyone ever created a > NeXTtime CODEC for DPS? What is the playback frame-rate on specific > machines for simple text animation? Any numbers available? Any dedicated > text animation apps out there for DPS? Well, finally someone whose memory is almost as bad as mine. Last time I mentioned the little real-time text-scaling app you were impressed... There are also various screen savers and 3D games that not only work but even work while multitasking. On an 040 cube. Marcel
From: jlarsson@rekursiv.pi.se (Jan Larsson) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sun, 05 Jan 1997 01:44:27 +0100 Organization: Rekursiv Teknik Message-ID: <jlarsson-0501970144270001@news.pi.se> References: <AEEFE2B6-491909@204.246.66.19> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <AEEFE2B6-491909@204.246.66.19>, "Nick Nallick" <nallick@winternet.com> wrote: > Does it still make sense to have an application framework such as MacApp or > PowerPlant on top of OpenStep What would make sense is a MacApp works on both System-7 and the NewOS. While this may not use OpenStep to its full potential it would still have all the other advantages like memory protection, threads, SMP etc. And it would allow developers to support both NewOS and System-7 for a while. /Jan Larsson ---------------------------------------------------------------- Jan Larsson jlarsson@numerik.se Numerik Design http://www.numerik.se ----------------------------------------------------------------
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 5 Jan 1997 01:41:00 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5an0rc$dfm@brachio.zrz.TU-Berlin.DE> References: <32CE8F2E.1A12@m4.sprynet.com> In article <32CE8F2E.1A12@m4.sprynet.com> piercej@m4.sprynet.com writes: > John Kheit wrote: > > >>That _IF_ apple does the right thing, and lets you > >>develop/design/compile one piece of source code for Apple > >>NewOS/win95/winNT/Solaris then this is still the place to be. > > I agree. > > >>Current NeXT development tools allow you to do so, actually to do > >>so for multiple hardware for each of the OS platforms (for Mach OS > >>you can compile to Intel, Sparc, HPPA, and soon PPC, and maybe 040 > >>hardware...)... That kind of single code base/cross development > >>is a powerful reason to use the new development platform... > > Code developed using the NEXT development tools and frameworks is still > OS dependant. > > Like the Next development tools, the Metrowerks tools allow you to > compile a single code base and target multiple processors (68K, PPC, > x86). Hmm... when I used the Metrowerks stuff, you had to have different projects for the two architectures (68k/PPC) that could then share source files. Things got out of sync very easily and it was almost impossible to figure out what libraries were required (no real docs on this) for the different platforms. With NextStep, going multi-platform usually required checking the architecture flags in project-builder (one click per architecture), as well as re-writing any endian-specific code. That was actually the biggest part of it because I was doing device-drivers. Marcel
From: Thomas Vincent <info@sfbayrun.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sat, 04 Jan 1997 17:40:31 -0800 Organization: SFbayrun Internet Message-ID: <32CF068E.27C1@sfbayrun.com> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5a9jba$mk0$1@news.cs.tu-berlin.de> <rex-ya023080000401970615070001@nntp.ix.netcom.com> <32CEAEB5.3BA@exnext.com.nonsense> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 1. I have heard that to remove DPS from the Next OS would be a very long, and big job. 2. If GX is so great then why are there only like ten apps in the whole mac world that take advantage of it? I mean, most people know Quickdraw GX as this monolithic ram eater. -- Cheers, Thomas Vincent =============== SFbayrun Internet | The MacStep News & BookStore http://www.sfbayrun.com/snet/ | http://www.sfbayrun.com/next/ --------------------------------------------------------- National High School Cross Country & Track and Field Pages http://www.sfbayrun.com/scholar/ ---------------------------------------------------------
From: hugues@precipice.fdn.fr (Hugues RICHARD) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 4 Jan 1997 15:45:38 GMT Organization: Individual - France Message-ID: <5altv2$3f8@precipice.fdn.fr> References: <5a476h$1el@precipice.fdn.fr> <AEEC692A-805EB@198.68.42.208> "Lawson English" <english@primenet.com> wrote: > MMMM... GX has other advantages over Display PostScript besides the > OOP-ness. One of the most important is the fact that various > calculation-results and other data are kept around in a "shape cache" > for each shape. This means that when you redraw/reuse that shape, GX > can use the information available to speed up whatever is being done > (drawing, masking, whatever). On PS level II (also DPS) you cache too but it is up to the programmer to specify if he wants to cache or not. If Apple build a GXKit, they may include this PS caching mecanism? > Using GX as an API on top of Display PostSCript would make less useful > since you're now working with an engine one or more layers removed. When working with OO framework, you always have one or more layers. If you don't want a lot of layer, go with the MS_all_direct attitude that prevent any evolution. At the begining, OO is an investment. >Another issue is fonts. While this won't really matter for printing, >GX fonts allow for up to 65,536 glyphs with layout, ligature, >justification, etc., information contained in the font tables. So PS level II does : characters are 16 bits encoded if Ligature must be seek at hand in afm files : C 174 ; WX 556 ; N fi ; B 31 0 521 683 ; C 175 ; WX 556 ; N fl ; B 32 0 521 683 ; you can find kerning, and composite characters in font tables. >Trying to bounce back and forth between the two strategies in real-time >sounds like it would be *terribly* inefficient for display. GX is >faster than standard QuickDraw graphics because it can cache certain >information for reuse. Doing this context-switching would more than >eat up all the time saved, I'm sure. Types have been the first things cached in PS (since day 1). Hugues. -------------------------------------------------------------------- hugues@precipice.fdn.fr - French, English, Italian and a few JP ->OK ------------ NS3.2 ------------ NS3.0J ------------ :-) ------------
From: Brian Arnold <arnold@rahul.net> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sat, 04 Jan 1997 18:51:12 -0800 Organization: Apple Computer, Inc. Message-ID: <32CF1721.1883@rahul.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jonathon, I'm glad to see you contributing to the debate over frameworks, but I don't agree with your position. Let me start by saying that it is plausible that AppKit chould become the primary choice for developing applications in the new OS, and it is inevitable for Apple to give NeXTStep components leading framework roles in the new OS. However, existing MacOS frameworks, even ones that have similar features to NeXTStep components, have a right, and a need, to coexist in the new OS for the forseeable future, because so much existing code depends on them that is strategic to jump-starting the NeXT-based OS. Equating Copland's problems in retaining compatibility is not an argument for a framework as deeply abstracted as MacApp, or even for one more thinly abstracted such as PowerPlant--in fact, the logic can be applied in reverse. For example, Copland faced compatibility issues with its new event model--a model which is fully abstracted in MacApp and that could be adapted once, rather than adapting all the applications that use MacApp. The most basic role for MacApp in the new OS could be to facilitate the migration of existing MacApp apps more quickly by doing the work once. There are well over a thousand applications developed with MacApp that ship millions of units per year. Some of these applications are strategic to Apple, and some are strategic to major third party software vendors. We all know viscerally that developers largely do not embrace change, they tend to stick to legacy code on shipping OSes. Significant delays in migrating existing applications and strategic tools to a new OS is about the last thing Apple needs right now. Apple learned already once before with the transition to PowerPC that it can't abandon its existing frameworks, lest it cut off a crucial asset: instant native applications. I should mention that I understand this issue first-hand. Two years after PowerMacintosh and MacApp 3.1 were introduced, and more years than that after C++ was written on stone tablets, I led the port of a "dead" version of MacApp (2.0), in its "dead" language (Object Pascal) to PowerPC, which drove the number of native PowerPC applications up by a couple hundred. The reason was simple: some people can't or won't migrate on a particular schedule or with particular tools, and you have to accept that position, and more importantly, you have to realize its implications. The point is: there's a lot of important code written with MacApp that is in critical need of timely migration, and it doesn't matter whether there is a framework which is better than MacApp (though I would be happy argue that topic in a separate thread ;-). It is not appropriate to demand that a thousand-plus MacApp applications change their client code to conform to a different language and framework--that would "let a thousand flowers die," to turn a phrase by Guy Kawasaki. If there is the possibility for changing MacApp to conform to the NeXT OS's underlying architecture, this issue should be explored, because there is obvious leverage in doing so. Developers will still be free to choose to use another framework or language based on its features and on their needs, and most importantly, on their preferences and on their schedule. Therefore, MacApp should play at least one specific role in the transition to the new OS, even if its role isn't primary, even if its role becomes reduced once the new OS becomes widely available, and even if most developers flock to another framework: to help move existing MacApp applications to the new OS much more quickly than otherwise. I should point out that the Metrowerks suite of tools and third party applications as obscure as Microsoft Internet Explorer would have a hard time moving to the NeXT-based OS if the PowerPlant framework didn't adapt as well, so the same logic applies. Having a choice of languages is more important than having a choice of frameworks because the benefit of migrating existing frameworks is destroyed since client code must also migrate to the new language. Even more importantly, there are many times more MacOS applications written in plain old C, C++ and Object Pascal (not to mention SmallTalk, Lisp, and the other wierer languages ;-) whose developers have have an even stronger set of preferences about their tools options. Therefore, choice of language has an even stronger effect on availability of native applications in the new OS, and it's vital to get clarity on this issue first, lest we "let twenty thousand flowers die." - Brian Arnold MacApp Frameworks Dude Apple Computer, Inc.
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.nsc.32k,comp.sys.palmtops,comp.sys.powerpc.advocacy,comp.sys.powerpc.misc,comp.sys.powerpc.tech,comp.sys.psion.misc,comp.sys.sgi.admin,comp.sys.sinclair,comp.sys.sun.admin,comp.sys.sun.hardware,comp.text.tex,comp.unix.admin,comp.unix.advocacy,comp.unix.aix Subject: cmsg cancel <jcr.852417619@idiom.com> Control: cancel <jcr.852417619@idiom.com> Date: 5 Jan 1997 03:25:04 GMT Organization: Sun Microsystems Inc., Mountain View, CA Message-ID: <5an6ug$edt@engnews1.Eng.Sun.COM> This article canceled.
From: John Hornkvist Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 4 Jan 1997 21:16:50 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5amhc2$dao@nyheter.chalmers.se> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <32CD82F6.488@exnext.com> In <32CD82F6.488@exnext.com> "Jonathan W. Hendry" wrote: >Larry Kilgallen wrote: >> >> In article <32CD396A.3DC@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: >> >> > If they don't use the OpenStep API's, why would they bother buying >> > NeXT? >> >> Memory protection, an OS kernel, scheduling, ... > >There's nothing special about NeXT's kernel. They could just as well >have used Be, or NuKernal. (In fact, it's not clear they won't.) I think they wanted the package. Mach and all. In fact, there are some things that are very special with Mach 2.5: OpenStep exists on the Mach kernel today. NeXT's engineers are used to the mach kernel. NeXT's engineers have experience porting the Mach kernel to new hardware. Add to this that: Apples engineers do not know OpenStep. NeXT's engineers do not know the NuKernel. To port OpenStep on Mach to the PPC, the NeXT engineers would not have to do much more than porting Mach, which is relatively easy, and supposedly done once already. If OpenStep were to be moved to the NuKernel, Apple's engineers would have to learn the internals of OpenStep first, or the NeXT engineers would have to learn how to use the NuKernel. This would take a lot more time. I don't think Apple will throw away time like that. > > If I recall correctly, part of the reason Copland was taking so > > long was the effort to maintain API compatability. Staying with > > MacApp seems like a continuation of that. > > The innards of MacApp could be modified to match an arbitrary API > which was capable of delivering the same look-and-feel as System 7. > An arbitrary API change, however, would decimate the ranks of > current non-MacApp developers, which would not be in Apple's best > interest (Do I win the understatement award? Do I? Do I?). The API change is hardly arbitrary. But, if it is reasonably simple to do, there should of course be conversion tools. If it is not reasonably simple, then emulation will have to do until attractive applications are ported to OpenStep. Let us not forget that Appled bought NeXT for $400 million. They did that because they needed that OS upgrade yesterday, and I find it highly unlikely that they will do any change to NEXTSTEP that will delay the release. ---- Sorry for not leaving my address in the header, but I get too many spam mails already. If you want to reach me, try nhoj at cd dot chalmers dot se John Hornkvist Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97?
From: John Hornkvist Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: 4 Jan 1997 21:11:50 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5amh2m$dao@nyheter.chalmers.se> References: <5aj8p3$rer@boursy.news.erols.com> <E3Fxyv.E3K@cam-ani.co.uk> In <E3Fxyv.E3K@cam-ani.co.uk> Ian Stephenson wrote: >it's 100% compatable (even to a BINARY level - I used to occasionaly run >Sun binaries) with 4.3BSD. > If I am not mistaken, it worked the other way too; NEXTSTEP would work on some Sun workstations up to version 1.1, or something like that. Supposedly because NEXTSTEP was developed on Suns. --- Sorry for not leaving my address in the header, but I get too many spam mails already. If you want to reach me, try nhoj at cd dot chalmers dot se John Hornkvist Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97?
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 5 Jan 1997 04:40:56 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5anbco$957@news4.digex.net> References: <5ag0ln$a2r@news4.digex.net> <AEF165A8-997F6@198.68.42.189> "Lawson English" <english@primenet.com> wrote: > John Kheit <jkheit@cnj.digex.net> said: > >Yes, I think this is reasonably doable... Put much of the GX > >api in a framework for OpenStep and have DPS do the basic > >drawing... Likely the quickest way to go... > Or the slowest, depending... But at least it will print. -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: "Mark Eaton" <marke@nwlink.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: knife says Mach/PPC kernel via MkLinux Date: 4 Jan 97 20:28:46 -0800 Organization: Northwest Link Message-ID: <AEF46E01-20D5D@206.129.17.26> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit nntp://news.nwlink.com/comp.sys.next.programmer Mac the Knife's Jan 6 column suggests that the Mach 3.0 kernel thats part of the MkLinux project will be 'crucial to' the NextStep/PPC project... <http://www.macweek.com/mactheknife/index.html>
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: knife says Mach/PPC kernel via MkLinux Date: Sat, 04 Jan 1997 23:46:19 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32CF321B.17DB@exnext.com.nonsense> References: <AEF46E01-20D5D@206.129.17.26> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mark Eaton wrote: > > Mac the Knife's Jan 6 column suggests that the Mach 3.0 kernel thats part > of the MkLinux project will be 'crucial to' the NextStep/PPC project... > > <http://www.macweek.com/mactheknife/index.html> Perhaps. On the other hand, maybe he got as far as the fact that they both use Mach and turned his brain off. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 5 Jan 1997 04:51:50 GMT Organization: MHPCC Message-ID: <5anc16$g3g@kaopala.mhpcc.edu> References: <5amli2$ol3@news.tuwien.ac.at> Cc: rft@cg.tuwien.ac.at In <5amli2$ol3@news.tuwien.ac.at> Robert F Tobler wrote: > > > PROPOSAL: > How to modify the Workspace manager to behave like the Finder > > * Make a shelf-only window that has the size of the screen and resides > below all other windows. This will be the Next Apple Desktop. Such a feature is implemented quite nicely by MonsterShelf, ftp://next-ftp.peak.org/pub/next/apps/utils/workspace/MonsterShelf.NIHS.bs.tar.gz I have found it simpler to use than Fiend, and it serves my needs adequately. ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: quinlan@sfu.ca (Brian Quinlan) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 5 Jan 1997 05:52:04 GMT Organization: Simon Fraser University Message-ID: <5anfi4$opo@morgoth.sfu.ca> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5a9jba$mk0$1@news.cs.tu-berlin.de> <rex-ya023080000401970615070001@nntp.ix.netcom.com> <32CEAEB5.3BA@exnext.com.nonsense> <32CF068E.27C1@sfbayrun.com> Thomas Vincent <info@sfbayrun.com> writes: >2. If GX is so great then why are there only like ten apps in the whole >mac world that take advantage of it? I mean, most people know Quickdraw >GX as this monolithic ram eater. If NeXTStep is so great then why does it fair so poorly in the market? Why do most people consider it a generator of compatibility problems. -- Brian Quinlan "Never ask what sort of computer a guy drives. If he's a Mac quinlan@sfu.ca user, he'll tell you. If not, why embarrass him?" - Tom Clancy
From: woody@alumni.caltech.edu (William Edward Woody) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sun, 05 Jan 1997 02:26:59 -0800 Organization: In Phase Consulting Message-ID: <woody-0501970226590001@192.0.2.1> References: <5a6l13$b8k@news3.digex.net> <AEED542B-56E54@198.68.42.230> <5a9jba$mk0$1@news.cs.tu-berlin.de> <rex-ya023080000401970615070001@nntp.ix.netcom.com> <32CEAEB5.3BA@exnext.com.nonsense> <32CF068E.27C1@sfbayrun.com> <5anfi4$opo@morgoth.sfu.ca> In article <5anfi4$opo@morgoth.sfu.ca>, quinlan@sfu.ca (Brian Quinlan) wrote: > Thomas Vincent <info@sfbayrun.com> writes: > If NeXTStep is so great then why does it fair so poorly in the market? Why > do most people consider it a generator of compatibility problems. Simple: NeXT never got over the 'users only buy what has programs for it; developers only write programs for systems users buy' hump. The fundamental problem with the market is that the basic game of who will dominate in the market place was basically decided way back in 1984; unless one of the major players totally screw up, you can expect the status quo to stay relatively the same until the end of time. Way back then, Apple introduced the Macintosh in a market where people were still tinkering and hacking with computers; basically the Macintosh showed up a couple of years too late and a couple of years too early. Too late because the IBM PC had already established itself in the hacker community as _the_ toy to play with. And too early because the windowing paradigm the Macintosh introduced (which is especially great for computer users) didn't fair too well with hackers (who are computer tinkerers and computer builders, not computer users). And once businesses started buying computers and hiring those hackers to help make the purchasing choices, the Macintosh was basically doomed to live in the 10% market share (with graphically intensive applications, even though the PC has long caught up to where graphically intensive applications can be written). And the IBM PC with Microsoft software was destined to live with the rest of the market share by virtue that the purchasing decisions would ultimately rest with the folks who were just last year tinkering with soldering irons building character generators to plug into the ISA bus for fun. In many ways I think it's too bad. First, because new technologies (such as the NeXT platform, which was really state of the art and the best bang for the buck when it first hit the market, or the BeBox, which is a damned good hardware deal today) don't have a chance. And second, because mediocre technologies (Microsoft) will live forever, only because the market share is too large and too invested in Microsoft technology to change to something else. Even if that something else (Apple, NeXT, Be, whatever) is clearly superior. - Bill -- William Edward Woody - In Phase Consulting - woody@alumni.caltech.edu http://www.alumni.caltech.edu/~woody
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 5 Jan 1997 13:45:32 GMT Organization: Vienna University of Technology, Austria Message-ID: <5aob9s$dc4@news.tuwien.ac.at> References: <5amli2$ol3@news.tuwien.ac.at> <5anc16$g3g@kaopala.mhpcc.edu> altenber@acpub.duke.edu (Lee Altenberg) wrote: > > * Make a shelf-only window that has the size of the screen and > > resides below all other windows. This will be the Next > > Apple Desktop > Such a feature is implemented quite nicely by MonsterShelf, There are a number of free- or shareware utilities that extend the Next Finder or the Next Workspace Manager to include some of the functionality I have described. This is, however, not enough, since they will not be available on preinstalled systems, and only a fraction of the total user base knows about them. Thus the average system will not have the functionality, and will rightfully be criticized for lacking it. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan5.085111.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> Date: Sun, 5 Jan 1997 13:51:11 GMT In article <5amhc2$dao@nyheter.chalmers.se>, John Hornkvist writes: > Let us not forget that Appled bought NeXT for $400 million. They > did that because they needed that OS upgrade yesterday, and I find > it highly unlikely that they will do any change to NEXTSTEP that > will delay the release. No, if Apple fails to retain the existing customer (and particularly, developer) base, the 400 million dollars is wasted. Customer loyalty is Apple's most precious asset, and in the US they rank second only to Harley-Davidson. Larry Kilgallen
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan5.085755.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <32CF1721.1883@rahul.net> Date: Sun, 5 Jan 1997 13:57:55 GMT In article <32CF1721.1883@rahul.net>, Brian Arnold <arnold@rahul.net> writes: > Having a choice of languages is more important than having a choice of > frameworks because the benefit of migrating existing frameworks is > destroyed since client code must also migrate to the new language. Even > more importantly, there are many times more MacOS applications written > in plain old C, C++ and Object Pascal (not to mention SmallTalk, Lisp, > and the other wierer languages ;-) whose developers have have an even > stronger set of preferences about their tools options. Therefore, > choice of language has an even stronger effect on availability of native > applications in the new OS, and it's vital to get clarity on this issue > first, lest we "let twenty thousand flowers die." In particular, certain applications are better suited to certain implementation languages. GUI calls can be done from many languages, but when it comes to the actual guts of a program which does statistics, natural language processing, or whatever, telling a company full of problem domain experts that in order to run on Macintosh they must switch to using some language derived from C is quite simply a non-starter. Larry Kilgallen
From: johns@efn.org (John Selhorst) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: Sun, 05 Jan 1997 06:57:58 -0800 Organization: Just me Message-ID: <johns-ya023380000501970657580001@news.efn.org> References: <5amli2$ol3@news.tuwien.ac.at> <32CF4C76.1EBF@cygnus.com> <5amnoa$ol3@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5amnoa$ol3@news.tuwien.ac.at>, Robert F Tobler <rft@cg.tuwien.ac.at> wrote: >I know about Fiend, but this *needs* to be in the Next Finder, and be the >default setup, in order to cater to current Macintosh users. Shareware >programs that provide the same functionality are not enough, since they >will not be available on preinstalled systems, and only a fraction of >the total user base knows about them. You don't need to reinvent the wheel. You just need to get Apple to license it and deliver it with the OS. No big deal. Johnny
From: suee1534@mailszrz.zrz.TU-Berlin.DE (Ozan Sueel) Newsgroups: comp.sys.next.programmer Subject: Interceptor Date: 5 Jan 1997 15:13:40 GMT Organization: Technical University Berlin, Germany Message-ID: <5aogf4$ht9@brachio.zrz.TU-Berlin.DE> -- ? ? Help M Main Menu P AG
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 5 Jan 1997 15:58:53 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5aoj3t$l4h@brachio.zrz.TU-Berlin.DE> References: <1997Jan5.085755.1@eisner> In article <1997Jan5.085755.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes: > In article <32CF1721.1883@rahul.net>, Brian Arnold <arnold@rahul.net> writes: > > > Having a choice of languages is more important than having a choice of > > frameworks because the benefit of migrating existing frameworks is > > destroyed since client code must also migrate to the new language. Even > > more importantly, there are many times more MacOS applications written > > in plain old C, C++ and Object Pascal (not to mention SmallTalk, Lisp, > > and the other wierer languages ;-) whose developers have have an even > > stronger set of preferences about their tools options. Therefore, > > choice of language has an even stronger effect on availability of native > > applications in the new OS, and it's vital to get clarity on this issue > > first, lest we "let twenty thousand flowers die." > > In particular, certain applications are better suited to certain > implementation languages. GUI calls can be done from many languages, > but when it comes to the actual guts of a program which does statistics, > natural language processing, or whatever, telling a company full > of problem domain experts that in order to run on Macintosh they > must switch to using some language derived from C is quite simply > a non-starter. > > Larry Kilgallen It sure is. And they don't have to. Does every Mac programmer have to use Assembler/Pascal? Of course not. The FUD is really flying low. Marcel
From: acurylo@inmediapresents.com (Alex Curylo) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sun, 05 Jan 1997 12:38:06 -0800 Organization: InMedia Presentations Distribution: world Message-ID: <acurylo-0501971238060001@van0224.tvs.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <32CD82F6.488@exnext.com> <5amhc2$dao@nyheter.chalmers.se> In article <5amhc2$dao@nyheter.chalmers.se>, sorry@no.more.spams wrote: > To port OpenStep on Mach to the PPC, the NeXT engineers would not > have to do much more than porting Mach, which is relatively easy, > and supposedly done once already. Er, three times, isn't it?? MkLinux is the Mach kernel, so is Tenon's MachTen or whatever they call it, and according to MacWEEK NuKernel is based on Mach as well. MacLeak also claims that NeXTStep is running on a twin 601 machine in NeXT's labs. So that would make _four_ ports of Mach to PPC in existence right now :) Seems to me that the MkLinux development efforts should be able to be leveraged straight into Avi's new group, and there's no obvious reason we can't have NeXTStep Mac running fine by WWDC. Which looking at Metrowerk's announcements about tool releases, seems to be what they expect too. Now, once the port's done, adding Mac OS APIs to NeXTStep ... there's an issue or two there, yeah ;) But FWIW, I think what Ellen's saying about porting NeXTStep to current hardware immediately, so Apple at least has an alternative to provide people, and *then* thinking about backwards compatibility (both API and hardware wise) is PRECISELY the correct strategy Apple needs to be taking at this point. For an example of how this strategy works from a marketing point of view in the real world, consider NT 3.5 vs. 4. Looks like a reasonable model to me. ---- Alex Curylo -- alex@witty.com
From: acurylo@inmediapresents.com (Alex Curylo) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sun, 05 Jan 1997 12:38:30 -0800 Organization: InMedia Presentations Distribution: world Message-ID: <acurylo-0501971238310001@van0224.tvs.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <32CD82F6.488@exnext.com> <5amhc2$dao@nyheter.chalmers.se> In article <5amhc2$dao@nyheter.chalmers.se>, sorry@no.more.spams wrote: > To port OpenStep on Mach to the PPC, the NeXT engineers would not > have to do much more than porting Mach, which is relatively easy, > and supposedly done once already. Er, three times, isn't it?? MkLinux is the Mach kernel, so is Tenon's MachTen or whatever they call it, and according to MacWEEK NuKernel is based on Mach as well. MacLeak also claims that NeXTStep is running on a twin 601 machine in NeXT's labs. So that would make _four_ ports of Mach to PPC in existence right now :) Seems to me that the MkLinux development efforts should be able to be leveraged straight into Avi's new group, and there's no obvious reason we can't have NeXTStep Mac running fine by WWDC. Which looking at Metrowerk's announcements about tool releases, seems to be what they expect too. Now, once the port's done, adding Mac OS APIs to NeXTStep ... there's an issue or two there, yeah ;) But FWIW, I think what Ellen's saying about porting NeXTStep to current hardware immediately, so Apple at least has an alternative to provide people, and *then* thinking about backwards compatibility (both API and hardware wise) is PRECISELY the correct strategy Apple needs to be taking at this point. For an example of how this strategy works from a marketing point of view in the real world, consider NT 3.5 vs. 4. Looks like a reasonable model to me. ---- Alex Curylo -- alex@witty.com
From: rbarris@quicksilver.com (Rob Barris) Newsgroups: comp.sys.next.programmer Subject: DPS Q: palette hardware Date: Sun, 05 Jan 1997 14:23:10 -0800 Organization: Quicksilver Software, Inc. Message-ID: <rbarris-ya023280000501971423100001@news.quicksilver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit As far as I can remember, Display Postscript systems such as the original 030 NeXT, 040 NeXTStations, and even NeXT on Intel were restricted to certain display modes, namely ones like 2 bit gray 8 bit gray 16/24 bit color That is to say "no color palettes", only direct "true color" or "gray scale" modes. While I admire the simplicity that this must bring to the DPS code, never having to worry about mapping a color back into a palette of arbitrarily chosen colors, I wonder what will/might happen to DPS and NextStep as it is brought to the Mac world. Does/can DPS support for example 8-bit color with palette hardware? Does it have a palette manager to manage the color hardware state as you switch from one app to another? Could it run on an old PowerMac with 4-bit color or 1-bit black and white display? As a multimedia/game person I would love it if everyone would buy fast high-color/true-color machines, it would eliminate a lot of headaches in production if we could do away with palettes forever, however the installed base has a lot of "less worthy" video hardware. Rob Barris Quicksilver Software Inc. rbarris@quicksilver.com * Opinions expressed not necessarily those of my employer *
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.next.programmer Subject: Re: DPS Q: palette hardware Date: 5 Jan 1997 23:35:50 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5apdsm$h9p@news4.digex.net> References: <rbarris-ya023280000501971423100001@news.quicksilver.com> rbarris@quicksilver.com (Rob Barris) wrote: > As far as I can remember, Display Postscript systems such as > the original 030 NeXT, 040 NeXTStations, and even NeXT on > Intel were restricted to certain display modes, namely ones > like > 2 bit gray 8 bit gray 16/24 bit color Add to the above 8bit color as well. > As a multimedia/game person I would love it if everyone would > buy fast high-color/true-color machines, it would eliminate > a lot of headaches in production if we could do away with > palettes forever, however the installed base has a lot of > "less worthy" video hardware. Well, DPS might be very nice. It uses 24bit (or even higher in some cases) color, and maps down on the fly. It will dither down to 8bit color, and the results are just great...b/c of the way dithering is done, an 8bit screen ends up looking like it has thousands or millions of colors. Also, 8bit color takes less memory and redraws faster...so it's very nice. For game developers...one doesn't even have to switch the entire screen to 8 or 16 or 24bit modes. Say you log in in 24bit mode. You can run an app at any bit depth...you can launch a newsreader in 2bit monochrome...that app and all its windows will be drawn in only 2bit mono, only use the memory required for 2bit mono, and redisplay faster b/c of the lower bit depth...If that app has any color, it will just be dithered down... The rest of the system will continue on working in color. Anyway, I imagine if you have 256 color CLUT based graphics, when you display them in 8bit color under nextstep...or any other bit depth...their 'pure' color values will be used, and it will be dithered down to as close a representation as possible... -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 5 Jan 1997 16:39:02 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF58CD0-8640A@198.68.42.176> References: <5altv2$3f8@precipice.fdn.fr> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hugues RICHARD <hugues@precipice.fdn.fr> said: >"Lawson English" <english@primenet.com> wrote: > >> MMMM... GX has other advantages over Display PostScript besides the >> OOP-ness. One of the most important is the fact that various >> calculation-results and other data are kept around in a "shape cache" >> for each shape. This means that when you redraw/reuse that shape, GX >> can use the information available to speed up whatever is being done >> (drawing, masking, whatever). > >On PS level II (also DPS) you cache too but it is up to the programmer to >specify if he wants to cache or not. > I believe that we're talking about a different level of cache, here. >If Apple build a GXKit, they may include this PS caching mecanism? > >> Using GX as an API on top of Display PostSCript would make less useful >> since you're now working with an engine one or more layers removed. > >When working with OO framework, you always have one or more layers. >If you don't want a lot of layer, go with the MS_all_direct attitude that >prevent any evolution. >At the begining, OO is an investment. The OOP-ness of GX is in the API: all shape objects respond to the same calls in a type-appropriate manner. DrawShape(mShape); works for any shape, be it line, rectangle, path, text, glyph or layout. > >>Another issue is fonts. While this won't really matter for printing, >>GX fonts allow for up to 65,536 glyphs with layout, ligature, >>justification, etc., information contained in the font tables. > >So PS level II does : characters are 16 bits encoded >if Ligature must be seek at hand in afm files : >C 174 ; WX 556 ; N fi ; B 31 0 521 683 ; >C 175 ; WX 556 ; N fl ; B 32 0 521 683 ; >you can find kerning, and composite characters in font tables. > But PS wasn't designed with the Chinese/Japanese/Korean/Hindu-Urdi/etc markets in mind. GX was. >>Trying to bounce back and forth between the two strategies in real-time >>sounds like it would be *terribly* inefficient for display. GX is >>faster than standard QuickDraw graphics because it can cache certain >>information for reuse. Doing this context-switching would more than >>eat up all the time saved, I'm sure. > >Types have been the first things cached in PS (since day 1). I understand that PS caches bit-map images of fonts at a given resolution. GX's architecture allows for the caching of all sorts of things. In fact, I understand that GX doesn't really store shapes as OOP-style *objects* but as entries in an optimized database, with the shape's reference (GX "pointer") being used as the index into that database. I would *guess* that recently used fonts are stored in bitmap format, since this is an obvious optimization strategy, but GX goes way beyond that in terms of sophistication. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 5 Jan 1997 16:43:03 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF58DA4-895E4@198.68.42.176> References: <32CF068E.27C1@sfbayrun.com> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thomas Vincent <info@sfbayrun.com> said: >1. I have heard that to remove DPS from the Next OS would be a very >long, and big job. > >2. If GX is so great then why are there only like ten apps in the whole >mac world that take advantage of it? I mean, most people know Quickdraw >GX as this monolithic ram eater. No-one that I know of is advocating that Apple remove DPS from NeXT/OpenStep. They want to keep the installed base of NeXT apps functional afterall and this would require that Apple implement GX as the backend for a "Ghost"-DPS server, which is no doubt doable, but would take a long time to optimize. Instead, GX fanatics are asking for Apple to make sure that GX works as a "native" API under the new OS and to seriously consider implementing the GUI using GX, since such an implementation would be faster and more versatile. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: John Hornkvist Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 5 Jan 1997 21:46:55 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5ap7gf$mnu@nyheter.chalmers.se> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> Cc: kilgallen@eisner.decus.org In <1997Jan5.085111.1@eisner> Larry Kilgallen wrote: >In article <5amhc2$dao@nyheter.chalmers.se>, John Hornkvist writes: > >> Let us not forget that Appled bought NeXT for $400 million. They >> did that because they needed that OS upgrade yesterday, and I find >> it highly unlikely that they will do any change to NEXTSTEP that >> will delay the release. > >No, if Apple fails to retain the existing customer (and particularly, >developer) base, the 400 million dollars is wasted. Customer loyalty >is Apple's most precious asset, and in the US they rank second only to >Harley-Davidson. Since it seems like Apple intends to continue development of System 7, I don't see why they'd be unable to keep their existing customer base. The NeXT Apple OS will take care of those users that want a better OS than System 7. That group may well include users of Windows'95 or NT. Even more important, Apple may gain the momentum that is needed to attract new computer users. Apropos customer loyalty, how large is Apple's customer base compared to the growth of the computer market? I have no idea, but it would be interesting to know. Anyway, I maintain that Apple will not delay the release of the new OS by adding Apple technologies. However, once that initial release is out, Apple is likely to start migrating those technologies that are needed. By the way, IIRC almost every major change of NEXTSTEP has forced developers to rewrite applications. Applications written for 3.3 will not compile under 4.0, although they will run. I suspect the situation will be similar for Mac developers. As for developers: 1) There are plenty of developers on OpenStep today. 2) Developers are usually early adaptors. 3) OpenStep is a developers dream. One of the most important factors in software development is time to market. The OpenStep frameworks, combined with the dynamic nature of Objective-C allows for a very short development cycle. If the developer has a decently structured application, which all people that call themselves developers should have, changing the UI code should be very simple. Normally you do not have to change more than that when porting to NEXTSTEP. Besides, developers have the same asset that Apple has; customers. If Apple can get their customers do move to the NeXT OS, which is likely, then developers will have to follow, or throw away a customer base that they have worked very hard to develop. The competition on the Windows market is fierce. Developing a customer base there will be incredibly hard. So, I still maintain get the new OS out on PPC yesterday, and if that means you'll have to leave Apple technologies behind, then so be it. Apple has to get something out quick. I find it likely that migrating MacApp will take longer than porting NEXTSTEP to the PPC, and therefore it will have to wait. Remember that there are many excellent applications available for OpenStep, and that the OpenStep developers are very positive about the port. Through the merger Apple has gained some momentum and caught attention. They have to show what NEXTSTEP is capable off on Apple's hardware. They have to get a working system out to developers. They don't have infinite time. All this does not mean that MacApp should not be ported, but that it should be ported when there is time, and in such a way that MacApp applications integrate with the new UI. Otherwise they can just as well stay in emulation. --- Sorry for not leaving my address in the header, but I get too many spam mails already... If you want to reach me, try nhoj at cd dot chalmers dot se John Hornkvist Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97?
From: John Hornkvist Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 5 Jan 1997 21:52:42 GMT Organization: Chalmers Tekniska Högskola Distribution: world Message-ID: <5ap7ra$mnu@nyheter.chalmers.se> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <32CD82F6.488@exnext.com> <5amhc2$dao@nyheter.chalmers.se> <acurylo-0501971238060001@van0224.tvs.net> Cc: acurylo@inmediapresents.com In <acurylo-0501971238060001@van0224.tvs.net> Alex Curylo wrote: > In article <5amhc2$dao@nyheter.chalmers.se>, sorry@no.more.spams wrote: > > > To port OpenStep on Mach to the PPC, the NeXT engineers would not > > have to do much more than porting Mach, which is relatively easy, > > and supposedly done once already. > > Er, three times, isn't it?? MkLinux is the Mach kernel, so is Tenon's > MachTen or whatever they call it, and according to MacWEEK NuKernel is > based on Mach as well. > > MacLeak also claims that NeXTStep is running on a twin 601 machine in > NeXT's labs. So that would make _four_ ports of Mach to PPC in existence > right now :) I meant that NeXT's engineers had already ported Mach to PPC once... :) > Seems to me that the MkLinux development efforts should be able to be > leveraged straight into Avi's new group, and there's no obvious reason we > can't have NeXTStep Mac running fine by WWDC. Which looking at Metrowerk's > announcements about tool releases, seems to be what they expect too. I think the differences between Mach 2 and 3 are great enough that the MkLinux teem will not have much more to add than the Copland team. That could still be a lot, though... :) > Now, once the port's done, adding Mac OS APIs to NeXTStep ... there's an > issue or two there, yeah ;) But FWIW, I think what Ellen's saying about > porting NeXTStep to current hardware immediately, so Apple at least has an > alternative to provide people, and *then* thinking about backwards > compatibility (both API and hardware wise) is PRECISELY the correct > strategy Apple needs to be taking at this point. For an example of how > this strategy works from a marketing point of view in the real world, > consider NT 3.5 vs. 4. Looks like a reasonable model to me. I am glad we agree. ---- Sorry for not leaving my address in the header, but I get too many spam mails already... If you want to reach me, try nhoj at cd dot chalmers dot se John Hornkvist Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97?
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 6 Jan 1997 04:38:11 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5apvjj$h9p@news4.digex.net> References: <32CF068E.27C1@sfbayrun.com> <AEF58DA4-895E4@198.68.42.176> "Lawson English" <english@primenet.com> wrote: > Instead, GX fanatics are asking for Apple to make sure that GX works as a "native" API under the new OS and to seriously consider implementing the GUI using GX, since such an implementation would be faster and more versatile. Faster than what? How could replacing something be faster than simply using the current structure? Or do you mean faster executing? Please followup to comp.sys.next.advocacy,comp.sys.mac.advocacy This kind of thread seems out of place in programming groups... -- Thanks, later, John Kheit monoChrome, Inc. | ASCII, MIME, PGP, SUN, & NEXTmail OK NEXT/OPENSTEP Developer | mailto:jkheit@cnj.digex.net Telepathy, It's coming... | http://www.cnj.digex.net/~jkheit New York Law School | Opinions expressed represent me only
From: Ones-And-Zeros@prodigy.net Newsgroups: comp.sys.next.programmer Subject: ! MASS POST Was Here! (WlmNpZ) Date: Mon, 06 Jan 97 05:40:06 GMT Organization: Mass Post Message-ID: <5aq38p$3no6@usenet1y.prodigy.net> MASS POST--the program by Ones and Zeros--has been used to send this message to thousands of newsgroups. (WlmNpZ)
From: vbragin@ix.netcom.com (Vicki Bragin) Newsgroups: comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.misc Subject: Need help from users of Rasmol for NEXTSTEP Date: 6 Jan 1997 05:44:41 GMT Organization: Netcom Message-ID: <5aq3g9$h71@dfw-ixnews9.ix.netcom.com> I am desperately looking for somebody who might help in recompiling the NEXTSTEP version of RasMol to update it and implement some functionalities that have been added to the other versions (Mac, Windows, SGI, etc.). For those who may not know about RasMol, it is a molecular display freeware written by Roger Sayle of Glaxo Wellcome. He has generously shared the code with the scientific world (supposedly 30,000 visitors to the RasMol home page over last 9 months, most recent count). It has been compiled for just about any platform one can think of. The problem is I believe nobody is maintaining the NEXTSTEP version. I tried to compile the NEXTSTEP version from the source code, there did not appear to be any problems in compilation, but I am unable to get a graphics display on the window. I will give more detail to any chemist, biochemist, molecular biologist, ... inerested in helping out. -- ********************************************************** Victoria M. Bragin Physical Sciences Division, Pasadena City College 1570 E. Colorado Blvd., Pasadena, CA 91106-2003 Phone: (818) 585-7147 Fax: (818) 585-7919 E-mail: (NeXTmail and MIME mail welcome) vbragin@nextlab.calstatela.edu vbragin@ix.netcom.com vbragin@paccd.cc.ca.us vbragin@pslc.ucla.edu **********************************************************
From: rbraver@ohww.norman.ok.us (Robert Braver) Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5aq38p$3no6@usenet1y.prodigy.net> Date: 6 Jan 1997 06:49:12 GMT Control: cancel <5aq38p$3no6@usenet1y.prodigy.net> Message-ID: <cancel.5aq38p$3no6@usenet1y.prodigy.net> Sender: Ones-And-Zeros@prodigy.net Spam cancelled. Autocancel spam type: ONESZEROS Original Subject: ! MASS POST Was Here! (WlmNpZ)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 6 Jan 1997 07:00:31 GMT Organization: ace dot net internet technologies Message-ID: <5aq7uf$7vo@huffalump.visi.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> piercej@m4.sprynet.com wrote: : Code developed using the NEXT development tools and frameworks is still : OS dependant. Wrong. You've missed the whole point of OpenStep. Thanks for playing, though. -- # david young: +oo developer # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com, dwy@ace.net (NeXTmail ok)
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: DPS Q: palette hardware Date: 6 Jan 1997 05:35:52 GMT Organization: Netcom Distribution: world Message-ID: <5aq2vo$bfu@sjx-ixn9.ix.netcom.com> References: <rbarris-ya023280000501971423100001@news.quicksilver.com> rbarris@quicksilver.com (Rob Barris) wrote: > Does it have a palette manager to manage the color hardware state as you > switch from one app to another? What's the correct way to deal with different apps that use different color palettes in a multitasking environment where windows from several apps might be on-screen simultaneously? X Window doesn't deal with this well at all (at least it didn't several years ago). The entire screen uses the color palette for the active app which makes the windows for other apps look pretty bad and the entire display flashes when another app becomes active as the color palette changes. Ugly! I don't know much about this stuff, but it doesn't seem like the color hardware can deal with multiple color palettes simultaneously, so the above behavior might be the only possibility. If so, this seems to be a major weakness for color palettes as opposed to DPS' dithered color. But then if one needs to display undithered colors for some reason, this may be a problem with DPS. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 6 Jan 1997 06:10:05 GMT Organization: Netcom Distribution: world Message-ID: <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> John Hornkvist wrote: > By the way, IIRC almost every major change of NEXTSTEP has forced > developers to rewrite applications. Applications written for 3.3 > will not compile under 4.0, although they will run. I suspect the > situation will be similar for Mac developers. This seems overstated. We have been developing under NEXTSTEP since 1.0a and our only rewrite has been the recent NEXTSTEP->OPENSTEP conversion, much of which was handled by automated conversion tools supplied with OPENSTEP. When NEXTSTEP 2.0 was released, the small number of classes and methods that were scheduled to become obsolete were supported through the various 2.x releases and dropped when 3.0 was released allowing more than a year to replace obsoleted code. I can't recall anything similar when 3.0 was released other than several new object kits being added although there may have been a few more obsoleted classes and methods that were supported through the 3.x releases. > If the > developer has a decently structured application, which all people > that call themselves developers should have, changing the UI code > should be very simple. When I worked on the NEXTSTEP port of WingZ, originally a Mac app, the port was not nearly as easy as you imply. Many of the View classes are provided by NeXT and included without code using InterfaceBuilder. This didn't seem to be the case with the Mac version for which much View code existed and had to be converted to InterfaceBuilder nib files. But MacApp may not have been used for the original WingZ, so maybe this isn't a valid comparison. The Controller classes require extensive rewrites because all UI interactions must be Objective-C messages. Model classes can remain in C or C++, though, with little porting effort required in general. However, no Pascal or Smalltalk to/from Objective-C communication appears to be supported. However, Java and Objective-C are so similar under the covers that NeXT has recently provided cross language support to such a degree that subclasses can be written in a different language than the superclass. Normally you do not have to change more than > that when porting to NEXTSTEP. Methinks Mac apps will require a considerable porting effort unless Apple and NeXT put a lot of effort into conversion tools. > The competition > on the Windows market is fierce. Developing a customer base there > will be incredibly hard. Unfortunately, this seems true. We develop apps for the business side of hospitals and have had absolutely no request for Mac versions. Business in general seems to be well-entrenched in the Microsoft world and change doesn't come easy :-( I don't know what the new Apple OS would have to offer to lure these Windows sites away. Microsoft has perfected the disgusting "just good enough" development strategy so that its perfected marketing machine can sell mediocrity with little effort. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: Sun, 05 Jan 1997 19:50:47 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D04C67.3FE2@exnext.com.nonsense> References: <5altv2$3f8@precipice.fdn.fr> <AEF58CD0-8640A@198.68.42.176> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawson English wrote: > The OOP-ness of GX is in the API: all shape objects respond to the same > calls in a type-appropriate manner. > > DrawShape(mShape); > > works for any shape, be it line, rectangle, path, text, glyph or layout. How do you extend GX? -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: polyex@mail.netsrq.com Newsgroups: comp.sys.next.programmer Subject: Re: Speculation about OS/NT's future, anyone? Date: 5 Jan 1997 00:19:41 GMT Organization: Intelligence Network Online, Inc. Message-ID: <5ams2t$7gl@mercury.IntNet.net> References: <59p564$o2l@sjx-ixn9.ix.netcom.com> <1996Dec26.004354.2389@seer.demon.co.uk> <marke-0401971530490001@ip029.mu3.nwlink.com> In <marke-0401971530490001@ip029.mu3.nwlink.com>, marke@nwlink.com (Mark Eaton) writes: >In article <1996Dec26.004354.2389@seer.demon.co.uk>, >Paul_Lynch@griffin.plsys.co.uk wrote: > >> In article <59p564$o2l@sjx-ixn9.ix.netcom.com> aisbell@ix.netcom.com (Art >> Isbell) writes: >> >> > It seems that Mac developers would like to be able to develop Mac >> > software using OPENSTEP that is nearly 100% source-code compatible with >> the >> > Windows version of the same software. Just think of the increased >> market >> > without much additional effort. Seems like a big win to me. >> > >> > > The NeXT/Apple thing brings something to either parties that each >> other >> > > need: Hardware to NeXT, software to Apple. Whatever concerns Intel >> boxes >> > > isn't of Apple's concerns. >> >> FWIW, I endorse Art's opinions. It seems to me that some of the >> statements from Ellen Hancock would seem to back this up. If Apple can >> persuade developers (even if only vertical market developers) to write for >> OpenStep for portability reasons, then this is a powerful attractant to >> support third party applications on (the future) MacOS. > >The MacApp team have been rumbling for a couple years about a Windows >version of MacApp. There is actually some demand for this. OpenStep would >be an even better solution. > >-Mark > >-- >---> >marke@nwlink.com One benifit you guys have not mentioned - It would allow developers to write programs NOW, for the operating system (Mac/Next) that is not out yet.
From: jamesl@io.com (James Lee) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 6 Jan 1997 17:02:42 GMT Sender: jamesl@jamesl.sirs.com Message-ID: <jamesl-0601971203510001@jamesl.sirs.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <32CF1721.1883@rahul.net> In article <32CF1721.1883@rahul.net>, arnold@lumina.com wrote (among many other insightful things): > We all know viscerally that developers largely do not embrace > change, they tend to stick to legacy code on shipping OSes. Actually, I disagree with this statement. This is usually a management decision based on the expense of converting a large base of legacy code to a new framework. Often management finds it far cheaper to continually patch an old app., even one built with a bloated and outdated framework, than to bite the bullet (and often all too real expense) of starting over from scratch. Most developers I know love having the latest tools work in and frameworks to work with. Thanks- Jim Lee __________________________________________________________________ jamesl@io.com
From: jamesl@io.com (James Lee) Newsgroups: comp.sys.next.programmer Subject: How to best learn NeXT? Date: 6 Jan 1997 17:27:25 GMT Sender: jamesl@jamesl.sirs.com Message-ID: <jamesl-0601971228350001@jamesl.sirs.com> Soliciting recommendations on how to best learn NeXT. Considering buying a NeXTstation 68040/16 for $379 used. Is that a good deal? Is it a good place to start? Please copy me via email. Thanks- Jim Lee __________________________________________________________________ jamesl@io.com
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: sound from NXRecordStream? Date: 6 Jan 1997 18:36:09 GMT Organization: University of Sheffield, UK Message-ID: <5argmp$6lb@bignews.shef.ac.uk> References: <5aek2b$t90@wagner.spc.videotron.ca> In-Reply-To: <5aek2b$t90@wagner.spc.videotron.ca> Followups-To: comp.sys.next.programmer On 01/01/97, Raymond Lutz wrote: > I want to play a sound freshly recorded by a NXRecordStream. > > How? > Depends on when you want to play it... I'm not sure if there's a way to play it *whilst* you're recording -- not easily and not without the likelihood of dropping samples anyway... The way I got round it (based on code sent to me by $an Stephenson, I think) was to use the delegate method (as you point out) @implementation Delegate - soundStream:sender didRecordData:(void *)data size:(unsigned int)numBytes forBuffer:(int)tag { mutex_lock(mlock); bufferTag--; buffsRead++; mutex_unlock(mlock); fwrite((const void *)data, numBytes, 1, fp); // <---- ** vm_deallocate(task_self(), (vm_address_t)data, numBytes); return self; } @end ** Here you can see I'm basically writing the data to a file on disk... Later on when I want to create the Sound object I read the data in from the file... - stop:sender { unsigned char *sndData; unsigned int bytesProcessed; if (recording == YES) { bytesProcessed = [recordStream bytesProcessed]; [(NXSoundStream *)recordStream deactivate]; recording = NO; cthread_join(stuffer_thread); [aSound setDataSize:bytesProcessed dataFormat:sstruct.dataFormat samplingRate:sstruct.samplingRate channelCount:sstruct.channelCount infoSize:4]; sndData = [(Sound *)aSound data]; rewind(fp); fread(sndData, bytesProcessed, 1, fp); fclose(fp); [playButton setState:0]; [playButton setEnabled:YES]; [recordButton setEnabled:YES]; [recordButton setState:0]; [soundView setSound:aSound]; } else { [aSound stop]; } return self; } If anyone knows how to do this more elegantly, maybe they could let me know?! :-) I guess you could copy it into a newly-created SNDSoundStruct, but that's more tricky as you'll have to dynamically allocate the memory for it as you go (and I suspect that you'll then run into problems with alocating enough memory in the time you have before the next bufferfull of data arrives -- I seem to recall I tried this, unsuccessfully). Note that you'll also have to set up a number of other things like stuffer_thread = cthread_fork((cthread_fn_t)dataStuffer, self); [NXSoundIn setUseSeparateThread:YES]; I hope this helps? > Should I wait MacStep to code all this in QuickDraw GX ? > :-) I wonder if any Apple people could show how this could be done on the Mac? (Not a troll -- I'm aware that people like DigiDesign have done inpressive stuff... the SoundKit is one area in NEXTSTEP which has evolved at a rather slower pace than other kits -- maybe we could have some ideas as to how it could be enhanced? Note: Followups to comp.sys.next.programmer) Best wishes, mmalc. --
From: jamesl@io.com (James Lee) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep Date: 6 Jan 1997 18:51:16 GMT Sender: jamesl@jamesl.sirs.com Message-ID: <jamesl-0601971352260001@jamesl.sirs.com> References: <5ami95$ol3@news.tuwien.ac.at> In article <5ami95$ol3@news.tuwien.ac.at>, Robert F Tobler <rft@cg.tuwien.ac.at> wrote: > PROPOSAL: > How to implement resource forks, file types, and file creators in > NeXTstep so that the user interface works like the Macintosh. As a Mac guy I am just curious about the Next world now and have been reading this thread. What is your goal with these interesting proposals? Thanks- Jim Lee __________________________________________________________________ jamesl@io.com
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep Date: 6 Jan 1997 20:38:14 GMT Organization: Vienna University of Technology, Austria Message-ID: <5arnrm$n1v@news.tuwien.ac.at> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> jamesl@io.com (James Lee) wrote: > As a Mac guy I am just curious about the Next world now and have been > reading this thread. What is your goal with these interesting proposals? > Thanks- Jim Lee For current Mac users I wanted to show, that it is not very hard to modify Nextstep to behave like the Macintosh System. Thus we can expect Apple/Next to implement something along these lines within a reasonable time-frame. Mac users should therefore not fear that the Next Apple OS will be any harder or different to use than their current system. For current Nextstep users I wanted to show, that it is very easy to keep the clean implementation and scalability of Nextstep while catering to the needs of current Macintosh users. These proposals would not in anyway reduce the functionality of the current Nextstep system, while still adding all of the Mac interface. Thus I think the fear of Nextstep users, that their system will be 'downgraded' is also unfounded. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: Can't Get NXData to work. Date: 6 Jan 1997 21:58:19 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5arshr$1uu2@news.doit.wisc.edu> I'm trying to copy an array of floating point data across a DO (distributed object) connection by encapsulating it in an NXData object. I have a pre-malloc'ed array of floats, use it to init the NXData object, with the appropriate size (in this case 80 bytes), and then pass it across a DO connection, as in: [remoteobject setData:mydata]; where mydata is of type (NXData *) . When I recieve the object at the server end, the array contains all zeros. However, the size is correct if I do a [mydata size] (80 bytes!). So for some reason it seems the data block is not being passed across the connection but the other instance variables are. Has anybody seen this problem before? I found nothing with a quick search of NextAnswers. -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: grettir@njardvik.orem.novell.com (Shawn Lynn) Newsgroups: comp.sys.next.programmer Subject: qsort = void? Date: 6 Jan 1997 22:43:32 GMT Organization: INTERNET AMERICA Message-ID: <5arv6k$rme@library.airnews.net> I'm compiling INN 1.5.1 and I've solved all of the config.data problems but one. When I attempt to run a make I get the following error message: In file included from getdtab.c:7: ../include/clibrary.h:143: conflicting types for `qsort' /NextDeveloper/Headers/ansi/stdlib.h:79: previous declaration of `qsort' But both clibrary.h and stdlib.h show the same declaration: extern void qsort(); Am I missing something? -- Shawn Lynn "Clothes make the man. Naked grettir@njardvik.orem.novell.com people have little or no influence in society." - Mark Twain
From: Mark Cruver <mcruver@objectgems.com> Newsgroups: comp.object,comp.sys.next.programmer Subject: Smalltalk Positions Date: Mon, 06 Jan 1997 05:31:35 -0500 Organization: OBJECTGems Message-ID: <32D0D486.4727@objectgems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: mcruver@objectgems.com OBJECTGems, a leader in applying Object-Oriented Technologies to solve problems in Business and Industry, is searching for software engineers with experience in OO development and the willingness to learn new technologies - Object-Oriented Databases, Object Request Brokers, WEB application Development, Java, Artificial Intelligence. We will consider both permanent employees as well as independent contractors. We currently have immediate openings the personnel with the following skills: NeXTStep, Objective C VisualWorks Smalltalk; VSE; VisualWave VisualAge Smalltalk for work primarily in the Washington, D.C. and Baltimore metropolitan area as well as throughout the US and some overseas locations. We offer competitive rates or excellent salary and benefits, and the opportunity to work on highly visable projects that are crucial to the mission of our customers; generally using leading edge technology. For consideration, please send your resume by email:mcruver@objectgems.com Office 703-917-6625 Fax: 703-893-8283 Also please visit our Web Site URL:http://www.objectgems.com for Company profile and further job opportunities.
From: Michael.Gentry@mci.com (Michael Gentry) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 6 Jan 1997 23:04:33 GMT Organization: InternetMCI Message-ID: <5as0e1$47q@news.internetmci.com> References: <5altv2$3f8@precipice.fdn.fr> <AEF58CD0-8640A@198.68.42.176> <32D04C67.3FE2@exnext.com.nonsense> In-Reply-To: <32D04C67.3FE2@exnext.com.nonsense> Lawson English wrote: > The OOP-ness of GX is in the API: all shape objects respond to the > same calls in a type-appropriate manner. > > DrawShape(mShape); This is vastly different than NeXT's/Objective-C's: [mShape display]; -- "We love Java, but we believe in choice." - Brad Silverberg, Microsoft Corporation, December 1996
From: "Mark Eaton" <marke@nwlink.com> Newsgroups: comp.sys.next.programmer Subject: Re: Speculation about OS/NT's future, anyone? Date: 6 Jan 97 15:01:16 -0800 Organization: Northwest Link Message-ID: <AEF6C440-1174D9@206.129.238.36> References: <5ams2t$7gl@mercury.IntNet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > One benifit you guys have not mentioned - It would allow > developers > to write programs NOW, for the operating system (Mac/Next) that is > not > out yet. > Sure, the minute Apple says the OpenStep API won't change, this will be possible. But if Apple makes non-trivial changes (probable) I'd rather just wait. -Mark
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.programmer Subject: GX versus DPS (a Trivial example) Date: 6 Jan 1997 15:48:24 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.852594456@idiom.com> So, I'm looking through Apple's docs on GX on the web, and I came across the following code snippet, which apparently draws a ten-pixel wide, fifty percent grey, three-point spline curve, rotated 45 degrees from the base coordinate system of the window in which it is drawn. Apple's sample code follows: /* shape object reference */ gxShape aCurveShape; /* shape geometry definition */ gxCurve aCurveGeometry = {{ff(40), ff(120)}, /* first point */ {ff(100), ff(0)}, /* control point */ {ff(200), ff(120)}};/* last point */ /* color structure */ gxColor halfGray; /* point structure for center point */ gxPoint curveCenter; /* view port object reference */ gxViewPort aViewPort; /* job object reference */ gxJob aPrintJob; /* shape object refernce for picture to contain shape */ gxShape aPage; /* Code to declare window pointer, initialize Macintosh */ /* Toolbox, and create window goes here. */ halfGray.space = gxGraySpace; /* color space is grayspace */ halfGray.profile = nil; /* no color-matching */ halfGray.element.gray = 0x8000; /* 50% intensity */ /* create and draw shape */ aCurveShape = GXNewShape(gxCurveType); GXSetCurve(aCurveShape, &aCurveGeometry); GXSetShapePen(aCurveShape, ff(10)); GXSetShapeColor(aCurveShape, &halfGray); GXSetShapeAttributes(aCurveShape, gxMapTransformShape); GXGetShapeCenter(aCurveShape, 0, &curveCenter); GXRotateShape(aCurveShape, ff(45), curveCenter.x, curveCenter.y); aViewPort = GXGetNewWindowViewPort(theWindow); GXSetShapeViewPorts(aCurveShape, 1, &aViewPort); GXDrawShape(aCurveShape); /* print shape */ GXInitPrinting(); GXNewJob(&aPrintJob); aPage = GXNewShape(gxPictureType); GXSetPicture(aPage, 1, &aCurveShape, nil, nil, nil); GXStartJob(aPrintJob, "\p Rotated Gray Curve ", 1); GXPrintPage(aPrintJob, 1, GXGetJobFormat(aPrintJob, 1), aPage); GXFinishJob(aPrintJob); GXDisposeShape(aPage); GXDisposeJob(aPrintJob); GXExitPrinting(); GXDisposeShape(aCurveShape); The tally: seven variable declarations, ten function calls, and twenty lines of of code. Add the printing stuff, and it's eight declarations, twenty-one function calls, and thirty-one lines of code. Off the top of my head, the way we'd do this in NEXTSTEP using Objective-C and DPS is: #import <appkit/appkit.h> @implementation myView:View // Bear in mind that this is an approximation, since in Postscript we use // Bezier curves, not splines. Also, the default coordinate space in GX // is not cartesian in layout, but is what we'd call a flipped coordinate // space. - drawSelf:(const NXRect *) rects :(int) rectCount { NXSetColor(NX_COLORGRAY); // Constant for a 50% gray value. PSsetlinewidth(10); PSmoveto(40.0, 120.0 ); PScurveto(100.0, 0.0, 100, 0, 200, 120); PSstroke(); } @end The tally: one object created, ten lines of code. There is no seperate printing code. All you need to do to print is send a -printPSCode message to the instance of myView. For rotation, you send a -rotate: -rotateBy: or -rotateTo: message to the view. So, what's the point of this? I'm not sure what the point is, but I will say that the biggest shift in my thinking when I went from the Mac to the NeXT six years ago, was realizing how much code I didn't have to write anymore. I doubt that I'll be using the GX API at all when I move my apps to the Macintosh. -jcr
From: David Riedel <silkcty2@ntplx.net> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Mon, 06 Jan 1997 18:42:40 -0500 Organization: Silk City Software Inc. Distribution: inet Message-ID: <32D18DED.277F@ntplx.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >>One of the most important factors in software development is time >>to market. The OpenStep frameworks, combined with the dynamic nature >>of Objective-C allows for a very short development cycle. If the >>developer has a decently structured application, which all people >>that call themselves developers should have, changing the UI code >>should be very simple. Normally you do not have to change more than >>that when porting to NEXTSTEP. If I have an application written in C++ using templates, exceptions and multiple inheritance, features which are major reasons for developing in C++ to start with, then I have to throw all this out and re-design and rewrite my application. Even if MW succeeds in putting some kind of C++ wrapper around Objective-C, there will be limits on what C++ features can be used for these wrapped classes. >>1) There are plenty of developers on OpenStep today. >>2) Developers are usually early adaptors. >>3) OpenStep is a developers dream. I've heard this in several places but it doesn't matter. The NextStep OS has been rejected by the marketplace over the last 9 years. Next has not made money in the past 3 years. People who buy Macs don't buy them to acess 'legacy' systems. Anyways, If there are so many developers for OpenStep, where are all the Objective-C books?? I searched compubooks database. With over 8700 books listed, there are only 2 for Objective-C, and one of them is from Next! If in fact there is this extensive developer community out there they must keep to themselves a lot. Given that Apple has decided to go with a unix based OS, why didn't they just reprise Aux?
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep Date: 7 Jan 1997 01:33:21 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5as951$361@duke.squonk.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <5arnrm$n1v@news.tuwien.ac.at> Robert F Tobler <rft@cg.tuwien.ac.at> wrote: > jamesl@io.com (James Lee) wrote: > > As a Mac guy I am just curious about the Next world now and > > have been reading this thread. What is your goal with these > > interesting proposals? Thanks- Jim Lee > > For current Mac users I wanted to show, that it is not very hard > to modify Nextstep to behave like the Macintosh System. Thus we > can expect Apple/Next to implement something along these lines > within a reasonable time-frame. Mac users should therefore not > fear that the Next Apple OS will be any harder or different to > use than their current system. > > For current Nextstep users I wanted to show, that it is very easy > to keep the clean implementation and scalability of Nextstep > while catering to the needs of current Macintosh users. These > proposals would not in anyway reduce the functionality of the > current Nextstep system, while still adding all of the Mac > interface. Thus I think the fear of Nextstep users, that their > system will be 'downgraded' is also unfounded. I haven't had the time to really think over your proposals, but they seemed reasonable enough at a glance. Of course, I'm not someone speaking for Apple, so my view doesn't effect much... :-) Note that for some NeXTSTEP users, the issue wasn't so much whether the Mac interface would be a "downgrade", as simply time-to-market. The more time spent changing the NeXTSTEP interface, the longer it will take for this new OS to reach user's hands. Given that I do a lot of Mac support, I can pretty much argue either side of any particular difference in the interfaces. As such, I'm mainly swayed by my desire to see something "sooner" rather than "later". --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: Re: Can't Get NXData to work. Date: 7 Jan 1997 03:10:37 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5aserd$3s98@news.doit.wisc.edu> References: <5arshr$1uu2@news.doit.wisc.edu> Cc: giddings@menominee.chem.wisc.edu In <5arshr$1uu2@news.doit.wisc.edu> Michael Giddings wrote: > So for some reason it seems the data block is not being passed across the > connection but the other instance variables are. > > Has anybody seen this problem before? I found nothing with a quick search of > NextAnswers. > > After a few more hours I figured it out, having to do with data transfer between little-endian and big-endian machines. I guess it was a case of RTFM - once I dug in there and did a more careful reading of the portability guide, I found that the swap functions for floats and doubles can't just be applied at the recieving end: you are required to first use them at the encoding end to convert them into the NXSwappedFloat and NXSwappedDouble types. Strange, but after wasting a whole day to figure this out, it works . . . -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: mmunz@inconnect.com (Mark Munz) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 7 Jan 1997 03:05:29 GMT Organization: Puppy Dog Software Message-ID: <mmunz-0601971958520001@slc-dial-32.inconnect.com> References: <jcr.852594456@idiom.com> In article <jcr.852594456@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: [ lots of source code of GX & DPS- snip] First, if it's Apple source code, there's no telling how verbose it really is (Apple has yet to provide a nice, clean, tight piece of sample code ever). Second, it appears that the GXShape can be retained and used later, but the DPS object is hard-coded MoveTo, LineTo. This appears to be a more object oriented approach for GX. A more accurate comparison would be to create an object in DPS that you could keep around and that could draw itself at different rotations and such. Third, it also looks like the printing code is generic enough to cover all the GX printing - it's quite possible to have a library call that you'd pass a GXPicture to and that's that. Fourth, the lines of source code is valid for some things, but the question is - how much native code is generated by the DPS lines. And how fast is each one. That's what is really important. Fifth, I believe one of the advantages of GX (from what I've been told) is that it is extensible and that DPS requires a change in the definition of DPS language (with a backward compatible interpreter for odl stuff) for additions to it. There are lots of things wrong with GX, but there are lots of things right with it.. Just my two cents. Mark Munz
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 7 Jan 1997 02:52:08 GMT Organization: Netcom Distribution: world Message-ID: <5asdoo$7us@dfw-ixnews8.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <32D18DED.277F@ntplx.net> David Riedel <silkcty2@ntplx.net> wrote: > If I have an application written in C++ using templates, exceptions and > multiple inheritance, features which are major reasons for developing in > C++ to start with, then I have to throw all this out and re-design and > rewrite my application. Even if MW succeeds in putting some kind of C++ > wrapper around Objective-C, there will be limits on what C++ features > can be used for these wrapped classes. The OPENSTEP compiler supports mixing C++ and Objective-C in the same app. Metrowerks has indicated their intention to provide similar capabilities. So you won't need to throw away C++ code that's used for Model classes, the functional core of any application. The Controller classes that bind the Model classes to View classes will need to have all messages to View classes reimplemented in Objective-C, usually not the major portion of an app. View classes must be Objective-C classes, but almost all that you'll need is included in OPENSTEP's AppKit. The use of these classes requires almost no coding because InterfaceBuilder archives instances of View classes that are unarchived at runtime. I can't see any need to wrap C++ classes around Objective-C, or vice-versa. They can coexist in most cases. Templates are a hack to deal with C++'s strict typing that aren't needed in Objective-C (hope my lack of full understanding of templates isn't showing too much :-) An Objective-C collection can contain objects of any type and can even include objects of different types without the need to resort to some sort of template mechanism. NeXT has implemented exceptions outside of Objective-C. OPENSTEP exceptions can be raised (thrown), caught at any stack frame at or above where they were raised, and handled accordingly. Exception memory management is handled by OPENSTEP's memory management which automatically releases autoreleased memory at the end of every event even if an exception has been raised. Maybe C++ exceptions offer something more, but I doubt that most C++ programmers will feel too deprived. Multiple inheritance is not directly supported in Objective-C, a situation that many feel is an advantage, but some may miss. Multiple inheritance can be simulated using Objective-C's ability to forward unimplemented messages to another object which can provide the functionality that multiple inheritance might provide. I don't think most programmers feel that the lack of true multiple inheritance is a problem. > I've heard this in several places but it doesn't matter. The NextStep > OS has been rejected by the marketplace over the last 9 years. Next has > not made money in the past 3 years. Unfortunately, I'd say that Apple shares a lot of these same problems with NeXT. As you know, technical excellence doesn't necessarily correlate well with market success. You're discussing technical issues here, not lame marketing which NeXT and Apple are both guilty of. People who buy Macs don't buy them > to acess 'legacy' systems. Apple has stated that it intends to target such markets, though. But then we've never accessed a legacy system with our NeXT machines, either. We use them for client access to today's database servers, not yesterday's legacy systems. > Anyways, If there are so many developers for OpenStep, where are all the > Objective-C books?? I searched compubooks database. With over 8700 > books listed, there are only 2 for Objective-C, and one of them is from > Next! Once you see how simple Objective-C is compared with C++, you'll understand why few books exist. Any C++ programmer can learn Objective-C in a day of self-study with the documentation supplied by NeXT. The language isn't where most of OPENSTEP's power lies - it's in the object kits where most of the learning process must occur. And one really needs to understand object-oriented analysis and design which isn't an Objective-C issue per se. If in fact there is this extensive developer community out there > they must keep to themselves a lot. They are mostly in large companies doing in-house mission-critical application development, something that these companies don't care to advertise to their competitors. Then there are the 3-letter government agencies that don't talk about anything they do :-) > Given that Apple has decided to go with a unix based OS, why didn't they > just reprise Aux? Must be because of everything else that OPENSTEP has to offer. We take the underlying operating system for granted and don't deal with it much in our programming. The OPENSTEP object kits and development tools are where the real value lies. The underlying operating system provides the solid support for robust applications, something that has been missing from the Mac but that doesn't seem like a big deal to us. However, we'd hate to be without it. I'm pretty dismayed by all of the antagonism that's being exchanged among Mac and OPENSTEP programmers. We're going to need help from each other in the future if we're going to make this thing work, so let's not poison the atmosphere at this early stage when none of us knows what's really going to happen. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Norbert Heger <bertl@hal.kph.tuwien.ac.at> Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 7 Jan 1997 11:13:33 GMT Organization: Vienna University of Technology, Austria Message-ID: <5atb4t$crq@news.tuwien.ac.at> References: <32D18DED.277F@ntplx.net> Originator: bertl@gemini David Riedel <silkcty2@ntplx.net> writes > Anyways, If there are so many developers for OpenStep, where are all the > Objective-C books?? I searched compubooks database. With over 8700 > books listed, there are only 2 for Objective-C, and one of them is from > Next! That shows how easy programming can be using Objective-C. You don't NEED more than two books! Sorry, I couldn't resist... ;-) - N.C. _________________________________________________________________ Norbert C. Heger <bertl@hal.kph.tuwien.ac.at> NEXTSTEP / OpenStep Software Development NeXTmail preferred, MIME is welcome Please finger for PGP public key
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 7 Jan 1997 03:42:08 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.852636452@idiom.com> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> mmunz@inconnect.com (Mark Munz) writes: >In article <jcr.852594456@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: >[ lots of source code of GX & DPS- snip] >First, if it's Apple source code, there's no telling how verbose it really >is (Apple has yet to provide a nice, clean, tight piece of sample code >ever). Good point. I remember the examples in Inside Macintosh from my system 6.x days. >Second, it appears that the GXShape can be retained and used later, but >the DPS object is hard-coded MoveTo, LineTo. This appears to be a more >object oriented approach for GX. A more accurate comparison would be to >create an object in DPS that you could keep around and that could draw >itself at different rotations and such. Actually, if I were following the usual practice in NEXTSTEP coding, I'd have defined a Shape class, which had orientation, color, etc. attributes, which any View could use. (Note to non-NeXT programmers: a View in NeXTSTEP is an object which renders part of the contents of a window, and receives the events that occur within that part. Views have a clipping boundary, they have a postscript drawing context, they can draw themselves to the screen, or to the printing machinery.) Incidentally, I coud have created a userpath in the DPS server, if I wanted it to stick around. userpaths take advantage of the font-caching system, and they're very fast. >Third, it also looks like the printing code is generic enough to cover all >the GX printing - it's quite possible to have a library call that you'd >pass a GXPicture to and that's that. >Fourth, the lines of source code is valid for some things, but the >question is - how much native code is generated by the DPS lines. And how >fast is each one. That's what is really important. I will also mention, that the example I wrote previously is using the single-operator PS library calls, which is not the most efficient way to do this. I could also have written my rendering code in PS, and run it through pswrap to generate a binary object sequence. >Fifth, I believe one of the advantages of GX (from what I've been told) is >that it is extensible and that DPS requires a change in the definition of >DPS language (with a backward compatible interpreter for odl stuff) for >additions to it. PS is a threaded intrepeted language. What could possibly be more extensible? If I write: /rectpath { /x exch def /y exch def /w exch def /h exch def newpath x y moveto w 0 rlineto 0 h rlineto w neg 0 rlineto closepath } bind def Then rectpath works just like it had always been there. In fact, I know of research projects where people used postscript to add functionality to servers and device drivers, that had nothing to do with graphics. It is a turing-complete programming language. You can write a LISP interpreter in it if you like! -jcr >There are lots of things wrong with GX, but there are lots of things right >with it.. >Just my two cents. >Mark Munz
From: nervous@system.net (Nervous) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 07 Jan 1997 00:33:10 -0500 Organization: Central Nervous System Message-ID: <nervous-0701970033100001@ascend6.netrover.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> Dated: 1.6.97 The exclusive information can be found at: http://www.macworld.com/daily/daily.912.html In brief - System 7.6 Harmony in late January - System 7.7 Tempo in July - System 7.8 Allegra in early 1998 - System 7.9 Sonata in mid-1998 - MacOS 8 code-named Rhapsody (in blue? see below) - 'Blue Box' window in Rhapsody to run System 7.x applications - new OS based on NeXTStep is called 'Yellow Box' - NeXTStep interface to be Mac-like. (Sorry NeXT mongers =) "...the company is convinced that the Mac OS's human interface is the best available and wants to ensure that this approach is maintained." (MacWorld 1.6.97) - UNIXness of MacOS 8 will be hidden - Appearance Manager to be implemented - continued support of Intel x86 and SunSparc versions of NeXTStep OS -- GO Mac GO!!!
From: "Jonathan W. Hendry" <jon@exnext.com.nonsense> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Tue, 07 Jan 1997 12:35:31 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D28963.6C27@exnext.com.nonsense> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Followups trimmed. Nervous wrote: > - NeXTStep interface to be Mac-like. (Sorry NeXT mongers =) > > "...the company is convinced that the Mac OS's human interface is > the best available and wants to ensure that this approach is > maintained." (MacWorld 1.6.97) Cutting the first part of that statement is a little dishonest, nervous. The full statement is: "While Apple will adopt some NextStep conventions, the company is convinced that the Mac OS's human interface is the best available and wants to ensure that this approach is maintained." Sorry, 'nervous'. Care to guess what those NextStep conventions might be? Left-side scrollbars? Menus? Dock? Browser? -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Tue, 7 Jan 1997 18:23:44 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Distribution: inet Message-ID: <E3nHrL.1tB@cam-ani.co.uk> References: <32D18DED.277F@ntplx.net> In article <32D18DED.277F@ntplx.net> David Riedel <silkcty2@ntplx.net> writes: > Anyways, If there are so many developers for OpenStep, where are all the > Objective-C books?? I searched compubooks database. With over 8700 > books listed, there are only 2 for Objective-C, and one of them is from > Next! If in fact there is this extensive developer community out there > they must keep to themselves a lot. There is very little need for an Objective-C book. Reason: Objective C is REALLY EASY. I do own a copy of "the" ObjectiveC book (Object Oriented Programming, an Evolutionary Aproach, Brad Cox and somoneoneelseski), and it's a great read, but only a small part of it is about teaching the language, and much of it is about concepts and ideas. I've programmed NeXTStep commercially for a few years, in a number of places, and many developers have never read it, and no one ever needs to refer to it. Contrast this with C++ there "the" book is three times thicker, and is entirly dedicated to trying to explain the language (including long lists of pratfalls waiting for anyone who is less than perfect to fall into). Every C++ programmer has a copy of this book, and most (self included) keep a copy by their desk. (Stroustrup (see I can spell this one cause its 4" form my left hand) new little about designing programming languages but everything about setting himself up a nice nestegg as an author) For those that DONT want to read teh ObjC book: $ans 5 minute tutotial on Objective C to define a class: #include "SuperClass.h" @interface MyClass : SuperClass { int instanceVar; float anotherInstanceVar; id aGenericObject; } +AClassMethod; -anInstanceMethod; -anInstanceMethodWith:param; -anInstanceMethodWith:param and:anotherParm; -anInstanceMethodWith:param and:anotherParm and:paramEtc; //Not the following has a non object param -setFloatValue:(float)val; @end Put the above in MyClass.h The following in MyClass.m @implementation MyClass +aClassMethod { puts("This is a class method - they're quite rare"); } -anInstanceMethod { //Call anInstanceMethodWith: in the current object //with a parameter of 0 [self anInstanceMethodWith:nil]; } -anInstanceMethodWith:param { //Param is of type id. // If our parameter was nil then make one if(param=nil) { //init is a convention //it is the standard default initialiser param=[[AClass alloc] init]; //Note Capital first letter for a Class (convention) //Lowercase first letter for an instance (convention) //param could be initiallised by a something more complex } //note we DON'T real know the class of param //it could be AClass, but not necessaritly [param setIntValue:instanceVar]; } -setFloatValue:(float)val { //If val is <= 0 we use the implementation in our superclass if(val >0) floatValue=val; else [super setFloatValue:val]; } .... implement all the rest .... @end There are also Catagories: @interface MyClass (aCatagory) -moreMethods; @end @implementaion MyClass (aCatagory) -moreMethods { //Clever bit thats you don't HAVE to know [aGenericObject makeObjectPerform:@selector(wibble)]; //Is a clever way of doing // [aGenericObject wibble]; // but @selector(wibble) is an expression which can //be assigned and passed as a parameter! } @end Adds another method to MyClass, so it can be broken up. Thats about it! The only other thing I can think of are Protocols, and they're not a core part of the language. It's REALLY hard to spin that out to a whole book. Hence there are no books. Perhaps it should have been made more difficult, and then you'd be happy! $an
From: cortesr@alleg.edu Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 7 Jan 1997 19:38:07 GMT Organization: Allegheny College Message-ID: <5au8mv$j8l@speering.alleg.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D28963.6C27@exnext.com.nonsense> Jonathan: Might wanna check out: http://www.macworld.com/daily/daily.912.html Tells details on the new os. Ricardo -- Ricardo Cortes Allegheny College cortesr@alleg.edu (NeXTMail OK) http://ace.alleg.edu/~cortes
From: dave@rsd.com (Dave Goldman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 07 Jan 1997 13:17:46 -0800 Organization: Research Software Design Message-ID: <dave-0701971317460001@ip-pdx03-33.teleport.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <32CF1721.1883@rahul.net> <jamesl-0601971203510001@jamesl.sirs.com> In article <jamesl-0601971203510001@jamesl.sirs.com>, jamesl@io.com (James Lee) wrote: > In article <32CF1721.1883@rahul.net>, arnold@lumina.com wrote (among many > other insightful things): > > We all know viscerally that developers largely do not embrace > > change, they tend to stick to legacy code on shipping OSes. > Actually, I disagree with this statement. This is usually a management > decision... > ... Most developers I know love having the latest tools work in > and frameworks to work with. For the purposes of this sort of discussion, it seems to me that the term "developer" refers to the _organization_ that develops software. Doesn't really change the outcome if it's management making the decision rather than the programmers. -- Dave Goldman Research Software Design
From: Joseph Strout <jstrout@ucsd.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 7 Jan 1997 15:06:37 -0800 Organization: The University of California at San Diego Message-ID: <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <nervous-0701970033100001@ascend6.netrover.com> gOn Tue, 7 Jan 1997, Nervous wrote: > - NeXTStep interface to be Mac-like. (Sorry NeXT mongers =) > > "...the company is convinced that the Mac OS's human interface is > the best available and wants to ensure that this approach is > maintained." (MacWorld 1.6.97) It can't be the best available, since it lacks proportionally sized scroll bars. GS/OS, NextStep, X-Windows, and others all have this. (Ironically, Apple had it first, with GS/OS, but they never moved it to the Mac.) Smart Scroll helps, but too many apps do funky things with their scroll bars that Smart Scroll can't figure out... OTOH, I just saw that BeOS is available for off-the-shelf PowerMacs now, and it already runs MacOS apps! And it should be shipping (non-beta) soon. Sounds like a good deal to me! ,------------------------------------------------------------------. | Joseph J. Strout Department of Neuroscience, UCSD | | jstrout@ucsd.edu http://www-acs.ucsd.edu/~jstrout/ | `------------------------------------------------------------------'
From: John Hornkvist Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 6 Jan 1997 18:45:17 GMT Organization: Chalmers Tekniska Högskola Distribution: world Message-ID: <5arh7t$2no@nyheter.chalmers.se> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> Cc: aisbell@ix.netcom.com In <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> Art Isbell wrote: >John Hornkvist wrote: > >> By the way, IIRC almost every major change of NEXTSTEP has forced >> developers to rewrite applications. /.../ > > This seems overstated. We have been developing under NEXTSTEP since 1.0a >and our only rewrite has been the recent NEXTSTEP->OPENSTEP conversion, much >of which was handled by automated conversion tools supplied with OPENSTEP. >When NEXTSTEP 2.0 was released, the small number of classes and methods that >were scheduled to become obsolete were supported through the various 2.x >releases and dropped when 3.0 was released allowing more than a year to >replace obsoleted code. I can't recall anything similar when 3.0 was >released other than several new object kits being added although there may >have been a few more obsoleted classes and methods that were supported >through the 3.x releases. I did not enter the NS world until version 3.2, but I have definitely heard complaints from developers about changes in the kits requiring them to rewrite applications. Those developing for the Music Kit, or DSP kit would be examples of that, I imagine. > When I worked on the NEXTSTEP port of WingZ, originally a Mac app, the >port was not nearly as easy as you imply. Many of the View classes are >provided by NeXT and included without code using InterfaceBuilder. This >didn't seem to be the case with the Mac version for which much View code >existed and had to be converted to InterfaceBuilder nib files. But MacApp >may not have been used for the original WingZ, so maybe this isn't a valid >comparison. If WingZ is a good example of how Macintosh apps are generally written, it does imply a problem. However, it may be easier for the original developers to do the port, since they are likely to be familiar with the code. >> Normally you do not have to change more than >> that when porting to NEXTSTEP. > > Methinks Mac apps will require a considerable porting effort >unless Apple and NeXT put a lot of effort into conversion tools. What worries me about this scenario is integration between the user interfaces. On the Amiga, for example there was a framework for easy porting of X-windows based applications. Those generally integrated far from seamlessly with the UI. The same was true with the transition from Amiga OS 1.3 to 2.0, where the look and feel of the UI changed. Old applications kept their look, and that was very negative. As I recall, most applications were quickly rewritten to benefit from the improved UI, though. Or replaced by applications from other sources with the new look and feel. To quote Percy Barnevik, board member of DuPont, and General Motors among other things: "It is better to be a little wrong early than to be completely right to late." --- John Hornkvist --- nhoj at cd dot chalmers dot se Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97? Sorry for not leaving my address in the header, but I get too many spam mails already... If you want to reach me, try nhoj at cd dot chalmers dot se
From: MWRon@metrowerks.com (MW Ron) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 07 Jan 1997 20:46:55 -0500 Organization: Metrowerks Distribution: world Message-ID: <MWRon-0701972046550001@aumi3-a03.ccm.tds.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> <5arh7t$2no@nyheter.chalmers.se> In this press release today, METROWERKS & APPLE COMPUTER SIGN DEVELOPMENT AGREEMENT FOR PORTING CODEWARRIOR TOOLS TO RHAPSODY, APPLE'S NEXT GENERATION OS Was this.... 3. Metrowerks PowerPlant To Be Transitioned to Rhapsody Metrowerks PowerPlant application framework will be transitioned to Rhapsody. Metrowerks and Apple Computer intend to outline and implement a transition strategy that will allow developers using Metrowerks' PowerPlant application framework to move their applications to Rhapsody as rapidly as possible. Ron -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 7 Jan 1997 18:57:03 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF85026-2F6EF@198.68.42.153> References: <32D28963.6C27@exnext.com.nonsense> nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.mac.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit >The full statement is: > >"While Apple will adopt some NextStep conventions, the >company is convinced that the Mac OS's human interface >is the best available and wants to ensure that this approach is >maintained." > >Sorry, 'nervous'. Care to guess what those NextStep >conventions might be? Left-side scrollbars? Menus? >Dock? Browser? > From the various pieces taht I've seen (couldn't see the presentation, only heard it), System 7.9 will have the same GUI as the first bundled version of Rhapsody. Should be very interesting to see what they come up with. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.sys.next.programmer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 7 Jan 1997 20:04:00 -0700 Organization: Primenet Services for the Internet Message-ID: <AEF85FBF-6A0FC@198.68.42.153> References: <5as0e1$47q@news.internetmci.com> nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >> The OOP-ness of GX is in the API: all shape objects respond to the >> same calls in a type-appropriate manner. >> >> DrawShape(mShape); > >This is vastly different than NeXT's/Objective-C's: > > [mShape display]; Sure. In C++ it would have been: myShape.display; The problem is that GX was done before any way existed to create an OOP library for the Mac OS, so they needed a non-OOP API. OpenDOc does the same thing with the "ev" variable. --------------------------------------------------- "Without a new GUI that is as innovative and ground-breaking as the original was in its time, the Macintosh will cease to matter, and we should all go home." -Me ---------------------------------------------------
From: carol1@apple.com (Andrew Carol) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 07 Jan 1997 21:18:12 -0800 Organization: Apple Computer, Inc. Message-ID: <carol1-0701972118120001@17.219.103.211> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> <5aq7uf$7vo@huffalump.visi.com> <32D2D0AD.6870@m4.sprynet.com> In article <32D2D0AD.6870@m4.sprynet.com>, piercej@sprynet.com wrote: > Not really. I didn't say processor dependant, I said OS dependant. > OpenStep is an OS and applications using it require it to be installed. OpenStep is _not_ an OS. It is an GUI API layed on top of an OS. OpenStep is runing today on at least 3 different OS's: 1) Solaris 2) Next Mach 3) NT -- Andrew Carol carol1@apple.com I do not speak for Apple. All opinions are my own.
From: bononno@acf2.nyu.edu (Robert Bononno) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 07 Jan 1997 22:55:57 -0500 Organization: Techline Message-ID: <bononno-ya023680000701972255570001@news.nyu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <Pine.SGI.3.94.970107150251.22376D-100000@ranvier>, Joseph Strout <jstrout@ucsd.edu> wrote: > >OTOH, I just saw that BeOS is available for off-the-shelf PowerMacs now, >and it already runs MacOS apps! And it should be shipping (non-beta) >soon. Sounds like a good deal to me! It does? I thought it didn't. BeOS will run my Mac applications? That's a possibility I had sort of forgotten about. And it will run on my 8500? Be has been hard at work I see. -- ------------------------------------------------------ Robert Bononno - bononno@acf2.nyu.edu - CIS:73670,1570
From: bononno@acf2.nyu.edu (Robert Bononno) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 07 Jan 1997 22:52:44 -0500 Organization: Techline Message-ID: <bononno-ya023680000701972252440001@news.nyu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <nervous-0701970033100001@ascend6.netrover.com>, nervous@system.net (Nervous) wrote: >Dated: 1.6.97 > >The exclusive information can be found at: > >http://www.macworld.com/daily/daily.912.html > >In brief - System 7.6 Harmony in late January > - System 7.7 Tempo in July > - System 7.8 Allegra in early 1998 > - System 7.9 Sonata in mid-1998 > - MacOS 8 code-named Rhapsody (in blue? see below) Yeah, but like when? Already we're into mid-98 here. Assume Rhapsody is the NeXT-based OS for Macintosh. So this is 1.5 to 2 years away. That's a long, long time in this business. > - 'Blue Box' window in Rhapsody to run System 7.x applications > - new OS based on NeXTStep is called 'Yellow Box' > - NeXTStep interface to be Mac-like. (Sorry NeXT mongers =) Too bad. I was hoping they would go with the NeXT GUI. > > "...the company is convinced that the Mac OS's human interface is > the best available and wants to ensure that this approach is > maintained." (MacWorld 1.6.97) > > - UNIXness of MacOS 8 will be hidden Totally hidden? No Unix at all? I was hoping they'd keep that aspect for some reason. > - Appearance Manager to be implemented > - continued support of Intel x86 and SunSparc versions of NeXTStep OS Well, that's good. Might provide a revenue stream for Apple/NeXT. -- ------------------------------------------------------ Robert Bononno - bononno@acf2.nyu.edu - CIS:73670,1570
From: spamwall@zercom.net (Martin-Gilles Lavoie) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 8 Jan 1997 13:41:26 GMT Organization: Groupimage, inc. Message-ID: <spamwall-0801970839370001@204.191.6.170> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> In article <nervous-0701970033100001@ascend6.netrover.com>, nervous@system.net (Nervous) wrote: > Dated: 1.6.97 > > The exclusive information can be found at: > > http://www.macworld.com/daily/daily.912.html > > In brief - System 7.6 Harmony in late January > - System 7.7 Tempo in July > - System 7.8 Allegra in early 1998 > - System 7.9 Sonata in mid-1998 > - MacOS 8 code-named Rhapsody (in blue? see below) [...] This isn't exclusive at all. I've downloaded all of this info (in great details, including time graphs) on Jan 7th at 4pm (eastern time), off Apple's DevWorld web site. At that time, www.apple.com was totally inaccessible (lots of trafics I guess), so lowwing to www.devworld.apple.com gave all info requested. Download at will. ================================================================= Please reply using the following address, rather than the "reply-to" address (my mail box is being filled with junk mail). ================================================================= Martin-Gilles Lavoie | Opinions expressed herein are just that. mouser@zercom.net | "No! Do, or do not. There is no try." Globimage, inc. | --Yoda on error handling
From: stephen_ma@mindlink.net (Stephen Ma) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Wed, 08 Jan 1997 01:30:28 -0800 Organization: MIND LINK! - British Columbia, Canada Distribution: inet Message-ID: <0k20yMppj+2S091yn@mindlink.net> References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> ians@cam-ani.co.uk (Ian Stephenson) wrote: >[impressively concise example using nearly all of Objective-C] > >Thats about it! The only other thing I can think of are Protocols, and >they're not a core part of the language. > >It's REALLY hard to spin that out to a whole book. Hence there are no >books. Perhaps it should have been made more difficult, and then you'd be >happy! You really seem to have covered the basics. I'd like to ask one question though: occasionally I see code that uses expressions like @"string" @(..., ..., ...) What are these things? There's no mention of them in NeXT's Objective-C book. --------------------------------------- Stephen Ma <stephen_ma@mindlink.bc.ca>
From: stephen_ma@mindlink.net (Stephen Ma) Newsgroups: comp.sys.next.programmer Subject: Interface Builder tutorial: rtfd headache Date: Wed, 08 Jan 1997 01:41:04 -0800 Organization: MIND LINK! - British Columbia, Canada Message-ID: <wu20yMppjOna091yn@mindlink.net> I downloaded the Interface Builder tutorial from ftp://ftp.next.peak.org/pub/next/documents/next/NeXT_IB_Tutorial.tar.gz but found to my dismay that it's in NeXT rtfd format. It seems almost compatible with standard PC word processors, but not quite. I suppose I could hack it until it fits, but I understand that anyone running NeXT could easily convert it to Postscript. Would some kind soul upload the Postscript (or, better yet, the Acrobat PDF) to peak? Thanks. --------------------------------------- Stephen Ma <stephen_ma@mindlink.bc.ca>
From: onscrn@aol.com (Bob Estes) Newsgroups: comp.sys.next.programmer Subject: Basic question about OpenStep Date: 8 Jan 1997 14:56:56 GMT Organization: OnScreen Science, Inc. Message-ID: <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net> Please excuse my ignorance, but it's amazing how many messages on OpenStep I've read without getting the answer to this basic question: Is OpenStep required to be present in order to run programs written using OpenStep? My assumption had always been yes, but I've read so many times that "if you write an OpenStep program it automatically will run on NT etc." I'm confused. So, can anyone with a machine running "stock" NT (no OpenStep addition of any kind) fire up a program written using OpenStep (compiled for the particular type of machine the user has) and run it? Bob Estes onscrn@aol.com
From: nervous@system.net (Nervous) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 8 Jan 1997 14:54:30 GMT Organization: Central Nervous System Message-ID: <nervous-0801970955030001@ascend3.netrover.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> <bononno-ya023680000701972255570001@news.nyu.edu> In article <bononno-ya023680000701972255570001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: In article <Pine.SGI.3.94.970107150251.22376D-100000@ranvier>, Joseph Strout <jstrout@ucsd.edu> wrote: > >OTOH, I just saw that BeOS is available for off-the-shelf PowerMacs now, >and it already runs MacOS apps! And it should be shipping (non-beta) >soon. Sounds like a good deal to me! It does? I thought it didn't. BeOS will run my Mac applications? That's a possibility I had sort of forgotten about. And it will run on my 8500? Be has been hard at work I see. Only 68K apps that aren't hardware dependent. -- rhapsody: rhap.so.dy \'rap-s*d-e-\ n recitation of selections from epic poetry; a highly emotional utterance or literary work; RAPTURE, ECSTASY; the new Macintosh OS.
From: "Dirk P. Fromhein" <Dirk.Fromhein@watershed.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 11:32:41 +0500 Organization: Watershed Technologies, Inc. Message-ID: <32D33F89.7C0E@watershed.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> <5arh7t$2no@nyheter.chalmers.se> <MWRon-0701972046550001@aumi3-a03.ccm.tds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: MW Ron <MWRon@metrowerks.com> I've used both NeXT's AppKit and Wetrowerks' PowerPlant. Getting PowerPlant to work under the AppKit will be a very very difficult thing. The development methodology differs greatly between C++ and Objective-C, you can't map on to the other... you just can't. Take a good hard long look at InterfaceBuilder for NeXTSTEP. What do you see? No code generation! You can't do a InterfaceBuilder with C++ without doing code generation. Will PowerPlant be Objective-C or C++? My point is that if you are going to go with a new paradigm, go with it. At some point you have to cut the baggage loose. Every project I have worked with that started with the premise that "we have to build on what we have even if it's not all that great" or "this new technology is cool, but we have to hedge our bets and keep some tie to what everyone else is using" has ended up being late, slow, bloated, and buggy. Only when you embrace a new technology (that is sound) and use it to it's limits do you get the phenomial bennefits most projects are looking for. It's interesting that Art mentioned WingZ, I find it a perfect example of the above. The app was very cool (unbelievably fast), but the UI was a "port". It did not feel like a NeXT app, nor did it behave like one. Most NeXT sites decided to go with a more natural fit, a spreadsheet that felt like a NeXT application (that I happened to work on: Mesa). Not that we should not have hired a GUI designer... :-) I've been doing NeXTSTEP since '90 and the Mac since '87. NeXTSTEP was love at first sight. I really hope that Apple does not screw NeXSTEP up while trying to preserve the past, they have already made some disturbing comments (I'm betting that they will screw it up). But all this is irrelevant as I think Java will be *THE* programming language from now on (for custom apps and even shrinkwap apps). Cheers, Dirk Fromhein df@watershed.com ================ Sure, Win95 == MacOS 85, but don't forget MacOS 97 == MacOS 85
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 8 Jan 1997 16:53:33 GMT Organization: Netcom Distribution: world Message-ID: <5b0jed$89r@sjx-ixn10.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> <5arh7t$2no@nyheter.chalmers.se> John Hornkvist wrote: > What worries me about this scenario is integration between the user > interfaces. On the Amiga, for example there was a framework for > easy porting of X-windows based applications. Those generally > integrated far from seamlessly with the UI. > The same was true with the transition from Amiga OS 1.3 to 2.0, > where the look and feel of the UI changed. Old applications kept > their look, and that was very negative. The DPS window server used by OPENSTEP along with some changes to the various UI classes seem to be able to produce the NEXTSTEP, Windows 95, and Solaris (I believe) looks-and-feels and native behaviors quite well, so I assume that the Mac look-and-feel will be relatively easy to produce as well. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 8 Jan 1997 17:02:43 GMT Organization: Netcom Distribution: world Message-ID: <5b0jvj$89r@sjx-ixn10.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> <5aq7uf$7vo@huffalump.visi.com> <32D2D0AD.6870@m4.sprynet.com> piercej@m4.sprynet.com wrote: > OpenStep is an OS OPENSTEP/Mach is an OS, but OPENSTEP/NT and OPENSTEP/Solaris aren't OS's - they're development and runtime environments that require the support of an underlying OS. and applications using it require it to be installed. > It is impossible for me to ship applications on W95 and WindowsNT > without requiring users to license and install OpenStep first. > > Even if users could obtain it free, they may not be willing to install > the environment since it adds overhead they may not feel is justified. Many Windows apps require the dynamic link libraries (DLLs) used to support their development environments. These DLLs are delivered with apps. This is the same approach used by OPENSTEP/NT whose runtime consists of DLLs and several (4?) daemons (processes running in the background). But your point of additional overhead is a valid one. OPENSTEP/NT probably increases overhead more than most runtime environments because it includes its own DPS window server, name server used for interapplication communications even across networks, Mach emulation daemon, and pasteboard server. Including these components eased the port of OPENSTEP to NT and adds capabilities that were not available under NT, so the news isn't all bad. I'm sure that this overhead can be reduced somewhat given a little more time and effort. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: geoff.clapp@apple.com (Geoffrey Clapp) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 09:42:50 -0800 Organization: Apple Computer, Inc. Message-ID: <geoff.clapp-0801970942500001@clapge.apple.com> References: <5aigjj$72u$1@aggedor.rmit.edu.au> <E3FvoM.Dun@cam-ani.co.uk> In article <E3FvoM.Dun@cam-ani.co.uk>, ians@cam-ani.co.uk (Ian Stephenson) wrote: >OK... I've never actually USED MacApp, but as I understand it, it's very >simlar _in_principle_ to the AppKit. The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, MFC, TCL, etc. etc. The question is where do we go and how do we get there. MetroWerks has already committed to PowerPlant for Rhapsody, but what does that really mean in terms of code portability, etc? Who knows....there are a ton of issues to still work out. >A port of MacApp threfore DOESN'T make sense, because the AppKit provides >the same basic functionality, but in a more complete, and standard way - >all NeXT apps (with very few exceptions) use the AppKit. And I have never used AppKit, but in pure number of classes, methods, and coverage, it is a less mature, smaller framework than MacApp. It certainly does not cover the breath of OS type features that MacApp does, but it does cover other areas more completley. I think what you are seeing is that there might be a convergence opporunity. I am amazed how many people think this has to be an all or none....it's a "merger" right? ;-> >> Will I be able to port my MacApp programs to NeXT? >you will be able to _PORT_ them. .....or run them in the compatilbility layer "blue box" geoffrey -------------------------------------------- Geoffrey Clapp Apple Computer, Inc. OpenDoc Engineering geoff.clapp@apple.com --------------------------------------------
Message-ID: <32D40A8C.712@nmaa.org> Date: Wed, 08 Jan 1997 12:58:52 -0800 From: Daniel Fahey <dansources@nmaa.org> Organization: DanSources Technical Services Inc. MIME-Version: 1.0 Newsgroups: comp.sys.next.programmer Subject: JOBS: Next Developers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Nexstep Developers We are seeking a bunch of Nextstep, EOF, Objective-C Developers for the monster program in Northern Virginia. Please contact us (301-217-0425)if you are interested. This program will have a lot CORBA exposure to connect with the Legacy. You would be working with the CORBA Developers and learn CORBA.. Thanks Sincerely, Dan Fahey
From: ibhan@student.med.harvard.edu (Ishir Bhan) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 08 Jan 1997 13:36:04 -0500 Organization: Harvard Medical School Message-ID: <ibhan-0801971336040001@infobhan.med.harvard.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> In article <bononno-ya023680000701972252440001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: > Yeah, but like when? Already we're into mid-98 here. Assume Rhapsody is the > NeXT-based OS for Macintosh. So this is 1.5 to 2 years away. That's a long, > long time in this business. Rhapsody is supposed to be released at the same time as 7.8. That is, one year from now. The developer release will preceed it by several months (possibly as soon as 6). -- Ishir Bhan Harvard Medical School '00 ibhan@student.med.harvard.edu http://www.digitas.harvard.edu/~ibhan
From: SoundChaser <soundchaser@velodrome.com> Newsgroups: comp.sys.next.programmer Subject: Re: Basic question about OpenStep Date: Wed, 08 Jan 1997 10:44:38 -0800 Organization: hmmm Message-ID: <32D3EB16.65C@velodrome.com> References: <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob Estes wrote: > > Please excuse my ignorance, but it's amazing how many messages on OpenStep > I've read without getting the answer to this basic question: Is OpenStep > required to be present in order to run programs written using OpenStep? Yes > My assumption had always been yes, but I've read so many times that "if you > write an OpenStep program it automatically will run on NT etc." I'm Marketing Hype > confused. So, can anyone with a machine running "stock" NT (no OpenStep > addition of any kind) fire up a program written using OpenStep (compiled > for the particular type of machine the user has) and run it? No > > Bob Estes > onscrn@aol.com
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 8 Jan 1997 19:15:04 GMT Organization: Global Objects Inc. Message-ID: <5b0rno$48e@news.xmission.com> References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> stephen_ma@mindlink.net (Stephen Ma) wrote: > [...] I'd like to ask one > question though: occasionally I see code that uses expressions like > > @"string" > @(..., ..., ...) > > What are these things? There's no mention of them in NeXT's > Objective-C book. This is syntactic sugar--almost a macro. The first one creates an NSString object with the specified value and the second creates an NSArray populated with the comma delimited list of objects between the parenthesis. Pretty simple stuff and a recent addition to the compiler as of the creation of the NeXT FoundationKit. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 13:31:12 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D3E7F0.4EE1@exnext.com> References: <5aigjj$72u$1@aggedor.rmit.edu.au> <E3FvoM.Dun@cam-ani.co.uk> <geoff.clapp-0801970942500001@clapge.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey Clapp wrote: > > In article <E3FvoM.Dun@cam-ani.co.uk>, ians@cam-ani.co.uk (Ian Stephenson) > wrote: > > >OK... I've never actually USED MacApp, but as I understand it, it's very > >simlar _in_principle_ to the AppKit. > > The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, > MFC, TCL, etc. etc. Please, Geoffrey. Please don't mention MFC in the same sentence as the NeXT frameworks (and MacApp and PowerPlant), let alone say they're 'very similar'. ;) -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 8 Jan 1997 19:23:19 GMT Organization: Rockwell Avionics - Collins Distribution: inet Message-ID: <5b0s77$26t@castor.cca.rockwell.com> References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> Cc: stephen_ma@mindlink.net In <0k20yMppj+2S091yn@mindlink.net> Stephen Ma wrote: > You really seem to have covered the basics. I'd like to ask one > question though: occasionally I see code that uses expressions like > > @"string" > @(..., ..., ...) > > What are these things? There's no mention of them in NeXT's > Objective-C book. > @"string" just means allocate an instance of NSString representing "string"
From: cgruber@q-soft.com (Christian Gruber) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 8 Jan 1997 20:02:41 GMT Organization: Quintessence Software Foundry Message-ID: <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII In article <1997Jan3.154332.1@eisner>, kilgallen@eisner.decus.org says... > >_Requiring_ any particular language due to OS limitations is a >mistake. Let a thousand flowers bloom. > >Larry Kilgallen For the record, I have it from reliable sources that OPENSTEP as released and supported by Next Software Inc. for the NT platform will include java as a completely interchangable language with objective-c, and given Apple's support for java, there is no reason to suppose this will change for an apple/next os with openstep. The objective-c and java object models are incredibly similar, even if the syntax is not and I already have a complete port of the Enterprise Object Framework and the Foundation framework in java as extensions to the WebObjects 3.0 system. This allows me to arbitrarily write objects in Objective-C, C++, Java, or procedural code in C, or scripted OO code in Webscript and have each of these pieces talk to each other as if these pieces were in the language I am calling them from (slight simplification, but the translation mechanism is pretty darned good.) So if you don't like obj-c then go with java, as of 4.2 or the next release after that, I am told (unauthenticated, but insider info) Openstep's next project and development tools will natively support java compilation just as they do obj-c now. (In fact Project builder already does with the WO3.0 server side java extensions, but this is beta software.) There's no way we're going to avoid java as a language with any kind of work related to the internet in a few months or years, so we may as well accept getting that particular language rammed down your throat if you don't like obj-c. Sincerely Christian Gruber
From: "Dirk P. Fromhein" <Dirk.Fromhein@watershed.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 16:05:50 +0500 Organization: Watershed Technologies, Inc. Message-ID: <32D37F8E.57A3@watershed.com> References: <5aigjj$72u$1@aggedor.rmit.edu.au> <E3FvoM.Dun@cam-ani.co.uk> <geoff.clapp-0801970942500001@clapge.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey Clapp wrote: 1: > The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, [munch] 2: > And I have never used AppKit [munch] Now how do you claim 1 and then say 2. The AppKit/OpenStep have nothing in common with MacApp, PowerPlant, TCL, etc. And I HAVE used them all (well MacApp only for a very short while). The design/implementation methods are from two different paradigms. They are totaly incompatible. Any attempt to combine the two is doomed to be slow, bloated, buggy, and fail. The AppKit is the most beautiffuly crafted class library I have ever seen. The only poor implementation detail was how they did PopUp menus. Well it shold be entertaining at the least... Dirk Fromhein df@watershed.com
From: geoff.clapp@apple.com (Geoffrey Clapp) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 13:05:06 -0800 Organization: Apple Computer, Inc. Message-ID: <geoff.clapp-0801971305060001@clapge.apple.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> In article <1997Jan3.154332.1@eisner>, kilgallen@eisner.decus.org (Larry Kilgallen) wrote: >In article <32CD396A.3DC@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> writes: > >> If they don't use the OpenStep API's, why would they bother buying >> NeXT? > >Memory protection, an OS kernel, scheduling, ... > Apple has made no official announcement on the kernel technology to be used in the new OS (as of yesterday's keynote, anyway, the way things are moving around here, it might be announced! ;->) geoffrey -------------------------------------------- Geoffrey Clapp Apple Computer, Inc. OpenDoc Engineering geoff.clapp@apple.com --------------------------------------------
From: geoff.clapp@apple.com (Geoffrey Clapp) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 13:09:50 -0800 Organization: Apple Computer, Inc. Message-ID: <geoff.clapp-0801971309500001@clapge.apple.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD3BBF.1750@exnext.com> <1997Jan3.140054.1@eisner> <5ak603$9je@news3.digex.net> In article <5ak603$9je@news3.digex.net>, jkheit@cnj.digex.net wrote: >kilgallen@eisner.decus.org (Larry Kilgallen) wrote: >> Regardless of how good the NeXTstep user interface might be, the >> consuming public will not stand for having it forced down their >> throats, and would desert Macintosh in droves if Apple were to >> insist on changing the interface. > >Again and the citation for this absolute truism? It taint >necessarily so. Apple was planning on 'shoving' a new UI down the >throats of mac users anyway, the only difference is this UI wasn't >invented there.... Funny, the company isn't doing the "not invented >here" thing anymore. In fairness to Larry, the Copland UI was very similar to the traditional 7.x UI. It was not the case of shoving a totally new UI onto users, as Ellen and other have said the "NextOS"/Rhapsody project will not do, either. gjc -------------------------------------------- Geoffrey Clapp Apple Computer, Inc. OpenDoc Engineering geoff.clapp@apple.com --------------------------------------------
From: Joe Nekrasz <nekrasz@cineon.kodak.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 07 Jan 1997 13:15:29 -0800 Organization: Eastman Kodak Company Message-ID: <32D2BCF1.41C6@cineon.kodak.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > - UNIXness of MacOS 8 will be hidden Any idea if we could still get to it if we want to, even if it is hidden? That's what I like about unix. The graphical system is nice, but it makes the OS so much more powerful when you can write scripts, use perl, and pipe things to do whatever but still drag a file to the trash. -- Joseph P. Nekrasz Pager: 415-253-6921 Systems Administrator Phone: 415-463-3040 Taos Mt. Software Email: jnekrasz@taos.com Palo Alto, CA or nekrasz@cineon.kodak.com
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer Subject: Re: Playing an audio stream Date: 8 Jan 1997 22:12:38 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5b164m$sdo@bias.ipc.uni-tuebingen.de> References: <5av8u8$rth@newsfeed.vivanet.com> Cc: dmr@westview.rochester.ny.us In <5av8u8$rth@newsfeed.vivanet.com> Daniel Rosenberg wrote: > Hi folks -- > I'm trying to play a network-acquired 8 bit mu-law audio > stream through the sound device. Now, on lesser machines, you just > pipe the stuff out to /dev/audio (or wherever) and viola, you get > RealAudio or IPhone or whatever. I'm finding on my Next (because I'm > pig ignorant) I've got to bcopy the stuff into a SNDSoundStruct and > SNDAlloc the structure each time before it'll play, and then it does > play, in short choppy bursts which make my audio sound like it's from > Mars. > > Is there a more raw interface to the sound device? Or does > anyone know of a way I can use the fancier NXAudioStream stuff which > seems to want converting into a 16 bit sample? > > The software I'm trying to convert, BTW, is WREK/Georgia > Tech's CyberAudio 1. > Look on my home page and you'll find everything done and ready. Well mostly... :-) (A port of CyberRadio to NS is in the download area) -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 08 Jan 1997 16:38:44 -0500 Organization: Atria Software Message-ID: <maury-0801971638440001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> In article <Pine.SGI.3.94.970107150251.22376D-100000@ranvier>, Joseph Strout <jstrout@ucsd.edu> wrote: > Smart Scroll helps, but too many apps do funky things with their scroll > bars that Smart Scroll can't figure out... Smart Scroll? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 08 Jan 1997 16:41:58 -0500 Organization: Atria Software Message-ID: <maury-0801971641590001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> In article <bononno-ya023680000701972252440001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: > Totally hidden? No Unix at all? I was hoping they'd keep that aspect for > some reason. Personally I'd like to see it all removed, all that /bin, /usr stuff, and left out of the standard install. Then you could purchase (or download if you don't need support) a POSIX/Unix "support pack" that you could then optionally install and use if you need to support Unix utilities directly. It would seem that this is the best of both worlds, you get to use Unix if you want, and don't have it on the drive if you don't need it. Better yet you beat NT in this regard, which removed POSIX support and didn't have any of the standard shells or utilities anyway. Maury
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan8.171354.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> Date: Wed, 8 Jan 1997 22:13:54 GMT In article <5b0uh1$lqc@priv-sys04-le0.telusplanet.net>, cgruber@q-soft.com (Christian Gruber) writes: > In article <1997Jan3.154332.1@eisner>, kilgallen@eisner.decus.org says... > >> >>_Requiring_ any particular language due to OS limitations is a >>mistake. Let a thousand flowers bloom. >> >>Larry Kilgallen > > For the record, I have it from reliable sources that OPENSTEP > as released and supported by Next Software Inc. for the NT platform > will include java as a completely interchangable language with > objective-c, and given Apple's support for java, there is no reason > to suppose this will change for an apple/next os with openstep. > > The objective-c and java object models are incredibly similar, even > if the syntax is not and I already have a complete port of the > Enterprise Object Framework and the Foundation framework in java > as extensions to the WebObjects 3.0 system. This allows me to > arbitrarily write objects in Objective-C, C++, Java, or procedural > code in C, or scripted OO code in Webscript and have each of these > pieces talk to each other as if these pieces were in the language > I am calling them from (slight simplification, but the translation > mechanism is pretty darned good.) > > So if you don't like obj-c then go with java, as of 4.2 or the next > release after that, I am told (unauthenticated, but insider info) > Openstep's next project and development tools will natively support > java compilation just as they do obj-c now. (In fact Project builder > already does with the WO3.0 server side java extensions, but this is > beta software.) I apologize for that long quotation (I hate it when people do that), but I felt it necessary how long someone can rattle on without mentioning any language which interests me. In fact, they all seem to be derivatives of C !!! How about: Ada, Basic, Cobol, Eiffel, Fortran, LISP, Pascal, PL/I and Prolog. Particular languages are useful for particular problem domains. To the person who has only a hammer, every problem looks like a nail. > There's no way we're going to avoid java as a language with any kind > of work related to the internet in a few months or years, so we > may as well accept getting that particular language rammed down your > throat if you don't like obj-c. I certainly disagree. Even if one considers "languages one can send over the net for extremely trusting individuals to execute in their own security context" (a _very_ small part of "work related to the internet"), the only element Java has going for it is the planned pervasiveness of the Java Byte Code engine. But Ada compilers can generate Java Byte Code just as good* as Java compilers !! Larry Kilgallen * some would say better than
From: geoff.clapp@apple.com (Geoffrey Clapp) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 08 Jan 1997 14:13:12 -0800 Organization: Apple Computer, Inc. Message-ID: <geoff.clapp-0801971413120001@clapge.apple.com> References: <5aigjj$72u$1@aggedor.rmit.edu.au> <E3FvoM.Dun@cam-ani.co.uk> <geoff.clapp-0801970942500001@clapge.apple.com> <32D37F8E.57A3@watershed.com> In article <32D37F8E.57A3@watershed.com>, "Dirk P. Fromhein" <Dirk.Fromhein@watershed.com> wrote: >Geoffrey Clapp wrote: >1: >> The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, >[munch] >2: >> And I have never used AppKit >[munch] > >Now how do you claim 1 and then say 2. My knowlegde of AppKit is academic, not commerical, so I wanted to qualify that before making sweeping comments so I would not be misunderstood as to my angle. I should have been more specific. My apologies. >The AppKit/OpenStep have nothing in common with MacApp, PowerPlant, TCL, >etc. And I HAVE used them all (well MacApp only for a very short >while). The goals and necessities are the same. I was not tring to suggest that all frameworks (which is why I listed MFC in the first posting) use the same models or approaches to problems, or even architectures or paradims. As you would know, each framework I listed, including the Mac-Specific, has varing architectures and paradims. The NeXT also has the OpenStep spec to consider, obviously, when discussing the merger or melding of these frameworks. I was commenting on from a design and metholodogy approach, not implemenation. Again, I apologize for any lack of clarity >The design/implementation methods are from two different paradigms. >They are totaly incompatible. Nor am I suggesting that MacApp or any other framework should be re-written in Objective-C, Java, or C++. I am talking at a higher level. The implementation details, despite the time I put in working on MacApp, is not of interest to me right now. >The AppKit is the most beautiffuly crafted class library I have ever >seen. The only poor implementation detail was how they did PopUp menus. And it is in the design that I hope something (which I refered to as a merger) will emerge, not just for the yellow box, but the blue as well. >Dirk Fromhein >df@watershed.com -------------------------------------------- Geoffrey Clapp Apple Computer, Inc. OpenDoc Engineering geoff.clapp@apple.com --------------------------------------------
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 8 Jan 1997 23:46:18 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5b1bka$sdo@bias.ipc.uni-tuebingen.de> References: <5aigjj$72u$1@aggedor.rmit.edu.au> <E3FvoM.Dun@cam-ani.co.uk> <geoff.clapp-0801970942500001@clapge.apple.com> Cc: geoff.clapp@apple.com In <geoff.clapp-0801970942500001@clapge.apple.com> Geoffrey Clapp wrote: > The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, > MFC, TCL, etc. Yeah right! And the sun shines out of my backside (much harder word to be used here) :-) Sorry to tell but you are wrong. AppKit and OpenStep frameworks have in fact not much in common with MacApp, PowerPlant, MFC, TCL, etc. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: nervous@system.net (Nervous) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 02:01:18 GMT Organization: Central Nervous System Message-ID: <nervous-0801972101520001@ascend3.netrover.com> References: <32D28963.6C27@exnext.com.nonsense> <AEF85026-2F6EF@198.68.42.153> In article <AEF85026-2F6EF@198.68.42.153>, "Lawson English" <english@primenet.com> wrote: >The full statement is: > >"While Apple will adopt some NextStep conventions, the >company is convinced that the Mac OS's human interface >is the best available and wants to ensure that this approach is >maintained." > >Sorry, 'nervous'. Care to guess what those NextStep >conventions might be? Left-side scrollbars? Menus? >Dock? Browser? > From the various pieces taht I've seen (couldn't see the presentation, only heard it), System 7.9 will have the same GUI as the first bundled version of Rhapsody. Should be very interesting to see what they come up with. What was this mention of 3D windows? I didn't seem to read anything about it. Do you have any ideas? The Mac UI and NeXT UI are sure to be a killer combination. Maybe Wintel World will do a Hershey Bar in it's undies afterall. =) -- rhapsody: rhap.so.dy \'rap-s*d-e-\ n recitation of selections from epic poetry; a highly emotional utterance or literary work; RAPTURE, ECSTASY; the new Macintosh OS.
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 01:47:27 GMT Organization: University of Sheffield, UK Message-ID: <5b1inf$996@bignews.shef.ac.uk> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> In-Reply-To: <1997Jan8.171354.1@eisner> On 01/08/97, Larry Kilgallen wrote: > Particular languages are useful for particular problem domains. > To the person who has only a hammer, every problem looks like a nail. > To go off on a tangent here, I saw a delightful .sig recently (I wish I knew who to give credit for this) along the lines of: If C++ is your hammer, every problem looks like a thumb. Best wishes, mmalc. --
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.be Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 02:40:31 GMT Organization: Cygnus Support Message-ID: <5b1lqv$abn@majipoor.cygnus.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1inf$996@bignews.shef.ac.uk> Cc: m.crawford@shef.ac.uk In <5b1inf$996@bignews.shef.ac.uk> mmalcolm crawford wrote: > On 01/08/97, Larry Kilgallen wrote: > > Particular languages are useful for particular problem domains. > > To the person who has only a hammer, every problem looks like a nail. > > > To go off on a tangent here, I saw a delightful .sig recently (I wish I knew > who to give credit for this) along the lines of: > > If C++ is your hammer, every problem looks like a thumb. > last year, in the middle of a discussion on various OO languages, the following came out of my mouth (I don't know where it came from inside me though..): For objects, Smalltalk is like working with astronaughts tools. They feel funny sometimes, but they always work incredibly well, and you know it was all carefully and elegantly thought out and designed. C++ is like working with a sledgehammer. Just a sledgehammer; no wrench, screwdriver, nor anything else. Not even a cast iron one. A big rock on the end of a stick. -- John "kzin" Rudd jrudd@cygnus.com (ex- kzin@email.sjsu.edu) =========Intel: Putting the backward in backward compatible.============ Spammers: I charge you for my time, disk, and bandwidth if you post off- topic solicitations for money in the groups I read. $500/post/group.
From: Michael D. Rossetti <rossetti@apple.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 9 Jan 1997 03:34:11 GMT Organization: Apple Computer, Inc. - MacApp Engineering Distribution: world Message-ID: <5b1ovj$tm6@nntp1.apple.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, aisbell@ix.netcom.com writes: > Multiple inheritance is not directly supported in Objective-C, a >situation that many feel is an advantage, but some may miss. Multiple >inheritance can be simulated using Objective-C's ability to forward >unimplemented messages to another object which can provide the functionality >that multiple inheritance might provide. I don't think most programmers feel >that the lack of true multiple inheritance is a problem. [Lots of great information in this thread! Lovin' it!] This is an interesting way to implement multiple inheritance. I guess this approach must mean that 'multiple inheritance' in Objective C is limited to only one base class and one 'proxy' class - is that correct? Can this occur multiple times in the hierarchy? That is, if class A2 derives from class A1 can A2 forward to B2 and A1 forward to B1? What is the overhead runtime cost of this approach? Curious minds want to know, Mike R. MacApp Engineering
From: Michael D. Rossetti <rossetti@apple.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 03:59:09 GMT Organization: Apple Computer, Inc. - MacApp Engineering Distribution: world Message-ID: <5b1qed$nlm@nntp1.apple.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, aisbell@ix.netcom.com writes: > I'm pretty dismayed by all of the antagonism that's being exchanged among >Mac and OPENSTEP programmers. We're going to need help from each other in >the future if we're going to make this thing work, so let's not poison the >atmosphere at this early stage when none of us knows what's really going to >happen. > I guess I've sensed a bit of angst but not really any serious antagonism. Everyone is wondering where this NeXT deal is going to leave them and some 'news' coming out of the executive offices at Apple is a bit more reassuring than other news. But generally I think the discussion going on here has been pretty reasoned and I've archived many comments for use in developing and arguing the MacApp strategy. It is somewhat helpful in these discussions to keep in mind that there are two types of developers: those with existing software investments and those starting fresh. It appears that MacApp will be a major contributor to the former but will still be somewhat valuable for the latter. So our strategy needs to address both continued support for System 7, transition support for Mac OS 8, and some form of contribution to the 'native' framework for Mac OS 8. I'd like to point out that there is no complete framework for Mac OS 8 yet though many in this discussion have talked like OpenStep _is_ that framework. This will come when OpenStep has been modified to provide some form of Macintosh User Experience. Perhaps MacApp can contribute in this way, too. Anyway, this has been a most interesting discussion and I appreciate Nick Nallick kicking it off. Mike R. MacApp Engineering
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Message-ID: <32D446AC.23A2@running-start.com> From: Eric Hermanson <eric@running-start.com> Date: Wed, 08 Jan 1997 17:15:24 -0800 References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <geoff.clapp-0801971305060001@clapge.apple.com> Organization: Running Start, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Geoffrey Clapp wrote: > Apple has made no official announcement on the kernel technology to be > used in the new OS (as of yesterday's keynote, anyway, the way things are > moving around here, it might be announced! ;->) Steve Jobs said in the keynote address that the kernel would be Mach. Probably Mach 3.0 if they can optomize it to run faster than dog-slow. Eric -- Running Start, Inc. * Ask About Our Software For: "The Enterprise Developer's Developer" * Workflow http://www.running-start.com * Web Commerce +1-520-760-4890 (4891 FAX) * Request Resolution eric@running-start.com * OPENSTEP/WebObjects/JAVA
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Message-ID: <32D44737.30CB@running-start.com> From: Eric Hermanson <eric@running-start.com> Date: Wed, 08 Jan 1997 17:17:43 -0800 References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> Organization: Running Start, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christian Gruber wrote: > For the record, I have it from reliable sources that OPENSTEP > as released and supported by Next Software Inc. for the NT platform > will include java as a completely interchangable language with > objective-c, and given Apple's support for java, there is no reason > to suppose this will change for an apple/next os with openstep. If you look at NeXT's web site, some of their documentation has already been "ported" to JAVA. This upsetted many Objective-C lovers, so NeXT agreed to write parallel Obj-C/JAVA documentation. It is clear NeXT is very serious about supporting JAVA. I wouldn't doubt if they're either implementing an OpenStep JAVA spec, or writing compilers that will compile Obj-C to JAVA bytecode? Eric -- Running Start, Inc. * Ask About Our Software For: "The Enterprise Developer's Developer" * Workflow http://www.running-start.com * Web Commerce +1-520-760-4890 (4891 FAX) * Request Resolution eric@running-start.com * OPENSTEP/WebObjects/JAVA
From: mbk@inls1.ucsd.edu (Matt Kennel) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 9 Jan 1997 03:36:52 GMT Organization: The University of California at San Diego Message-ID: <5b1p4k$8sf@news1.ucsd.edu> References: <maury-0801971641590001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : In article <bononno-ya023680000701972252440001@news.nyu.edu>, : bononno@acf2.nyu.edu (Robert Bononno) wrote: : > Totally hidden? No Unix at all? I was hoping they'd keep that aspect for : > some reason. : Personally I'd like to see it all removed, all that /bin, /usr stuff, : and left out of the standard install. Then you could purchase (or : download if you don't need support) a POSIX/Unix "support pack" that you : could then optionally install and use if you need to support Unix : utilities directly. No. This is stupid. It means that standard applications cannot assume the presence of useful unix style utilities. Users might not want to know about '/bin', but they do not want a program or internal script to die on account of its absence. : Maury
From: John Hornkvist Newsgroups: comp.sys.next.programmer Subject: Re: Basic question about OpenStep Date: 9 Jan 1997 00:38:50 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5b1emq$qmk@nyheter.chalmers.se> References: <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net> Cc: onscrn@aol.com In <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net> Bob Estes wrote: >Please excuse my ignorance, but it's amazing how many messages on OpenStep >I've read without getting the answer to this basic question: Is OpenStep >required to be present in order to run programs written using OpenStep? My >assumption had always been yes, but I've read so many times that "if you >write an OpenStep program it automatically will run on NT etc." I'm >confused. So, can anyone with a machine running "stock" NT (no OpenStep >addition of any kind) fire up a program written using OpenStep (compiled >for the particular type of machine the user has) and run it? Running OpenStep programs requires that you have an OpenStep environment. This "environment" includes a DPS server, mach style name server, and OpenStep libraries. (And possibly more.) NeXT chose to confuse the issue by renaming the OpenStep compatible operating system NEXTSTEP 4.0 to OPENSTEP/Mach. --- John Hornkvist --- nhoj at cd dot chalmers dot se Working on MSc in Computer Engineering, and MSc in Industrial Engineering and Management of Technology Does anyone need a NEXTSTEP/OPENSTEP savvy programmer for the summer of '97? Sorry for not leaving my address in the header, but I get too many spam mails already... If you want to reach me, try nhoj at cd dot chalmers dot se
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 9 Jan 1997 06:40:10 GMT Organization: Global Objects Inc. Message-ID: <5b23sa$48e@news.xmission.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Multiple inheritance is not directly supported in Objective-C, > > [...]. Multiple > > inheritance can be simulated using Objective-C's ability to > > forward unimplemented messages to another object which can > > provide the functionality that multiple inheritance might > > provide. I don't think most programmers feel that the lack > > of true multiple inheritance is a problem. > > This is an interesting way to implement multiple inheritance. > I guess this approach must mean that 'multiple inheritance' in > Objective C is limited to only one base class and one 'proxy' > class - is that correct? No, it isn't! When the Objective C runtime sees an object doesn't implement a method, the object's -forward: method is called and asked to deal with the unknown message. The default implementation of -forward: causes an exception and the program bails. But if you override it, you can choose to forward the message to any number of delegates--and you can even send it to more than one of them! In effect, you are extending the message dispatching system yourself, and you can do it any way you like, lending a lot of flexibility to the usage. A concrete example is the MiscKit's MiscTee object. What it does is act like a tee (as in plumbing)--send a message into it and it will turn around and pass the message on to every object on its "output", but only that that object actually responds to the message. The Tee itself doesn't respond to any of these messages. Instead, when you send it a message, that message is trapped by the -forward: method, which then loops through all the delegates and passes the message on to each of the ones that can handle it. Since the MiscTee can effectively respond to any message that is handled by any of the objects that is connected to it, we have overridden the -respondsTo: method as well. As you add and remove objects to the Tee's list of "delegates", the set of messages it responds to will appear to change! It turns out that that particular object is _really_ handy in some circumstances. (Especially in Interface Builder, where all GUI objects have a single target. With the MiscTee, they can have as many targets as you want! There's also an additional functionality where you can have the tee associate a _particular_ message with a particular delegate and then, when it gets a -ping: message, each delegate gets sent its particular message. Those who work with IB know how useful _that_ little treat is!) Anyway, since it is a reasonably good example of how the forwarding mechanism works, I'll append the source to this message. (Don't worry-it is pretty short, considering what it does.) I don't think you'll find any objects in C++ that implement this sort of functionality so cleanly and in such a generic way. :-) > Can this occur multiple times in the hierarchy? That is, > if class A2 derives from class A1 can A2 forward to B2 > and A1 forward to B1? Sure. You can code it any way you like. :-) Objective C, as simple as it is, is surprisingly flexible. You have hooks into _everything_. You can do some really nifty things. One of my all time favorites is ObjectivePerl and ObjectiveTCL by TipTop software. They have integrated Perl and Tcl (respectively) into Objective C so that you can write subclasses of Obj-C objects in Tcl or Perl. And, better yet, you can actually write Objective-C classes--which compile just fine--that descend from Tcl and Perl objects! The cool part of it is, if you're writing in Objective-C, the way you send messages to the objects is the same. Without actually querying the object, you can't tell what language it was written in. (You can ask and find out, using the appropriate messages, if you care.) Sending messages from the TCL and Perl sides requires you learn some minor extensions to those languages, however. Then, the real mind blower is that you can actually _mix_ the languages when defining a single class! A particular class could have methods implemented in TCL, Perl, and/or Objective-C. This same technology could be used to hook up Java (and it appears NeXT has done that with the latest WebObjects extensions for Java--may it make it back into the base OS!) or any other language you like. And it uses the hooks that have always been in Objective C. > What is the overhead runtime cost of this approach? Urm, well...it can be pretty bad, depending on how many times a message gets passed on to somebody else. Like any good thing, this can be taken to ridiculous extremes. You really have to benchmark a particular case of it--and that benchmark won't generalize very well. Basically, the overheads are: (a) messaging versus function call--a few CPU cycles more, and present in every Objective C message. Experience with NEXTSTEP has shown that this is fairly insignificant for all but the tightest computational loops (and, in those cases, you can ask Obj-C for a function pointer and turn the method call into a function call, so the point is moot). (b) forwarding means at least _two_ extra method dispatches than normal since you have (1) original call, (2) -forward:, and (3) message sent on to delegate. But there could be more-- how long is your chain of delegates? How many delegates are you sending messages to? In practice, (b) isn't too bad. The Objective TCL and Objective Perl products--even though Tcl and Perl are interpreted languages-- have shown surprisingly good performance! I wish I could give more concrete answers (numbers) but I don't have them handy. For those who are truly interested in how the dynamism of Objective C changes--and simplifies--OO programming (and how it simplifies many of the GOF Design Patterns), Andy Grosso and I have been working on some pages on the MiscKit web site that discuss all this. They aren't quite ready for prime time (yet), but I'll post the URL to comp.lang.[objective-c|java|c++] when they are ready for public consumption. The pages are dynamic, like a guest list page, so people will be able to create a discussion of sorts if they want to. If you're too curious and just can't wait for it, email me and I'll see what I can do. :-) Apple is doing a good thing in bringing Objective C to a wider audience--it isn't the end all, be all of languages, but it is a darned sight nicer to work with than C++! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a> MiscTee source code: [I have cut out some of the methods that aren't germane to this discussion. If you want the whole object, grab the MiscKit. And anyone doing NeXT programming probably already has it...] [this comment block is cut out of the .m (source) below for brevity, but still applies to both portions] // MiscTee.h -- An object which will pass a message on to any of // the objects connected to it. This is useful for splitting // an action message to multiple recipients or for allowing // multiple delegates to be connected to provide different services. // // Written by David Fedchenko. Copyright 1994 by David Fedchenko. // Version 1.1 All rights reserved. // Additions by Don Yacktman to remove warnings and avoid infinite loops. // // This notice may not be removed from this source code. // // This object is included in the MiscKit by permission from the author // and its use is governed by the MiscKit license, found in the file // "LICENSE.rtf" in the MiscKit distribution. Please refer to that file // for a list of all applicable permissions and restrictions. #import <appkit/appkit.h> @interface MiscTee:Object { id (idConnections); // a Storage object filled with CONPAIRs // which are defined in the source file (not here, since this is a // public header and CONPAIRs are a private structure) BOOL inTee; } - addConnection:anObject with:(SEL)anAction; - removeConnection:anObject; - ping:sender; - forward:(SEL)aSelector :(marg_list)argFrame; - (BOOL)respondsTo:(SEL)aSelector; @end // MiscTee.m // // Written by David Fedchenko. Copyright 1994 by David Fedchenko. // Version 1.1 All rights reserved. // This notice may not be removed from this source code. #import "MiscTee.h" typedef struct { // Object *idObject; // Using this would remove warnings _if_ isa were // not protected, but as things stand, we'll have to live with the // warnings. :-( That's what you get for "isa hacking"! //id idObject; // This is where we got warnings...original definition... struct objc_class *idObject; // This seems to work right... SEL selAction; } CONPAIR; @implementation MiscTee - ping:sender { int i; CONPAIR * pcp; if (inTee) return self; inTee = YES; for (i = 0; i < [idConnections count]; i++) { pcp = (CONPAIR *)[idConnections elementAt:i]; if (strcmp(pcp->idObject->isa->name, "FREED(id)") && pcp->idObject != sender && pcp->selAction) { [pcp->idObject perform:pcp->selAction with:sender]; } } inTee = NO; return self; } - forward:(SEL)aSelector :(marg_list)argFrame { int i; CONPAIR * pcp; void * pv = nil; BOOL fSent = NO; if (inTee) return self; inTee = YES; for (i = 0; i < [idConnections count]; i++) { pcp = (CONPAIR *)[idConnections elementAt:i]; if (strcmp(pcp->idObject->isa->name, "FREED(id)") && [pcp->idObject respondsTo:aSelector]) { pv = [pcp->idObject performv:aSelector :argFrame]; fSent = YES; } } if (!fSent) { [self doesNotRecognize:aSelector]; } inTee = NO; return (id)pv; } -(BOOL) respondsTo:(SEL)aSelector { int i; CONPAIR * pcp; if ([super respondsTo:aSelector]) { return YES; } for (i = 0; i < [idConnections count]; i++) { pcp = (CONPAIR *)[idConnections elementAt:i]; if (strcmp(pcp->idObject->isa->name, "FREED(id)") && [pcp->idObject respondsTo:aSelector]) { // don't worry about multiple positive responses return YES; } } return NO; } @end
From: toon@omnigroup.com (Greg Titus) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 8 Jan 1997 19:50:26 GMT Organization: Omni Development, Inc. Message-ID: <5b0tq2$407@gaea.titan.org> References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> stephen_ma@mindlink.net (Stephen Ma) wrote: >ians@cam-ani.co.uk (Ian Stephenson) wrote: >>[impressively concise example using nearly all of Objective-C] Note that there was a typo in there... the "if(param=nil)" in -anInstanceMethodWith: should have been "if(param==nil)" as a C programmer would expect. Just don't want you to think Objective-C has some funky operator difference from plain old C. :) >You really seem to have covered the basics. I'd like to ask one >question though: occasionally I see code that uses expressions like > @"string" > @(..., ..., ...) > >What are these things? There's no mention of them in NeXT's >Objective-C book. This is something new with OPENSTEP/NeXTSTEP 4.0/WebObjects, it is a syntax for statically constructed objects from NeXT's Foundation framework. The Obj-C compiler only recognizes the string form (I think), but WebObjects' scripting language (which looks exactly like Obj-C otherwise) also recognizes the array form. // foo points to an automatically built NSString object with the content bar NSString *foo = @"bar"; // foo points to an automatically built NSArray object containing a couple // of NSStrings NSString *foo = @(@"bar", @"baz"); --------------------- Greg Titus Omni Development Inc. gtitus@omnigroup.com
From: bononno@acf2.nyu.edu (Robert Bononno) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 08 Jan 1997 22:36:31 -0500 Organization: Techline Message-ID: <bononno-ya023680000801972236310001@news.nyu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <maury-0801971641590001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: >In article <bononno-ya023680000701972252440001@news.nyu.edu>, >bononno@acf2.nyu.edu (Robert Bononno) wrote: > >> Totally hidden? No Unix at all? I was hoping they'd keep that aspect for >> some reason. > > Personally I'd like to see it all removed, all that /bin, /usr stuff, >and left out of the standard install. Then you could purchase (or >download if you don't need support) a POSIX/Unix "support pack" that you >could then optionally install and use if you need to support Unix >utilities directly. That sounds like quite a kludge. Add in the command line support/shell later on? > > It would seem that this is the best of both worlds, you get to use Unix >if you want, and don't have it on the drive if you don't need it. Better >yet you beat NT in this regard, which removed POSIX support and didn't >have any of the standard shells or utilities anyway. I thought POSIX support was NT's big selling point? -- ------------------------------------------------------ Robert Bononno - bononno@acf2.nyu.edu - CIS:73670,1570
Newsgroups: comp.sys.next.programmer From: as@asci.fdn.fr (Antoine Schmitt) Subject: Re: sound from NXRecordStream? Message-ID: <1997Jan9.025209.20257@asci.fdn.fr> Sender: as@asci.fdn.fr Organization: Antoine Schmitt - Paris, France. References: <5argmp$6lb@bignews.shef.ac.uk> Date: Thu, 9 Jan 1997 02:52:09 GMT In article <5argmp$6lb@bignews.shef.ac.uk> mmalcolm crawford <m.crawford@shef.ac.uk> writes: > On 01/01/97, Raymond Lutz wrote: > > I want to play a sound freshly recorded by a NXRecordStream. [stuff about writing to a file - Deleted] > I guess you could copy it into a newly-created SNDSoundStruct, but that's > more tricky as you'll have to dynamically allocate the memory for it as you > go (and I suspect that you'll then run into problems with alocating enough > memory in the time you have before the next bufferfull of data arrives -- I > seem to recall I tried this, unsuccessfully). I did this once. To cope with the incoming flux of data, I would store the pointers to the incoming data in an array while I was recording. Then, when recording was over, I would allocate a new SNDSoundStruct, and bcopy all the pieces of data in it before deallocating them. Then the SNDStruct is playable. And you dont have to go through a file. But I'm not sure I was multithreaded. (Would this be a problem ?) I still have the code somewhere I guess. Antoine -- ________________________________________________________ Antoine Schmitt, ASCI - Paris, France
From: mmunz@inconnect.com (Mark Munz) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 06:13:51 GMT Organization: Puppy Dog Software Message-ID: <mmunz-0801972312570001@slc-dial-65.inconnect.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <geoff.clapp-0801971305060001@clapge.apple.com> <32D446AC.23A2@running-start.com> In article <32D446AC.23A2@running-start.com>, eric@running-start.com wrote: >Steve Jobs said in the keynote address that the kernel would be Mach. >Probably Mach 3.0 if they can optomize it to run faster than dog-slow. Actually, Apple has said it will not have an official decision on the Kernel issue until the end of January. What Steve Jobs may say at a keynote can't be taken as gospel (of course, neither can anything anyone else says). Mark Munz
From: mmunz@inconnect.com (Mark Munz) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 9 Jan 1997 06:24:28 GMT Organization: Puppy Dog Software Message-ID: <mmunz-0801972323330001@slc-dial-65.inconnect.com> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> In article <jcr.852636452@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: >In fact, I know of research projects where people used postscript to add >functionality to servers and device drivers, that had nothing to do with >graphics. It is a turing-complete programming language. You can write >a LISP interpreter in it if you like! I don't want yet another programming language .. I just want to be able to image. The fact that PS is intrepeted is also bothersome.. Never has interpreted been equated with high speed. The whole purpose of pre-emptive MT and other such goodies is give performance to the user. This is an area that I think BeOS seems to win in (their imaging is extremely fast). I would have actually liked to see something closer to how Be did it (taking advantage of the FPU in PPC chips -- and Pentinum also has FPU built-in).. it seems disappointing. While some of this is bothersome, I'm not ready to condemn DPS - but it does raise some questions about it. I hope Apple talks to someone BESIDES Adobe (they're opinions are SLIGHTLY BIASED) on this to make sure they're making the right decision about the imaging model. Mark Munz
From: bononno@acf2.nyu.edu (Robert Bononno) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 08 Jan 1997 22:35:03 -0500 Organization: Techline Message-ID: <bononno-ya023680000801972235030001@news.nyu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <ibhan-0801971336040001@infobhan.med.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <ibhan-0801971336040001@infobhan.med.harvard.edu>, ibhan@student.med.harvard.edu (Ishir Bhan) wrote: >In article <bononno-ya023680000701972252440001@news.nyu.edu>, >bononno@acf2.nyu.edu (Robert Bononno) wrote: > >> Yeah, but like when? Already we're into mid-98 here. Assume Rhapsody is the >> NeXT-based OS for Macintosh. So this is 1.5 to 2 years away. That's a long, >> long time in this business. > >Rhapsody is supposed to be released at the same time as 7.8. That is, one >year from now. The developer release will preceed it by several months >(possibly as soon as 6). > That's not what I read. -- ------------------------------------------------------ Robert Bononno - bononno@acf2.nyu.edu - CIS:73670,1570
From: mikey3141@aol.com (Mikey3141) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 9 Jan 1997 07:49:52 GMT Organization: AOL http://www.aol.com Message-ID: <19970109074800.CAA02596@ladder01.news.aol.com> References: <E3nHrL.1tB@cam-ani.co.uk> on the behalf of us that have been trying to find books on obj c, we thank you, ian. I can't wait to have AppleStep to arrive
From: "Steven W. Schuldt" <sschuldt@highway1.com> Newsgroups: comp.sys.next.programmer Subject: Re: Basic question about OpenStep Date: 9 Jan 1997 03:40:08 GMT Organization: Bostonix Communications Message-ID: <01bbfdb4$87f2d680$953c8018@winona> References: <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net> You need the OPENSTEP runtime installed on NT; just as you need a runtime to execute Java applets, just as you need a runtime for PowerBuilder apps. Everyone and his grandma wants Apple to give this thing away for free. For now, Apple seems so baffled at NeXT's embarassment of technological riches and harangued by it's frantic, wide-eyed userbase that it appears to not even know that this is an issue. - Steve Bob Estes <onscrn@aol.com> wrote in article <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net>... > Please excuse my ignorance, but it's amazing how many messages on OpenStep > I've read without getting the answer to this basic question: Is OpenStep > required to be present in order to run programs written using OpenStep?... > > Bob Estes > onscrn@aol.com >
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 9 Jan 1997 08:15:58 GMT Organization: Netcom Distribution: world Message-ID: <5b29fu$a8b@sjx-ixn3.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Multiple inheritance is not directly supported in Objective-C, a > >situation that many feel is an advantage, but some may miss. Multiple > >inheritance can be simulated using Objective-C's ability to forward > >unimplemented messages to another object which can provide the functionality > >that multiple inheritance might provide. I don't think most programmers feel > >that the lack of true multiple inheritance is a problem. > > This is an interesting way to implement multiple inheritance. I wouldn't characterize this as a multiple inheritance implementation :-) It's just a strategy that provides some of the functionality of multiple inheritance without most of the problems that true multiple inheritance implementations can cause. I'm not stating that forwarding is "better" - I was just trying to indicate an approach that can be used when multiple inheritance might be useful. I doubt that this approach is a technique commonly used by most Objective-C programmers. The need for multiple inheritance just doesn't seem to be that great. I guess > this approach must mean that 'multiple inheritance' in Objective C is > limited to only one base class and one 'proxy' class - is that correct? > Can this occur multiple times in the hierarchy? That is, if class A2 > derives from class A1 can A2 forward to B2 and A1 forward to B1? Allow me to use NeXT's documentation of NSObject's (the root class) forwardInvocation: method. They explain it much better than I can :-) -(void)forwardInvocation:(NSInvocation *)anInvocation Overridden by subclasses to forward messages to other objects. When an object is sent a message for which it has no corresponding method, the run-time system gives the receiver an opportunity to delegate the message to another receiver. It does this by creating an NSInvocation object representing the message and sending the receiver a forwardInvocation: message containing this NSInvocation as the argument. The receiver's forwardInvocation: method can then choose to forward the message to another object. (If that object can't respond to the message either, it too will be given a chance to forward it.) The forwardInvocation: message thus allows an object to establish relationships with other objects that will, for certain messages, act on its behalf. The forwarding object is, in a sense, able to inherit some of the characteristics of the object it forwards the message to. An implementation of the forwardInvocation: method has two tasks: To locate an object that can respond to the message encoded in anInvocation. This need not be the same object for all messages. To send the message to that object using anInvocation. anInvocation will hold the result, and the run-time system will extract and deliver this result to the original sender. In the simple case, in which an object forwards messages to just one destination (such as the hypothetical friend instance variable in the example below), a forwardInvocation: method could be as simple as this: - (void)forwardInvocation:(NSInvocation *)invocation { SEL selector = [invocation selector]; if ([friend respondsToSelector:selector]) [invocation invokeWithTarget:friend]; else [self doesNotRecognizeSelector:selector]; } The message that's forwarded must have a fixed number of arguments; variable numbers of arguments (in the style of printf()) are not supported. The return value of the message that's forwarded is returned to the original sender. All types of return values can be delivered to the sender: ids, structures, double-precision floating point numbers. Implementations of the forwardInvocation: method can do more than just forward messages. forwardInvocation: can, for example, be used to consolidate code that responds to a variety of different messages, thus avoiding the necessity of having to write a separate method for each selector. A forwardInvocation: method might also involve several other objects in the response to a given message, rather than forward it to just one. NSObject's implementation of forwardInvocation: simply invokes the doesNotRecognizeSelector: method; it doesn't forward any messages. Thus, if you choose not to implement forwardInvocation:, unrecognized messages will raise an exception. > What is the overhead runtime cost of this approach? Good question. The Objective-C run-time does a lot of caching of method implementations so that the first time a message is sent, the overhead is highest, but subsequent messages hit the cache and are probably quite speedy. However, there is no free lunch. Objective-C message dispatches aren't as fast as C function calls, but for interactive applications where user events drive an app, the user is so much slower than the Objective-C run-time that performance isn't a problem. If certain code segments are performance-critical, Objective-C's run-time can provide a function pointer for the implementation of a method so performance can be as good as a C function call, but this will eliminate the possibility of polymorphism. This approach might be used in a loop where a message is sent to the same object repeatedly so that polymorphism isn't an issue. But if performance is still a problem, C or C++ can be substituted for Objective-C. > Curious minds want to know, Should I have misled, please correct me. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: suckow@bln.sel.alcatel.de (Ralf Suckow) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 9 Jan 1997 09:04:12 GMT Organization: Alcatel/Bell Distribution: world Message-ID: <5b2cac$s0a@btmpjg.god.bel.alcatel.be> References: <5b0tq2$407@gaea.titan.org> Greg Titus writes > // foo points to an automatically built NSArray object containing a couple > // of NSStrings > NSString *foo = @(@"bar", @"baz"); > Shouldn't this read NSString *foo = @("bar", "baz"); ?? Yours, ------------------------ Ralf.Suckow@bln.sel.alcatel.de | All opinions are mine.
From: Constantin Szallies <szallies@energotec.de> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 9 Jan 1997 10:03:00 GMT Organization: Tech Net GmbH Message-ID: <5b2fok$det2@ddfservb.technet.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> Michael D. Rossetti <rossetti@apple.com> wrote: >In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, >aisbell@ix.netcom.com writes: >> Multiple inheritance is not directly supported in Objective-C, a >>situation that many feel is an advantage, but some may miss. Multiple >>inheritance can be simulated using Objective-C's ability to forward >>unimplemented messages to another object which can provide the functionality >>that multiple inheritance might provide. I don't think most programmers feel >>that the lack of true multiple inheritance is a problem. > >[Lots of great information in this thread! Lovin' it!] > >This is an interesting way to implement multiple inheritance. I guess >this approach must mean that 'multiple inheritance' in Objective C is >limited to only one base class and one 'proxy' class - is that correct? > >Can this occur multiple times in the hierarchy? That is, if class A2 >derives from class A1 can A2 forward to B2 and A1 forward to B1? > >What is the overhead runtime cost of this approach? Objective-C does have multiple inheritance!! Multi interface inheritance but only single implementation inheritance. The same concept as in Java, if you know this language. And NO multiple inheritance can't be simulated by objective C's abibliy to forward messages. These forwarding is the same as delegation, you just don't have to write code like: public void someMessage() { delegate.someMessage(); } With forwarding, you just have to implement one method that forwards all method invocations that can't be handled by the receiver to the delegate. The overhead is one additional method invocation and one slot more in the call stack. But this doesn't change the type of the receiver!! Multiple inheritance in Objective-C looks like this (example from the Foundation Kit, a framework with basic datastructures for OPENSTEP applications): @interface NSArray:NSObject <NSCopying, NSMutableCopying> This means NSArray inhertits from NSObject (implementaion) and from NSCopying and NSMutableCopying (iterface only). NSCopying and NSMutableCopying are so called protocols which define a set of method signatures. NSArray must implement all methods in these protocols. You can check if some Object is of type NSCopying at runtime by calling [someObject conformsTo:@protocol(NSCopying)] -- Constantin Szallies, Energotec GmbH szallies@energotec.de 49211-9144018
Newsgroups: comp.sys.next.programmer From: tom@icgned.nl (Tom Hageman) Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Message-ID: <E3qLFp.K9D@icgned.nl> Sender: news@icgned.nl Organization: IC Group References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> <5b0rno$48e@news.xmission.com> Date: Thu, 9 Jan 1997 10:35:49 GMT don@globalobjects.com (Don Yacktman) wrote: >stephen_ma@mindlink.net (Stephen Ma) wrote: >> [...] I'd like to ask one >> question though: occasionally I see code that uses expressions like >> >> @"string" >> @(..., ..., ...) >> >> What are these things? There's no mention of them in NeXT's >> Objective-C book. > >This is syntactic sugar--almost a macro. The first one creates >an NSString object with the specified value and the second creates >an NSArray populated with the comma delimited list of objects >between the parenthesis. Pretty simple stuff and a recent addition >to the compiler as of the creation of the NeXT FoundationKit. Really? (No question about the NSString construct, but this is the first I heard of the NSArray one.) When I tried to compile the following test code: --- @array.m --- #if (NS_TARGET_MAJOR <= 3) #import <foundation/NSString.h> #import <foundation/NSArray.h> #else #import <Foundation/Foundation.h> #endif void test() { id array = @(@"aap", @"noot", @"mies"); // test @(..., ...) } --- I got the following errors: cc -c @array.m @array.m: In function `test': @array.m:10: invalid identifier `@' @array.m:10: warning: initialization makes pointer from integer without a cast Using both the NS3.3 and OS/Mach 4.1 compiler. Maybe it does work with the OS/NT or the latest gcc compiler, I haven't checked. It is possible to get about the same effect by defining a macro like: #define @(objects...) [NSArray arrayWithObjects:objects, nil] but this would (a) use a gcc-specific preprocessor feature, and (b) it does not yield an array constant like @"string" yields a string constant. In the same vein: should @123 or @45.678 yield NSNumbers? :-) -- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ IC Group <tom@icgned.nl> (work) __/__/__/ "Ed is the standard text editor" __/ _/_/ -- Unix Programmer's Manual
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Organization: LJK Software Message-ID: <1997Jan9.070842.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b29fu$a8b@sjx-ixn3.ix.netcom.com> Date: Thu, 9 Jan 1997 12:08:42 GMT In article <5b29fu$a8b@sjx-ixn3.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) writes: > Michael D. Rossetti <rossetti@apple.com> wrote: >> In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, >> aisbell@ix.netcom.com writes: >> > Multiple inheritance is not directly supported in Objective-C, a >> >situation that many feel is an advantage, but some may miss. Multiple >> >inheritance can be simulated using Objective-C's ability to forward >> >unimplemented messages to another object which can provide the > functionality >> >that multiple inheritance might provide. I don't think most programmers > feel >> >that the lack of true multiple inheritance is a problem. >> >> This is an interesting way to implement multiple inheritance. > > I wouldn't characterize this as a multiple inheritance implementation :-) > It's just a strategy that provides some of the functionality of multiple > inheritance without most of the problems that true multiple inheritance > implementations can cause. I'm not stating that forwarding is "better" - I > was just trying to indicate an approach that can be used when multiple > inheritance might be useful. > > I doubt that this approach is a technique commonly used by most > Objective-C programmers. The need for multiple inheritance just doesn't seem > to be that great. The mechanism described seems perfectly adequate to handle "mixins", which some would say is the most useful application of multiple inheritance. Is there some other technique for "mixins" used by the class of "most Objective-C programmers", or do they just not need mixins for most of their work ? And for bonus points: Did the term "mixins" really derive from Steve's Ice Cream in Davis Square, Sommerville, Massachusetts, USA ? Larry Kilgallen
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Thu, 9 Jan 1997 12:25:05 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Distribution: inet Message-ID: <E3qqHu.58C@cam-ani.co.uk> References: <0k20yMppj+2S091yn@mindlink.net> In article <0k20yMppj+2S091yn@mindlink.net> stephen_ma@mindlink.net (Stephen Ma) writes: > I'd like to ask one > question though: occasionally I see code that uses expressions like > > @"string" > @(..., ..., ...) > > What are these things? There's no mention of them in NeXT's > Objective-C book. They're an extension thats prominent in NeXTStep4/OpenStep (I think they existed before but were never used). They're a shortcut to create a string object, equivalent to [NSString stringWithCString:"string"]; They're automatically put into the releasepool, so you'd need to retain such a string if you needed to keep a copy. $an
From: spamwall@zercom.net (Martin-Gilles Lavoie) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 13:49:43 GMT Organization: Groupimage, inc. Message-ID: <spamwall-0901970846450001@204.191.6.170> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> <bononno-ya023680000701972255570001@news.nyu.edu> In article <bononno-ya023680000701972255570001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: > In article <Pine.SGI.3.94.970107150251.22376D-100000@ranvier>, Joseph > Strout <jstrout@ucsd.edu> wrote: > > > >OTOH, I just saw that BeOS is available for off-the-shelf PowerMacs now, > >and it already runs MacOS apps! And it should be shipping (non-beta) > >soon. Sounds like a good deal to me! > > It does? I thought it didn't. BeOS will run my Mac applications? That's a > possibility I had sort of forgotten about. And it will run on my 8500? Be > has been hard at work I see. I have BeOS on my PowerMac at this instant. BeOS doesn't support Mac applications, nor does it (currently) support the Mac file system. The BeOS for PowerMac requires Mac OS to boot. When in the Finder, you double-click on "BeOS Launcher", which forces a shutdown of your Mac and boots up BeOS. The Mac toolbox, in all respect, is considered "off". For BeOS to be running Mac apps, you require a software called "Virtual Mac" which requires the presence of your PowerMac ROMs (ie, does not work on BeBox). Following is an excerp of the press release: Be Operating System (BeOS) Summary of MacOS System 7.x Compatibility Features DUAL BOOT CAPABILITIES Includes the ability to run the BeOS and MacOS on a single PowerPC system. One OS is active at any one time. Supports loading systems on separate hard disks, or on separate partitions of a single disk. Available: Now Introduced with the BeOS development kit last month. Will be a feature of the Q1 public release. DATA COMPATIBILITY Includes the ability to access MacOS formatted volumes directly from within the BeOS, and ability to read System 7.x files and various data formats. Available: In Q1 Release NETWORK COMPATIBILITY Internet TCP/IP-based service compatibility and interchange with Mac and Windows systems, and AppleTalk capabilities with Mac-based systems. Available: Now Internet capabilities to be enhanced in the Q1 release. Be is studying AppleTalk network compatibility, availability to be announced. VIRTUALMAC CAPABILITIES Includes the ability to run existing System 7.x applications within the BeOS environment. Available: Demonstrated Availability to be announced later in Q1 ================================================================= Please reply using the following address, rather than the "reply-to" address (my mail box is being filled with junk mail). ================================================================= Martin-Gilles Lavoie | Opinions expressed herein are just that. mouser@zercom.net | "No! Do, or do not. There is no try." Globimage, inc. | --Yoda on error handling
From: stephen_ma@mindlink.net (Stephen Ma) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Wed, 08 Jan 1997 22:40:35 -0800 Organization: MIND LINK! - British Columbia, Canada Message-ID: </xJ1yMppjC2A091yn@mindlink.net> References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> <5b0rno$48e@news.xmission.com> don@globalobjects.com (Don Yacktman) wrote: >stephen_ma@mindlink.net (Stephen Ma) wrote: >> [what do the following expressions mean?] >> @"string" >> @(..., ..., ...) > >This is syntactic sugar--almost a macro. The first one creates >an NSString object with the specified value and the second creates >an NSArray populated with the comma delimited list of objects >between the parenthesis. Pretty simple stuff and a recent addition >to the compiler as of the creation of the NeXT FoundationKit. Thanks to everyone who replied. Have any other features been added recently to the language? Is there an official specification? My copy of "Object-Oriented Programming and the Objective C Language", produced by NeXT and published by Addison-Wesley, is rather old (1993). --------------------------------------- Stephen Ma <stephen_ma@mindlink.bc.ca>
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer Subject: Re: sound from NXRecordStream? Date: 9 Jan 1997 14:13:17 GMT Organization: University of Sheffield, UK Message-ID: <5b2udt$kce@bignews.shef.ac.uk> References: <5argmp$6lb@bignews.shef.ac.uk> <1997Jan9.025209.20257@asci.fdn.fr> In-Reply-To: <1997Jan9.025209.20257@asci.fdn.fr> On 01/08/97, Antoine Schmitt wrote: > I did this once. To cope with the incoming flux of data, I would store the > pointers to the incoming data in an array while I was recording. Then, > when recording was over, I would allocate a new SNDSoundStruct, and bcopy > all the pieces of data in it before deallocating them. Then the SNDStruct > is playable. And you dont have to go through a file. > But I'm not sure I was multithreaded. (Would this be a problem ?) > I'm not sure if threading would be a problem -- your solution sounds like a useful alternative to mine, thanks. I'd only be worried about allocating enough space to hold all the pointers to begin with, but this is a minor consideration. Best wishes, mmalc. --
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Thu, 9 Jan 1997 13:30:47 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E3qtJC.5JH@cam-ani.co.uk> References: <geoff.clapp-0801970942500001@clapge.apple.com> In article <geoff.clapp-0801970942500001@clapge.apple.com> geoff.clapp@apple.com (Geoffrey Clapp) writes: > In article <E3FvoM.Dun@cam-ani.co.uk>, ians@cam-ani.co.uk (Ian Stephenson) > wrote: > > >OK... I've never actually USED MacApp, but as I understand it, it's very > >simlar _in_principle_ to the AppKit. > > The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, > MFC, TCL, etc. etc. The question is where do we go and how do we get > there.MetroWerks has already committed to PowerPlant for Rhapsody, but > what does that really mean in terms of code portability, etc? Who > knows....there are a ton of issues to still work out. Aggreed. However the danger is that we end up with two or more frameworks on NeXTStep. NeXTStep's strenght has been it's consistancy, and interoperability. A hasty port of several competing frameworks might keep Mac develpers happy in the short term, but ultimatly we need to get everyone onto OpenStep. NeXT recently did a major overhaul of the AppKit moving from NeXTStep to OpenStep. This was(is) painfull for developers in the short term, but more beneficial in the long term, as everyone ends up using the same, new improved kit. I'd like to see something like that to convert MacApp apps to appkit apps (or more likly a first attempt, which the programmer then patches up), rather than having two frameworks co-existing. > >A port of MacApp threfore DOESN'T make sense, because the AppKit provides > >the same basic functionality, but in a more complete, and standard way - >I think what you are seeing is > that there might be a convergence opporunity. I am amazed how many people > think this has to be an all or none....it's a "merger" right? ;-> Yep... And the Dev environments have to merge too. A port of MacApp doesn't make sense because that wouldn't merge the enviropnments - it just allows both camps to live on the same hardware. OpenStep == Appkit. Thats a fact. What can be done is to take features from MacApp which are more advanced (you say it's more broad in its scope), and make new Kits which provide the functionality that MacApp (or powerplant) users think is missing. eg - I suspect that adding a generic document class would be a good thing. $an
Date: Thu, 09 Jan 1997 08:28:26 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Message-ID: <milkweed-0901970828260001@port5.chester.smallmedia.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b2fok$det2@ddfservb.technet.net> Organization: Milkweed Software In article <5b2fok$det2@ddfservb.technet.net>, Constantin Szallies wrote: > Objective-C does have multiple inheritance!! Multi interface inheritance but only > single implementation inheritance. The same concept as in Java, if you know this > language. Interface inheritance hardly really counts, as I understand it, since the "descendent" cannot inherit behavior. Seems more like a template, in that it allows clients to access methods without knowing the class (other than that it inherits certain interfaces). Better than nothing but the need to implement all methods in the inherited protocols is rather tedious. Anders. -- Anders Pytte Milkweed Software
Date: Thu, 09 Jan 1997 09:08:22 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Message-ID: <milkweed-0901970908220001@port5.chester.smallmedia.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> Organization: Milkweed Software In article <5b23sa$48e@news.xmission.com>, don@globalobjects.com wrote: > A concrete example is the MiscKit's MiscTee object. What it > does is act like a tee (as in plumbing)--send a message into > it and it will turn around and pass the message on to every > object on its "output", but only that that object actually > responds to the message. The Tee itself doesn't respond to > any of these messages. Instead, when you send it a message, > that message is trapped by the -forward: method, which then > loops through all the delegates and passes the message on to > each of the ones that can handle it. Since the MiscTee can > effectively respond to any message that is handled by any of > the objects that is connected to it, we have overridden the > -respondsTo: method as well. As you add and remove objects > to the Tee's list of "delegates", the set of messages it > responds to will appear to change! > ... > Anyway, since it is a reasonably good example of how the > forwarding mechanism works, I'll append the source to this > message. (Don't worry-it is pretty short, considering > what it does.) I don't think you'll find any objects in > C++ that implement this sort of functionality so cleanly > and in such a generic way. :-) This is a great feature. I made a recreational attempt to build this functionality on top of non-objective language years before objective languages were available for the Mac ('86 or '87). Did not fit in with the business plan, though. Before we had multiple inheritance we mimicked in an analogous way by attaching behaviors (and other objects) rather than mixing them in, we and still try to mimick abstract delegation with (for example, in MacApp 3) dependency spaces. But the point I wish to raise is that for many programmers (including myself) choice of language is not as important as programming habits and code design. My mental model includes ideal implementations of all these features, and my programming habits act as a sort of "precompiler" into whatever language I am using. In this case, wouldn't it be better if the language I used matched my mental model exactly? Perhaps, but depends on the costs (they work both ways). Objective C may require of a project fewer lines of code and no days housekeeping memory, but then the code object is larger and slower, which is a significant concern in our case. Now if I were starting a new project, especially if I was managing inexperienced programmers, I would probably choose Objective C. But there is no weightier reality in this business than legacy code (that I can think of). Legacy code is capital and even if it has a short life cycle you cannot just throw it away. Anders. -- Anders Pytte Milkweed Software
From: spamwall@zercom.net (Martin-Gilles Lavoie) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 14:00:24 GMT Organization: Groupimage, inc. Message-ID: <spamwall-0901970857270001@204.191.6.170> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <geoff.clapp-0801971305060001@clapge.apple.com> In article <geoff.clapp-0801971305060001@clapge.apple.com>, geoff.clapp@apple.com (Geoffrey Clapp) wrote: > In article <1997Jan3.154332.1@eisner>, kilgallen@eisner.decus.org (Larry > Kilgallen) wrote: > > >In article <32CD396A.3DC@exnext.com>, "Jonathan W. Hendry" > <jon@exnext.com> writes: > > > >> If they don't use the OpenStep API's, why would they bother buying > >> NeXT? > > > >Memory protection, an OS kernel, scheduling, ... > > > > Apple has made no official announcement on the kernel technology to be > used in the new OS (as of yesterday's keynote, anyway, the way things are > moving around here, it might be announced! ;->) I've read everything Apple had to say since December 20th. According to "Plan A" (phun), Apple will be using a "modern kernel which supports SMP". As far as I know, the current OpenStep/Mach isn't SMP, but NuMach (Apple's kernel developed for Copland and Gershwin) does support it. Will they just modify NeXT's, or use Apple's? This wasn't specified. Apple has also said that "the next generation OS will use an API based upon that of the current OpenStep, with minor modifications to include Apple technology where it makes sense". Further down: "Apple will move more towards a PostScript model [...] and will incorporate technologies from QuickDraw GX and ColorSync to add extra value". This means that DPS is going to be the driving graphics, but GX functions might be used on top on DPS in order to support features otherwise not available (trasparency?). Apple also mentioned that the initial release (DR-1) will use most of the current OpenStep look and feel, with minor modifications, but will gradually (until Golden Master) be transposed to the Mac UI, while keeping the best of both UIs. ================================================================= Please reply using the following address, rather than the "reply-to" address (my mail box is being filled with junk mail). ================================================================= Martin-Gilles Lavoie | Opinions expressed herein are just that. mouser@zercom.net | "No! Do, or do not. There is no try." Globimage, inc. | --Yoda on error handling
From: jdevlin@umich.edu Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Encryption Date: 9 Jan 1997 16:54:09 GMT Organization: University of Michigan Message-ID: <5b37rh$ss5@lastactionhero.rs.itd.umich.edu> NEXT promised encryption with NEXTSTEP 3.0, but had to relent due to federal export restrictions. Nonetheless, they shipped NS 3.x with a nice interface for encrypted email, and you can load a publicly available PGP bundle which dynamically binds with that interface. (You've got to love an OS that can dynamically load bundles -- EVERY app on the new Apple OS should have a published interface for them ...) Moreover, NEXT owns a patent on Fast Elliptic Encryption (FEE) - a cryptosystem which, according to reported hints from Steve Jobs, the NSA regards as more secure than PGP. (The NSA was rumored to be one of NEXT's larger customers ...) SUGGESTION: Apple should include a documented interface for encryption in both Mail.app and WorkspaceManager, and allow customers to load their favorite cryptographic engine as a bundle. Moreover, Apple should follow MIT's example and make a FEE bundle available on their website to anyone in the United States and make the Objective-C implementation of the algorithm available without restriction as an ascii file. Between FEE and PGP, virtually everyone would have access to military grade encryption with a consistent and well thought out GUI. -- John Devlin Department of Philosophy The University of Michigan Ann Arbor, MI 48109 - 1003
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 9 Jan 1997 16:58:24 GMT Organization: Global Objects Inc. Message-ID: <5b383g$esi@news.xmission.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b2fok$det2@ddfservb.technet.net> Constantin Szallies wrote: > And NO multiple inheritance can't be simulated by objective C's > abibliy to forward messages. These forwarding is the same as > delegation, you just don't have to write code like: Actually I don't feel that is quite correct--and this is only a matter of opinion and is therefore debatable. But let me explain what I mean... While creative use of the forwarding mechanism is not true multiple implementation inheritance, it *does* allow implementations to be shared amongst several objects (via delegation), and that is a very close approximation of multiple implementation inheritance. So I guess that you could say this isn't an implementation of MI, but rather an approximation to it that will cover the times when you would want to use MI, making the lack of MI in Objective C effectively a non-issue. Note that we are talking about a simulation--not a fullblown implementation. If, in Objective-C, you were to ever run into a situation that required multiple inheritance of implementations, this technique is the path many programmers would take to approach a solution. The fact still remains that (a) a lot of these multiple inheritance issues are moot in Objective-C because its dynamism removes the need to use multiple inheritance in most if not all cases, and (b) protocols--multiple inheritance of interfaces--cover nearly all of the remaining cases. And, IMHO, (c) a better OO design gets rid of the rest. I've done a lot of Objective C programming and have never needed to use the -forward: feature to simulate multiple inheritance. I know it can be done, because I understand the language and its implications and have used the discussed mechanisms for other things, but I've never used it in this way. So IMHO "good" designs, meaning Objective-C friendly designs I guess, should cover any remaining cases. (I do not think that using an "Objective-C friendly design" when programming Objective-C is entirely a bad thing. While you don't want your designs to be implementation independent, the tool you use _will_ influence the way you approach your design _always_ whether you admit it or not. [Take the choice of choosing an OO vs. procedural language--right there your design methodology changes...and there are subtle effects for any language you pick within those classes.] And, you might as well use your chosen tool to the best of its capacity. Luckily, Objective-C allows for much simpler designs than, for example, C++.) At any rate, the blessing of dynamic OO is enough that no one should mind the fact that it also lifts the curse of multiple inheritance at the same time. :-) And I think the above answers this question: Larry Kilgallen wrote: > The mechanism described seems perfectly adequate to > handle "mixins", which some would say is the most useful > application of multiple inheritance. Is there some other > technique for "mixins" used by the class of "most > Objective-C programmers", or do they just not need mixins > for most of their work ? I've never needed it, but I'd use this mechanism if I did. I can't say that I'm "most Objective-C programmers", but from what I've seen I think there's a lot of us that would take this approach as well...if we ever needed it. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 17:22:50 GMT Organization: University of Sheffield, UK Message-ID: <5b39ha$2cn@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> In-Reply-To: <maury-0901971043380001@199.166.204.230> On 01/09/97, Maury Markowitz wrote: > I personally don't need Unix, and thus don't want all those paths all > over the place. I can also say that I'm a minority in this regard though, > at least in the newsgroups. > So I guess you wouldn't want /System/Control Panel etc either...? That's basically what most of this stuff is. There are also a number of features in the current implementation of NEXTSTEP which explicitly allow you to hide some files (the most basic one bing the "Unix Expert" flag in Preferences, which if not selected hides exactly all those /bin, /etc folders you don't want to see. I agree, this is the way it should be, for most users. A small group of users, however, will find those directories and their contents very useful -- mainly developers and some system administrators (techies if you want). Whilst a minority, IMHO AppLE cannot afford to make these people's lives more difficult just for the sake of it... Applications have to be ported to the new OS; people will have to network the new machines and connect them to the Internet. Anything that can make these tasks easier is a win for Apple, and, as far as I can tell, keeping Unix there will do just that. Unless you have any alternative suggestions? Best wishes, mmalc. --
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 17:28:54 GMT Organization: University of Sheffield, UK Message-ID: <5b39sm$2u9@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> In-Reply-To: <maury-0901971047250001@199.166.204.230> On 01/09/97, Maury Markowitz wrote: > Sure, why not? You can add a command line to the Mac now if you want > to, 3rd party (even Unix-like shells) and this doesn't seem to be a > problem. For the _vast_ majority of Mac users the presence of Unix simply > wastes disk space because they're never going to use it. Why install all > that code for something that only 10% or less of the market is going to > use? > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to buy a disk < 1GB, this is not exactly *big*. And remember much of this is stuff which is used by the OS itself... I am having difficulty understanding your prejudice here -- what all this stuff represents is effectively what I (assume) MacOS has in its /System folder, it's just spread around a bit more (perhaps something for AppLE to address, though doing so might break a lot of stuff), and with a more obscure nomenclature. Best wishes, mmalc. --
From: TimT@asiatlanta.com (Tim Triemstra) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Using NT libs with OpenStep NT? Date: Thu, 09 Jan 97 17:37:26 GMT Organization: Alpha Star International Message-ID: <5b3am6$l6v@client2.news.psi.net> I am looking to purchase OpenStep for NT because an development library I use under NS 3.3 has stopped supporting NeXT in the present version. I was curious, could I expect to be able to use the NT libraries provided by this vendor with the rest of the OpenStep project? This is a database library and I'd like to be able to keep using all my .nib files and ObjectiveC code along with the NT binrary .lib files to access the database. Any information on plausibility and potential pitfalls would be helpful. I of course realize that the clients will have to be using NT OpenStep as well. Tim Triemstra ....... TimT@ASIAtlanta.com Alpha Star International, Atlanta GA USA
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: Basic question about OpenStep Date: Thu, 9 Jan 97 00:00:19 +0100 Organization: Warty Wolfs Message-ID: <9701082300.AA04026@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In article <onscrn-0801970958320001@151.atlanta-10.ga.dial-access.att.net>, you wrote: > Please excuse my ignorance, but it's amazing how many messages on OpenStep > I've read without getting the answer to this basic question: Is OpenStep > required to be present in order to run programs written using OpenStep? My > assumption had always been yes, but I've read so many times that "if you > write an OpenStep program it automatically will run on NT etc." I'm > confused. So, can anyone with a machine running "stock" NT (no OpenStep > addition of any kind) fire up a program written using OpenStep (compiled > for the particular type of machine the user has) and run it? Your assumption is correct. You need the OPENSTEP/NT runtime in order to run OPENSTEP/NT apps. (the runtime basically consist of a bunch of shared libraries, plus some server programs like windowserver). --- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ IC Group <tom@icgned.nl> (work) __/__/__/ "Any magic sufficiently advanced is indistinguishable __/ _/_/ from a perl script" -- Larry Wall, mangled
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 19:07:44 GMT Organization: Global Objects Inc. Message-ID: <5b3fm0$esi@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5b1p4k$8sf@news1.ucsd.edu>, mbk@inls1.ucsd.edu (Matt Kennel) wrote: > > > No. This is stupid. It means that standard applications cannot assume the > > presence of useful unix style utilities. Users might not want to know > > about '/bin', but they do not want a program or internal script to die on > > account of its absence. > > Standard applications can current assume that Unix is not installed. I > run about 100 applications on my Macs, and not a single one of them calls > anything remotely like Unix. Sure having the utilities allows a lazy > programmer to do less work, but I don't see this as a goal. There are a lot of NEXTSTEP applications that use the shell and UNIX commands to do a lot of things. I don't think it is wise to throw all that out. In fact, I wouldn't want to lose all those apps. And if half the apps you buy, in their installation, insist that you install an "optional" UNIX shell package, the user might as well just have it installed automatically from the beginning so they don't have to be bothered with that extra detail. Now, most people won't need to access the commands directly, BUT if many of their apps do, then they need to be there. The answer is simple, and NEXTSTEP already has it. From the GUI, by default, the /bin, /usr, .* files, /etc, plus several other files in the filesystem are hidden and do not appear in the GUI. This is system wide--open/save panels, WorkSpace, etc. You can even add a file called ".hidden" to a directory to tell the system which files should be hidden by default. The user who wants to see the files goes into the Preferences.app (analogous to a control panel) and turns on the "UNIX Expert" checkbox. So the GUI can hide the complexity from those who don't need to see it and show it to those who want it. It seems like that is adequate to solve the problem. [Aside: I've known NeXT slab owners who I've helped with their systems. When I turn on UNIX Expert mode, they are surprised--"I didn't know all that was there!" These are people who have owned NeXT machines for _years_ and never knew. Their daily usage of the system probably invoked many of those commands and made use of much of that hidden stuff--the swapfile is an obvious example--but they never saw it, or even cared. And they didn't need to know it to get their work done. That's an effective GUI--it did what it is supposed to do with no hassles for the user.] OK, so there's still the "lazy programmer" argument. Well, my counter to this is the fact that a large part of the NeXT environment--not just third party apps--uses the underlying UNIX commands in /bin and elsewhere. If you got rid of them, you'd suddenly have a hell of a lot more work to do to create Rhapsody. I don't think Apple wants to do that. Additionally, why shouldn't a programmer use these commands? Why re-invent the wheel for every app? By sharing resources that are already available as much as possible, you enhance the stability and robustness of the entire system. Which is easier to debug: fifteen routines to do a file copy in fifteen different apps or a single "cp" program on the system? Plus, in the case of "cp", we already know it works. If we rely upon it, that is one less bug we have to worry about! We're building off the stability that already exists. Software is becoming very complex and this (and other forms of OOP) is the one of the reasonable ways we currently have to manage that complexity. Moreover, if the system "cp" program _is_ broken and Apple is too slow to fix it, you can grab source off the net (or a prebuilt package someone else may have already built) and replace that portion of the system with a version that works. Without having to wait. NeXT users have done this with sendmail, ftpd, httpd, and many other portions of the system for a long time and it works. And, with NeXT's Installer.app, it is easy to create, distribute, and install these minor upgrades via the GUI without *ever* having to deal with UNIX directly! It is no different than installing a vendor patch, and the ease of creating packages helps the situation because NeXTophiles create these updates left and right--so that most of us can have modern systems without having to deal with UNIX. But without the underlying tar and compress commands, even the Installer would break... My point is that those commands need to be there for apps to run well. The user may never touch them directly, but that's OK. They can obtain the benefits of these programs without ever knowing that they are using them because the GUI hides the underlying complexity. I think that's a win-win reason for keeping it in there. As food for thought, here are some other interesting features in the environment that I really like, which are direct results from the UNIX commands: In Edit.app, the editor that comes free with NEXTSTEP, the expert mode, if turned on, gives you the option to pipe any text selection through a UNIX command of your choice. (Select the text with the mouse, type Command-|, type the UNIX command into the text field, hit return, and voila!) This is great because it makes the editor that much more extensible. I find that piping logs through grep or grep -v allows me to analyze them very rapidly and is highly useful. Programmers would have all sorts of use for this feature, too. The MiscKit contains an object called the MiscShell that makes it trivial to connect an arbitrary UNIX command or shell script up to the NEXTSTEP GUI--all from InterfaceBuilder.app, without writing code. Tell me, when was the last time you saw someone use drag and drop to create a flat file news reader _without_ _writing_ _any_ _code_? This is way cool, but the capability relies heavily upon the underlying UNIX inside of NEXTSTEP. I'm sure that I could keep spouting off examples, but you get the idea. Part of the stability and richness of the NeXT environment are directly attributable to the good sense NeXT had in building on top of something as powerful as UNIX. While IMHO UNIX is unfriendly to novices and it is good to hide it from them via a good GUI, it is also IMHO that it would be dumb to throw out that power. And isn't this what OOP is all about? Code reuse? Is it really lazy to reuse existing code? Or is it just a wise application of expensive and limited programmer hours, making an efficient use of that time? -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: tiggr@es.ele.tue.nl (Pieter Schoenmakers) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 09 Jan 1997 20:59:58 +0100 Organization: Eindhoven University of Technology Sender: tiggr@tom.ics.ele.tue.nl Distribution: inet Message-ID: <x7sp4ar54x.fsf@tom.ics.ele.tue.nl> References: <0k20yMppj+2S091yn@mindlink.net> <E3qqHu.58C@cam-ani.co.uk> In-reply-to: ians@cam-ani.co.uk's message of Thu, 9 Jan 1997 12:25:05 GMT In article <E3qqHu.58C@cam-ani.co.uk> ians@cam-ani.co.uk (Ian Stephenson) writes: > @"string" They're a shortcut to create a string object, equivalent to [NSString stringWithCString:"string"]; No they are not. They're automatically put into the releasepool, so you'd need to retain such a string if you needed to keep a copy. @"String objects" are part of the executable. If you want to keep them, retain them; after retaining, release them, but do not retain them to prevent them from being autoreleased, since they aren't (autoreleased, that is). Not that an extra retain matters, since they can not leak anyway (apart from the retainment administration). --Tiggr
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 9 Jan 1997 21:04:38 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5b3mh6$ijp$1@brachio.zrz.TU-Berlin.DE> References: <5b2cac$s0a@btmpjg.god.bel.alcatel.be> In article <5b2cac$s0a@btmpjg.god.bel.alcatel.be> suckow@bln.sel.alcatel.de (Ralf Suckow) writes: > Greg Titus writes > > // foo points to an automatically built NSArray object containing a couple > > // of NSStrings > > NSString *foo = @(@"bar", @"baz"); > > > Shouldn't this read > NSString *foo = @("bar", "baz"); The @() syntax is part of WebScript, not Objective-C. In WebScript, it creates "constant" NSArrays. @"" creates constant NSStrings in both WebScript and Objective-C. In Objective-C, the objects are created by the compiler as instances of NXConstantString class (though I would assume this to be implementation-dependent.) To see for yourself, try using the @"" syntax in a source file that does not include the NSString header file. Marcel
From: ibhan@student.med.harvard.edu (Ishir Bhan) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 09 Jan 1997 16:09:50 -0500 Organization: Harvard Medical School Message-ID: <ibhan-0901971609500001@infobhan.med.harvard.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <ibhan-0801971336040001@infobhan.med.harvard.edu> <bononno-ya023680000801972235030001@news.nyu.edu> In article <bononno-ya023680000801972235030001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: > That's not what I read. Well, read more carefully, then. http://www.macos.apple.com -- Ishir Bhan Harvard Medical School '00 ibhan@student.med.harvard.edu http://www.digitas.harvard.edu/~ibhan
From: spamwall@zercom.net (Martin-Gilles Lavoie) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 21:24:42 GMT Organization: Groupimage, inc. Distribution: world Message-ID: <spamwall-0901971621430001@204.191.6.170> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1qed$nlm@nntp1.apple.com> In article <5b1qed$nlm@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: [...] > I'd like to point out that there is no complete framework for Mac OS 8 > yet though many in this discussion have talked like OpenStep _is_ that > framework. This will come when OpenStep has been modified to provide > some form of Macintosh User Experience. Perhaps MacApp can contribute in > this way, too. Interestingly, I am working on a new framework which was intended to be used as a bridge for Mac OS 7.x and (R.I.P.) Copland (using it's HIObject-based classes), to replace what we're currently using in-house (another home-brewed framework). This framework's core classes strangelly ressembles OpenStep's (as per the drafts of 94, as found on www.next.com), and I'm thingking of making this framework a cross-platform (ie, Mac OS 7.x/Rhapsody) framework. I'm still examining the OpenStep code for feasability (OpenStep is new to me, as for many Mac programmer). See for yourself: (c) copyright 1996-1997 Martin-Gilles Lavoie All rights reserved CKernel CLinkedList CBinary CClassList CMemory CKernelEvent CKernelObject CMenu COSAObject CCAFEStream CCAFEWindow CDynamicObjectMember CDynamicObject CKernelTask CApplication CEventScheduler CGarbageCollector CGraphicsEngine CIdleTask CAgent CIdleFunction CIODevice CIOTextStream CFile CDynamicObjectsFile CKeyboard CSerial CModem CSpeachIO CMouse CNetwork CSCSI CKODE CKODEVariable CWindowThing CWindowCaptionThing CWindowButtonThing CWindowPopMenuThing CWindowPushButtonThing CWindowCheckButtonThing CWindowRadioButtonThing CWindowPictButtonThing CWindowEditFieldThing CWindowLabelThing CWindowListThing CWindowTextThing CWindowLinesThing CWindowBezierThing CWindowViewThing CWindowClusterThing CToolBox CUndoRedoList CString CNumber CTokenList CQueuedList The interesting thing in this framework is that OS 7 events are mapped to CKernelEvent objects. Therefore, mapping OpenStep messages in there would be trivial. Also, since both Rhapsody and the "blue box" will support AppleEvents, it doesn't break the 'COSAObject' class hierarchy. The above framework is about 20% functional (core stuff is in, and some of the CWindowThings are all set...details available on request), and is currently being compiled with Copland interfaces (something I'll have to change, I guess). This framework handles garbage collection, runtime code interpretation (CKODE= Kernel Object Developer Extention), instantiation by name and by type, *fast* in-window UI (910 items drawn in less than 1.5 secs on Quadra 840AV--power macs where not timed yet as we use that Quadra for performance bottom-line). The CKernel object is the main loop container, and administrator of all registered classes, objects and tasks (which makes somewhat of a miss-namer). If anyone wants to give his/her insights, I'd welcome them. ================================================================= Please reply using the following address, rather than the "reply-to" address (my mail box is being filled with junk mail). ================================================================= Martin-Gilles Lavoie | Opinions expressed herein are just that. mouser@zercom.net | "No! Do, or do not. There is no try." Globimage, inc. | --Yoda on error handling
From: rickg@sunsoft.eng.sun.com (Richard Goldstein) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 09 Jan 1997 13:10:53 -0800 Organization: SunSoft, Inc. Sender: rickg@upuaut Message-ID: <ku7d8velfky.fsf@upuaut> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> In-reply-to: mmunz@inconnect.com's message of 9 Jan 1997 06:24:28 GMT From: mmunz@inconnect.com (Mark Munz) Newsgroups: comp.sys.next.programmer Date: 9 Jan 1997 06:24:28 GMT Organization: Puppy Dog Software >In fact, I know of research projects where people used postscript to add >functionality to servers and device drivers, that had nothing to do with >graphics. It is a turing-complete programming language. You can write >a LISP interpreter in it if you like! I don't want yet another programming language .. I just want to be able to image. The fact that PS is intrepeted is also bothersome.. Never has interpreted been equated with high speed. The whole purpose of pre-emptive These concerns are a good part of what I try to address in my somewhat expirimental Modello class library for DPS/X, which in part implements the PS types on the client side in a commonly used language (in this case a subset of C++), such that you can do more on the client side, in a compiled language environment, and only download the PS commands that really need to be done there. It includes a complete language binding for PS which gets converted directly to binary object sequences for faster execution. This works fine for Solaris OpenStep, which uses DPS/X. Anyone interested, there is a white paper discussing this, plus the issues with pswrap, etc. in the release available in ftp.x.org:/contrib/devel_tools/DPS/ rick -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Richard M. Goldstein richard.goldstein@Eng.Sun.COM 64-bit Linkers, Libs & Executables SunSoft, Inc. "Without time we pick up all the streams, and find the leaves that drift out inbetween..." -Kirkwood
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 9 Jan 1997 13:21:21 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.852844537@idiom.com> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> mmunz@inconnect.com (Mark Munz) writes: >In article <jcr.852636452@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: >>In fact, I know of research projects where people used postscript to add >>functionality to servers and device drivers, that had nothing to do with >>graphics. It is a turing-complete programming language. You can write >>a LISP interpreter in it if you like! >I don't want yet another programming language .. I just want to be able to >image. The fact that PS is intrepeted is also bothersome.. Never has >interpreted been equated with high speed. The whole purpose of pre-emptive I wasn't suggesting that we all start writing apps in Postscript. I was making a point about extensibility. The speed of DPS comes from its caching machinery, and raster operations. These have had many years and many passes of code revision, and Adobe does have some of the best graphics hackers who ever wrote code. I know a few of them. >MT and other such goodies is give performance to the user. This is an area >that I think BeOS seems to win in (their imaging is extremely fast). I >would have actually liked to see something closer to how Be did it (taking >advantage of the FPU in PPC chips -- and Pentinum also has FPU built-in).. >it seems disappointing. AFAIK, DPS does use the floating-point hardware in whatever CPU it's running on. As for Be's speed, well, they'd *better* be fast on a dual-PPC machine. DPS was fast enough to use on a 25Mhz '040. I can't wait to see some of the PS fractal hacks run on a 225Mhz 604! >While some of this is bothersome, I'm not ready to condemn DPS - but it >does raise some questions about it. >I hope Apple talks to someone BESIDES Adobe (they're opinions are SLIGHTLY >BIASED) on this to make sure they're making the right decision about the >imaging model. Apple hasn't been doing much talking to Adobe on this subject. Adobe only found out about the merger a few days before we all did. -jcr
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 09 Jan 1997 16:23:04 -0500 Organization: Atria Software Message-ID: <maury-0901971623200001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> In article <5b39ha$2cn@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > So I guess you wouldn't want /System/Control Panel etc either...? > > That's basically what most of this stuff is. Oh, true enough, but there's a quality and quantity thing. I mean, do I need all the .conf files? How about the shells and all the support stuff for them? man pages? > There are also a number of features in the current implementation of NEXTSTEP > which explicitly allow you to hide some files (the most basic one bing the > "Unix Expert" flag in Preferences, which if not selected hides exactly all > those /bin, /etc folders you don't want to see. Yeah, but all that stuff adds up a lot in size. I'd personally rather not have it installed unless I want it. > A small group of users, however, will find those directories and their > contents very useful -- mainly developers and some system administrators > (techies if you want). Whilst a minority, IMHO AppLE cannot afford to make > these people's lives more difficult just for the sake of it... Absolutely, and they should get to install it off the same CD. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 09 Jan 1997 16:24:17 -0500 Organization: Atria Software Message-ID: <maury-0901971624340001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> In article <5b39sm$2u9@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > stuff which is used by the OS itself... My mom's HD is 80Meg. So now we get to buy a new HD to store files she'll never use. Hmmmm. Maury
From: piercej@m4.sprynet.com Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 07 Jan 1997 22:39:41 +0000 Organization: Sprynet News Service Message-ID: <32D2D0AD.6870@m4.sprynet.com> References: <AEEFE2B6-491909@204.246.66.19> <5aigjj$72u$1@aggedor.rmit.edu.au> <5ak4r4$9je@news3.digex.net> <32CE8F2E.1A12@m4.sprynet.com> <5aq7uf$7vo@huffalump.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: jonathan_pierce@seagram.com >piercej@m4.sprynet.com wrote: >: Code developed using the NEXT development tools and frameworks is >still OS dependant. david young responded: >>Wrong. You've missed the whole point of OpenStep. >>Thanks for playing, though. Not really. I didn't say processor dependant, I said OS dependant. OpenStep is an OS and applications using it require it to be installed. It is impossible for me to ship applications on W95 and WindowsNT without requiring users to license and install OpenStep first. Even if users could obtain it free, they may not be willing to install the environment since it adds overhead they may not feel is justified. -Jonathan
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Apple-NeXT Conflicts? Followup-To: comp.sys.next.programmer Date: 9 Jan 1997 22:35:50 GMT Organization: University of Sheffield, UK Message-ID: <5b3rs6$jvc@bignews.shef.ac.uk> References: <petrichE3Ct2r.3AJ@netcom.com> <32CB01DB.41AB@exnext.com> <marke-0201970014260001@port55.annex5.nwlink.com> <maury-0601971027400001@199.166.204.230> <32D3AD84.237C@aurora.jhuapl.edu> <5b0h10$73b@bignews.shef.ac.uk> <maury-0801971735060001@199.166.204.230> <5b1d96$5hn@bignews.shef.ac.uk> <maury-0901971309580001@199.166.204.230> In-Reply-To: <maury-0901971309580001@199.166.204.230> Note: followups to comp.sys.next.programmer On 01/09/97, Maury Markowitz wrote: > > If a Class adopts a Protocol > > it asserts that it has definitions for all the methods declared in the > > Protocol. Furthermore, since Objective-C allows dynamic binding (and the > > concept of Delegates) messages sent to one Object can be forwarded on to > > another for handling. > > Ok, can you give me an example? I'll give you one and perhaps you can > illustrate how this works to the same solution... > There is a thread on this subject already in comp.sys.next.programmer in which this is being discussed by people for more able than I, and a couple of excellent examples have already been given -- may I point you to those. > In the PowerPlant book them give a perfect example of why MI works well > in a class lib. Consider a window field that allows the user to input a > string. It's got a lot in common with a lot of other standard things that > can be placed in windows, so we group the common code into something like > WindowGizmos. These are things that can be drawn in windows, so you put > them into some WindowItems class. > > But the cursor in the field has to blink, it will have to get time every > so often. So this means that you have to have it be a part of a > Periodical class, because lots of other things need time too. Without MI > this means that the View class has to come from the Periodical class, even > though only a SINGLE class WAYYYY down the chain needs anything from > Periodical! Making Periodical a mixin class solves the problem, you > inherit it directly into the classes that need it. > > The result is easy to see, TCL is VERY deep, PowerPlant is VERY flat. I > like flat. > > Ok, so can this be done in Object C? Can you give an example? > Well, clearly it can be done -- my cursor's blinking away as I type! :-) This sort of thing, though, is usually handled by the (PostScript) Window Server, which handles timed events, and can be used in a number of creative ways. For most TextFields etc that you use, unless you're writing your own DTP app, I'd imagine you'd either be using an AppKit TextField or a subclass thereof, in which case the cursor is handled for you automatically. Best wishes, mmalc. --
From: shimpei@argo.patnet.caltech.edu (Shimpei Yamashita) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 14:44:29 -0800 Organization: Hummingbird Heaven Message-ID: <5b3scd$8et@argo.patnet.caltech.edu> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> In article <maury-0901971045180001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b1p4k$8sf@news1.ucsd.edu>, mbk@inls1.ucsd.edu (Matt Kennel) wrote: > >> No. This is stupid. It means that standard applications cannot assume the >> presence of useful unix style utilities. Users might not want to know >> about '/bin', but they do not want a program or internal script to die on >> account of its absence. > > Standard applications can current assume that Unix is not installed. I >run about 100 applications on my Macs, and not a single one of them calls >anything remotely like Unix. Sure having the utilities allows a lazy >programmer to do less work, but I don't see this as a goal. If you hate Unix so much, Nextstep is constructed such that you don't have to use any of them, and you don't have to see any of them unless you go hunting for them. I see a whole bunch of files in my System Folder whose purposes are entirely unclear; I'm just afraid to delete them all in case I screw something up. They are definitely an eyesore--gosh, the Preference folder sure gathers up a lot of muck after a few months of trying out new software! Ditto for the Extensions folder. On the other hand, they appear to be perfectly harmless if left alone, so I keep my mouse pointers away from them. The little Unix files in /bin, /etc and whatever are no different if you don't know or like Unix. Some of them are absolutely necessary for running a system (I'm not sure exactly how NeXT handles bootup, but if it's anything like normal Unix, bootup is handled through Bourne shell scripts, which rely heavily on these Unix programs), and others come in very handy once every so often. And if you don't want to see them, nothing prevents you from ignoring their existence, much like I ignore the Extension folder's existence 99.9% of the time. I completely disagree about the laziness issue. Maybe it's true for commercial-grade programs, because using external routines often introduces big speed penalties. On the other hand, people who often write short programs or scripts (the same folks who have embraced AppleScript) will benefit a lot from having a complete set of file-manipulation utilities lying around. For those types of applications, development time is much more important than the speed of the final solution. -- Shimpei Yamashita <http://www.cco.caltech.edu/%7Eshimpei/> Graduate Student, Caltech Dept. of Physics shimpei@socrates.caltech.edu
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Thu, 9 Jan 1997 22:07:39 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E3rHGs.7BC@cam-ani.co.uk> References: <5b1bka$sdo@bias.ipc.uni-tuebingen.de> In article <5b1bka$sdo@bias.ipc.uni-tuebingen.de> frank@this.net (Frank M. Siegert) writes: > In <geoff.clapp-0801970942500001@clapge.apple.com> Geoffrey Clapp wrote: > > > The AppKit and OpenStep frameworks are very similar to MacApp, PowerPlant, > > MFC, TCL, etc. > > Sorry to tell but you are wrong. AppKit and OpenStep frameworks have in fact > not much in common with MacApp, PowerPlant, MFC, TCL, etc. While I've disagreed with Geoff Clapp about a number of details in this thread, if you don't see that MacApp and AppKit are similar, then you don't understand the issues here. The point of MacApp, and the fundamental structure of an AppKit program are the same: That you relinquish the control flow to an App object which then asks objects within your program to perform tasks as appropriate in response to user actions. Both systems set up a null application with the user then fills in the behaviours for. This fundamentally different to the way X, or older Mac programs are/were written. Here the program retains control, doing it's own thing, and polls the UI for information about the users actions receiving a list of events which it then has to parse and deal with. Having ported a number of apps from X to NeXTStep, changing this around can be a problem (Uae uses a very nasty hack to get round this). The fundamental structure of a MacApp app is the same as an AppKit app, and this is a good start for those transfering. $an
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 9 Jan 1997 23:40:05 GMT Organization: Global Objects Inc. Message-ID: <5b3vkl$ebp@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5b39ha$2cn@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > > > So I guess you wouldn't want /System/Control Panel etc either...? > > > > That's basically what most of this stuff is. > > Oh, true enough, but there's a quality and quantity thing. I mean, do I > need all the .conf files? How about the shells and all the support stuff > for them? man pages? Man pages are already installed from a seperate package. You have to want them to get them. The remaining .conf files are needed by the system to function properly. They are the UNIXy things that haven't moved into NetInfo, and they alone don't take up much space. If Apple gets rid of them by moving them into NetInfo, then great, but the difficulty there is that they are things that typically get configured _before_ NetInfo starts up! (Note that the GUI sysadmin tools _do_ modify many of these files, so you don't have to go in with vi or emacs to configure things--in many cases.) You don't want to throw out the /usr/adm stuff, since the logs in there are the first thing a support person would want to look at to determine what is wrong with a system. You can't throw out /private because that's where the vm filesystem is as well as all the .conf files (/etc is a link into there) and is needed for normal operation of the machine. What's left? A few shlibs and some UNIX commands. The large majority of them are needed by GUI apps--they are the underlying functionality. I wrote another port on this in more detail explaining why those shouldn't be thrown out. > > There are also a number of features in the current implementation of > > NEXTSTEP which explicitly allow you to hide some files (the most > > basic one being the "Unix Expert" flag in Preferences, which if not > > selected hides exactly all those /bin, /etc folders you don't want > > to see. > > Yeah, but all that stuff adds up a lot in size. I'd personally rather > not have it installed unless I want it. I really think the UNIX Expert preference is all the hiding Apple needs to do--and is all they should do. You should have a least common denominator that all app developers can count on, and it is important to not take away functionality in the system. You might not use it directly yourself, but the GUI Apps you do use directly will rely upon it. You may not want that stuff, but it turns out you'll need it to run things. If Apple's going to get this thing out the door within a year, they don't have time to rewrite all the UNIXy stuff and move it elsewhere on the system--and I can't really see any advantage to embarking on such a project anyway. You lose more than you gain. > In article <5b39sm$2u9@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult > > these days to buy a disk < 1GB, this is not exactly *big*. And > > remember much of this is stuff which is used by the OS itself... > My mom's HD is 80Meg. So now we get to buy a new HD to store files > she'll never use. Hmmmm. I think you should consider a new HD as part of the price of an upgrade. Or just don't upgrade. Stick with what you have that already works. Or spend the $200-$300 to get a new 1GB+ hard drive. It won't kill you! Also note that the compiler and about half of the stuff that is installed on the drive mentioned is another optional package--the developer tools. So the footprint is smaller than you think for the UNIXy stuff. An 80Meg hard drive is outdated hardware at this stage of the game, and not sufficient for a modern OS. If the disk is only 80 Meg, even if Apple _does_ remove all the UNIXy stuff, I guarantee you that Rhapsody will NOT fit on it, let alone anything else. You honestly need to have a 400M or larger drive to run NEXTSTEP/OPENSTP. And don't expect that to shrink too much--once you get backward compatability added in, expect that to only _expand_! Disk space is cheap nowadays. That shouldn't be clouding decisions like this one. (And at Apple, I'm sure it isn't...) Then again, maybe I'm spoiled by the ~8 GB of space I have shared by my NeXTs for development. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 02:09:27 GMT Organization: Netcom Distribution: world Message-ID: <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) wrote: > How about: > Ada, Basic, Cobol, Eiffel, Fortran, LISP, Pascal, PL/I and Prolog. A few of the above are or have been available for NEXTSTEP. I would imagine that they, plus others, will be ported to Rhapsody with its probable significantly better market share than NEXTSTEP/OPENSTEP/Mach. However, none of them took advantage of the huge amount of functionality provided by the various Objective-C object kits included by NeXT. > Even if one considers "languages one can send > over the net for extremely trusting individuals to execute in their > own security context" (a _very_ small part of "work related to the > internet"), the only element Java has going for it is the planned > pervasiveness of the Java Byte Code engine. I humbly suggest that Java provides much of the advantages of Objective-C plus provides automatic garbage collection, a big win. Some of the languages you list above support automatic GC also, but for programmers accustomed to C-based languages, automatic GC is very attractive. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 9 Jan 1997 01:55:47 GMT Organization: Netcom Distribution: world Message-ID: <5b1j73$fr3@sjx-ixn2.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5amhc2$dao@nyheter.chalmers.se> <1997Jan5.085111.1@eisner> <5ap7gf$mnu@nyheter.chalmers.se> <5aq4vt$bfu@sjx-ixn9.ix.netcom.com> <5arh7t$2no@nyheter.chalmers.se> <MWRon-0701972046550001@aumi3-a03.ccm.tds.net> <32D33F89.7C0E@watershed.com> "Dirk P. Fromhein" <Dirk.Fromhein@watershed.com> wrote: > But all this is irrelevant as I think Java will be *THE* programming > language from now on (for custom apps and even shrinkwap apps). I agree. I guess it's too much to hope for considering the huge job Apple and NeXT engineers have ahead of them just to get a nice OS running on Mac hardware, but my dream would be for a port of the OPENSTEP API to Java so we won't have to deal with memory management any more. But I would miss the self-documenting Objective-C named method arguments - initWithContentRect:styleMask:backing:defer: (NSWindow's designated initializer). NeXT apparently recently released support for mixing Java and Objective-C to the extent that a class implemented in one language could be subclassed in the other language, so this might be a reasonable approximation if it works seamlessly. I don't have any details about this, so maybe I just dreamed it :-) -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Chung Yang <chyang@eng.sun.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 09 Jan 1997 15:18:03 -0800 Organization: Sun Microelectronics Sender: chyang@thesands Message-ID: <840rajujv4k.fsf@Eng.Sun.COM> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> maury@softarc.com (Maury Markowitz) writes: > > In article <5b1p4k$8sf@news1.ucsd.edu>, mbk@inls1.ucsd.edu (Matt Kennel) wrote: > > > No. This is stupid. It means that standard applications cannot assume the > > presence of useful unix style utilities. Users might not want to know > > about '/bin', but they do not want a program or internal script to die on > > account of its absence. > > Standard applications can current assume that Unix is not installed. I > run about 100 applications on my Macs, and not a single one of them calls > anything remotely like Unix. Sure having the utilities allows a lazy > programmer to do less work, but I don't see this as a goal. Try to look at it from another perspective. Having utility allows a "not so lazy" programmer to be more productive. IMHO, is a good goal to have. Also consider why people needed Unix untilities. Unix is a huge operating system that most of the time exists in a heavily networked environment that often needs to work on completely different harware platforms. Even the most astute programmar would not be able to hack a piece of code that works on all machines. Lets consider for a moment. What if the MacOS is a cross platform OS? How would you be able to keep your sanity to make sure that the app you are writing works on all variations of MacOS? Recompile on every machine? Or wouldn't it be better to have a set of commonly used utility already in the OS. And if you want to do tool control or file level manipulation, all you do is to write scripting languages to execute those utilities. Finally, consider for a moment. The next generation OS for the Mac platform will need to do all those stuff that unix has been able to do for over 20 years. - Chung > Maury
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 00:19:50 GMT Organization: Global Objects Inc. Message-ID: <5b41v6$ebp@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> shimpei@argo.patnet.caltech.edu (Shimpei Yamashita) wrote: > If you hate Unix so much, Nextstep is constructed such that you don't > have to use any of them, and you don't have to see any of them unless > you go hunting for them. This is very true. They are in well defined places and by default are hidden by the GUI. > I see a whole bunch of files in my System > Folder whose purposes are entirely unclear; I'm just afraid to delete > them all in case I screw something up. They are definitely an > eyesore--gosh, the Preference folder sure gathers up a lot of muck > after a few months of trying out new software! Ditto for the > Extensions folder. On the other hand, they appear to be perfectly > harmless if left alone, so I keep my mouse pointers away from them. The beauty of NEXTSTEP is that you wouldn't even have to see these! They would be out of sight and out of mind. :-) You can configure which files are hidden by the GUI. > The little Unix files in /bin, /etc and whatever are no different if > you don't know or like Unix. Some of them are absolutely necessary for > running a system (I'm not sure exactly how NeXT handles bootup, but if > it's anything like normal Unix, bootup is handled through Bourne shell > scripts, which rely heavily on these Unix programs), That's right. It uses sh. And, if you do hopelessly screw up your system config, you can usually boot into single user mode and fix it back up without losing any files. Obviously, this is a feature Joe User won't use, but a support technician would need it to recover the system. And that relies upon sh and vi/emacs at the very least to get the job done. There's a lot of other UNIX programs that get run during bootup, too, and are absolutely necessary to start the system. > I completely disagree about the laziness issue. Maybe it's true for > commercial-grade programs, because using external routines often > introduces big speed penalties. Even then, it depends upon what the program is doing. Most of the backup programs for NeXT are actually wrappers around tar and/or dump, which are UNIX programs, for example. In this case, that is a good thing, because gnutar, for example, is well tested software and that inspires confidence in the user. And the extra process overhead on a tar dump isn't going to be significant since a backup will almost always take long enough to make the startup of a new process negligible. The Installer is also wrapped around tar/compress, and Opener.app wraps around just about every archiving and compressing tool in existence. Apps like these are as robust and fast as necessary and that "extra overhead" isn't a problem at all. Another advantage of using these tools is that other apps can also make use of the same tools--sort of like a primitive shared library. That helps cut down on the app size and conserves disk space. > On the other hand, people who often > write short programs or scripts (the same folks who have embraced > AppleScript) will benefit a lot from having a complete set of > file-manipulation utilities lying around. For those types of > applications, development time is much more important than the speed > of the final solution. Absolutely! For those who have taken the time to learn what tools exist and how to use them, this is an understatement! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: ici@giocoso.osk.threewebnet.or.jp (Toshinao Ishii) Newsgroups: comp.sys.next.programmer Subject: Re: Audio problem after upgrading 3.2 -> 3.3 Date: 09 Jan 1997 15:57:21 GMT Organization: 3Web internet service Message-ID: <ICI.97Jan10005723@giocoso.osk.threewebnet.or.jp> References: <5aj1r6$mu6@tron.sci.fi> In-reply-to: comm@sci.fi's message of 3 Jan 1997 13:33:26 GMT In article <5aj1r6$mu6@tron.sci.fi> comm@sci.fi (Juha Tuominen) writes: > I updated a customer's Intel NeXTstep system from 3.2 to 3.3. Their audio > program began acting weird after the update. When recording a sound and > stopping the recording with stop button (sends stop: message to sound > object) the audio driver receives the stop message and it stops recording, > but sound object fails to send didRecord: message to delegate object What about changing IRQ ? I have an experience that playing sound became not smooth after I changed video card. I tried several combination of IRQs asigned to the sound card and found a good one. -=-=-=-=-=-=-= Toshinao Ishii email: ici@osk.threewebnet.or.jp (NeXTMAIL/MIME Welcome)
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 10 Jan 1997 00:33:28 GMT Organization: Global Objects Inc. Message-ID: <5b42oo$ebp@news.xmission.com> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> <jcr.852844537@idiom.com> jcr@idiom.com (John C. Randolph) wrote: > AFAIK, DPS does use the floating-point hardware in whatever CPU > it's running on. That is correct. In fact, when NEXTSTEP was ported from m68k to x86 architectures, one of the disappointments was the the graphics speeds weren't much better. When you sit down to analyze why this is, there are two reasons: (1) Bus architectures. NeXT had local bus video (and a fine design of it) long before the Intel world did and subsequently the PC bus slowed things down. Nowadays, there are good video subsystems for Intel hardware that take care of this problem adequately. But, even more telling, (2) When you compare x86 and m68k series, you find that Motorola's FP performance is better than that of an equivalent Intel CPU. Conversely, the Intel processors do better with integer math. Since DPS does so many FP calculations, you find that the m68k still retained an advantage--longer than one might have originally expected. So you can count on DPS to take full advantage of the FPU! In fact, the FPU and the graphics bus speeds are far more important to DPS than the integer math speed of the CPU. > As for Be's speed, well, they'd *better* be > fast on a dual-PPC machine. DPS was fast enough to use on a 25Mhz > '040. I can't wait to see some of the PS fractal hacks run on a > 225Mhz 604! No kidding! DPS is really a lot faster than most people expect. I've got a Pentium Pro that dual boots OPENSTEP and Win95/WinNT. Frankly, OPENSTEP _feels_ as fast as the other OSes. In fact, it feels _really_ fast on this hardware, after coming off my Turbo slab (which is still bearable performance, at least). -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: bmunn@lighthouse.com (Beth Munn) Newsgroups: comp.sys.next.programmer Subject: Open Positions! Lighthouse Design, Sun Microsystems, Inc. business Date: 10 Jan 1997 00:38:22 GMT Organization: Lighthouse Design, a Sun Microsystems business Message-ID: <5b431u$35v@nntp1.best.com> Lighthouse Design (a Sun Microsystems business) 2929 Campus Drive San Mateo, Ca. 94403 415.570.7736 http://www.lighthouse.com Founded in 1989, and acquired by Sun Microsystems in July of 1996, Lighthouse Design is one of the industry's most experienced developers of applications for purely object-oriented environments. Lighthouse offers the exciting and fast paced environment of a small company, while being able to provide "big company" benefits. JavaPlan, the newest product from Lighthouse Design is the industry's first enterprise devlopment platform forthe analysis, design and generation of sophisticated Java applications. Lighthouse is also the premiere provider of productivity applications for the OpenStep and Solaris environments. We are looking for individuals who can demonstrate excellence in Object-OrientedTechnology, GUI design, software engineering management, and application development. Your skills should include: JAVA, OBJECTIVE-C, SMALLTALK, C++, OPENSTEP, SOLARIS, Windows NT, RDBMS, OODBMS, OO A/D, and "off the shelf" application development, The following positions are currently open: JAVA DEVELOPMENT MANAGER APPLICATIONS ENGINEERS JAVAPLAN ENGINEERS SALES ENGINEERS TRAINERS/CURRICULUM DEVELOPERS OPERATIONS MANAGER .....and others!! Lighthouse is a leader in the Object-Oriented software industry, come and work with some of the best people in the business. For more informaiton please contact or send your resume to: Beth Munn 415-570-7736 bmunn@lighthouse.com For other opportunities, please see our web site at: www.lighthouse.com
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Thu, 09 Jan 1997 19:04:56 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D587A8.5ECB@steeldriving.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit <followups trimmed to limit ecological damage> Maury Markowitz wrote: > > In article <5b39sm$2u9@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > > stuff which is used by the OS itself... > > My mom's HD is 80Meg. So now we get to buy a new HD to store files > she'll never use. Hmmmm. Something tells me your Mom won't be running out to buy the new OS. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 01:01:03 GMT Organization: University of Sheffield, UK Message-ID: <5b44cf$s7g@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> In-Reply-To: <maury-0901971623200001@199.166.204.230> On 01/09/97, Maury Markowitz wrote: > Oh, true enough, but there's a quality and quantity thing. I mean, do I > need all the .conf files? How about the shells and all the support stuff > for them? man pages? > Shells you certainly want, as the OS (as it is at the moment) depends on them. Man pages are not installed as standard (you have to explicitly install the Documentation package). .conf files... hmm, can't say I've ever touched them myself, and I can't see more than half a dozen of them. Again, looks like the system depends on them though. I certainly agree it would be good if AppLE could tidy come of this up... in the fullness of time :-) (Back to this "get something out of the door ASAP theme) > Yeah, but all that stuff adds up a lot in size. I'd personally rather > not have it installed unless I want it. > I'm not sure how much superfluous stuff there really is... much of the space is taken up with things like libraries (20+MB in /usr/lib), the kernel etc. The Bourne shell, for example, is only 120K. The whole of NEXTSTEP, absolute minimum installation, takes up less than 100MB I believe. I don't know just how much MacOS uses, but if you added enough extras to give you the same functionality (i.e. you'd have to add internet connectivity, a number of applications for system administration etc), I wonder if you'd be in the same ballpark? Say 50MB? Or am I being wildly "pessimistic" (I may be, I have no idea... I have a copy of an upgrade for 7.5.5 here, but can't work out the sizes of the relevant files). > Absolutely, and they should get to install it off the same CD. > As others have pointed out, I suspect that so many things would depend on whatever you would like to be made optional that the majority of users would end up having to install this stuff later anyway, after the inconvenience of finding out the hard way that they did need it. At a time when, as I said before, it seems to be difficult to find a hard drive smaller than 1GB, for the sake of a few tens of MB at the most, it doesn't seem worth worrying about "wasted space". (Your concerns about hiding things from the user are fair enough, and I hope others have shown that NeXT had already taken effective steps to address that -- hopefully AppLE can now take a few steps further). Best wishes, mmalc. --
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 02:58:40 GMT Organization: Netcom Distribution: world Message-ID: <5b4b90$9u8@dfw-ixnews12.ix.netcom.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5b39sm$2u9@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > > stuff which is used by the OS itself... > > My mom's HD is 80Meg. So now we get to buy a new HD to store files > she'll never use. Hmmmm. Hopefully, all readers of this group understand that a system with an 80 MB system disk isn't going to have the other resources necessary to run Rhapsody (how much RAM does her system have?). This system will continue to work fine with the various System 7 upgrades and isn't a system that Apple has targeted for Rhapsody. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: mckinnon@tezcat.com (Chuck McKinnon) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 00:53:44 -0600 Organization: Satan's Servers of Process Message-ID: <mckinnon-1001970053450001@mckinnon.tezcat.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> In article <32D5DFF0.2FB4@surf.net.au>, Ferret <ferret@surf.net.au> wrote: >Here are the files that make my Mac go in the system folder: >Finder - the basis of the OS >System - what makes the finder go >Control Panels - filled with all sorts a crap that I throw in there >Extentions - same as control panels >Fonts - pretty obvious >Preferences - ditto > >No /usr or /etc or any of that crut, Well if .apps all have to go into a certian location for the OS to work, why not make the "Applications" folder act like the System folder. Currently, the Applications folder is a normal folder with a special icon, and the system will recognize it as such; also the Finder allows for protection of this folder. Just go the next step (pun intended) and make the Applications folder the required place for .apps and make the system treat it as such. This would make even more sense for new/consumer user: it makes sense. All apps go in the Applications folder, [duh!] and the new system will get what it need. Or is this too simple? -- Chuck McKinnon + mckinnon@tezcat.com --------------------------------------------------- Chicago Municipal Code Section 4-24-140: "No domestic animals, except _cats_, shall be permitted in a bakery or place where flour or meal is stored in connection therewith, and suitable provisions shall be made to prevent nuisances from the presence of cats."
From: Koplien@vnet.IBM.com Newsgroups: comp.sys.next.programmer Subject: Re: Speculation about OS/NT's future, anyone? Date: Fri, 10 Jan 97 07:53:08 Organization: Lockheed Martin Federal Systems in Manassas, VA, USA Message-ID: <5b4p0r$uv6@news.manassas.ibm.com> References: <5ams2t$7gl@mercury.IntNet.net> <AEF6C440-1174D9@206.129.238.36> <5av8el$mo4@news.digifix.com> I think it makes no sense to do anything now. My opinion about the migration of Steve is: NeXTStep is dead. Apple have had very hard times and Steve isn't the phoenix. The PowerPC was a great mess and chips like the 620 will never come. Apple have to build a new machine with a xxx (?) processor nobody knows, to compete with. The well designed OS don't succeed on the most common platform, so why should things go better on a dead processor? Tell me! And keep in mind, the hardware problems of the black ones are not unknown to Steve... (BTW, AMD quits the remake of the Intel chips, so there is nobody left to strike against the valance of Intel) The opinions are mine. Henry
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 09 Jan 1997 21:50:42 -0800 Organization: Bridge Family Message-ID: <abridge-0901972150420001@dcn134.dcn.davis.ca.us> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> In article <5b3scd$8et@argo.patnet.caltech.edu>, shimpei@argo.patnet.caltech.edu (Shimpei Yamashita) wrote: etely disagree about the laziness issue. Maybe it's true for > commercial-grade programs, because using external routines often > introduces big speed penalties. On the other hand, people who often > write short programs or scripts (the same folks who have embraced > AppleScript) will benefit a lot from having a complete set of > file-manipulation utilities lying around. For those types of > applications, development time is much more important than the speed > of the final solution. > > -- > Shimpei Yamashita <http://www.cco.caltech.edu/%7Eshimpei/> > Graduate Student, Caltech Dept. of Physics shimpei@socrates.caltech.edu Unfortunately you're looking at your machine like a mechanic -- not like a user who has not interest or desire to open the hood. The Mac world, in its philosophy, is nothing like the UNIX world. They are polar opposites. What for you makes a wonderful set of tools would scare the bejesus out of my wife if something she saw even HINTED they were there - she's been a Mac user for 9 years, through 3 different hardware systems, and does highly productive design work. It's a tool -- and one that is completely command-line free. In my opinion, if Apple is to succeed, they MUST maintain that distance between the OS and the user interface. I don't care if it's UNIX under the hood or OpenVMS or BeOS, I want the machine to work, not crash, and present a consistant and relatively familier user-interface. If there's more there, it's okay, as long as I'm NEVER required to make use of it. Which means I can install applications ANYWHERE I want on my system, including dumb places. Having the OS system in a more rigorously defined location is okay -- but I shouldn't have to manipulate what's there directly through some arcane set of UNIX commands designed back in the days when ASR33 teletypes were the state of the art. I recognize the power of complex command-line driven tools. They're wonderful for mega-power-users. But hold little meaning for virtually ALL current Macintosh USERS. Regards, Adam Bridge
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 00:33:42 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5b4kbm$642@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> In article <maury-0901971045180001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > Standard applications can current assume that Unix is not installed. I > run about 100 applications on my Macs, and not a single one of them calls > anything remotely like Unix. Sure having the utilities allows a lazy > programmer to do less work, but I don't see this as a goal. You apparently aren't a programmer. There are gobs of well-written utilities around, and it's utterly senseless to rewrite them from scratch, especially considering that they have already gone through extensive testing/debugging cycles. Why should an application have code to send mail when it can call an existing mail transport agent? Why should it have code to search files for text when there are already grep programs which are optimized to within an inch of their lives to do this? Etc. Sure, you could make the utilities optional, but if app developers can't assume that they're there, they're not likely to opt to use them, and will end up rewriting lots of things. And when it comes down to it, all the Unix utilities comprise a relatively small portion of the total disk usage. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Ferret <ferret@surf.net.au> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 16:21:36 +1000 Organization: n/a Message-ID: <32D5DFF0.2FB4@surf.net.au> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mmalcolm crawford wrote: > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > stuff which is used by the OS itself... > > I am having difficulty understanding your prejudice here -- what all this > stuff represents is effectively what I (assume) MacOS has in its /System > folder, it's just spread around a bit more (perhaps something for AppLE to > address, though doing so might break a lot of stuff), and with a more obscure > nomenclature. Here are the files that make my Mac go in the system folder: Finder - the basis of the OS System - what makes the finder go Control Panels - filled with all sorts a crap that I throw in there Extentions - same as control panels Fonts - pretty obvious Preferences - ditto No /usr or /etc or any of that crut, Ferret -- +-------------------------------------------------------------------+ |Sverre 'Ferret' Gunnersen | |e-mail: mailto:ferret@surf.net.au | |Melbourne, Australia | | "I like reality, It tastes of bread." -J. Aliyoueh | +-------------------------------------------------------------------+
From: jbf@frazer.com (James B. Frazer) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 01:20:37 -0500 Organization: The Internet Access Company, Inc. Message-ID: <jbf-ya023580001001970120370001@news.tiac.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b44cf$s7g@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b44cf$s7g@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > The whole of NEXTSTEP, absolute minimum installation, takes up less than > 100MB I believe. I don't know just how much MacOS uses, but if you added > enough extras to give you the same functionality (i.e. you'd have to add > internet connectivity, a number of applications for system administration > etc), I wonder if you'd be in the same ballpark? My system partition, with the 7.5.5 OS and a minimal set of Unixy utilities, runs to 90MB. Now that's somewhat inflated by my PowerPC architecture; perhaps the equivalent would be 60-70 MB on a 680x0. That's close enough so that Mac fans shouldn't fret. And, believe me, those Unix utilities replace a great many small Mac applications. Barney
From: kcd@babylon5.jumpgate.com (Kenneth C. Dyke) Newsgroups: comp.sys.next.programmer,comp.sys.be Subject: Interpreted Drawing (Was Re: GX versus DPS (a Trivial example)) Date: 10 Jan 1997 06:57:22 GMT Message-ID: <5b4p8i$m0l@nntp1.best.com> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> In-Reply-To: <mmunz-0801972323330001@slc-dial-65.inconnect.com> On 01/08/97, Mark Munz wrote: > >I don't want yet another programming language .. I just want to be >able to image. The fact that PS is intrepeted is also bothersome.. ^^^^^^^^^^ >Never has interpreted been equated with high speed. The whole purpose >of pre-emptive MT and other such goodies is give performance to the >user. This is an area that I think BeOS seems to win in (their imaging >is extremely fast). I would have actually liked to see something >closer to how Be did it (taking advantage of the FPU in PPC chips -- >and Pentinum also has FPU built-in).. it seems disappointing. I don't think that DPS is THAT much different than what Be is doing as for as interpreting drawing commands goes. (Someone from Be correct me if I'm wrong on this...) Under NeXTSTEP/OpenStep, an application will either use the DPS client library functions or pswraps to send encoded postscript rendering commands to the DPS Window server. On BeOS, a similar mechanism is used by the BView class to send drawing commands to the app_server process. So in a sense, theyare BOTH using interpreters. The difference is that the DPS window server's byte code just happens to be encoded PostScript, while on BeOS it's proprietary. Both systems are able to take advantage of multitasking and multiprocessing (at least on NT, and presumably on the new Apple OS) to offload the drawing operations to another task and/or CPU. -Ken
From: jesjones@halcyon.com (Jesse Jones) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Bad mouthing templates Date: Thu, 09 Jan 1997 22:06:15 -0800 Organization: Jet City Studios, Inc Distribution: world Message-ID: <jesjones-ya023580000901972206150001@news.halcyon.com> References: <5b1omq$adg@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b1omq$adg@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Templates are a hack to deal with C++'s strict typing that aren't needed > >in Objective-C (hope my lack of full understanding of templates isn't showing > >too much :-) An Objective-C collection can contain objects of any type and > >can even include objects of different types without the need to resort to > >some sort of template mechanism. > > > > I believe that perhaps the better way to phrase this might be: Templates > are a hack to provide type safety in C++'s that isn't needed in > Objective-C... Like Eiffel C++ was designed to make writing production quality code easier. A large part of this is static type checking which at compile time checks *all* your code for type mismatches. In a language with less static type checking you need to execute each code path in your application to get the same result. For a large application this is very difficult. Like Eiffel C++ provides compile time polymorphism to achieve additional flexibility without sacrificing type safety. In C++ this is done with templates which are useful for much more than just container classes. For example, in C++ it's as easy to write a templatized FFT as one hardcoded for a specific type. Yet the template version allows you to use floats, doubles, long doubles, or even a big float class. I can only remember seeing three half-way valid criticisms of templates: 1) Templates cause massive code. This can happen very easily with naive implementations, but it can be largely alleviated by using non-template base classes and partial specialization. 2) It's difficult to write exception safe template code since any method of the parameterized class can throw an exception. This is also overblown: with care and experience with exception handling safe code can be written. 3) Templates force the compiler to slog thru much more code thereby reducing compile speeds. This can be dealt with by not using MSVC, by using non-template base classes, and by forward referencing template classes in headers. It's my understanding that the ANSI committe has blessed seperate compilation for templates so this will hopefully become moot. I keep seeing Objective-C advocates claiming that it makes writing programs much easier. That may well be true, but the hard part of programming is not coding it's making the program do what it's supposed to do, perform well, and gracefully handle errors. C++ makes this easier because the language and the philosophy emphasize catching problems at compile time. Maintaining backward compatibility with C does make C++ less safe than it would otherwise have been, but in the hands of a skilled engineer it's a powerful and effective tool. --Jesse
From: jesjones@halcyon.com (Jesse Jones) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Bad mouthing templates Date: Thu, 09 Jan 1997 22:03:30 -0800 Organization: Jet City Studios, Inc Distribution: world Message-ID: <jesjones-ya023580000901972203300001@news.halcyon.com> References: <5b1omq$adg@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b1omq$adg@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Templates are a hack to deal with C++'s strict typing that aren't needed > >in Objective-C (hope my lack of full understanding of templates isn't showing > >too much :-) An Objective-C collection can contain objects of any type and > >can even include objects of different types without the need to resort to > >some sort of template mechanism. > > > > I believe that perhaps the better way to phrase this might be: Templates > are a hack to provide type safety in C++'s that isn't needed in > Objective-C... Like Eiffel C++ was designed to make writing production quality code easier. A large part of this is static type checking which at compile time checks *all* your code for type mismatches. In a language with less static type checking you need to execute each code path in your application to get the same result. For a large application this is very difficult. Like Eiffel C++ provides compile time polymorphism to achieve additional flexibility without sacrificing type safety. In C++ this is done with templates which are useful for much more than just container classes. For example, in C++ it's as easy to write a templatized FFT as one hardcoded for a specific type. Yet the template version allows you to use floats, doubles, long doubles, or even a big float class. I can only remember seeing three half-way valid criticisms of templates: 1) Templates cause massive code. This can happen very easily with naive implementations, but it can be largely alleviated by using non-template base classes and partial specialization. 2) It's difficult to write exception safe template code since any method of the parameterized class can throw an exception. This is also overblown: with care and experience with exception handling safe code can be written. 3) Templates force the compiler to slog thru much more code thereby reducing compile speeds. This can be dealt with by not using MSVC, by using non-template base classes, and by forward referencing template classes in headers. It's my understanding that the ANSI committe has blessed seperate compilation for templates so this will hopefully become moot. I keep seeing Objective-C advocates claiming that it makes writing programs much easier. That may well be true, but the hard part of programming is not coding it's making the program do what it's supposed to do, perform well, and gracefully handle errors. C++ makes this easier because the language and the philosophy emphasize catching problems at compile time. Maintaining backward compatibility with C does make C++ less safe than it would otherwise have been, but in the hands of a skilled engineer it's a powerful and effective tool. --Jesse
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 02:28:59 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D5EFBB.2562@steeldriving.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b44cf$s7g@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mmalcolm crawford wrote: > At a time when, as I said before, it seems to be difficult to find a hard > drive smaller than 1GB, for the sake of a few tens of MB at the most, it > doesn't seem worth worrying about "wasted space". (Your concerns about > hiding things from the user are fair enough, and I hope others have shown > that NeXT had already taken effective steps to address that -- hopefully > AppLE can now take a few steps further). The fact that NeXT's filesystem doesn't suffer from the same file bloat the MacOS does should help a bit. A little 100-byte config file on the new OS won't take up 16k or 32k, like it would on HFS. It's not inconceivable that hard disks under the new OS, might actually end up with *more* free space, despite the apparent increase in system files. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 09:06:15 GMT Organization: Global Objects Inc. Message-ID: <5b50q7$39e@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> Ferret <ferret@surf.net.au> wrote: > mmalcolm crawford wrote: > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > > stuff which is used by the OS itself... > > > > I am having difficulty understanding your prejudice here -- what all this > > stuff represents is effectively what I (assume) MacOS has in its /System > > folder, it's just spread around a bit more (perhaps something for AppLE to > > address, though doing so might break a lot of stuff), and with a more obscure > > nomenclature. > > Here are the files that make my Mac go in the system folder: > Finder - the basis of the OS > System - what makes the finder go > Control Panels - filled with all sorts a crap that I throw in there > Extentions - same as control panels > Fonts - pretty obvious > Preferences - ditto > > No /usr or /etc or any of that crut, The point is that the "crud" in /usr and /etc is a combination of Extensions and System--NEXTSTEP needs that stuff to run. You never have to look at it yourself if you don't want to. (I like the mechanic and hood comparison. Yes, the ugly user-unfriend- liness of UNIX is there. NEXTSTEP hides it with a more than adequate hood and _you_ have to lift that hood to see it. Most users never will. End of story. You can't just throw out the engine and expect the car to run, you know. You can't delete your System folder and expect your Mac to work very well. And Blow away /etc or /usr and your NeXT won't boot. Most users won't mess with the engine, System, or /usr and /etc and will never need to--and the "hood" hides the complexity. The mechanics of the world know it is there, though, and just love to play in the dirt and grime... :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 02:50:30 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5b4apm$al2@usenet.rpi.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > My mom's HD is 80Meg. So now we get to buy a new HD to store > files she'll never use. Hmmmm. Your mother has a PowerMac with an 80-meg disk? Really? And if she has a 68K-based, then she wasn't going to be running *any* of the new operating system choices that Apple was considering. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 10 Jan 1997 09:39:11 GMT Organization: Global Objects Inc. Message-ID: <5b52nv$39e@news.xmission.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> jesjones@halcyon.com (Jesse Jones) wrote: > I keep seeing Objective-C advocates claiming that it makes writing programs > much easier. That may well be true, but the hard part of programming is not > coding it's making the program do what it's supposed to do, perform well, > and gracefully handle errors. C++ makes this easier because the language > and the philosophy emphasize catching problems at compile time. Maintaining > backward compatibility with C does make C++ less safe than it would > otherwise have been, but in the hands of a skilled engineer it's a powerful > and effective tool. Wow. This is amazing. And he really believes what he's saying! <RANT> With C++ my productivity hits rock bottom, at least when compared to what I can crank out in Objective C. And even with all the type checking the compiler is doing for me, I find my code quality is in the dumps with C++, as compared to Objective-C. Yeah, that picky compiler keeps me busy all right. Bow down to the needs of the compiler and satisfy its every whim. I like Objective C becase it reduces clutter in the system's design and is simply a better OO implementation (for reasons that have been hashed out zillions of times before). Let's face it: a large C++ project versus a large Objective-C project, what are the differences? * That picky C++ compiler means I can hire twice as many programmers and take twice as long to get it written. And even then it probably won't work right anyway. So much for stamping the bugs early on. The simplicity of Objective-C keeps most of those bugs from happening in the first place, because it is easier to write! Besides, a good design will, by nature, help reduce the bugs in the product. You should never trust a compiler to make up for flaws in a bad design, which is what I see far too many C++ programmers doing. (Not all are that way, thank heavens, but in practice the "compiler will spot the bugs" attitude often leads to this outcome.) * My resulting app will be much larger because of unnecessary code bloat caused by lack of dynamism. The design will bloat as well, as I work around language deficiencies. [To do effective GUI work you need to have a certain amount of dynamism. In C++, this means you re-invent your own mini runtime each time. In Objective-C, where you start with a runtime, you save yourself that much effort. Less code usually means fewer bugs, as far as I've seen.] * The C++ _may_ run a little faster, since I don't have the overhead of the runtime--but not as much as you'd think because of that code bloat and the less-than-optimal design the compiler's pickiness forces me to use. * C++ has all these nifty features (syntactic sugar) that I can use to increase my productivity. Too bad that the next guy that comes along--to maintain my code--can't figure out what the hell I did. Most Objective-C code is very nearly self documenting. The simpler designs mean the maintenance guys can come in and quickly find and fix problems. If there are any. You could argue that good and bad programming styles affect this comparison--and yes they sure do--but C++ promotes arcane usage and bad style because of its haphazard design whereas Objective-C does a lot to help promote good design. Plus, how many syntax elements does C++ add to C? Has anyone ever sat down and counted? Compare Objective-C's number--I think it is in the _teens_. So which is going to be easier to debug? And I could keep going...but I think my bias is obvious. Why? I've used both and I _know_ which one works better. As a final point, which OO environment has faster execution speed on like hardware and is more time tested and proven: NEXTSTEP or Taligent? Does anything more have to be said? That's two large systems of similar complexity, and one seems to be doing just a little bit better than the other, now, wouldn't you think? And while languge isn't the only reason for that particular situation, you can't blame management on that one. NeXT is notorious for being one of the most poorly managed companies ever, at least according to its many "enemies" and even a large portion of its advocates. Yes, with all that mismanagement, their product has _still_ survived, in spite of all they have done to apparently try and kill it off! That really says something to me about the product's quality! Of course, after using the product and those of competitors, I know firsthand why it is so great. You really have to give it a chance to "get it", and once you do, you'll never want to go back... </RANT> As I sign off, I will say that a good design is paramount, no matter which language you choose. A lot of Objective C projects have failed, too, because of that. I _strongly_ suggest Bruce Webster's book, "Pitfalls of Object Oriented Programming." That's the wise voice of sad experience speaking there. May we all read and learn from it and avoid those traps! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: dozer@netwizards.net Newsgroups: comp.sys.next.programmer Subject: would you be my friend? Date: Fri, 10 Jan 1997 01:03:31 Message-ID: <5b50kh$kmr@news1-alterdial.uu.net> Hello, I'm 14 years old and I think I may be a gay. I'm looking for some support and friendship with a older male age 18-40. Please email if you can help.
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 03:07:09 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.852894286@idiom.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> maury@softarc.com (Maury Markowitz) writes: [munch] > My mom's HD is 80Meg. So now we get to buy a new HD to store files >she'll never use. Hmmmm. Yeah, and isn't it a disgrace that the new mac OS isn' going to run on my Mac Plus, with one meg of RAM? Sheesh! Seriously, maury. Disks are cheap. Buy your mom a new 1Gbyte drive. -jcr
Newsgroups: comp.sys.next.programmer From: dozer@netwizards.net Subject: cmsg cancel <5b50kh$kmr@news1-alterdial.uu.net> Control: cancel <5b50kh$kmr@news1-alterdial.uu.net> Message-ID: <cancel.5b50kh$kmr@news1-alterdial.uu.net> Followup-to: junk References: <5b50kh$kmr@news1-alterdial.uu.net> Date: Fri, 10 Jan 1997 01:03:31 Spam-cancel: "would you be my friend?"
From: shihong@mbox.kyoto-inet.or.jp (LAO Shihong) Newsgroups: comp.sys.next.programmer,comp.sys.mc.prorammer.misc Subject: Re: DPS *and* GX (was : Welcome to the New World Order) Date: 10 Jan 1997 10:23:35 GMT Organization: OMRON Corporation, Kyoto, JAPAN Message-ID: <5b55b7$rml@omrongw2.wg.omron.co.jp> References: <AEF58CD0-8640A@198.68.42.176> In article <AEF58CD0-8640A@198.68.42.176> "Lawson English" <english@primenet.com> writes: > But PS wasn't designed with the Chinese/Japanese/Korean/Hindu-Urdi/etc > markets in mind. GX was. Maybe, but the best fonts for Chinese, Japanese are all PS fonts. Please stop saying such meaningless words. You just seems know nothing about DPS. GX might be good technology, but it's not enough to save Apple. ---- LAO Shihong (Firstname is surname) $(0@9'a$(1,c(B(use mule to show Chinese)
From: Ferret <ferret@surf.net.au> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 19:16:57 +1000 Organization: n/a Message-ID: <32D60909.42EC@surf.net.au> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chuck McKinnon <mckinnon@tezcat.com> Chuck McKinnon wrote: > Well if .apps all have to go into a certian location for the OS to work, > why not make the "Applications" folder act like the System folder. > Currently, the Applications folder is a normal folder with a special > icon, and the system will recognize it as such; also the Finder allows > for protection of this folder. > > Just go the next step (pun intended) and make the Applications folder > the required place for .apps and make the system treat it as such. This > would make even more sense for new/consumer user: it makes sense. > All apps go in the Applications folder, [duh!] and the new system will > get what it need. > > Or is this too simple? Well, um. The thing is, I dont want to be 'forced' into putting apps in the apps folder. All of my real apps are in the apps folder already. But temp apps, say resedit, I am only leaving there for an hour or so. I dont want to have to go thru the apps folder to get to it. I put in my disk, copy res edit to the desktop. Use it, throw it in the trash. As someone else said, i like to put things where I want. Even in dumb places. Yours, Ferret -- +-------------------------------------------------------------------+ |Sverre 'Ferret' Gunnersen | |e-mail: mailto:ferret@surf.net.au | |Melbourne, Australia | | "I like reality, It tastes of bread." -J. Aliyoueh | +-------------------------------------------------------------------+
From: Ferret <ferret@surf.net.au> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 23:52:29 +1000 Organization: n/a Message-ID: <32D6499E.1017@surf.net.au> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don Yacktman wrote: > The point is that the "crud" in /usr and /etc is a combination > of Extensions and System--NEXTSTEP needs that stuff to run. You > never have to look at it yourself if you don't want to. (I like > the mechanic and hood comparison. Yes, the ugly user-unfriend- > liness of UNIX is there. NEXTSTEP hides it with a more than > adequate hood and _you_ have to lift that hood to see it. Most > users never will. End of story. You can't just throw out the > engine and expect the car to run, you know. You can't delete > your System folder and expect your Mac to work very well. And > Blow away /etc or /usr and your NeXT won't boot. Most users > won't mess with the engine, System, or /usr and /etc and will > never need to--and the "hood" hides the complexity. The > mechanics of the world know it is there, though, and just love > to play in the dirt and grime... :-) How easy is it in NEXTSTEP to add functionality. This is not an attempt to get at NEXTSTEP, I do actually know. This is a real question. On the Mac I can get any extension or control panel, toss it in the system folder, i get the dialoge that it needs to go in the appropriate folder, and so i click yes, and it put's it there. If I want it out: if it was an extension, go to HD, go to system folder, go to Extensions, drag the file to trash. If it is a Control Panel, do the same but go to the Control Panels folder rather than the Extension folder. If I have a NEXTSTEP extention (do they have them?), or a NEXTSTEP equivilant, what directory do i put it in? /usr? /etc? or is there a /extensions? Well? Ferret -- +-------------------------------------------------------------------+ |Sverre 'Ferret' Gunnersen | |e-mail: mailto:ferret@surf.net.au | |Melbourne, Australia | | "I like reality, It tastes of bread." -J. Aliyoueh | +-------------------------------------------------------------------+
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 10 Jan 1997 13:32:12 GMT Organization: University of Sheffield, UK Message-ID: <5b5gcs$92n@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> In-Reply-To: <32D60909.42EC@surf.net.au> comp.sys.next.programmer removed from followups. On 01/10/97, Ferret wrote: > As someone else said, i like to put things where I want. Even in dumb > places. > Please point out where anyone said you could not do this in NEXTSTEP. If you can't, please can we move on from here, and would you please stop spreading disinformation. (Inference: you can put apps wherever you like. Even in dumb places.) Best wishes, mmalc. --
From: logi27@imaginet.fr (Logi27 Development Team) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Fri, 10 Jan 1997 15:17:22 +0100 Organization: LOGI 27 Distribution: world Message-ID: <logi27-1001971517220001@cyber59.montpellier.imaginet.fr> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> In article <5b1ovj$tm6@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Multiple inheritance is not directly supported in Objective-C, a > >situation that many feel is an advantage, but some may miss. Multiple > >inheritance can be simulated using Objective-C's ability to forward > >unimplemented messages to another object which can provide the functionality > >that multiple inheritance might provide. I don't think most programmers feel > >that the lack of true multiple inheritance is a problem. > > [Lots of great information in this thread! Lovin' it!] > > This is an interesting way to implement multiple inheritance. I guess > this approach must mean that 'multiple inheritance' in Objective C is > limited to only one base class and one 'proxy' class - is that correct? > > Can this occur multiple times in the hierarchy? That is, if class A2 > derives from class A1 can A2 forward to B2 and A1 forward to B1? > > What is the overhead runtime cost of this approach? > > Curious minds want to know, > Mike R. > MacApp Engineering What's the future of MacApp at Apple ? at the last European Developper Forum at London in November 1996 it was said that one issue for MacApp was to become CrossPlatform. But the last Announce from Apple concerning the OS is new shock for MacApp isn't it ? a+ Paul Plaquette
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Librarian replacement Date: 10 Jan 1997 14:18:42 GMT Organization: University of Sheffield, UK Message-ID: <5b5j42$bh7@bignews.shef.ac.uk> One of the really useful apps that's always shipped with NS is Librarian. Now, as I understand it, it'll be difficult to port to the new OS since it's dependent on the defunct IndexingKit? So, we may need a replacement? Fortunately the IR world has advanced substantially since Librarian was developed, so I wondered, would it be possible to wrap a GUI around Glimpse or somesuch? Best wishes, mmalc. --
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 15:26:11 GMT Organization: Rockwell Avionics - Collins Message-ID: <5b5n2j$9e8@castor.cca.rockwell.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> <32D6499E.1017@surf.net.au> Cc: ferret@surf.net.au In <32D6499E.1017@surf.net.au> Ferret wrote: > If I have a NEXTSTEP extention (do they have them?), or a NEXTSTEP > equivilant, what directory do i put it in? /usr? /etc? or is there a > /extensions? > > Well? > Ferret > First, by default, UNIX directories are hidden in the file viewer. Second, in a networked environment, security is essential. Third, in order to preserve security, users should not log in with root privileges. Fourth, without root privileges, you can not mess with stuff in UNIX directories even if you want to. Specifically regarding extensions: There are two types of extensions. Some add "system" services such as device drivers or additional networking and file system protocols. Others are just "utility" services such as automatic conversion of file types, adding a banner to print requests, workspace extender's, dock replacements, screen savers, etc. "system" extensions can be installed by a novice only if the installing program is VERY clever because a botched "system" extension can/will crash the system. Generally, only competent individuals should even attempt to install "system" services. (most users should wait for the next system release) "system" extensions will generally go in /usr or /etc or /lib directories. "utility" services are owned by individual users and can be installed by individual users. The worst thing a buggy "utility" service can do is mess up an individual's environment. Perhaps there is a central problem - that MAC users asking questions do not understand the issues surrounding multi-user network operating systems. I am not criticizing Ferret, I am just wondering if using NeXtstep for a little while would clear up all of these questions and stop the worrying. In my extensive experience, extremely novice MAC users have felt comfortable in NeXTstep. I have routinely failed to tell them that they are using UNIX and I am sure most never suspect.
Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system From: Fabien_Roy@free.fdn.org Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Message-ID: <E3spt1.B9u@free.fdn.fr> Sender: news@free.fdn.fr Organization: Fabien Roy Consultant. References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> Date: Fri, 10 Jan 1997 14:05:25 GMT As a programmer, I rely on the presence of /bin /usr/bin etc... stuff. I prefer to do this: system("df -i /Disk|grep dev > /tmp/df.result"); than to rewrite the df code. Then I can proceed the /tmp/df.result file to see how many inodes used/free on the local disk thus avoiding the "out of inodes" message. Stripping those UNIX tools would make developing software much more difficult. Excerpt from the man df: DF(1) UNIX Programmer's Manual DF(1) NAME df - report free disk space on file systems SYNOPSIS df [ -i ] [ filesystem ... ] [ file ... ] [ -t type ] [ filesystem ... ] [ filename ... ] CIAO. -- Fabien Roy --------------------------------------------------------------------- Fabien_Roy@free.fdn.org (NextMail/MIME accepted) Fabien Roy Consultant NEXTSTEP/OPENSTEP/EOF Consultant, SYBASE DBA 10 rue de la DEFENSE 93100 MONTREUIL, France Tel: 33 (0)1 45 28 32 23 Fax: 33 (0)1 48 55 09 90 GSM: 33 (0)6 60 46 36 83
From: thomas@catlan.met.FU-Berlin.DE (Thomas Hensel) Newsgroups: comp.sys.next.programmer Subject: HELP: Maximum Memory for NS3.3 Intel Date: 10 Jan 1997 16:12:39 GMT Organization: Freie Universitaet Berlin Message-ID: <5b5ppn$jpn@fu-berlin.de> What is the maximum memory size for Intel based NextStep-Systems ??? NextAnswers 1002: (Intel) RAM requirements vary depending upon your selection of graphics adapter and imaging model. NextAnswers 1843, 1844 (HP, Sparc) RAM requirements vary depending upon the user's selection of graphics adapter. NEXTSTEP Release 3.3 supports a maximum of 256MB of memory. If it is true, that for Intel systems only 256 MB are supported, how can I change this ? Are there Kernel-Patches ? Thanks in advance, Thomas -- || Who: Dipl. Phys. Thomas Hensel MIKS - Meteorologische Informations- || EMail: thomas@bibo.met.FU-Berlin.DE und Kommunikations-Systeme || Voice: (+49 30) 838 71 225 an der Freien Universitaet Berlin || FAX: (+49 30) 791 90 02 Schmidt-Ott-Str. 13 - 12165 Berlin
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 08:11:54 -0800 Organization: Bridge Family Message-ID: <abridge-1001970811540001@dcn131.dcn.davis.ca.us> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> <32D6499E.1017@surf.net.au> <5b5n2j$9e8@castor.cca.rockwell.com> In article <5b5n2j$9e8@castor.cca.rockwell.com>, embuck@palmer.cca.rockwell.com (Erik M. Buck) wrote: > Specifically regarding extensions: > > There are two types of extensions. Some add "system" services such as device > drivers or additional networking and file system protocols. Others are just > "utility" services such as automatic conversion of file types, adding a > banner to print requests, workspace extender's, dock replacements, screen > savers, etc. > > "system" extensions can be installed by a novice only if the installing > program is VERY clever because a botched "system" extension can/will crash > the system. Generally, only competent individuals should even attempt to > install "system" services. (most users should wait for the next system > release) "system" extensions will generally go in /usr or /etc or /lib > directories. > Having NO experience with NeXT at all I'm wondering about the nature of extensions that fall in this catagory. For a Mac user you drag something to System Folder, drop it, and it gets put where it belongs. End of installation for Extensions. The idea there's something that requires heroic knowledge for installation isn't comforting. But, I suppose, a good installer would take care of this. > "utility" services are owned by individual users and can be installed by > individual users. The worst thing a buggy "utility" service can do is mess > up an individual's environment. > Another place where I'd like an example of what sort of things are being added by these extensions. > Perhaps there is a central problem - that MAC users asking questions do not > understand the issues surrounding multi-user network operating systems. I > am not criticizing Ferret, I am just wondering if using NeXtstep for a little > while would clear up all of these questions and stop the worrying. > > In my extensive experience, extremely novice MAC users have felt comfortable > in NeXTstep. I have routinely failed to tell them that they are using UNIX > and I am sure most never suspect. > Many Mac users use a very simple peer-to-peer file sharing built into their machines which does allow/deny access to volumes, folders, or files. It's easy and it works. It doesn't have access control lists, etc. which I recognize in an enterprise enviornment are essential. It's an issue of ease-of-use -- these machines are used by everyone, from home users to college wizards, and the user interface has to bow to the lowest common denominator in terms of ease of us. Adam
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: 10 Jan 97 10:24:27 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan10102427@slave.one.net> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> <jcr.852844537@idiom.com> <5b42oo$ebp@news.xmission.com> In-reply-to: don@globalobjects.com's message of 10 Jan 1997 00:33:28 GMT In article <5b42oo$ebp@news.xmission.com>, don@globalobjects.com (Don Yacktman) writes: jcr@idiom.com (John C. Randolph) wrote: > AFAIK, DPS does use the floating-point hardware in whatever CPU > it's running on. That is correct. In fact, when NEXTSTEP was ported from m68k to x86 architectures, one of the disappointments was the the graphics speeds weren't much better. When you sit down to analyze why this is, there are two reasons: (1) Bus architectures. NeXT had local bus video <...> (2) When you compare x86 and m68k series, you find that Motorola's FP performance is better than that of an equivalent Intel CPU. <...> So you can count on DPS to take full advantage of the FPU! In fact, the FPU and the graphics bus speeds are far more important to DPS than the integer math speed of the CPU. And don't forget memory! DPS vs older windowing systems is somewhat like Unix versus "PC operating systems" in that it's _not_ heavily optimized to be a memory miser. Just like with older printers, this was somewhat of a problem - not so long ago, a 4M printer was considered somewhat insane, nowadays there's really no point to putting less than 4M in a printer. Today, we're getting to the point that it's silly to even think of buying a new machine with 16M of ram versus 32M. The $70 you saved would end up being _very_ expensive in the long run. One very visible area where this shows up is in backing store. DPS spends memory to keep backing stores for each window, which really _is_ silly if your machine isn't powerful enough to keep more than one or two apps in the air at a time. But when you're running five or six apps at once, it's utility becomes apparent. When you move a window, instead of five or six apps competing for the CPU to redraw tiny portions of their windows, you have _one_ app, the DPS windowserver, which handles it all. These days implementation decisions like that are starting to look almost prophetic. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: sanguish@digifix.com Newsgroups: comp.sys.next.advocacy,comp.sys.next.announce,comp.sys.next.hardware,comp.sys.next.software,comp.sys.next.misc,comp.sys.next.sysadmin,comp.sys.next.bugs,comp.sys.next.programmer Subject: NEXTSTEP/OpenStep Resources on the Net Supersedes: <587851299369@digifix.com> Date: 10 Jan 1997 16:42:13 GMT Organization: Digital Fix Development Message-ID: <475852914532@digifix.com> Topics include: Stepwise NEXTSTEP/OpenStep Information WWW site eduSTEP WWW site NeXT Computer, Inc. WWW site comp.sys.next newsgroups related newsgroups comp.sys.next newsgroups mailing list ftp sites NeXTanswers Stepwise NEXTSTEP/OpenStep Information WWW site =============================================== This online community resource includes - ISV company pages - ISV product descriptions - NEXTSTEP Developer Directory - NEXTSTEP Community WhitePages - Mailing List archives and information You can connect via the world wide web at: http://www.stepwise.com/ Suggestions or comments can be directed to me at sanguish@digifix.com If you would like to get your company and product information on Stepwise, please contact me at sanguish@digifix.com. eduSTEP WWW site ================ http://www.nmr.embl-heidelberg.de/eduStep/ eduStep aims to provide up-to-date information on: - NextStep tools and projects for scientists. - Third-party products interesting for the educational and scientific community (with educational discounts noted, where they exist). - A listing of resellers and shops interested in working with customers in the educational community. - Conferences, meetings, workshops - Major projects, such as SciTools, EMBL's project to develop a NextStep scientific work environment - Status reports on GNUStep, a freely-available implementation of OpenStep now being developed NeXT Computer, Inc. WWW site ============================ http://www.next.com comp.sys.next.* newsgroups ========================== news:comp.sys.next.advocacy This is the "why NEXTSTEP is better (or worse) than anything else in the known universe" forum. It was created specifically to divert lengthy flame wars from .misc. news:comp.sys.next.announce Announcements of general interest to the NeXT community (new products, FTP submissions, user group meetings, commercial announcements etc.) This is a moderated newsgroup, meaning that you can't post to it directly. Submissions should be e-mailed to next-announce@digifix.com where the moderator (Scott Anguish) will screen them for suitability. Archives are available by ftp at ftp://ftp.stepwise.com/pub/Next_Announce_Archives Messages posted to announce should NOT be posted or crossposted to any other comp.sys.next groups. news:comp.sys.next.bugs A place to report verifiable bugs in NeXT-supplied software. Material e-mailed to Bug_NeXT@NeXT.COM is not published, so this is a place for the net community find out about problems when they're discovered. This newsgroup has a very poor signal/noise ratio--all too often bozos post stuff here that really belongs someplace else. It rarely makes sense to crosspost between this and other c.s.n.* newsgroups, but individual reports may be germane to certain non-NeXT- specific groups as well. news:comp.sys.next.hardware Discussions about NeXT-label hardware and compatible peripherals, and non-NeXT-produced hardware (e.g. Intel) that is compatible with NEXTSTEP. In most cases, questions about Intel hardware are better asked in comp.sys.ibm.pc.hardware. Questions about SCSI devices belong in comp.periphs.scsi. This isn't the place to buy or sell used NeXTs--that's what .marketplace is for. news:comp.sys.next.marketplace NeXT stuff for sale/wanted. Material posted here must not be crossposted to any other c.s.n.* newsgroup, but may be crossposted to misc.forsale.computers.workstation or appropriate regional newsgroups. news:comp.sys.next.misc For stuff that doesn't fit anywhere else. Anything you post here by definition doesn't belong anywhere else in c.s.n.*--i.e. no crossposting!!! news:comp.sys.next.programmer Questions and discussions of interest to NEXTSTEP programmers. This is primarily a forum for advanced technical material. Generic UNIX questions belong elsewhere (comp.unix.questions), although specific questions about NeXT's implementation or porting issues are appropriate here. Note that there are several other more "horizontal" newsgroups (comp.lang.objective-c, comp.lang.postscript, comp.os.mach, comp.protocols.tcp-ip, etc.) that may also be of interest. news:comp.sys.next.software This is a place to talk about [third party] software products that run on NEXTSTEP systems. news:comp.sys.next.sysadmin Stuff relating to NeXT system administration issues; in rare cases this will spill over into .programmer or .software. Related Newsgroups ================== news:comp.soft-sys.nextstep Like comp.sys.next.software and comp.sys.next.misc combined. Exists because NeXT is a software-only company now, and comp.soft-sys is for discussion of software systems with scope similar to NEXTSTEP. news:comp.lang.objective-c Technical talk about the Objective-C language. Implemetations discussed include NeXT, Gnu, Stepstone, etc. news:comp.object Technical talk about OOP in general. Lots of C++ discussion, but NeXT and Objective-C get quite a bit of attention. At times gets almost philosophical about objects, but then again OOP allows one to be a programmer/philosopher. (The original comp.sys.next no longer exists--do not attempt to post to it.) Exception to the crossposting restrictions: announcements of usenet RFDs or CFVs, when made by the news.announce.newgroups moderator, may be simultaneously crossposted to all c.s.n.* newsgroups. Getting the Newsgroups without getting News =========================================== Thanks to Michael Ross at antigone.com, the main NEXTSTEP groups are now available as a mailing list digest as well. next-nextstep next-advocacy next-announce next-bugs next-hardware next-marketplace next-misc next-programmer next-software next-sysadmin object lang-objective-c (For a full description, send mail to listserv@antigone.com). The subscription syntax is essentially the same as Majordomo's. To subscribe, send a message to *-request@lists.best.com saying: subscribe where * is the name of the list e.g. next-programmer-request@lists.best.com The ftp sites ============= ftp://ftp.next.peak.org - The main site for North American submissions formerly ftp.cs.orst.edu ftp://ftp.informatik.uni-muenchen.de: - (Peanuts) Located in Germany. ftp://ftp.dn.net/pub/next - Peanuts mirror in the US ftp://terra.stack.urc.tue.nl - (Dutch NEXTSTEP User Group) ftp://cube.sm.dsi.unimi.it - (Italian NEXTSTEP User Group) ftp://ftp.nmr.embl-heidelberg.de/pub/next - eduStep ftp://ftp.next.com: - See below ftp.next.com and NextAnswers@next.com ===================================== [from the document ftp://ftp.next.com/pub/NeXTanswers/1000_Help] Welcome to the NeXTanswers information retrieval system! This system allows you to request online technical documents, drivers, and other software, which are then sent to you automatically. You can request documents by fax or Internet electronic mail, read them on the world-wide web, transfer them by anonymous ftp, or download them from the BBS. NeXTanswers is an automated retrieval system. Requests sent to it are answered electronically, and are not read or handled by a human being. NeXTanswers does not answer your questions or forward your requests. USING NEXTANSWERS BY E-MAIL To use NeXTanswers by Internet e-mail, send requests to nextanswers@next.com. Files are sent as NeXTmail attachments by default; you can request they be sent as ASCII text files instead. To request a file, include that file's ID number in the Subject line or the body of the message. You can request several files in a single message. You can also include commands in the Subject line or the body of the message. These commands affect the way that files you request are sent: ASCII causes the requested files to be sent as ASCII text SPLIT splits large files into 95KB chunks, using the MIME Message/Partial specification REPLY-TO address sets the e-mail address NeXTanswers uses These commands return information about the NeXTanswers system: HELP returns this help file INDEX returns the list of all available files INDEX BY DATE returns the list of files, sorted newest to oldest SEARCH keywords lists all files that contain all the keywords you list (ignoring capitalization) For example, a message with the following Subject line requests three files: Subject: 2101 2234 1109 A message with this body requests the same three files be sent as ASCII text files: 2101 2234 1109 ascii This message requests two lists of files, one for each search: Subject: SEARCH Dell SCSI SEARCH NetInfo domain NeXTanswers will reply to the address in your From: line. To use a different address either set your Reply-To: line, or use the NeXTanswers command REPLY-TO If you have any problem with the system or suggestions for improvement, please send mail to nextanswers-request@next.com. USING NEXTANSWERS BY FAX To use NeXTanswers by fax, call (415) 780-3990 from a touch-tone phone and follow the instructions. You'll be asked for your fax number, a number to identify your fax (like your phone extension or office number), and the ID numbers of the files you want. You can also request a list of available files. When you finish entering the file numbers, end the call and the files will be faxed to you. If you have problems using this fax system, please call Technical Support at 1-800-848-6398. You cannot use the fax system outside the U.S & Canada. USING NEXTANSWERS VIA THE WORLD-WIDE WEB To use NeXTanswers via the Internet World-Wide Web connect to NeXT's web server at URL http://www.next.com. USING NEXTANSWERS BY ANONYMOUS FTP To use NeXTanswers by Internet anonymous FTP, connect to FTP.NEXT.COM and read the help file pub/NeXTanswers/README. If you have problems using this, please send mail to nextanswers-request@next.com. USING NEXTANSWERS BY MODEM To use NeXTanswers via modem call the NeXTanswers BBS at (415) 780-2965. Log in as the user "guest", and enter the Files section. From there you can download NeXTanswers documents. FOR MORE HELP... If you need technical support for NEXTSTEP beyond the information available from NeXTanswers, call the Support Hotline at 1-800-955-NeXT (outside the U.S. call +1-415-424-8500) to speak to a NEXTSTEP Technical Support Technician. If your site has a NeXT support contract, your site's support contact must make this call to the hotline. Otherwise, hotline support is on a pay-per-call basis. Thanks for using NeXTanswers! _________________________________________________________________ Written by: Eric P. Scott ( eps@toaster.SFSU.EDU ) and Scott Anguish ( sanguish@digifix.com ) Additions from: Greg Anderson ( Greg_Anderson@afs.com ) Michael Pizolato ( alf@epix.net ) Dan Grillo ( dan_grillo@next.com )
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Librarian replacement Date: 10 Jan 1997 17:04:41 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5b5sr9$ad1@bias.ipc.uni-tuebingen.de> References: <5b5j42$bh7@bignews.shef.ac.uk> Cc: m.crawford@shef.ac.uk In <5b5j42$bh7@bignews.shef.ac.uk> mmalcolm crawford wrote: > One of the really useful apps that's always shipped with NS is Librarian. > Now, as I understand it, it'll be difficult to port to the new OS since it's > dependent on the defunct IndexingKit? > > So, we may need a replacement? Fortunately the IR world has advanced > substantially since Librarian was developed, so I wondered, would it be > possible to wrap a GUI around Glimpse or somesuch? > My Datacase.app (see my home page) is a wrapper around FreeWAIS. I use it daily but on the downside - the indexing mechanism is slow (update takes a few 10 seconds... ok it runs in the background) - the index files are quite large - there is no support for RTF or RTFDs yet, you have to use plain text files (it is a matter of writing a RTF/RTFD input filter for waisindex) and on the upside - the search engine has the potential to work on multiplatfroms network wide (it's WAIS....) - it does a very fast search - it does not use the indexing kit at all :-) It should be trivial to use glimpse instead of freewais. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: xray@cs.brandeis.edu (Nathan G. Raymond) Newsgroups: comp.sys.next.programmer Subject: Developing for MacOS and Be now, MacSTEP in the future (question) Date: 10 Jan 1997 18:33:10 GMT Organization: Default Usenet Organization Distribution: brandeis Message-ID: <5b6216$kk6@new-news.cc.brandeis.edu> Summary: C++ and Objective C, how well do they jive? Keywords: MacOS, BeOS, NeXTSTEP I'm in the planning stages of developing an application for simultaneous deployment on both MacOS (System 7) and BeOS. Development will be with Metrowerks in C++. I have no experience with Objective C, how can I make the code forward compatible with, or at least easily portable to, the forthcoming MacSTEP (Apple's NeXTSTEP)? Are there any specific design pitfalls I should avoid? Paradigms I should strive for? Can I expect there to be tools available at a later date to ease the transition? -- Nathan Raymond xray@cs.brandeis.edu raymond@binah.cc.brandeis.edu http://www.cs.brandeis.edu/~xray
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Librarian replacement Date: Fri, 10 Jan 1997 13:11:24 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D6864C.5DE6@steeldriving.com> References: <5b5j42$bh7@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mmalcolm crawford wrote: > > One of the really useful apps that's always shipped with NS is Librarian. > Now, as I understand it, it'll be difficult to port to the new OS since it's > dependent on the defunct IndexingKit? > > So, we may need a replacement? Fortunately the IR world has advanced > substantially since Librarian was developed, so I wondered, would it be > possible to wrap a GUI around Glimpse or somesuch? Doesn't the new 4.0 Project Builder perform some sort of indexing? Does that use parts of the Indexing Kit? If so, porting it might not be a problem. Apple has some sort of searching tool called V-Twin. I don't know if it uses index files or not, but it might be a suitable replacement for the Indexing Kit's engine. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: 10 Jan 1997 19:00:55 GMT Organization: University of Sheffield, UK Message-ID: <5b63l7$s80@bignews.shef.ac.uk> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <abridge-0901972150420001@dcn134.dcn.davis.ca.us> In-Reply-To: <abridge-0901972150420001@dcn134.dcn.davis.ca.us> Followups trimmed to advocacy groups. On 01/10/97, Adam Bridge wrote: > In my opinion, if Apple is to succeed, they MUST maintain that distance > between the OS and the user interface. I don't care if it's UNIX under > the hood or OpenVMS or BeOS, I want the machine to work, not crash, and > present a consistant and relatively familier user-interface. If there's > more there, it's okay, as long as I'm NEVER required to make use of it. > Which means I can install applications ANYWHERE I want on my system, > including dumb places. Having the OS system in a more rigorously defined > location is okay -- but I shouldn't have to manipulate what's there > directly through some arcane set of UNIX commands designed back in the > days when ASR33 teletypes were the state of the art. > OK. So in what way does NEXTSTEP as it currently ships, let alone before AppLE improves it, fail to meet your needs? Best wishes, mmalc. --
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 19:10:51 GMT Organization: Global Objects Inc. Message-ID: <5b647r$s70@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> Ferret <ferret@surf.net.au> wrote: > Well, um. The thing is, I dont want to be 'forced' into putting apps in > the apps folder. All of my real apps are in the apps folder already. But > temp apps, say resedit, I am only leaving there for an hour or so. I > dont want to have to go thru the apps folder to get to it. I put in my > disk, copy res edit to the desktop. Use it, throw it in the trash. > > As someone else said, i like to put things where I want. Even in dumb > places. You can _run_ a NEXTSTEP app from anywhere in the file system. If you don't put the app in a folder that is in the "application search path", then the WorkSpace doesn't know that the app is available to open files of whatever type the app can open. And if it offers services, then you can't use those services. But I open up apps in /tmp to run and test them from there all the time, for example. When you are developing an app, you run it (to test it) from the project folder; you don't have to move it to any of the app folders. To explain the above, the application search path is a list of folders that tells the WorkSpace where it should look to find applications. When it is creating its list of filetypes, icons, and applications that open them, it only looks in the folders listed in the application search path. This is also true for apps which provide services. Note that if you have a lot of apps, this slows down the login process, since WorkSpace scans the application search path every time you log in. To solve the login problem, a lot of sites have /LocalApps for apps which define file types and services and /OtherApps (which is _not_ in the application search path) for the remaining apps. This speeds login and isn't too confusing (though IMHO is isn't all that user friendly, but that's the sysadmin's choice). Finally, what folders are in the application search path? /LocalApps /NextApps /NextDeveloper/Apps/ /NextDeveloper/Demos/ ~/Apps (the folder "Apps" within your home directory) And yes, you can add folders to this list or remove them as you wish. It is more structured than what the Mac offers, but it is still very flexible. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: gchapman@irus.rri.uwo.ca (Greg Chapman) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.mac.programmer.tools,comp.sys.newton.programmer,comp.sys.next.programmer,comp.unix.programmer,comp.sys.mac.programmer.games Subject: Re: SX Tracker Defect Tracking System Date: Fri, 10 Jan 1997 13:17:49 -0500 Organization: John P. Robarts Research Institute Message-ID: <gchapman-1001971317490001@anise.irus.rri.uwo.ca> References: <5b46dp$etc@news.mitec.net> In article <5b46dp$etc@news.mitec.net>, andrews@stormx.com (Andrew Stelmaszek) wrote: > Come to our Web Site and download a free trial of our > Defect and Program Enhancement tracking system for Win > 95/NT. What does this POSSIBLY have to do with most of the newsgroups you posted to? Are you soft in the head? -- Greg Chapman Mac Developer - Robarts Research Institute Imaging Research Labs --- "You! Out of the gene pool!"
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 19:20:48 GMT Organization: Global Objects Inc. Message-ID: <5b64qg$s70@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> <32D6499E.1017@surf.net.au> <5b5n2j$9e8@castor.cca.rockwell.com> <abridge-1001970811540001@dcn131.dcn.davis.ca.us> abridge@wheel.dcn.davis.ca.us (Adam Bridge) wrote: > [...]. For a Mac user you drag something > to System Folder, drop it, and it gets put where it belongs. End of > installation for Extensions. The idea there's something that requires > heroic knowledge for installation isn't comforting. But, I suppose, a > good installer would take care of this. Practically every commercial software package (and a large number of freeware and shareware packages as well) are distributed as a ".pkg" file. To install, double click the file and the Installer.app will open it and give you a panel with info about the package (size, what it is, icon, etc.). Click the "Install button". You may be asked where you'd like to install the package (with a default given for the "typical installation"). If the package _must_ be installed to a particular place (UNIIX sometimes requires that) you won't be given the option. Then, you'll be asked to pick which architectures you wish to install, the default being only the architecture of the machine you're using. If you want to install for other architectures, though, you add them to the selections. (I do because I have m68k and x86 hardware running NEXTSTEP, for example.) After that, you get a little progress bar and the installation happens. (Some packages may ask for other information, too, but that is rare.) It is extremely easy to install and it is very nearly foolproof, especially if you just pick all the defaults. I don't think too many folks will find this onerous--and Apple may come out with something even better for Rhapsody. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: alanf@izzy.net Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Librarian replacement Date: 10 Jan 1997 20:37:13 GMT Organization: "Comshare, Inc." Message-ID: <5b699p$req$3@inet-prime.comshare.com> References: <5b5j42$bh7@bignews.shef.ac.uk> Cc: m.crawford@shef.ac.uk In <5b5j42$bh7@bignews.shef.ac.uk> mmalcolm crawford wrote: > One of the really useful apps that's always shipped with NS is Librarian. > Now, as I understand it, it'll be difficult to port to the new OS since it's > dependent on the defunct IndexingKit? > > So, we may need a replacement? Fortunately the IR world has advanced > substantially since Librarian was developed, so I wondered, would it be > possible to wrap a GUI around Glimpse or somesuch? > > Best wishes, > > mmalc. > > What about expanding Librarian to be the Help System as well? Balloon help would be part of the app, but context sensitive help events would launch the Librarian (if it wasn't already running), and open the applications help "book", going to the appropriate location. It could serve as both a Help System and a general purpose clipping/cutting repository utility. Regards, Alan Frabutt (alanf@izzy.net)
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:15:07 -0500 Organization: Atria Software Message-ID: <maury-1001971415220001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> In article <5b3scd$8et@argo.patnet.caltech.edu>, shimpei@argo.patnet.caltech.edu (Shimpei Yamashita) wrote: > If you hate Unix so much, Nextstep is constructed such that you don't > have to use any of them, and you don't have to see any of them unless > you go hunting for them. Great! It's not that I hate Unix, I just don't need it on my desktop machine and don't want it takin up space from all my games. ;-) > The little Unix files in /bin, /etc and whatever are no different if > you don't know or like Unix. The problem is that I believe this will lead to dependance on them, and let's face it, a lot of what's in there is not all that great code. > I completely disagree about the laziness issue. Maybe it's true for > commercial-grade programs, because using external routines often > introduces big speed penalties. On the other hand, people who often > write short programs or scripts (the same folks who have embraced > AppleScript) will benefit a lot from having a complete set of > file-manipulation utilities lying around. For those types of > applications, development time is much more important than the speed > of the final solution. Yes, but the quality of these applications varies, some is passable, lots os terrible. rm doesn't even ask you to confirm, let alone allow you to rescue the items. It's not lazy coders that's the problem, it's the code that exists from years ago that is. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:17:56 -0500 Organization: Atria Software Message-ID: <maury-1001971418120001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> In article <5b3vkl$ebp@news.xmission.com>, don@globalobjects.com wrote: > Man pages are already installed from a seperate package. You have > to want them to get them. Well that's my point exactly. > You don't want to throw out the /usr/adm stuff, since the logs in > there are the first thing a support person would want to look at to > determine what is wrong with a system. But that could just as easily be a folder called Log Files or some such. If we can do this without changing anything, great. > I really think the UNIX Expert preference is all the hiding Apple > needs to do--and is all they should do. You should have a least > common denominator that all app developers can count on, and it is > important to not take away functionality in the system. You might > not use it directly yourself, but the GUI Apps you do use directly > will rely upon it. Well if it's indeed this easy, then I'm happy. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:19:28 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-1001971419440001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> <5b4b90$9u8@dfw-ixnews12.ix.netcom.com> In article <5b4b90$9u8@dfw-ixnews12.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > Hopefully, all readers of this group understand that a system with an 80 > MB system disk isn't going to have the other resources necessary to run > Rhapsody (how much RAM does her system have?) 8 meg. > This system will continue to > work fine with the various System 7 upgrades and isn't a system that Apple > has targeted for Rhapsody. Exactly the problem. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:20:48 -0500 Organization: Atria Software Message-ID: <maury-1001971421040001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> In article <5b4kbm$642@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > You apparently aren't a programmer. There are gobs of well-written > utilities around And most of them aren't standard parts of Unix, who's standard parts vary widely from Unix release to release, and vary in quality from passable to horrid. These are the exact items I'm talking about. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:22:16 -0500 Organization: Atria Software Message-ID: <maury-1001971422310001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> In article <mckinnon-1001970053450001@mckinnon.tezcat.com>, mckinnon@tezcat.com (Chuck McKinnon) wrote: > Just go the next step (pun intended) and make the Applications folder > the required place for .apps and make the system treat it as such. This > would make even more sense for new/consumer user: it makes sense. > All apps go in the Applications folder, [duh!] and the new system will > get what it need. > > Or is this too simple? Too inflexible anyway. I like putting my apps where I like them, I have a number of drag and drop ones on my desktop for instance. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:23:02 -0500 Organization: Atria Software Message-ID: <maury-1001971423170001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> <5b4apm$al2@usenet.rpi.edu> In article <5b4apm$al2@usenet.rpi.edu>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > Your mother has a PowerMac with an 80-meg disk? Mac II with a math-pro (my old machine). Yeah I know it's not going to run on it, that's my *complaint*. Maury
From: Eren_Kotan@next.com (Eren Kotan) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 10 Jan 1997 21:52:56 GMT Organization: NeXT Software, Inc. Distribution: inet Message-ID: <5b6dno$goj@news.next.com> References: <E3nHrL.1tB@cam-ani.co.uk> Hi all, just a couple of things I'd like to add to two posts on this thread: Ian Stephenson writes > Reason: Objective C is REALLY EASY. Amen to that. I'll go further and say that it only takes one day for you to learn Objective C if you are already familiar with OO design issues and an alternative OO language like C++ or Smalltalk. How can I be so certain? Because I recently was on a training course with an experienced C++ developer who had never used Objective C before. By the end of the 1st day, he was competent. By the end of the course (four days later) he was very much smitten by Objective C, though he still thought C++ was handy in a few respects. Tom Hageman writes: > id array = @(@"aap", @"noot", @"mies"); // test @(..., ...) This syntax is currently supported only in WebScript (for our WebObjects product) as a shortcut to creating NSArrays. It would fail when used from an OPENSTEP app, as you found out. In OPENSTEP, you still have to use a class "convenience method" as a shortcut to creating arrays, ie. id myArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", nil]; Still, this is pretty straightforward, anyway, right? Regards, Eren -- Eren Kotan - NeXT Software (UK) Limited oh, one moment, it's Apple now The best friend money can buy ObjectLine Support E-mail: Eren_Kotan@next.com - WWW: http://www.next.com/
From: alvin@cse.ucsc.edu (Alvin Jee) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Encryption Date: 10 Jan 1997 20:20:07 GMT Organization: UC Santa Cruz CIS/CE Message-ID: <5b689n$b2m@darkstar.ucsc.edu> References: <5b37rh$ss5@lastactionhero.rs.itd.umich.edu> In article <5b37rh$ss5@lastactionhero.rs.itd.umich.edu>, <jdevlin@umich.edu> wrote: > NEXT promised encryption with NEXTSTEP 3.0, but had to relent due to >federal export restrictions. Nonetheless, they shipped NS 3.x with a nice >interface for encrypted email, and you can load a publicly available PGP >bundle which dynamically binds with that interface. (You've got to love an Yes, but you can only send encrypted NeXTmail around. The current bundle doesn't support a MIME format (yet?). > Moreover, NEXT owns a patent on Fast Elliptic Encryption (FEE) - a >cryptosystem which, according to reported hints from Steve Jobs, the NSA >regards as more secure than PGP. (The NSA was rumored to be one of NEXT's >larger customers ...) Hmm. I did remember seeing quite a few NeXTSTEP boxes around the last time I was in one of their buildings. Then again, I also saw a few OS/2 boxes laying around. My suggesstion is to enhance the CryptorBundle to spit out MIME mail also. -- Alvin Jee alvin@neander.com http://www.neander.com NeXTMail gleefully accepted!
Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: Encryption Message-ID: <E3tB8n.IL@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <5b37rh$ss5@lastactionhero.rs.itd.umich.edu> Date: Fri, 10 Jan 1997 21:48:23 GMT jdevlin@umich.edu wrote: > > Moreover, NEXT owns a patent on Fast Elliptic Encryption (FEE) - a > cryptosystem which, according to reported hints from Steve Jobs, the NSA > regards as more secure than PGP. (The NSA was rumored to be one of NEXT's > larger customers ...) I am not sure if NeXT owns the patent or NeXTs mathematics guru...Richard Crandall (hey..maybe he's one of the reasons why Mathematica has always remained available for NeXTSTEP). Side Note: Elliptic Encryption can provide more unique keys with shorter key length the public key systems based on primes. Richard found a way to remove all divisions in the EE encryption and could replace the with simple plus and mius operations. Thuse it is called FEE. FEE is more secure then PGP since it can take a 40bit key and will cause the same amount of "cracking" headache as a 120bit PGP (ok..these numbers are wrong I would have to look them up...but you get the idea) At ObejctWorld'95 NeXT officially said that they will provide an encrption API with release 4.0. We all know they didn't. And we all know that encryption is a hairy issues in some countries (e.g. US, France) > > SUGGESTION: Apple should include a documented interface for encryption > in both Mail.app and WorkspaceManager, and allow customers to load their > favorite cryptographic engine as a bundle. This IMHO was planned and hopefully will be deliverd. > Moreover, Apple should follow > MIT's example and make a FEE bundle available on their website to anyone in > the United States and make the Objective-C implementation of the algorithm > available without restriction as an ascii file. Between FEE and PGP, This is unlikely since the implementation is something they can sell (to NSA for example) As far as I know the algorithm is described in some paper by Richard Crandall..but I am not sure if all the details of the implementation are available. But then..if it is patented you would not be allowed to implement it. > virtually everyone would have access to military grade encryption with a > consistent and well thought out GUI. This is why I won't happen :-) Governments are afraid of encryption and still hope that people will remain dumb enough to believe the claim that encryption prohibition is just to keep the "bad guys" from using it. "Bad guys" don't care if it is prohibited. Its the "good guys" who are the target. Aloha Tomi
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 10 Jan 1997 20:36:45 GMT Organization: The University of Iowa Message-ID: <5b698t$qsa@flood.weeg.uiowa.edu> References: <5b52nv$39e@news.xmission.com> From article <5b52nv$39e@news.xmission.com>, by don@globalobjects.com (Don Yacktman): > jesjones@halcyon.com (Jesse Jones) wrote: >> [ C++ ] ... in the hands of a skilled engineer it's a powerful >> and effective tool. > > Wow. This is amazing. And he really believes what he's saying! And it is true. You say so yourself with your closing statements: > As I sign off, I will say that a good design is paramount, no matter > which language you choose. A lot of Objective C projects have > failed, too, because of that. I _strongly_ suggest Bruce Webster's Design is absolutely the most important thing. If don't have a good one, it doesn't matter how you express it. > * That picky C++ compiler means I can hire twice as many programmers > and take twice as long to get it written. And even then it probably > won't work right anyway. So much for stamping the bugs early on. That picky compiler isn't just blowing smoke. The type system of C++ was well-thought out, and has grown stronger with standardization. An error is an error. > * My resulting app will be much larger because of unnecessary code > bloat caused by lack of dynamism. The design will bloat as well, > as I work around language deficiencies. [To do effective GUI work Here is the cause of your problems: C++ is not Smalltalk. C++ does does not share it's object model like Objective-C does. If you can only "think" in goto's, all of the abstraction compabilities of C, Pascal, ... matter not. If you can only think without types, then strong typing is definitely going to get in the way. > you need to have a certain amount of dynamism. In C++, this means > you re-invent your own mini runtime each time. Think virtual. If it can't be done with virtual member functions, then think dynamic_cast. If it still can't be done, think type_info. Each is is small, additional layer over C, so you pay for what you use. If you need more dynamism, and a great many problems do not, C++ is a poor choice. > * The C++ _may_ run a little faster, since I don't have the overhead > of the runtime--but not as much as you'd think because of that code > bloat and the less-than-optimal design the compiler's pickiness forces > me to use. Code bloat in C++ does not usually refer to "extra" instructions created because of run-time binding, which are truly minimal. It refers to the inlining of non-trivial template definitions. This is not a C++ problem, but a compiler implementation one. On the Mac (at least), there are manual ways to control this. I think rewriting the Stepanov Benchmark would be an interesting test. It provides a measure of the "abstraction penalty" for language features. Good optimizing C++ compilers have remarkably low penalities, even for advanced features. I would think Objective-C would fall in the same category as (Typed) Smalltalk. > * C++ has all these nifty features (syntactic sugar) that I can use > to increase my productivity. Too bad that the next guy that comes > along--to maintain my code--can't figure out what the hell I did. > Most Objective-C code is very nearly self documenting. A good rule of thumb for overloading is overload only when extending existing behavior. If you are designing a fixed point arithmetic library, what could possibly be more self-documenting than FixedPoint f1, f2, f3; ... f1 = f2 * f3; // extends * (multiplication) for fix point numbers ? Other uses are no different than poor name selection. If another programmer defines FPMFPFP(), how are you suppose to know it means "multiply a fixed point by a fixed point producing a fixed point"? > Plus, how many syntax elements does C++ add to C? Has anyone ever > sat down and counted? Compare Objective-C's number--I think it is > in the _teens_. So which is going to be easier to debug? Consider the role of C++. First, the user community of C++ is considerably larger than any other language but C, as well as its area of application. This means features need to support many, varied problem domains, and still maintain the efficency and conciseness. Second, I know of no other language in which the user community played such a large role in standardization, mostly through the rise of the Internet. Just about every C++ user thinks the language is too large, but no one wants to give anything up ("it's just too important to my work"), and many want just 1 more feature added (or two). Heck, even you do - a more dynamic notion of types. Third, C compatibility requirements can be quite restrictive, yet few would give this up even today. Without it, the adoption rate of C++ would most likely be that of Objective-C's. > And I could keep going...but I think my bias is obvious. Why? I've > used both and I _know_ which one works better. > > As a final point, which OO environment has faster execution speed on > like hardware and is more time tested and proven: NEXTSTEP or > Taligent? While such a comparison is meaningless, why didn't you pick BeOS for representative C++ system? According to MacWorld, almost everything is implemented in C++ and most users consider it very, very fast. Those who don't consider very, very fast, consider it just very fast. > As I sign off, I will say that a good design is paramount, no matter > which language you choose. Amen. -mc
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Fri, 10 Jan 1997 15:43:25 -0600 Organization: mementech, inc. Message-ID: <32D6B7FD.3D460A1B@screaming.org> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> <5b4apm$al2@usenet.rpi.edu> <maury-1001971423170001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > Garance A Drosehn wrote: > > > > Your mother has a PowerMac with an 80-meg disk? > > Mac II with a math-pro (my old machine). Yeah I know it's > not going to run on it, that's my *complaint*. Even if the Copeland project was saved by the hand of God it still wouldn't run on that hardware either. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Laurent.Champciaux@emn.fr Newsgroups: comp.sys.next.programmer Subject: Time and multiThreading Date: 14 Jan 1997 12:37:11 GMT Organization: Ecole des Mines de Nantes Distribution: world Message-ID: <5bfuln$aif@wfn.emn.fr> Hi, Is there someone who can explain me how the user time and the system time of a thread are calculated by the thread_info function ? For the very same process running in a thread, the user time at the end of the execution is never exactly the same. The first step is maybe to have a definition of what are the user time and the system time ! Any clue ? I use NEXTSTEP 3.3 (SPARC) and the MiscThreadedObject class of the MiscKit. Laurent. -- ======================================================= Laurent Champciaux Departement Informatique - Ecole des Mines de Nantes 4, rue A.Kastler - BP 20722 - 44307 Nantes Cedex 03 Tel: 33 2 51 85 82 18 (B220) email: Laurent.Champciaux@emn.fr WWW: http://www.emn.fr/dept_info/perso/laurent/
Newsgroups: comp.sys.next.programmer From: mattj@invisix.com Subject: perl4 and libwww Message-ID: <1a7cd$142215.283@news.goldengate.net> Date: Sat, 11 Jan 1997 02:34:21 GMT Hey there, I am interested in utilizing perl4 and libwww on my NS 3.2 station. Do I have to have the development option for 3.2 or can I get perl from somewhere (http://www.perl.com is down at the moment or something)...? I downloaded libwww for perl4 which should just work with it, as it's just a bunch of scripts, I take it. Is perl4 pretty portable between unixes? I'm considering doing this project on NS 3.2 or SGI Irix 5.3, which if I decide to change in the middle will my scripts work on the other machine? Thanks alot for the info, getting into some stuff I've never done before so I need a little help from you programming wizards out there....! -- MATT | mailto:mattj@invisix.com NeXTMail Ok jurcich | http://www.invisix.com Silicon Graphics Personal Iris 4D/25G, 16MB, 800MB, 20", Irix 5.3 NeXTstation Turbo Color, 24MB, 250MB, NEC XP21, NEXTSTEP 3.2
From: Ferret <ferret@surf.net.au> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 11 Jan 1997 14:24:18 +1000 Organization: n/a Message-ID: <32D715F2.6D08@surf.net.au> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b5gcs$92n@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: mmalcolm crawford <m.crawford@shef.ac.uk> mmalcolm crawford wrote: > > comp.sys.next.programmer removed from followups. > > On 01/10/97, Ferret wrote: > > As someone else said, i like to put things where I want. Even in dumb > > places. > > > Please point out where anyone said you could not do this in NEXTSTEP. > If you can't, please can we move on from here, and would you please stop > spreading disinformation. > > (Inference: you can put apps wherever you like. Even in dumb places.) Ok, if you can put apps on the desktop then fine. But the reason I sai#################################################################### Path: news.informatik.uni-muenchen.de!lrz-muenchen.de!informatik.tu-muenchen.de!fu-berlin.de!news.mathworks.com!news.sprintlink.net!news-peer.sprintlink.net!news.sprintlink.net!news-pull.sprintlink.net!news.sprintlink.net!news-fw-12.sprintlink.net!tmpnews.crd.ge.com!news.crd.ge.com!rebecca!rpi!usenet From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 11 Jan 1997 02:18:12 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Lines: 16 Message-ID: <5b6t94$nk@usenet.rpi.edu> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> NNTP-Posting-Host: mlor.its.rpi.edu X-Newsreader: Alexandra.app (Version 0.82) Xref: news.informatik.uni-muenchen.de comp.sys.next.programmer:21535 comp.sys.next.advocacy:52770 comp.sys.mac.advocacy:178857 comp.sys.mac.system:191292 nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: > > You apparently aren't a programmer. There are gobs of well-written > utilities around, and it's utterly senseless to rewrite them from > scratch, especially considering that they have already gone > through extensive testing/debugging cycles. Well, I wouldn't go too far praising the wonderfulness of the code in most unix utilities. A fair number of them are hacks thrown quickly together, which have been good enough that no one bothered to rewrite them (until GNU came along...). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Librarian replacement Date: 11 Jan 1997 02:04:04 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5b6sek$nk@usenet.rpi.edu> References: <5b5j42$bh7@bignews.shef.ac.uk> <5b699p$req$3@inet-prime.comshare.com> alanf@izzy.net wrote: > mmalcolm crawford wrote: > > So, we may need a replacement? Fortunately the IR world has > > advanced substantially since Librarian was developed, so I > > wondered, would it be possible to wrap a GUI around Glimpse or > > somesuch? > > What about expanding Librarian to be the Help System as well? > Balloon help would be part of the app, but context sensitive help > events would launch the Librarian (if it wasn't already running), > and open the applications help "book", going to the appropriate > location. It could serve as both a Help System and a general > purpose clipping/cutting repository utility. I think that this is one of those examples where Apple already has the technology for this area. I see little reason for Apple to rewrite the indexing kit when they've already got V-twin. And the help facilities on the Mac are nicer (in my opinion) than most anything that's been done on NeXTSTEP, with the exception of the customized help system that Scott Hess used to have in Stuart and TickleServices. Now, let me hasten to add that I think the indexing kit would be good for other purposes, and I hope to see a revitalized version reappear as part of the MiscKit. However, I don't think Apple needs to spend time on it. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 11 Jan 1997 02:16:11 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5b6t5b$nk@usenet.rpi.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> <5b4b90$9u8@dfw-ixnews12.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) wrote: > Hopefully, all readers of this group understand that a system > with an 80 MB system disk isn't going to have the other resources > necessary to run Rhapsody (how much RAM does her system have?). > This system will continue to work fine with the various System > 7 upgrades and isn't a system that Apple has targeted for Rhapsody. Actually, I'm not all that sure that system 7.6 (with all it's goodies, such as OpenDoc) will be particularly comfortable on an 80meg disk either. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: jesjones@halcyon.com (Jesse Jones) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: Fri, 10 Jan 1997 22:19:40 -0800 Organization: Jet City Studios, Inc Message-ID: <jesjones-ya023580001001972219400001@news.halcyon.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> <5b52nv$39e@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b52nv$39e@news.xmission.com>, don@globalobjects.com wrote: > <RANT> > > With C++ my productivity hits rock bottom, at least when compared > to what I can crank out in Objective C. And even with all the > type checking the compiler is doing for me, I find my code quality > is in the dumps with C++, as compared to Objective-C. Yeah, that > picky compiler keeps me busy all right. Bow down to the needs of > the compiler and satisfy its every whim. And what whims are we talking about? Requiring that the method exists for the object it's invoked on? Requiring that pointer assignments be between compatible types? Do you agree that it's better, as a general rule, to find errors as soon as possible? > I like Objective C becase it reduces clutter in the system's design > and is simply a better OO implementation (for reasons that have been > hashed out zillions of times before). I can see how a more dynamic language can lead to a simpler class design: I've made careful use of dynamic_cast in my C++ code and been pleased with the results. However I don't think this is worth sacrificing static type safety for. I want my code to be as solid and robust as possible. A language where an object may or may not be able to handle a method call seems like a giant step backward. I must have missed those zillion discussions of why Objective-C is a better OOPL than C++. Care to elaborate? > Let's face it: a large C++ project versus a large Objective-C > project, what are the differences? > > * That picky C++ compiler means I can hire twice as many programmers > and take twice as long to get it written. And even then it probably > won't work right anyway. So much for stamping the bugs early on. > The simplicity of Objective-C keeps most of those bugs from happening > in the first place, because it is easier to write! Besides, a good > design will, by nature, help reduce the bugs in the product. You > should never trust a compiler to make up for flaws in a bad design, > which is what I see far too many C++ programmers doing. (Not all are > that way, thank heavens, but in practice the "compiler will spot the > bugs" attitude often leads to this outcome.) As I said before simple to write doesn't mean a language is suitable for software engineering. BASIC makes it easy to bang out code, but very few would claim that it's suitable for large commercial quality projects. I would claim (and I know I'm not alone) that C is, at best, barely adequate for software engineering. C++ has added a lot to the language with most of the additions focused on making it easier to write large robust systems. What has Objective-C done to meet this goal? [snip] > * C++ has all these nifty features (syntactic sugar) that I can use > to increase my productivity. Too bad that the next guy that comes > along--to maintain my code--can't figure out what the hell I did. > Most Objective-C code is very nearly self documenting. The simpler > designs mean the maintenance guys can come in and quickly find and fix > problems. If there are any. You could argue that good and bad > programming styles affect this comparison--and yes they sure do--but > C++ promotes arcane usage and bad style because of its haphazard > design whereas Objective-C does a lot to help promote good design. > Plus, how many syntax elements does C++ add to C? Has anyone ever > sat down and counted? Compare Objective-C's number--I think it is > in the _teens_. So which is going to be easier to debug? C++ was not haphazardly designed and it doesn't "promote arcane usage and bad style". The worst C++ code is written by old time C hackers who don't grasp OOD and the evils of the preprocessor. Slamming C++ because its a big language is absurd: the language was written for professional developers who can relatively easily learn the mechanics of the language. There are valid criticisms of C++, but they're almost entirely due to backward compatibility with C. [snip] > As I sign off, I will say that a good design is paramount, no matter > which language you choose. A lot of Objective C projects have > failed, too, because of that. I _strongly_ suggest Bruce Webster's > book, "Pitfalls of Object Oriented Programming." That's the wise > voice of sad experience speaking there. May we all read and learn > from it and avoid those traps! I've read Webster's book. It was interesting in places, but I don't think I learned much. A much better book IMO is "Object Oriented Software Construction" by Bertand Meyer. In the book he discusses OOD and OOP from a software engineering perspective using Eiffel for his examples. The book is one of the classics in the field and should be read by anyone who cares about robust software. --Jesse
From: ting@tartarus.uwa.edu.au (Tee Chuan Ng) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 12 Jan 1997 05:16:56 GMT Organization: Bayle Inc. Message-ID: <ting-1201971325500001@hera.ee.uwa.edu.au> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> In article <5b647r$s70@news.xmission.com>, don@globalobjects.com wrote: >You can _run_ a NEXTSTEP app from anywhere in the file system. > >If you don't put the app in a folder that is in the "application >search path", then the WorkSpace doesn't know that the app is >available to open files of whatever type the app can open. And >if it offers services, then you can't use those services. But >I open up apps in /tmp to run and test them from there all the >time, for example. Hmm ... so /app is one of the defaults in the $PATH variable? So does this mean that the OS will not be able to find apps which aren't in any of the directories listed in $PATH? If this is the case then "double clicking" a document created by an application not located in the search path wouldn't be possible and would be very un Mac-like - assuming that the document in question doesn't reside in the same directory as the application. Am I mistaken about this conclusion? Furthermore, is searching the path directories recursive? If this is the case then a solution to make NeXT more Mac like would be to add a / to the end of the search path list. Have fun, TC
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer Subject: Re: NeXT on Mac 68040 Date: 14 Jan 1997 18:12:24 GMT Organization: University of Sheffield, UK Message-ID: <5bgia8$r15@bignews.shef.ac.uk> References: <5bd75k$36t@infa.central.susx.ac.uk> <jbf-ya023580001301971222120001@news.tiac.net> In-Reply-To: <jbf-ya023580001301971222120001@news.tiac.net> On 01/13/97, James B. Frazer wrote: > In article <5bd75k$36t@infa.central.susx.ac.uk>, matteos@cogs.susx.ac.uk > (Matteo Sartori) wrote: > > > Is NeXT available on Apple Macs or is it only NeXT hardware compatible ? > > Only on NeXT hardware. > Just to clarify -- NEXTSTEP does not run on 68040-based Macs. In addition to NeXT hardware, however, it also runs on Intel PCs and Sun SparcStations. Best wishes, mmalc. posn. research facilitator where institute for language speech and hearing sheffield university west court 2 mappin street sheffield s1 4dt england vox (+44) 114 282 5269 fax (+44) 114 278 0972 email m.crawford@dcs.shef.ac.uk NeXTMail, SunMail, MIME welcome PGP key available on request http://www.dcs.shef.ac.uk/research/ilash/ --
From: jesjones@halcyon.com (Jesse Jones) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: Sun, 12 Jan 1997 20:15:22 -0800 Organization: Jet City Studios, Inc Distribution: world Message-ID: <jesjones-ya023580001201972015220001@news.halcyon.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972206150001@news.halcyon.com> <5bb1j8$qb3@peng.ping.at> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bb1j8$qb3@peng.ping.at>, hannes@ping.at (Hannes Tiefenbrunner) wrote: > In <jesjones-ya023580000901972206150001@news.halcyon.com> Jesse Jones wrote: > > ....snip.... > > Like Eiffel C++ was designed to make writing production quality code > > easier. A large part of this is static type checking which at compile time > > checks *all* your code for type mismatches. In a language with less static > > type checking you need to execute each code path in your application to > get > > the same result. > > Does this mean, that you hope not needing to do so, when using static type > checking? If you carefully read what I wrote you'll see that this is not what I said. Basicly I was just trying to emphasize the difference between compile time and run time checking. With compile time checking all of your code is checked each time you compile it. With run time checking the tests are executed only if you happen to execute that code path. For this reason I strongly prefer languages whose design and philosophy encourage compile time checks. > > ....snip... > > I keep seeing Objective-C advocates claiming that it makes writing > programs > > much easier. That may well be true, but the hard part of programming is > not > > coding it's making the program do what it's supposed to do, perform well, > > and gracefully handle errors. C++ makes this easier because the language > > and the philosophy emphasize catching problems at compile time. > > What problems can be caught by C++ at compile time? Do you mean problems due > to using wrong data-types? > I also think, that static type checking can help avoid some bugs. That`s why > I most of the time use it in ObjectiveC. Unfortunately, using wrong types is > one of the smaller bug-producers. Wrong types may or may not be a major source of bugs, but I feel much better knowing that I'm using a language that is going to catch almost all of my type errors. I want to use a compiler that will do everything it can do find bugs in my programs. I want frameworks that rigorously check method arguments and perform invariant checks upon entering every public function. I want garbage collection. I want a language that was designed for writing large robust systems. Hmmm, sounds kind of like....Eiffel! --Jesse
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: SimonSays (speech recognition) Date: 12 Jan 1997 13:01:59 GMT Organization: University of Sheffield, UK Message-ID: <5banc7$kim@bignews.shef.ac.uk> Someone asked recently about SimonSays, the NeXT app for voice control of the interface... If I remember rightly there was a Mac equivalent (Voice Navigator?) which was available a while ago -- is that still around? I notice from the Apple developer pages http://speech.apple.com/speech/dev/dev.html that a development environment for speech recognition has been released (it looks similar in many respects to Visus' SpeechKit which was released for the NeXT a few years ago) -- it actually also has a chap sporting a bow tie similar to that which SimonSays had too! I wonder if this kit is to be ported to Rhapsody (it looks as if it's written in C++ at the moment -- it could be used "as is", else maybe better ported to Objective-C)? I'd have thought that given this kit it should not be too difficult to reconstruct SimonSays, probably (given that ASR technology has improved since then) actually rather better... Despite my background (or perhaps because of it!) I'm not convinced that SR is quite ready for prime time yet, and one of my main criticisms has always been that I didn't thingk enough attention had been paid to the User Interface. What's really encouraging about the article is the emphasis that the developers give to the creation of a good and imaginitve UI. Best wishes, mmalc. --
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 14 Jan 1997 11:37:45 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-1401971137450001@199.166.204.230> References: <5aq7uf$7vo@huffalump.visi.com> <toolz-1101972317210001@news> <magao-ya02408000R1301970004010001@news.zip.com.au> <5be9qd$k2k@nntp1.apple.com> In article <5be9qd$k2k@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: Thank you for your clear and informative message. A question if I may... > 1. Support for existing MacApp/C++-based applications which will remain > on the Mac OS 7.x path until that path goes away (Blue Box). Seems reasonable. > 2. Support for moving existing MacApp/C++-based applications > over to Rhapsody (Yellow Box). A very good idea. > 3. Enhancing AppKit through integration of key MacApp concepts. Can't comment. > 4. Support for writing new or reworking existing MacApp/Objective C > applications to run only under Rhapsody (Yellow Box). Also reasonable. My question addresses the opposite problem, what do Yellow Box developers do to get their code running on Sys7? This strikes me as rather important, and to date, ignored in all the press releases and such. Maury
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 13 Jan 1997 06:57:36 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bcmd0$bk0@duke.squonk.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> <32D6499E.1017@surf.net.au> <5b5n2j$9e8@castor.cca.rockwell.com> <32D71873.546C@surf.net.au> Ferret <ferret@surf.net.au> wrote: > Yes, using NEXTSTEP probably would clear up some concernes. But > how would I use NEXTSTEP? It's not like I have them at work. I > dont have a job. I live at home during the holdidays with my Mac > PowerBook and my Quadra 610, and at school I use my PowerBook > and the PC's they have there. Funny, I dont see NeXT anywhere in > there. Well, another thing to realize is that Apple is working on something they're calling Rhapsody. This is based on NeXTSTEP, but it will look and feel more like the MacOS than NeXTSTEP does. So even if you used NeXTSTEP, you might get yourself (and us!) all worked up about issues that won't exist in Rhapsody... > Why is NeXT spelt with capital N, lower e, capital X, and capital T It's a trademark. It's a way to recognize that you mean "the company which calls itself 'NeXT'", instead of just the standard word next. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Tue, 14 Jan 1997 11:43:49 -0500 Organization: Atria Software Distribution: inet Message-ID: <maury-1401971143490001@199.166.204.230> References: <E3nHrL.1tB@cam-ani.co.uk> <5b6dno$goj@news.next.com> In article <5b6dno$goj@news.next.com>, Eren_Kotan@next.com wrote: > id myArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", nil]; I'm curious, why the NSxxx class names? I know the historical context, but is this important today? Seems somewhat unpleasing to the eye. Maury
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: SimonSays (speech recognition) Date: 13 Jan 1997 23:32:12 GMT Organization: Indiana University, Bloomington Message-ID: <5begls$nkk@dismay.ucs.indiana.edu> References: <5banc7$kim@bignews.shef.ac.uk> <5bcasp$614@dismay.ucs.indiana.edu> <5be2di$1mev@msunews.cl.msu.edu> NNTP-Posting-User: glhansen In article <5be2di$1mev@msunews.cl.msu.edu>, <spammers@ruin.the.internet> wrote: >In <5bcasp$614@dismay.ucs.indiana.edu> Gregory Loren Hansen wrote: >> That, and I can't think of anything useful to do with speech recognition, >> so I don't use it. But that's not for lack of technical excellence. >Geeze I have an idea for a definate 'killer app' once SR is commonly >available. It's so simple and so insanely useful is almost made me cry. Well, there's some Star Trek database thing that's voice-controlled like the computers on the Enterprise (speaking of which, do you think there'll be a Star Trek theme for the Appearance Manager?), but I didn't consider that a good enough use to buy it. >I've been researching using a PC with the technology and interfacing >the SR in there to various OS's. I think that a next generation OS >should really consider incorporating a SR engine into the UI, very >much like how SimonSays works. But from the SimonSays example it Just to clarify what you mean by integration, what do you think of Apple's speech recognition? It's not quite integrated to the point where you can say "close window" and the OS will close a window, but you can say "close window" and it will run the Close Window script in the Speakable Items folder, and it works while another app is active. >Frankly it is time for us to be unchained from our keyboards and >mice. Heck mostly we use a mouse just to navigate windows and >the GUI and a keyboard to type words/commands.. I personally >don't ever want to have to use a keyboard again!!!!! Let me walk I don't know. I always feel kind of dumb talking to my computer. >And this is why you'd want multiple cpu's (SR eats a lot of cpu!) Well, that's not the *only* reason I'd want multiple CPUs, but that's a very good point. >Also using some of the hearing aid technology it should be easy >to make a microphone that will pick up only sounds from a persons >lips and not the surrondings (at least one that sits 1-3" from your mouth).. Spy tech! Plug your microphone into a preprocessor that filters background noise, amplifies the voice range, searches for speech patterns, maybe it can take a load off of the processor. >Please give us decent SR under OpenStep on PPC Apple/NeXT >and I'll give you a killer app that could sell 10s-100s of millions >of machines. You're awfully optimistic. What did you have in mind? -- "But you can't let the package hide the pudding; evil is just plain bad. You don't cotton to it. You've got to hit it in the nose with the rolled-up newspaper of goodness. Bad Dog! BAD! DOG!" - The Tick
From: John Friesen Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: SimonSays (speech recognition) Date: 13 Jan 1997 23:09:45 GMT Organization: BCTEL Advanced Communications Message-ID: <5befbp$87q2@news.bctel.net> References: <5banc7$kim@bignews.shef.ac.uk> <5bcasp$614@dismay.ucs.indiana.edu> <5be2di$1mev@msunews.cl.msu.edu> > mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > That, and I can't think of anything useful to do with speech recognition, > so I don't use it. But that's not for lack of technical excellence. I have used the demo version of SimonSays on my Nextstation Turbo and it worked very well. I just spoke normally to the computer and it followed about a dozen commands that I set for it. There is also a demo called Text to Speech and that program is wild.....all you do is drag text into the app and it reads it to you. It is very good for checking reports, etc. I hope an app will soon be available on Openstep that will convert Speech to text.....keyboards are the slowest human/computer interface.....
From: Greg_Anderson@afs.com (Gregory H. Anderson) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 14 Jan 1997 20:57:32 GMT Organization: Anderson Financial Systems Inc. Distribution: inet Message-ID: <5bgrvs$pib@shelob.afs.com> References: <maury-1401971143490001@199.166.204.230> Maury Markowitz writes > I'm curious, why the NSxxx class names? I know the historical context, > but is this important today? Seems somewhat unpleasing to the eye. To avoid namespace collisions, it is typical for each vendor of objects to adopt a 2 or 3 letter prefix identifying the author in the class name. Otherwise, two ISVs might both write a "Foo" class, which could never be used together in the same project. "NS" is the prefix NeXT chose for its own classes. -- Gregory H. Anderson | "I wander'd off by myself, In the Crystal Ball/Star Gazer | mystical moist night-air, and from Anderson Financial Systems | time to time, Look'd up in perfect greg@afs.com (NeXTmail OK) | silence at the stars." Walt Whitman
From: "Hiroki Yamaberi" <yamaberi@gokhu.com> Newsgroups: comp.sys.next.programmer Subject: CMU Common Lisp for NS 3.3 FIP Date: 14 Jan 1997 01:16:15 GMT Organization: C&C Internet Service mesh Message-ID: <01bc01b8$080225e0$020000c0@mini> Hi, I'm porting CMU Common Lisp for NEXTSTEP 3.3 for Intel. And current Free snapshot is avairable, but with no warranty: ftp://gokhu.com/pub/cmucl17f.tgz You better get Emacs Editor as a lisp listener. Have fun. -- /// Hiroki Y.
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 14 Jan 1997 21:01:54 GMT Organization: Digital Fix Development Message-ID: <5bgs82$ldk@news.digifix.com> References: <E3nHrL.1tB@cam-ani.co.uk> <5b6dno$goj@news.next.com> <maury-1401971143490001@199.166.204.230> In-Reply-To: <maury-1401971143490001@199.166.204.230> On 01/14/97, Maury Markowitz wrote: >In article <5b6dno$goj@news.next.com>, Eren_Kotan@next.com wrote: > >> id myArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", nil]; > > I'm curious, why the NSxxx class names? I know the historical context, >but is this important today? Seems somewhat unpleasing to the eye. > >Maury > Actually, I think its better. The reason being as long as you keep your own objects out of the NSxxx namespace, you will not find yourself being stomped on. As well, it gives you a definate indication of ownership of the original class. NS (OpenStep), Misc (MiscKit), etc.. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: beatty@netcom.com (Derek Lee Beatty) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 13 Jan 1997 18:30:21 GMT Organization: none Message-ID: <5bduvt$e54@beatty.slip.netcom.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> <5b52nv$39e@news.xmission.com> <jesjones-ya023580001001972219400001@news.halcyon.com> <5b8mje$nam@news.xmission.com> don@globalobjects.com (Don Yacktman) wrote: >Having used both, the question of which I would rather use is >a no-brainer. I'd like to know if other people who have used >_both_ languages _extensively_ feel the same as I do or not. >I don't want to hear from people who have only used one or the >other or who have not used them both a lot; there would be too >much bias in the answer to get what I'm looking for here. I'm not quite what you're looking for but I'm fairly close. I've used C++ extensively and Objective C only occasionally (but Smalltalk extensively), and I'd much rather use Objective C than C++. The problem is not that I can't build a large system; I've built large systems in Smalltalk, and I've built large systems in a mixture of Scheme and C. I've written lots of C over the years, and I've had people seek me out out tell me what a pleasure it was to read my code. I've done some teaching of Common Lisp. I've done a little work using pure functional languages. I've done research on formal methods for hardware design. I think I have a fairly well-rounded CS background. I think the real problem with C++, compared to Objective C, is that while Objective C was very clear on its design goal (add the flexibility of OOP to C), C++ suffered not having clear goals. C++ was structured on two tenets: "compatibility" and "speed:" 1) compatibility with C, and 2) getting the highest possible performance for small snippets of code like foo->bar(). I'll give you the compatibility. C++ is highly compatible with C. Some complain that the language is maligned because much code was written by poorly-trained C programmers. Was it Perlis who said that one man's bug is another man's feature? I'll also give you the speed, for small chunks of code. Compile-time type-checking facilitates compile-time optimizations. Unfortunately, this kind of type checking has been misrepresented as offering superior safety. Although it can, you don't see the safety because C++ is fat with other dangers, as I'll explain later. (If you want a similar language with this kind of type-checking designed for safety, try Modula-3.) Doing as much binding of message (name) to method (code) as possible at compile time seems like a great idea because the compiler can check a lot. It works well in a waterfall development methodology (i.e., one where requirements don't change) led by an omniscient system architect (i.e., one who gets the base classes right the first time). Where this early binding breaks down is where the first version isn't right. Sometimes the requirements change after you've started coding. This can happen because the requirements analysis wasn't done right; it can also happen because the requirements are unknowable. Examples of the latter are programs that must comply with a law ("nobody is safe while the legislature is in session") or that have a non-trivial user interface (User studies followed by code changes are the only way to build good interfaces for novel tasks.) This point is easily missed. It's hard to grasp for students whose programming problems are well-specified (what instructor has time to take the student questions that an ill-specified problem generates?). It's also be hard to grasp for ivory-tow#################################################################### Path: news.informatik.uni-muenchen.de!lrz-muenchen.de!uni-erlangen.de!news.apfel.de!fu-berlin.de!news.mathworks.com!howland.erols.net!math.ohio-state.edu!news.cis.ohio-state.edu!nntp.sei.cmu.edu!bb3.andrew.cmu.edu!andrew.cmu.edu!cs4w+ From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 14:25:10 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Lines: 31 Message-ID: <AmrGwKS00iV9E5mDUv@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.e <scottm-ya02408000R1401972248330001@news.erols.com> NNTP-Posting-Host: po7.andrew.cmu.edu In-Reply-To: <scottm-ya02408000R1401972248330001@news.erols.com> Xref: news.informatik.uni-muenchen.de comp.sys.next.programmer:21560 comp.sys.next.advocacy:52959 comp.sys.mac.advocacy:179197 comp.sys.mac.system:191593 Excerpts from netnews.comp.sys.next.advocacy: 14-Jan-97 Re: MacWorld Exclusive: App.. by Scott Maxwell@nic.com >> Right. You can run the app, but not launch it by double clicking >> one of its data files. > > Well how about this. Perhaps a method could be devised so that when you > move an application the database of locations is updated when the move > occurs? I know nothing of the internal operation of OpenStep but it seems > like an easy thing to implement. What would that gain you? Right now, NEXTSTEP has conventions for the filesystem locations for applications and other components which are supposed to be available to everyone on the system. These conventions exist for a number of good reasons-- they simplify system administration and fileserver configuration, and they make it much easier for users to use a new machine without having to waste time trying to figure out where important applications were installed. Nothing prevents you from installing applications whereever you want and making links (aka aliases) into the standard locations, or from making links from the standard locations whereever else you like. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system Subject: Re: DPS Hit Detection Date: 15 Jan 1997 22:26:44 GMT Organization: Global Objects Inc. Message-ID: <5bjlj4$sab@news.xmission.com> References: <5biv18$h7p@castor.cca.rockwell.com> <AF028AED-9B7E4@198.68.42.195> "Lawson English" <english@primenet.com> wrote: > Erik M. Buck <embuck@palmer.cca.rockwell.com> said: > >It seems that GX provides higher level abstractions of "Graphics" than > >DisplayPostscript. I have not heard any reason why GX could not be > >implemented as frameworks based on DisplayPostscript. I can not give any > >details (proprietary information) but my company makes a product that does > >essentially that. It is not GX, but it has similar capabilities. > > GX is an optimized data base that is written entirely in compiled C that > calls its primitives directly as part of a single function call, rather > than as a string of bytes interpreted by the DPS server. If you're going to dig that deep into the engine, you'll find that DPS's binary object sequences are surprisingly similar. And this is how most of the NEXTSTEP drawing occurs--it is a lot faster than you would expect from an "interpreter" because most of the "interpreting" was done by PSwrap at compile time and ends up being more of a jump table. DPS is very, very well written, contrary to what you think. > The cached data that GX generates is available to be used by the primitives > because there is no intermediate set of calls needed as is the case with > non-DPS cache info used with DPS primitives.[...]. > > Being forced to store the cache info for the font (not just bit-maps, but > info used for hit-testing of the above kinds of text-strings) on the other > side of the DPS server stream from the primitives that would use it, would > slow things down. I suspect that it would slow things down a lot more than > would be acceptable in a multi-tasking environment, which is probably why > Apple has explicitly said that the GX line layout was being merged with > DPS. Maybe the rest of it can be made fast enough to work in frameworks or > maybe they are abandoning the rest. [...] Now here's a problem. You're effectively saying that Erik's solution wouldn't work because it would be too slow if built upon DPS. Well, although like Erik, I can't give any details, I have seen his _actual_ _implementation_ of this and IT WORKS! It is even reasonable when running on a 33MHz 68040! It isn't as bad as you think, I would posit, because quite simply I've seen a working implementation that disproves your theory. This is _fact_. You can posture all you want, but at some point you'll scrape up against reality... By the way, I do hope Erik's work is someday available as a commercial product. It is _way_ cool. It impresses me; GX does not. :-) [That's not a flame at GX--it is nice for what it is, but Erik's product--the part of it that runs on top of the GX-like code and could probably be ported onto GX--is really, really nifty.] -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer,comp.sys.mac.advocacy,comp.sys Subject: OPENSTEP Documentation on the Web Date: Wed, 15 Jan 1997 19:42:06 GMT Organization: Electronics Service, Unit No. 16 Message-ID: <5bjc0a$js2@news.wco.com> NeXT has a new page up on the NeXT site pointing to all available OpenStep documentation for Mac programmers. You can access it through: http://www.next.com/Pubs/Documents/Download Thanks to the NeXT Technical Publications group for pulling this together. Mike Paquette -- I don't speak for my employer, whoever it is, and they don't speak for me. mpaque@wco.com mpaque@next.com NeXT business mail only, please
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 17:53:29 -0500 Organization: Atria Software Message-ID: <maury-1501971753450001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > In any event, your entire argument here is weak and irrelevant. You're right of course, who would want something like standardization? > issue was whether Rhapsody should include Unix utilities. I argued > that it should, because many developers of GUI applications could use > them to save time. Your response is to assert that Unix utilities are > "nonstandard". No, my argument is, and was sidestepped, that these functions are better off provided vias modern interfaces rather than command line tools. > Rhapsody! Whatever Rhapsody includes is a de facto standard Rhapsody > utility, and may be used in Rhapsody GUI apps. So they should get rid of the command line stuff then. Maury
From: ga@ed4u.com (G. Gordon Apple, PhD) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Wed, 15 Jan 1997 13:24:33 -0700 Organization: Advanced Communications Engineering, Inc. Distribution: world Message-ID: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> In article <tbrown-ya023580001401970003470001@news.netset.com>, tbrown@netset.com (Ted Brown) wrote: > > Obj-C does not support multiple inheritance. > > I keep hearing that multiple inheritance is a "must have" feature, but I've > never really noticed the lack if it's missing. The fact that others find > it necessary leads me to believe that I must be missing something > somewhere. I've posted before that I don't find it a needed feature, maybe > I'm just being dense. > > Could you list off a few reasons why lacking mulitple inheritance in a > language is limiting and annoying? (looking around ruefully) I don't > really want to cause another language riot or flamefest, I'd really like to > know. > MI is extremely useful as both a design tool and a modification tool if used properly. Like any other tool you can also misuse it in ways that get you into deep yogurt. In the design case, it allows you to partition and encapsulate various independently-useful orthogonal functionalities so that they can be combined at will (mixins) without each feature tripping over the others. In the case of modifications, it allows addition of features without messing up the original classes. For example, you buy (or obtain by hook or by crook) a library of objects that you really don't want to modify, but now you want to subclass and implement streams or something that was not included in that object library. It's easy to do with MI. Without it, you're hosed, or you at least have a lot more work than you had planned. -- G. Gordon Apple, PhD The Ed4U Project Advanced Communications Engineering, Inc. Redondo Beach, CA ga@ed4u.com www.ed4u.com
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system Subject: Re: DPS Hit Detection Date: 15 Jan 1997 13:10:02 -0700 Organization: Primenet Services for the Internet Message-ID: <AF028AED-9B7E4@198.68.42.195> References: <5biv18$h7p@castor.cca.rockwell.com> nntp://news.primenet.com/comp.sys.mac.misc, nntp://news.primenet.com/comp.sys.mac.system Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Erik M. Buck <embuck@palmer.cca.rockwell.com> said: >It seems that GX provides higher level abstractions of "Graphics" than >DisplayPostscript. I have not heard any reason why GX could not be >implemented as frameworks based on DisplayPostscript. I can not give any >details (proprietary information) but my company makes a product that does >essentially that. It is not GX, but it has similar capabilities. GX is an optimized data base that is written entirely in compiled C that calls its primitives directly as part of a single function call, rather than as a string of bytes interpreted by the DPS server. The cached data that GX generates is available to be used by the primitives because there is no intermediate set of calls needed as is the case with non-DPS cache info used with DPS primitives. If a GXLayout shape contains Korean Hangul text, GXHitTestLayout(myShape...) can return the tri-glyph that was clicked on OR which side (left/middle/right) of the tri-glyph was clicked on, depnding on which options are set. GX hit-testing even helps resolve (although not completely from what I understand) the case where you have clicked on the boundry of right-to-left and left-to-right text combinations (e.g. Hebrew quoting English). Given how complex some languages and combinations of languages are, even simple text-selection done in real-time isn't a trivial task, and you would like to do it as optimally as possible. Having all the cache info available immediately to the GX call makes it as speedy as possible. Being forced to store the cache info for the font (not just bit-maps, but info used for hit-testing of the above kinds of text-strings) on the other side of the DPS server stream from the primitives that would use it, would slow things down. I suspect that it would slow things down a lot more than would be acceptable in a multi-tasking environment, which is probably why Apple has explicitly said that the GX line layout was being merged with DPS. Maybe the rest of it can be made fast enough to work in frameworks or maybe they are abandoning the rest. I hope that they don't abandon the rest of GX. Since GX is a complete package, including printing, I'd like the entire thing to be available. Printing is a good example of where the GX strategy has its advantage: having everything sent to the print driver as a stream of GX shape objects means that you can pre-process the print job as individual shapes before it is finally translated into PS calls. Since there is only one print model ever used under NeXT/OpenStep, the printing problems that have plagued Apple since they released GX won't be an issue. A document that is rendered using GX would merely call a "GX printing translator" that that would allow the GX "print extension" processing to occur and THEN would translate it to PS for normal NeXT/OpenStep printing. Straight-forward and trivial to implement compared to what Apple has had to deal with under System 7.x, due to all the backwards compatibility issues due to various old-style print architecture limitations. Some of the more powerful applications would patch the OS all over the place for printing purposes and they would no longer print once GX was installed. Not the case here, since ONLY GX-rendered applications would ever call the GX printing translater and UNIX doesn't allow apps to patch the OS directly (sorry Microsoft). --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: [charter] comp.sys.*.advocacy Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Wed, 15 Jan 1997 16:39:36 -0600 Organization: mementech, inc. Message-ID: <32DD5CA8.561F84AB@screaming.org> References: <petrichE3Ct2r.3AJ@netcom.com> <marke-0201970007270001@port55.annex5.nwlink.com> <AEF16B02-AD9E5@198.68.42.189> <5ahf5n$pq2@bignews.shef.ac.uk> <5ajg47$soi@bignews.shef.ac.uk> <1997010514570823842@p026.gor.euronet.nl> <5ap7db$mnu@nyheter.chalmers.se> <5argj1$84s@majipoor.cygnus.com> <5auv1t$h2c@nyheter.chalmers.se> <5b0vqa$k9@majipoor.cygnus.com> <maury-0801971738540001@199.166.204.230> <5b1bq7$48e@news.xmission.com> <maury-0901971304410001@199.166.204.230> <5b5vme$s70@news.xmission.com> <maury <maury-1401971527570001@199.166.204.230> <0mrHfT600iV945m0Ei@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles W Swiger wrote: > No doubt some Mac advocates recall that I and other non-Mac people have > slammed the Mac hard for it's flaws in multitasking and VM; but the > truth is that I've criticised NeXT harder than I ever have the Mac. > I've bitched about the miserably buggy POSIX "support", the inability to > turn NetInfo _OFF_, the lack of a modern sendmail, and a handful of > other issues for years. It's true. Charles has simultaneously been one of this forum's most harsh NeXT critics, and one of the strongest NeXTstep advocates. You'll find that he's a great source of knowledge and information. <genuflect> > Constructive criticism can be very useful to developers, assuming that > it is based off of knowledge of the problem and not some knee-jerk > reaction. Most NEXTSTEP advocates are honest enough to acknowledge that > there are other ways of doing things that may be better than the current > "NEXTSTEP way". So go ahead and criticise what we have to say (if > you've understood what the subject is), because that process will help > make Rhapsody better. > > And that is what we're all trying to do, right? I might also add that we should try to contain these discussions to single groups within the comp.sys.next.* and comp.sys.mac.* hierarchies. Many people try to read all of the groups within, which makes crossposting between them a pain. Besides, the people in the *.programmer groups already have issues to deal with concerning already-released versions of the soon-to-be-merged systems. Unlike the advocacy groups, they're trying to get immediate answers to questions that their work depends upon. I'm sure they'll drop by *.advocacy in their downtime. All we have to do is a little follow-up trimming. [followups trimmed back to advocacy groups.] -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: rex@mit.edu (Eric King) Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system Subject: Re: DPS Hit Detection Date: Wed, 15 Jan 1997 18:07:26 -0400 Organization: Netcom Message-ID: <rex-ya023080001501971807260001@nntp.ix.netcom.com> References: <5bg2e0$ar2@bignews.shef.ac.uk> <AF00F4DB-4F859@198.68.42.175> <32DBDD3C.1EBAB5AF@screaming.org> <5bh10q$c1s@bignews.shef.ac.uk> <rex-ya023080001501970056130001@nntp.ix.netcom.com> <5bj1nk$sab@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bj1nk$sab@news.xmission.com>, don@globalobjects.com wrote: )You can do this, but it's a sort of a hack. You set the *linewidth* )to your tolerance. The hit detection is done according to what PS )would have drawn, if it were drawing, so increasing the linewidth will )expand the hit "tolerance" a bit. Not obvious, but it works. :-) )Changing the line caps will affect the corners, too. Lotsa fun, eh? That's what I suspected, and it *is* a hack ;) Inefficient too, if there are a lot of thin objects to be checked. -Eric -- Excerpt from Marianne Moore's 'The Pangolin' This near artichoke with head and legs and grit-equipped gizzard, the night miniature artist engineer is, yes, Leonardo da Vinci's replica- impressive animal and toiler for whom we seldom hear.
From: rlarson@semlab5.sbs.sunysb.edu (Richard K. Larson) Newsgroups: comp.sys.next.programmer Subject: Porting from NS to Rhapsody Date: 7 Jan 1997 20:28:16 GMT Organization: State University of New York at Stony Brook Message-ID: <5aubl0$aql@abel.ic.sunysb.edu> I realize that a gazillion issues with NeXTSTEP/Rhapsody are up in the air at the moment, but is there any sense out there about how easy/difficult it is going to be to move existing NS applications to Rhapsody? For example, - if Apple changes from Mach 3.2 to Nukernel, will that entail significant reprogramming, - what about the QuickDraw/DisplayPS issue? - etc. I mostly interested in how the possible choices now facing Apple will impact on the issue of moving over. Obviously it won't be possible to say "it'll be easy" vs. "it'll be hard" at this stage. Thanks! -Richard Larson
From: sugee@imap2.asu.edu Newsgroups: comp.sys.next.programmer Subject: Cost of a NeXT Web Site? Date: 15 Jan 1997 22:58:37 GMT Organization: Arizona State University Message-ID: <5bjnet$b79@news.asu.edu> I doubt that many advocates and customers like Chylser, CyberSlice, Nissan, and etc. as the list goes on, will argue about the merits of using NeXT's Web technologies for deploying their Web sites. We have all heard plenty and are proud of what is being accomplished. However, what I haven't heard anything about, something which curiously dawned on me recently and after reviewing what some of these folks are doing, is the cost of implementing and deploying these Web Sites. Can anybody provide approximate costs or actual figures of sites like these? I do respect people's anonymity. Cheers, Sue
From: rex@mit.edu (Eric King) Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system Subject: Re: DPS Hit Detection Date: Wed, 15 Jan 1997 22:14:24 -0400 Organization: Netcom Message-ID: <rex-ya023080001501972214240001@nntp.ix.netcom.com> References: <5biv18$h7p@castor.cca.rockwell.com> <AF028AED-9B7E4@198.68.42.195> <5bjlj4$sab@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bjlj4$sab@news.xmission.com>, don@globalobjects.com wrote: )If you're going to dig that deep into the engine, you'll find that )DPS's binary object sequences are surprisingly similar. And this is )how most of the NEXTSTEP drawing occurs--it is a lot faster than you )would expect from an "interpreter" because most of the "interpreting" )was done by PSwrap at compile time and ends up being more of a jump )table. DPS is very, very well written, contrary to what you think. I don't think any of us GX proponents have ever questioned the quality of DPS' code. We're questioning the merits of using it as the one and only imaging and display system. For instance the fact that DPS uses a very fast byte-code evaluation system doesn't change the fact that the tight coupling between GX's object database and its rasterization components allows for some optimizations and operations that aren't achievable with the current DPS system. The fact that Adobe has repeatedly stated that its interpreted systems were inefficient and is actively developing new somewhat GX-like systems such as Bravo and Supra, makes me question whether or not DPS should be the foundation for the future of Mac imaging. The fact that Next made a usable DPS-based system doesn't mean that system couldn't be enhanced, nor does it mean that its the best system given today's technology. )_actual_ _implementation_ of this and IT WORKS! It is even reasonable )when running on a 33MHz 68040! As is GX. :) )By the way, I do hope Erik's work is someday available as a commercial )product. It is _way_ cool. It impresses me; GX does not. :-) )[That's not a flame at GX--it is nice for what it is, but Erik's )product--the part of it that runs on top of the GX-like code and could )probably be ported onto GX--is really, really nifty.] It certainly sounds intriguing :) Me, I'm looking forward to MovieClips Pro, the non-pro version right now gives you a very tantalizing taste of what kinds of real-time video effects are possible with GX's graphics engine. Has anyone tried making something that can transform and blend NextTime movies together in real-time? (That is on a Pentium or Pentium Pro, not on an ND board.) -Eric -- Excerpt from Marianne Moore's 'The Pangolin' This near artichoke with head and legs and grit-equipped gizzard, the night miniature artist engineer is, yes, Leonardo da Vinci's replica- impressive animal and toiler for whom we seldom hear.
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 01:37:59 GMT Organization: Indiana University, Bloomington Message-ID: <5bk0pn$f3i@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971753450001@199.166.204.230> NNTP-Posting-User: glhansen In article <maury-1501971753450001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> In any event, your entire argument here is weak and irrelevant. > > You're right of course, who would want something like standardization? > >> issue was whether Rhapsody should include Unix utilities. I argued >> that it should, because many developers of GUI applications could use >> them to save time. Your response is to assert that Unix utilities are >> "nonstandard". > > No, my argument is, and was sidestepped, that these functions are better >off provided vias modern interfaces rather than command line tools. > >> Rhapsody! Whatever Rhapsody includes is a de facto standard Rhapsody >> utility, and may be used in Rhapsody GUI apps. > > So they should get rid of the command line stuff then. If nothing else, you need the command line stuff to run scripts. That's reason enough for me to keep it in. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 17:42:04 -0500 Organization: Atria Software Message-ID: <maury-1501971742190001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> In article <5b7chs$bi3@ra.patnet.caltech.edu>, shimpei@ra.patnet.caltech.edu (Shimpei Yamashita) wrote: > Seeing the litany of bugs plaguing any new Apple technology (68K CFM? > Open Transport 1.0.x? PCI support in general?) Well aside from the problem with the CFM 68k, the other two seem to be doing very well indeed. > MacOS doesn't exactly > appear to be a treature trove of good code either (but of course we'll > never know for sure because we can't look at the source code). Yeah, but at least you get an _API_ rather then sending streams to a shell! > No one is asking you to use rm on the command line! If the rm thing is > the extent of your complaint about the Unix programs, I'd say you > haven't used them enough to really understand their value. Sigh. > I do know many Unices ship with some truly buggy programs built-in. > This is really a different issue from your beef about rm's user > interface; No, it's the same beef. It's time someone started making open OS's that DIDN'T use command lines and shell scripts to accomplish things. We've had GUI's for ten years now, isn't it time to stop calling utils with them? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 18:10:34 -0500 Organization: Atria Software Message-ID: <maury-1501971810510001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> In article <5b8scv$6ue@darla.visi.com>, dwy@ace.net (David Young) wrote: > : Yes, but the quality of these applications varies, some is passable, > : lots os terrible. rm doesn't even ask you to confirm, let alone allow you > : to rescue the items. It's not lazy coders that's the problem, it's the > : code that exists from years ago that is. > > Now demoing at MacWorld! It's the person without a clue whatsoever! > > Have you ever even *used* a UNIX shell prompt? It's clear that you don't > have any idea what you're talking about. Ummm, so you're saying that rm's default behaviour is to ask you to confirm? Or that all of this stuff is standardized? Or is ad hominem attacks just something you do for fun? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 18:11:24 -0500 Organization: Atria Software Message-ID: <maury-1501971811400001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Oooh, I bet the _Unix Hater's Handbook_ told you to say that. No actually, it's post right here in this conference that show examples. For instance... I've been tearing my hair out the last couple days dealing with HP-UX, Hewlett-Packard's version of Unix. They made a raft of gratitious filesystem changes that added NOTHING to the value of the OS, except to make it difficult to work with in a multivendor Unix environment. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 18:20:50 -0500 Organization: Atria Software Message-ID: <maury-1501971821060001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5be4ot$q7q@catapult.gatech.edu> In article <5be4ot$q7q@catapult.gatech.edu>, nobody@ictyl.gt.ed.net wrote: > A lot of what is in the mac toolbox from who knows when is not great code > ;) Exactly, isn't that why they're buying NeXT? To get rid of it? > Furthermore, all users can benefit for the same reason that even now Mac > programs are smaller than the same windows programs(though not as > dramaticly as before)-- common tasks are part of the system, so a program > can expect and call them there. This makes programs smaller, and also make > it faster to write programs because the wheel (or a search routine) need > not be reinvented. Code re-use is something all programmers should seek to > employ. I agree, so use the library system that makes OpenStep so great, and publish the interfaces. Why do all then Unix-hacks find this so terribly odd? I see comments about how great it is to have direct manipulation over objects in the same message with people lauding command line tools! > if the line "alias rm='rm -i'" And that fixes all the problem with the tool being unsafe in the first place. Sigh. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 18:22:07 -0500 Organization: Atria Software Message-ID: <maury-1501971822220001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <SHESS.97Jan13105442@howard.one.net> In article <SHESS.97Jan13105442@howard.one.net>, shess@one.net (Scott Hess) wrote: > To put another spin on it, if they did decide to rearrange everything > into a new "sensible" order, it would be Just Another Arbitrary > System, aka Windows NT. The _only_ positive thing Apple has with > OpenStep/Mach (nee NeXTSTEP) is to make it a better Unix. If they > turn it into "Just as good as Unix, but different", then there is no > reason to run NeXTSTEP over OpenStep/NT, and it's already clear that > most of the market doesn't buy OpenStep/NT over raw NT Or they can put both on the CD and allow the user to chose. We're not all running ISP's, and people running Photoshop could care less about needing /usr. Maury
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.misc Subject: Re: DPS Hit Detection Date: 15 Jan 1997 20:23:02 -0700 Organization: Primenet Services for the Internet Message-ID: <AF02F03F-657BA@198.68.42.167> References: <853351061.18559@dejanews.com> nntp://news.primenet.com/comp.sys.mac.programmer.misc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit marko@wgatg.com said: > >The missing piece of information though is that with NEXTSTEP/OpenStep, >we use nested NSView subclasses for drawing, and "hit detection" is >already provided for these - a view that is clicked receives a mouseDown: >message if it >wants. > >Furthermore, through a mechanism called the "responder chain," if a >nested View fails to acknowledge a hit, then its superview is given the >opportunity to acknowledge >it. > >There is no real work involved here - you just implement the method and >you'll receive notification of a hit within your bounds. If you need to >specialize the hit test however, you just override the mouseDown: method >and perform a geometric test, or as a fallback for complex shapes, use >the DPS hit test routines (which for us serve to complete the business of >hit detection, they aren't the sole source of hit detection >mechanism). This is standard framework stuff going back to the days of MacApp, if not to SmallTalk itself. This won't work well for things like a large collection of shapes embedded within shapes. Nor for tri-glyph Korean Hangul characters. --------------------------------------------------- "It doesn't take a rocket scientist to realize that Macs work better than PCs... But you'd be a fool not to follow their lead." -Sanjay S Vakil, graduate student, MIT Aeronautics and Astronautics Dept. -100% Mac ---------------------------------------------------
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: Cost of a NeXT Web Site? Date: 16 Jan 1997 03:57:51 GMT Organization: Digital Fix Development Message-ID: <5bk8vv$3im@news.digifix.com> References: <5bjnet$b79@news.asu.edu> In-Reply-To: <5bjnet$b79@news.asu.edu> On 01/15/97, sugee@imap2.asu.edu wrote: > >I doubt that many advocates and customers like Chylser, CyberSlice, >Nissan, and etc. as the list goes on, will argue about the merits of >using NeXT's Web technologies for deploying their Web sites. We have all >heard plenty and are proud of what is being accomplished. > >However, what I haven't heard anything about, something which curiously >dawned on me recently and after reviewing what some of these folks are >doing, is the cost of implementing and deploying these Web Sites. Can >anybody provide approximate costs or actual figures of sites like these? >I do respect people's anonymity. > Thats likely not something that you're going to have much luck finding out, the spectrum is pretty wide there. There are some WebObjects projects like Stepwise (a NEXTSTEP/OpenStep product registry) that are based on EOF and WOF and it took perhaps 20-40 hours to implement. (The back end OpenStep UI has probably taken about as long). Of course I've re-written it a number of times now so thats a rather poor example. I've written sample catalog applications in WebObjects in a matter of a weekend. However I know of _much_ larger scale projects that have been in development for 6-8 months with a pretty good team of people on it (4-6).. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 17:50:38 -0500 Organization: Atria Software Message-ID: <maury-1501971750540001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> In article <5b8scv$6ue@darla.visi.com>, dwy@ace.net (David Young) wrote: > I think developers shouldn't be given APIs or frameworks because this will > lead to dependence on them. Next thing you know they'll be wanting > compilers. Computers shouldn't have operating systems, because, let's face > it, what's in there isn't all that great code. You know, what is it about this thread that leads to such terrible, and in this case idiotic, reducto ad absurdum arguments from people that know better? Dave, I'm not asking for people to get rid of the *&(#&^*%$ utilties. I'm saying that they should be OOPS libs on the disk with published interfaces that you can call from within your programs regardless of version and do so without having to flatten your code to a byte stream! Like OpenStep. You've heard of that right? Let's take a page from you're books... Since CLI's run on all computer's, it's obvious that we should get rid of libraries of code altogether and make absolutely everything a shell command. It's obvious isn't it? windisp -c "MyWindow" < my_text.txt There, now we don't need those silly library things and we can just ask cshell to display our windows for us! Better yet, let's get rid of all those imcompatible and confusing programming languages, let's do EVERYTHING in the shell! Yeah, addition and division and everything! It'll work! > Have you ever even *used* a UNIX shell prompt? It's clear that you don't > have any idea what you're talking about. Oh, then would you like to point out this paradigm of superb programming you refer to but don't name? sendmail? ls? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 18:15:43 -0500 Organization: Atria Software Message-ID: <maury-1501971815580001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5bbtbb$b14@news.xmission.com> In article <5bbtbb$b14@news.xmission.com>, don@globalobjects.com wrote: > rm is a bad example. For what I was trying to illustrate, it's a great one. > Most ISPs I've seen have aliased "rm" so that > it does an "rm -i" which asks about every single file before removing > it...though admittedly, without that change, the default is to assume > that the user knows what they are doing. Of course the "-i" bugs me > because I _do_ know what I'm doing when I do an "rm". At least it is > there for those who don't know what they are doing. :-) Now do you see my point? All of these things in the "perfect" OS would be object libs on the drive. Your programs would send them messages with objects as parameters. Your CLI would do the opposite of what you have to do now, it would take flat bytes and turn them into objects to pass to these libs. Look, ignore Unix, just look at that last paragraph and tell me what exactly is so wrong for asking for the entire OS to work the same way, rather than some one way and others others? No, I _don't_ expect this to happen any time soon. Is that a reason to think it's a bad idea to try? > which this reliance perhaps needs some reexamination. But I'll be > damned if I'm going to try to rewrite awk or sed--or sendmail--so that > my apps can use them. Those already work, and I'd like to save some > time to get to the core of what I wish to produce. Yeah, but do you really like flattening out your objects so you can stream them? Maury
From: martin.boucher@cgocable.ca ($$$ EASY MONEY $$$) Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.transputer,comp.sys.unisys,comp.sys.xerox,comp.sys.zenith.z100,comp.terminals,comp.terminals.bitgraph Subject: $ Take 5 minutes to read this and it WILL change your life $ Date: 16 Jan 1997 05:33:52 GMT Organization: cgocable Distribution: inet Message-ID: <5bkek0$fah@nr1.ottawa.istar.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=ISO-8859-1 $$$$$$ $50.000 for the New Year $$$$$$ Take five minutes to read this and it WILL change your life. The internet has grown tremendously. It doubles in size every 4 months, think about it. You see those "Make Money Fast " posts more and more. That's ... because it WORKS! So I thought, all those new users might make it work. And I decided to try it out, a few months ago. Besides, whats $5.00, I spend more than in the morning on my way to work on coffee and cigs for the day. So I send in my money and posted. Everyone was calling it a scam, but there are SO many new users from AOL, Netcom, etc. they will join in and make it work for you. Well, two weeks later, I began recieving bucks in the mail! I couldn't believe it! Not just a little, I mean big bucks! At first only a few hundred dollars, then a week later, a couple of thousand, then BOOM. By the end of the fourth week, I had recieved nearly $47.000.00. It came from all over the world. And every bit of it perfectly legal and on the up and up. I've been able to pay off all my bills and still had enough left over for a nice vacation for me and my family. Not only does it work for me, it works for other folks as well. Markus Valppu says he made $57,883 in four weeks. Dave Manning claims he made $53,664 in the same amount of time. Dan Shepstone says it was only $17,000 for him. Do I know these folks? No, but when I read how they say they did it, it made sense to me. Enough sense that I'm taking a similar chance with $5 of my own bucks. Not a big chance, I admit, but one with incredible potential, because $5 is all anyone ever invests in this system. Period. That's all Markus, Dave, or Dan invested, yet their $5 netted them tens of thousands of dollars each, in a safe, legal, completely legitimate way. Here's how it works in 3 easy steps: STEP 1 Invest your $5 by writing your name and address on five seperate pieces of paper along with the words: "PLEASE ADD ME TO YOUR MAILING LIST." (In this way, you're not just sending a dollar to someone; you're paying for a legitimate service.) Fold a $1 bill inside each paper, and mail them by standard Mail to the following five addresses: 1- Stuart Koch Connolly Hall Box c115 501 E St-Joseph Rapide City, SD 57701-3995 2- Karen Lundgren 3889 Kencrest Ave. Halifax, NS Canada B3K 3L4 3- David Wilson 7967 Shoals Drive Apt C Orlando, FL 32817 USA 4- Sylvain Huot 157 Comeau Sept-Iles, Qc, CANADA G4R 1J6 5- Martin Boucher 690 Allard Sept-Iles, Qc, CANADA G4R 1S8 STEP 2 Now remove the top name from the list, and move the other names up. This way, # 5 becomes # 4 and so on. Put your name in as the fifth one on the list. STEP 3 Post the article to at least 250 newsgroups. There are at least 19000 newsgroups at any given moment in time. Try posting to as many newsgroups as you can. Remember the more groups you post to, the more people will see your article and send you cash! (There is always help available from you online service if you do not know how to post to newsgroups, but it's pretty simple... once you modify your letter...250 newsgroups shouldn't take more than 30 to 60 minutes... Then just sit back and wait. STEP 4 You are now in business for yourself, and should start seeing returns within 7 to 14 days! Remember, the Internet is new and huge. There is no way you can lose. Now here is how and why this system works: Out of every block of 250 posts I made, I got back 5 responses. Yes, thats right only 5. You make $5,00 in cash, not checks or money orders, but real cash with your name at #5. Each additional person who sent you $1.00 now also makes 250 additional postings with your name at # 4, 1000 postings. On average then, 50 people will send you $1.00 with your name at # 4 ....$50,00 in your pocket! Now these 50 new people will make 250 postings each with your name at # 3 or 10,000 postings. Average return, 500 people = $500 They make 250 postings each with your name at # 2 = 100,000 postings = 5000 returns at $1.00 each=$5,000.00 in cash! Finally, 5,000 people make 250 postings each with your name at # 1 and you get a return of 60,000 before your name drops off the list. And that's only if everyone down the line makes only 250 postings each! Your total income for this one cycle is $55,000. From time to time when you see your name is no longer on the list you take the latest posting you can find and start all over again. The end result depends on you. You must follow through and repost this article everywhere you can think of. The more postings you make, the more cash ends up in your mailbox. It's too easy and too cheap to pass up!! So thats it. Pretty simple sounding stuff, huh? But believe me, it works! There are millions of people surfing the net every day, all day, all over the world. And 100,000 new people get on the net every day. You know that, you've seen the stories in the paper. So, my friend, read and follow the simple instructions and play fair. Thats the key, and thats all there is to it. Print this out right now so you can refer back to this article easily. Try to keep an eye on all the postings you made to make sure everyone is playing fairly. You know where your name sould be. If you're really not sure or still think this can't be for real, then don't do it. But please print this article and pass it along to someone you know who really needs the bucks, and see what happens. REMEMBER...HONESTY IS THE BEST POLICY. YOU DON'T NEED TO CHEAT THE BASIC IDEA TO MAKE THE BUCKS! GOOD LUCK TO ALL, AND PLEASE PLAY FAIR AND YOU WILL WIN AND MAKE SOME REAL INSTANT FREE CASH! *** By the way, if you try to deceive people by posting the messages with your name in the list and not sending th bucks to the people already included, you will not get much. I know someone who did this and only got about $150 (and that's after two months). Then he sent the 5 bills, people added him to their lists and in 4-5 weeks he had over $10.000! TRY IT AND YOU'LL BE HAPPY!!!! :))))
Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.transputer,comp.sys.unisys,comp.sys.xerox,comp.sys.zenith.z100,comp.terminals,comp.terminals.bitgraph,control From: news@news.msfc.nasa.gov Message-ID: <cancel.5bkek0$fah@nr1.ottawa.istar.net> Control: cancel <5bkek0$fah@nr1.ottawa.istar.net> Subject: cmsg cancel <5bkek0$fah@nr1.ottawa.istar.net> no reply ignore Organization: Semi-Automatic Chain Letter Remover Date: Thu, 16 Jan 1997 05:36:48 GMT Sender: martin.boucher@cgocable.ca ($$$ EASY MONEY $$$) ignore Make Money Fast post canceled by news@news.msfc.nasa.gov. Make Money Fast has been posted thousands of times, enough to qualify as cancel-on-sight spam. The chain letter scheme it describes is illegal in many countries. For example, see: http://www.usps.gov/websites/depart/inspect/chainlet.htm J. Porter Clark, d/b/a The Unknown News Administrator
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 14 Jan 1997 22:48:33 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R1401972248330001@news.erols.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au> <5bbuae$b14@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bbuae$b14@news.xmission.com>, don@globalobjects.com wrote: >The paths in the application search path are, by default: > >~/Apps >/LocalApps >/NextApps >/NextAdmin >/NextDeveloper/Apps >/NextDeveloper/Demos > >And all the subdirectories in those listed above. > >> So does this >> mean that the OS will not be able to find apps which aren't in >> any of the directories listed in $PATH? > >Right. You can run the app, but not launch it by double clicking >one of its data files. > Well how about this. Perhaps a method could be devised so that when you move an application the database of locations is updated when the move occurs? I know nothing of the internal operation of OpenStep but it seems like an easy thing to implement. -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:18:35 GMT Organization: ace dot net internet technologies Message-ID: <5bkh7r$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : Dave, I'm not asking for people to get rid of the *&(#&^*%$ utilties. : I'm saying that they should be OOPS libs on the disk with published : interfaces that you can call from within your programs regardless of : version and do so without having to flatten your code to a byte stream! Originally you were. When I had posted my reply, you were being utterly clueless and going on about the evils of cp, ls and rm and how horrible rm was because it didn't ask for confirmation (which, it does with the -i switch). Byte streams work well for some things. Objects work well for some things. You're not required to do system("mv foo bar"), you can use system calls, file system objects, whatever. Programmer's choice, which is really the important issue. : Since CLI's run on all computer's, it's obvious that we should get rid : of libraries of code altogether and make absolutely everything a shell : command. It's obvious isn't it? Are you trying to match my sarcastic wit? :) : There, now we don't need those silly library things and we can just ask : cshell to display our windows for us! Better yet, let's get rid of all : those imcompatible and confusing programming languages, let's do : EVERYTHING in the shell! Yeah, addition and division and everything! : It'll work! You're not following what I'm saying. There's nothing wrong with objects (in fact, I love objects. I live and die for objects.), but in many cases it makes more sense to use the shell. mv, rm, ls are bad examples. awk, sed, cut, sort, and uniq are better examples. They're designed for bytestream manipulation, which is something that is pretty common in most programs. Certain things don't always model well as objects; very complex pattern matching comes to mind. : Oh, then would you like to point out this paradigm of superb programming : you refer to but don't name? sendmail? ls? BTW, I don't know what paradigm you're inferring from my earlier posts. Do you think I'm somehow against OOP? What's wrong with ls? You prefer, say, dir /w? I doubt that a program would ever invoke ls and parse the output; it'd be more work than opendir(). Sendmail, despite its flaws, is incredibly powerful, btw. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:22:53 GMT Organization: ace dot net internet technologies Message-ID: <5bkhft$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971753450001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : No, my argument is, and was sidestepped, that these functions are better : off provided vias modern interfaces rather than command line tools. You're wrong. It'd be better as both. Else, you could argue that providing System 7 compatibilty is a waste, which is something I'm sure I'd be more likely to accept than you. The breadth of functionality that is covered in the UNIX utility suite is pretty big. Re-implementing perfectly clean interfaces like popen ("/usr/lib/sendmail -f maury@softarc.com dwy@ace.net") is time better spent on pushing forward. It's not like we're dealing with DOS here. : So they should get rid of the command line stuff then. Didn't you just suggest the exact opposite in the last post I replied to? -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:29:19 GMT Organization: ace dot net internet technologies Message-ID: <5bkhrv$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971810510001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : > : Yes, but the quality of these applications varies, some is passable, : > : lots os terrible. rm doesn't even ask you to confirm, let alone allow you : > : to rescue the items. It's not lazy coders that's the problem, it's the : > : code that exists from years ago that is. Take note, you are faulting "rm" itself, which I will respond to below. : Ummm, so you're saying that rm's default behaviour is to ask you to : confirm? Or that all of this stuff is standardized? Or is ad hominem : attacks just something you do for fun? There are more issues at work than just rm, and if you had an understanding of UNIX, you'd know that. The site's administrator might choose to put 'alias rm "rm -i"' in /etc/tcshrc, in which case prompting would be the "default" behavior for that site. Or, maybe he thought he was clever and put 'alias rm "mv $* ~/.Trash"' and added "rm -rf ~/.Trash" in /etc/logout. Woo woo, there's all the functionality you were just whining about in two lines of shell aliases that'll work across the board on all unices with tcsh. There are really three levels of "default" behavior here: the factory rm, without aliases; the site-wide shell alias (if any) for rm, and the per-user alias (if any) for rm. The idea of "default" kind of loses its meaning in this context, wouldn't you say? rm does one thing, and one thing only: delete stuff. Anything else gets added someplace else, in the shell, or where ever. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 10:06:43 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bkujj$rm5@duke.squonk.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au> <5bbuae$b14@news.xmission.com> <scottm-ya02408000R1401972248330001@news.erols.com> scottm@nic.com (Scott Maxwell) wrote: > Well how about this. Perhaps a method could be devised so that > when you move an application the database of locations is updated > when the move occurs? I know nothing of the internal operation > of OpenStep but it seems like an easy thing to implement. One difference between the MacOS and NeXTSTEP is that the MacOS is really conceived of and envisioned as a personal computer. One computer, which has one owner. NeXTSTEP is designed for multiple users. In the world of multiple users, I'm not so sure that the above is a good idea. It is probably doable, but I think it'd be more confusing than helpful. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan16.103207.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> Date: Thu, 16 Jan 1997 15:32:07 GMT In article <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) writes: > MI is extremely useful as both a design tool and a modification tool if > used properly. Like any other tool you can also misuse it in ways that > get you into deep yogurt. In the design case, it allows you to partition > and encapsulate various independently-useful orthogonal functionalities so > that they can be combined at will (mixins) without each feature tripping > over the others. > > In the case of modifications, it allows addition of features without > messing up the original classes. For example, you buy (or obtain by hook > or by crook) a library of objects that you really don't want to modify, > but now you want to subclass and implement streams or something that was > not included in that object library. It's easy to do with MI. Without > it, you're hosed, or you at least have a lot more work than you had > planned. That ending seems to be a rather broad claim: > It's easy to do with MI. Without > it, you're hosed, or you at least have a lot more work than you had > planned. If one wants to add "mixins" in Ada95 one uses generics, and I have not seem any claim that generics are in any way more difficult for mixins. They certainly remove a lot of the risk associated with multiple inheritance, since there is ambiguity regarding common ancestors differently overridden, etc. Larry Kilgallen
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.next.programmer Subject: How to get started Date: Thu, 16 Jan 1997 08:14:56 -0800 Organization: Bridge Family Message-ID: <abridge-1601970814560001@dcn134.dcn.davis.ca.us> I'm looking at what it will take to get started writing NeXT software. The price of admission, I have to admit, seems awfully high. Am I missing something? And are there recommendations as to platform (since I'm going to have to build a machine to run it). Thanks, Adam Bridge
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 16:29:09 GMT Organization: Netcom Distribution: world Message-ID: <5bll0l$me7@dfw-ixnews2.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > It's time someone started making open OS's that > DIDN'T use command lines and shell scripts to accomplish things. We've > had GUI's for ten years now, isn't it time to stop calling utils with > them? Why? Various scripting languages are all the rage now. JavaScript, WebScript, VBScript, etc. plus what proponents sell as advanced 4th-generation languages (4GLs) which are usually interpreted. The Unix Bourne shell language is similar. Scripting languages are a powerful alternative to GUI interfaces which can be very cumbersome in many cases. Providing both just creates a richer environment as long as users aren't *required* to use a CLI. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Mark_Bessey@next.com (Mark Bessey) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 16 Jan 1997 16:27:01 GMT Organization: NeXT Software, Inc. Distribution: world Message-ID: <5blksl$ruc@news.next.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> G. Gordon Apple, PhD writes > MI is extremely useful as both a design tool and a modification > tool if used properly. Like any other tool you can also misuse it in > ways that get you into deep yogurt. In the design case, it allows you > to partition and encapsulate various independently-useful orthogonal > functionalities so that they can be combined at will (mixins) without > each feature tripping over the others. The mix-in model of OOP isn't supported very well by Objective-C. You can often achieve much the same results by using delegation and forwarding to create "composite" objects. > In the case of modifications, it allows addition of features > without messing up the original classes. For example, you buy (or > obtain by hook or by crook) a library of objects that you really don't > want to modify, but now you want to subclass and implement streams or > something that was not included in that object library. It's easy to > do with MI. Without it, you're hosed, or you at least have a lot more > work than you had planned. This is exactly what Objective-C protocols are for. They allow you to add methods to any existing class. This can even be done for classes that you don't have the source code to - can C++ do that? There are surely some features of C++ that would be nice to have in Objective-C (stack-allocated objects and operator overloading, for instance), but Multiple Inheritance a feature I often wish I had. -Mark -- Mark Bessey NeXT Software, Inc Software Quality Assurance -->I DON'T SPEAK FOR NeXT <--
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.oop.macapp3 Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 16 Jan 97 10:48:07 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan16104807@howard.one.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> In-reply-to: Charles W Swiger's message of Tue, 14 Jan 1997 21:59:22 -0500 In article <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> writes: As for the size and performance of Obj-C based applications, I would suggest trying it before worrying about problems that most people don't encounter. C++ advocates always seem to imply there is a big tradeoff here, but I cannot recall ever seeing a NEXTSTEP developer (someone who has actually released commercial software) state that the size and performance of Obj-C was a significant problem. Fact of the matter is, most NeXTSTEP apps which are slow are slow because the developer didn't spend enough time looking at what the app is doing. If your app is drawing the same scene multiple times without changing it, then even if your language gives you 100% of the hardware's capability, it could be slower than an interpretted language which only draws the scene _once_. A long-term project I'm involved with is essentially a word processor with the capability of substantially rewriting the text based on answers users give to questions. The engine is written entirely in Objective-C. Every six to nine months, we manage to double or triple the speed of certain paths through the engine, without disrupting the UI (or application model) much at all, all while we continue to add new features to it. There's no reason we couldn't translate the engine into C++, gaining a "free" 10% in performance. OTOH, that would probably expand our six to nine month performance improvement schedule out to 12 to 16 months. That's an expensive price to pay for a 10% performance gain! As with anything else, algorithmic optimizations pay off much better than micro optimizations. If I thought we _really_ had anything to gain by going to C++ for our engine, we'd be there already. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 09:29:56 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5bloik$aqu@crl.crl.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> In article <maury-1501971811400001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> Oooh, I bet the _Unix Hater's Handbook_ told you to say that. > > No actually, it's post right here in this conference that show >examples. For instance... > >I've been tearing my hair out the last couple days dealing with >HP-UX, Hewlett-Packard's version of Unix. They made a raft of >gratitious filesystem changes that added NOTHING to the value >Unix environment. 1. I said that. 2. It was said in the context of someone's proposal to make Apple's proposed Unix system "better" by renaming things like /usr. 3. I think all the unix utilities oughta be in there, in their full glory and grime. 4. Unix may suck--all OSes do--but making a bunch of gratitous changes that would make Apple's Unix layer different from every other Unix would suck even more. Casual, everyday users should never see Unix. Power users and developers are perfectly capable of dealing with the quirks of Unix, and removing or bastardizing Unix would be a tragedy of the first order, as well as a dumb business move. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 18:01:27 GMT Organization: Airwindows Message-ID: <jinx6568-1601971303370001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> In article <mckinnon-1001970053450001@mckinnon.tezcat.com>, mckinnon@tezcat.com (Chuck McKinnon) wrote: > Well if .apps all have to go into a certian location for the OS to work, > why not make the "Applications" folder act like the System folder. > Currently, the Applications folder is a normal folder with a special > icon, and the system will recognize it as such; also the Finder allows > for protection of this folder. What folder? This is something that came with my Mac I suppose, like the short-lived Documents folder? > Just go the next step (pun intended) and make the Applications folder > the required place for .apps and make the system treat it as such. This > would make even more sense for new/consumer user: it makes sense. > All apps go in the Applications folder, [duh!] and the new system will > get what it need. > Or is this too simple? Way too simple for me, I'm afraid, I would find that disgustingly restrictive. The notion of an 'Applications', 'Documents' etc folder, is horribly Win-like, not something I could deal with. My root folders are along the lines of 'video', 'writing' etc, not categories that are frankly only useful to the computer itself. "Applications"? What good does that do me? Useless. Jinx_tigr (aka Chris Johnson)
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 18:28:40 GMT Organization: Airwindows Message-ID: <jinx6568-1601971330530001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b44cf$s7g@bignews.shef.ac.uk> <jbf-ya023580001001970120370001@news.tiac.net> In article <jbf-ya023580001001970120370001@news.tiac.net>, jbf@frazer.com (James B. Frazer) wrote: > > The whole of NEXTSTEP, absolute minimum installation, takes up less than > > 100MB I believe. I don't know just how much MacOS uses, but if you added > > enough extras to give you the same functionality (i.e. you'd have to add > > internet connectivity, a number of applications for system administration > > etc), I wonder if you'd be in the same ballpark? > My system partition, with the 7.5.5 OS and a minimal set of Unixy utilities, > runs to 90MB. Now that's somewhat inflated by my PowerPC architecture; perhaps > the equivalent would be 60-70 MB on a 680x0. That's close enough so that Mac > fans shouldn't fret. And, believe me, those Unix utilities replace a great > many small Mac applications. 40.1 MB here on 68K 7.5.5. This is not including GX, no speech extensions, no Applescript or Apple Guide extensions (I do trim my system to be more compact). But it does include CD-Rom, open transport, PPP etc etc etc, the Netscape 3.01 Java libraries and cache (currently at 5M and full) as well as Kaleidoscope and support files, and a limited amount of Clarisworks support files, and of course the Eudora support folder *think* what else? Anyway, that's 40.1 megs in total. In a lot of ways I'd like to see the end of the extensions and system folders. One reason is that if I am going to use something like Kaleidoscope I want to _replace_ the relevant code and discard the previous code, rather than patching it in. I also don't particularly like needing to have app stuff in my system folder. Though it's sobering that even with Netscape and Eudora and Clarisworks I'm at 40M. How is it that it can require 100M? Jinx_tigr (aka Chris Johnson)
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software Subject: Re: killer apps for Apple/NeXT Date: 16 Jan 1997 01:31:25 GMT Organization: Rockwell Avionics - Collins Message-ID: <5bk0dd$jnq@castor.cca.rockwell.com> References: <32DD473F.334E@worldnet.att.net> Cc: ziziz@worldnet.att.net In <32DD473F.334E@worldnet.att.net> zizi zhao wrote: > Dean Hall is looking for killer apps for Apple/NeXT OS. He says: > "So far > most of the stories have been about > Apple , I would really like to know > about how the deal affects NeXT > developers. Does anyone have a > killer app in the works? What about > game developers? " > in his webpage http://members.tripod.com/~dehall/nextstep.html One of the companies I contract for may just have the "killer app". Imagine building first class OpenStep objects (especially highly graphical animating ones) with no code at all. This thing could put Visual Basic out of the picture and or be a great way to build Visual Basic component ware. My company is in fact working on a high end game using all of the latest greatest NeXT technology. Sorry I can not give details. P.S. Renderman was already available for Mac
From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Installing software, was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 13:20:15 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <Qmrb5T600iWp05gzo0@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.e <scottm-ya02408000R1401972248330001@news.erols.com> <AmrGwKS00iV9E5mDUv@andrew.cmu.edu> <scottm-ya02408000R1601970249580001@news.erols.com> In-Reply-To: <scottm-ya02408000R1601970249580001@news.erols.com> Excerpts from netnews.comp.sys.next.advocacy: 16-Jan-97 Re: MacWorld Exclusive: App.. by Scott Maxwell@nic.com >> Right now, NEXTSTEP has conventions for the filesystem locations for >> applications and other components which are supposed to be available to >> everyone on the system. [ ... ] > > This is true. I'm not debating that. But, there are quite a few single > users (not multi-user) who might find it strange not to be able to put > things where they want them. I didn't say it was a good or bad thing. It's > just the way a lot of people are used to doing things. What you've said is clearly true. I suspect that for many people it simply won't be a problem. So let's consider an example of how a typical software installation works under NS, and see whether there is anything that you feel might be a problem. Let's say you're browsing some NS sites on the web, and see some software that you want to get-- a new demo, or an updated version, or whatever. You click on the URL, and your web browser happily goes and downloads the file. Let's say this was some shrinkwrapped software which was built into an Installer.app package [.pkg], and is archived to the FTP or web site probably in .compressed or .tar.gz format (1). When the download is done, your web browser will automatically invoke Opener.app to extract the package, and Opener.app will in turn automatically invoke Installer.app. Installer.app has a really nice and simple interface; all you have to do is click the "Install" button, and Installer may ask you where the files should go if you don't choose to accept the default location that the authors of the package recommend. You can also do such things as select which languages and which architectures (if you've got a FAT binary). But unless you tell it differently, software installed via this mechanism will be put in a sensible place. That's all, folks-- one click in the web browser, one click for Installer.app. Oh, in some cases you might have to hit return once or twice to confirm where to put the software and which languages/architectures to install. If you have a reason to install the software somewhere else than the default, no problem. If you do that and still want to have the system recognize the document types associated with that software, you can make a link. So I am of the opinion that the conventions in use for where things 'should' go will be something that most Mac people will like if they ever think about it at all. [ This is assuming that Apple doesn't change any of this, which they presumably would if Apple thinks that their user base is going to have problems. ] One more thing-- uninstalling software is just as easy. Whenever you install a package, Installer saves a record of the files installed and how to uninstall them in /NextLibrary/Receipts/. Just double-click on the .pkg file for whatever it is to run Installer, and then click "Uninstall". -Chuck ----------------- (1) NeXT's .compressed is another name for .tar.Z, and is used by the WorkSpace which lets you compress, decompress, and inspect .compressed files. Opener.app is an awesome utility that understands pretty much every major archive format used: *.Z,tar,shar,lzh,lha unix compressed files *.z,gz GNU gzipped files *.taz,tgz msdos .tar.Z, .tar.gz *.uu uuencoded file *.hqx,bin,sit,cpt macintosh archives *.arc,zip,zoo msdos arc archives *.PS (Preview misses cap .PS) *.arj msdos arj archives (extraction only) *.compressed NeXT compressed files Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 15:44:43 -0500 Organization: Atria Software Message-ID: <maury-1601971544430001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> <5bkh7r$big@darla.visi.com> In article <5bkh7r$big@darla.visi.com>, dwy@ace.net (David Young) wrote: > Originally you were. No I wasn't. > When I had posted my reply, you were being > utterly clueless and going on about the evils of cp cp? I don't think it's been mentioned once in this thread before. > horrible rm was because it didn't ask for confirmation (which, it does > with the -i switch). Yeah, the non-default action is the dangerous one. That's great interface design for you. +--------------------------+ | | | Are you sure you want | | to explode your car? | | | | +------+ | | | OK | | | +------+ | +--------------------------+ > Are you trying to match my sarcastic wit? :) Couldn't touch it. > You're not following what I'm saying. There's nothing wrong with objects > (in fact, I love objects. I live and die for objects.) And you're not following what _I'm_ saying. There's nothing wrong with CLI's, in fact I love CLI's. (although I don't die for them, only pizza and beer). > it makes more sense to use the shell. mv, rm, ls are bad examples. > awk, sed, cut, sort, and uniq are better examples. They're designed for > bytestream manipulation, which is something that is pretty common in most > programs. Certain things don't always model well as objects; very complex > pattern matching comes to mind. myString.findPattern("why the heck isn't rm -i the *&^$&%^ default"); > BTW, I don't know what paradigm you're inferring from my earlier posts. > Do you think I'm somehow against OOP? No, do you really think I'm against all CLI's. Heck, I think VMS rocks. > What's wrong with ls? You prefer, say, dir /w? Sure, whatever, as long as that's the same API that programs use. > would ever invoke ls and parse the output; it'd be more work than > opendir(). AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!! (head explodes) WHAT THE HECK DO YOU THINK I'VE BEEN SAYING FOR THE LAST WEEK?!?!?! I need more beer. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 15:49:25 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-1601971549250001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> In article <5bll0l$me7@dfw-ixnews2.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > Why? Various scripting languages are all the rage now. JavaScript, > WebScript, VBScript, etc. plus what proponents sell as advanced > 4th-generation languages (4GLs) which are usually interpreted. The Unix Read it carefully, I was taling about calling these things from the command line, not the command line itself or using it as a person. IE, programs should not have to call things by "pretending" to typing in CLI commands. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 15:46:25 -0500 Organization: Atria Software Message-ID: <maury-1601971546250001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971810510001@199.166.204.230> <5bkhrv$big@darla.visi.com> In article <5bkhrv$big@darla.visi.com>, dwy@ace.net (David Young) wrote: > There are more issues at work than just rm, and if you had an understanding > of UNIX, you'd know that. The site's administrator might choose to put > 'alias rm "rm -i"' in /etc/tcshrc, in which case prompting would be the > "default" behavior for that site. Or, maybe he thought he was clever and > put 'alias rm "mv $* ~/.Trash"' and added "rm -rf ~/.Trash" in /etc/logout. > Woo woo, there's all the functionality you were just whining about in two > lines of shell aliases that'll work across the board on all unices with tcsh. Dave, if you think that patching the problem is as good as good design in the first place, I have a Pinto to sell you. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 15:47:40 -0500 Organization: Atria Software Message-ID: <maury-1601971547400001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5bbtbb$b14@news.xmission.com> <maury-1501971815580001@199.166.204.230> <5bkkst$sab@news.xmission.com> In article <5bkkst$sab@news.xmission.com>, don@globalobjects.com wrote: > I understand what you want. In general, I like the idea too. > I don't see it feasible to do given what Apple has to work with > and where they need to get to, given the time frame they are > forced to deal with. Yeah, but we can dream, right? Maury
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.sysadmin,comp.sys.next.programmer,comp.sys.next.software Subject: vgrind help? Date: 16 Jan 1997 18:52:36 GMT Organization: The Ohio State University Message-ID: <5bltdk$ioq@charm.magnus.acs.ohio-state.edu> When I try to use vgrind, I get the following: # vgrind area.cc pscat: trouble reading .ct file lpr: stdin: empty input file # What do I need to do to so that vgrind works? Thanks. Randy -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 18:50:39 GMT Organization: Airwindows Message-ID: <jinx6568-1601971352540001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> In article <5b6dih$9bm@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > One thing I'm pretty sure of is that the applications like tar, emacs, > and especially cc, will not be present. This new OS will not survive > without developer support, and I mean support by current Mac developers, > not NeXT developers. Apple can't afford to upset its developers by > giving away things that will in any way make users reluctant to buy new > software. I can't imagine any Mac user forgoing DropStuff or Stuffit Expander for tar... or _anything_ for emacs (don't know what cc is, could somebody describe?) This isn't something for Mac developers to worry about. :) Jinx_tigr (aka Chris Johnson)
Date: Thu, 16 Jan 1997 16:18:48 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Distribution: world Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <milkweed-1601971618480001@port10.chester.smallmedia.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> Organization: Milkweed Software In article <5blksl$ruc@news.next.com>, MaRK_BeSSeY@NeXT.CoM wrote: > This is exactly what Objective-C protocols are for. They allow you to > add methods to any existing class. This can even be done for classes > that you don't have the source code to - can C++ do that? > > There are surely some features of C++ that would be nice to have in > Objective-C (stack-allocated objects and operator overloading, for > instance), but Multiple Inheritance a feature I often wish I had. I don't understand how this works. May one create a behavior just once, as protocols, mix them into various objects, go back and change the behavior, and have this change effect all classes to which the protocols have been added? May the classes to which you have added a set of protocols be passed to methods that take as an argument any classes containing that particular set of protocals? If not yes to all the above then there is really no equivalence to multiple inheritence. As for the ability to add methods to existing classes, that is a traditional feature of a subclass. What advantage do protocols add? The class with added protocols is no different than a subclass in any sense I can determine (unless perhaps it does not add an entire leaf to the virtual tables). Anders. p.s. I'm active in this thread because I really want to see why all the excitment about Obj-C. I don't mean to be a spoiler. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 16 Jan 1997 21:17:26 GMT Organization: Rockwell Avionics - Collins Distribution: world Message-ID: <5bm5t6$qji@castor.cca.rockwell.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> Cc: ga@ed4u.com In <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> G. Gordon Apple, PhD wrote: > In article <tbrown-ya023580001401970003470001@news.netset.com>, > tbrown@netset.com (Ted Brown) wrote> > MI is extremely useful as both a design tool and a modification tool if > used properly. Like any other tool you can also misuse it in ways that > get you into deep yogurt. In the design case, it allows you to partition > and encapsulate various independently-useful orthogonal functionalities so > that they can be combined at will (mixins) without each feature tripping > over the others. > > In the case of modifications, it allows addition of features without > messing up the original classes. For example, you buy (or obtain by hook > or by crook) a library of objects that you really don't want to modify, > but now you want to subclass and implement streams or something that was > not included in that object library. It's easy to do with MI. Without > it, you're hosed, or you at least have a lot more work than you had > planned. > Suppose you have a library of objects from a third party. The library contains a base class called Base. Now suppose the library contains many subclasses derived from Base. You do not have source code to the library. Now suppose you would like to add some capability to all of the subclasses of Base. Lets say you want to be able to serialize objects derived from Base along with objects from other libraries. You could create a subclass of every object that you may want to serialize and mix in a serializer class that implements the virtual void BaseDerived::serialize(MyStream &aStream) member function. Unfortunatly, one of the classes in the library contains the following code: myInstanceVariable = new BaseDerived; There is no way to get the library code to call new MySerializingBaseDerived instead. Since myInstanceVariable is not one of the subclasses that implements the serialize(MyStream &aStream) member function via mixin, there is no way to serialize the variable even from code in your subclass. IN CONTRAST OBJC ALLOWS THE FOLLOWING: @interface Base (MySerializeCatagory) - (void)serialize:(MyStream *aStream); @end Now every instance of Base and all of its sub-classes implement the -serialize: method. The code inside the library that executes the following line now works correctly! myInstanceVariable = [[BaseDerived alloc] init]; // This code will correctly allocates an object // that implements the -serialize: method even // without being recompiled!!!
Newsgroups: comp.lang.tcl,comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.next.programmer From: Fabien_Roy@free.fdn.org Subject: Re: Help!!! Tcl7.6/Tk4.2 compile errors on Openstep4.0 black (LONG) Message-ID: <E44E15.86p@free.fdn.fr> Sender: news@free.fdn.fr Organization: Fabien Roy Consultant. References: <32dd6305.171085267@ceco> Date: Thu, 16 Jan 1997 21:22:17 GMT In article <32dd6305.171085267@ceco>, you wrote: > Hi Tcl/Tk & Next community! > > Subject says it all. I am encountering compile errors while trying to > install Tcl7.6 on a NextStation (32Mb) Mono running Openstep 4.0 > developer. > > Here is the output... > [....] > tclUnixFCmd.c: In function `TclpCreateDirectory': > tclUnixFCmd.c:430: `S_IRUSR' undeclared (first use this function) > tclUnixFCmd.c:430: (Each undeclared identifier is reported only once > tclUnixFCmd.c:430: for each function it appears in.) > tclUnixFCmd.c:430: `S_IWUSR' undeclared (first use this function) > tclUnixFCmd.c:430: `S_IXUSR' undeclared (first use this function) > tclUnixFCmd.c: In function `CopyFileAtts': > tclUnixFCmd.c:826: storage size of `tval' isn't known > tclUnixFCmd.c:829: `S_IRWXU' undeclared (first use this function) > tclUnixFCmd.c:829: `S_IRWXG' undeclared (first use this function) > tclUnixFCmd.c:829: `S_IRWXO' undeclared (first use this function) > *** Exit 1 > Stop. Make sure you have the included header <bsd/sys/stat.h> tclUnixFCmd.c #include <bsd/sys/stat.h> > > > Help me please. I am a lowly sysadmin trying to write scripts in > Tcl/Tk, expect, and Perl. All of these have compiled fine at work > under NT3.51 and Solaris2.x (sparc). I'd really like to get to use > this lovely unix environment at home. > > TIA > > eric chu > echu@bpo-ess.ceco.com Hope that helps. Fabien --- Fabien Roy --------------------------------------------------------------------- Fabien_Roy@free.fdn.org (NextMail/MIME accepted) Fabien Roy Consultant NEXTSTEP/OPENSTEP/EOF Consultant, SYBASE DBA 10 rue de la DEFENSE 93100 MONTREUIL, France Tel: 33 (0)1 45 28 32 23 Fax: 33 (0)1 48 55 09 90 GSM: 33 (0)6 60 46 36 83
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Thu, 16 Jan 1997 15:59:11 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-1601971559110001@199.166.204.230> References: <maury-1401971143490001@199.166.204.230> <5bgrus$nkc$1@brachio.zrz.TU-Berlin.DE> In article <5bgrus$nkc$1@brachio.zrz.TU-Berlin.DE>, marcel@sysyem.de wrote: > > I'm curious, why the NSxxx class names? I know the historical > context, > > but is this important today? Seems somewhat unpleasing to the eye. > > Really just a convention so different class libraries can be intermixed > without having to extend the language. ...and... > To avoid namespace collisions, it is typical for each vendor of objects ...and... > Actually, I think its better. The reason being as > long as you keep your own objects out of the NSxxx namespace, > you will not find yourself being stomped on. ...and... > It's important because those are the class names specified in the OPENSTEP I think I get it. It has something to to with the parameter order, right? :-) Maury
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 17:27:45 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DEAB61.6FD9@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <jinx6568-1601971411390001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Johnson wrote: > Garance confirmed these observations, with the added detail that the > GNU implementations were less prone to being dumb hacks... > > Thus, I am less interested in finding out how you feel about it as I am > in asking Garance whether the standard NeXT stuff bears more resemblance > to the GNU stuff than the dumb hacks. I suspect it must resemble the GNU > or the unix-savvy NeXTians would be less confident. So, Garance, is it so? It depends. They've added more gnu versions over the years, but there are lots of non-GNU programs in there. For some programs, it really doesn't make much sense to make changes. They're tolerable. In other cases, there are definite improvements that can be made. For instance, tar, lex, yacc have GNU versions (gnutar, flex, bison). These are complex enough that there are real benefits to reengineering them. -- Jonathan W. Hendry jon @ exnext . com
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Date: Thu, 16 Jan 1997 16:31:07 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DE9E1B.6067@exnext.com> References: <petrichE3Ct2r.3AJ@netcom.com> <marke-0201970007270001@port55.annex5.nwlink.com> <AEF16B02-AD9E5@198.68.42.189> <5ahf5n$pq2@bignews.shef.ac.uk> <5ajg47$soi@bignews.shef.ac.uk> <1997010514570823842@p026.gor.euronet.nl> <5ap7db$mnu@nyheter.chalmers.se> <5argj1$84s@majipoor.cygnus.com> <5auv1t$h2c@nyheter.chalmers.se> <5b0vqa$k9@majipoor.cygnus.com> <maury-0801971738540001@199.166.204.230> <5b1bq7$48e@news.xmission.com> <maury-0901971304410001@199.166.204.230> <5b5vme$s70@news.xmission.com> <maury <maury-1401971527570001@199.166.204.230> <0mrHfT600iV945m0Ei@andrew.cmu.edu> <maury-1601971527030001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <0mrHfT600iV945m0Ei@andrew.cmu.edu>, Charles W Swiger > <cs4w+@andrew.cmu.edu> wrote: > > > multiple sections supported by Mach-O are a straightforward extension of > > the venerable a.out format, which had precisely three sections: TEXT, > > DATA, and BSS. > > Ahhhhhhh. So (you see this coming), why did it stop there? It didn't, NeXT added more sections. Later, they decided to go with appwrappers, which they felt were better than Mach-O. I happen to agree, since it makes life much easier if you want to much about with your applications - no need for a resedit-type tool to gain access to the Mach-O sections. -- Jonathan W. Hendry jon @ exnext . com
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 17 Jan 1997 00:37:59 GMT Organization: ace dot net internet technologies Distribution: world Message-ID: <5bmhl7$qqf@darla.visi.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> Anders Pytte (milkweed@plainfield.bypass.com) wrote: : I don't understand how this works. May one create a behavior just once, as : protocols, mix them into various objects, go back and change the behavior, : and have this change effect all classes to which the protocols have been : added? [c/protocols/categories for most of this article] No, categories are used for a different thing, and are specific to each class. However, if we were using the composition model instead of MI, then you could modify the "composed" class's behavior, and it would indeed change across your framework. : May the classes to which you have added a set of protocols be passed to : methods that take as an argument any classes containing that particular : set of protocals? If not yes to all the above then there is really no : equivalence to multiple inheritence. I don't follow what you mean. Why *wouldn't* you be able to send an object to a method of the same class? : As for the ability to add methods to existing classes, that is a : traditional feature of a subclass. What advantage do protocols add? The : class with added protocols is no different than a subclass in any sense I : can determine (unless perhaps it does not add an entire leaf to the : virtual tables). Subclasses are awkward in some situations. Supposing I base my application on NSStrings, and then halfway through the project I realize I need functionality NSString doesn't cover. Should I rewrite the entire app to use my subclass *probably just search and replace for the most part, but still..) : p.s. I'm active in this thread because I really want to see why all the : excitment about Obj-C. I don't mean to be a spoiler. I suggest you read NeXT's book on Objective-C, which is someplace on their web site. Also, some realted links: http://www.next.com/Pubs/Documents/OPENSTEP/ObjectiveC/objctoc.htm http://www.batech.com/~dekorte/Objective-C/objc.html -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 01:11:48 GMT Organization: Indiana University, Bloomington Message-ID: <5bmjkk$p15@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> NNTP-Posting-User: glhansen In article <maury-1501971811400001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> Oooh, I bet the _Unix Hater's Handbook_ told you to say that. > > No actually, it's post right here in this conference that show >examples. For instance... > >I've been tearing my hair out the last couple days dealing with >HP-UX, Hewlett-Packard's version of Unix. They made a raft of >gratitious filesystem changes that added NOTHING to the value >of the OS, except to make it difficult to work with in a multivendor >Unix environment. Uh... maybe I'm getting my contestants mixed up. Who was it that didn't want a hard drive littered with /bin and /etc and stuff? I think this is a good argument for leaving them in. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 16 Jan 1997 14:12:28 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5bm94c$n0f@crl.crl.com> References: <AEEFE2B6-491909@204.246.66.19> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> In article <acurylo-1601971109400001@van0217.tvs.net>, Alex Curylo <acurylo@inmediapresents.com> wrote: [Categories.] >What gets me is how, if all these super-neat features like this that the >Obj-C guys keep casually throwing out really do exist as described, why on >earth did the universe at large adopt C++ instead? We Obj-C guys wonder, too. Categories have a couple weaknesses. You can't add ivars, for example, and you really shouldn't override existing methods. But they really are amazingly useful. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 01:14:18 GMT Organization: Indiana University, Bloomington Message-ID: <5bmjpa$p1q@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> NNTP-Posting-User: 1073745024 In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, William Raphael Hix <raph@porter.as.utexas.edu> wrote: >Donald R. McGregor (mcgredo@crl.com) wrote: >: 3. I think all the unix utilities oughta be in there, in their >: full glory and grime. > >The existance of a lot of Unix utilities in Rhapsody would be a >tremendous disincentive to some Mac developers to port their software >to the new OS. Since Apple has said that it knows that Mac developer I don't follow your logic. How could Unix utilities possibly discourage the porting of software to the new OS? -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 16 Jan 1997 15:50:38 -0800 Organization: Cygnus Solutions Message-ID: <qdwwtduqlt.fsf@blues.cygnus.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> acurylo@inmediapresents.com (Alex Curylo) writes: > In article <5bkjj6$big@darla.visi.com>, dwy@ace.net (David Young) wrote: > What gets me is how, if all these super-neat features like this that the > Obj-C guys keep casually throwing out really do exist as described, why on > earth did the universe at large adopt C++ instead? Several reasons (all IMHO): * Two of the best features of Objective-C, categories and protocols, were not added until later by NeXT. Although the original Objective-C implementation was nice, the above two really brought a fair amount of power that was lacking into the language. * At its inception, C++ was created at and backed by AT&T, a well-known heavyweight in the C world. Objective-C was backed only by Stepstone (the language inventor) and later by NeXT. * Someone (AT&T?) created cfront, a widespread C++-to-C translator which made it possible to use C++ code with your existing C compilers while good C++ compilers were still in the pipeline. Because of Objective-C's dependency on a runtime, it wasn't easy to make that kind of translator program unless it included the code for a runtime inside of it. * Perhaps most importantly, C++ fixed a number of shortcomings in the C language (good type checking, inline functions, ...) whereas Objective-C began by focusing on adding a good Smalltalk-style object layer to the C language. Hence, many people started using C++ because it was `a better C', ignoring the `object-oriented' features for a long time. -- Stephen L. Peters speters@cygnus.com PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "What, do you think soup is a biped?" -- Crow, MST3K
From: giddings@barbarian.com Newsgroups: comp.sys.next.programmer Subject: How to get the APM entry points? Date: 16 Jan 1997 23:52:47 GMT Organization: Barbarian Computer Services Distribution: world Message-ID: <5bmf0f$1b5u@news.doit.wisc.edu> Cc: michael_floyd@next.com I'm trying to figure out how to write a driver that interfaces better with the APM BIOS on a Toshiba Tecra than the NeXT supplied kernel does (so suspend/resume works, etc). The only piece of the puzzle missing is information on how to get the necessary protected mode entry points which the kernel obtains at boot time, and to also know specifically what the kernel does and doesn't do with respect to APM. If anyone knows how one can get the entry points from the kernel, or knows anything further on the subject, I would greatly appreciate the info. NeXT has been utterly unhelpful so far with my requests, even though my sales rep promised this would be part of the tech support provided with the developer program I signed up for. They won't even supply a header file, though I know it exists because one of the driver examples references functions in it (the AMD SCSI Driver). -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 18:10:27 -0800 Organization: Modulation Message-ID: <32DEDF93.7CA5@concentric.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Johnson wrote: > > In article <5bbe59$8fh@crl.crl.com>, mcgredo@crl.com (Donald R. McGregor) wrote: > > It would be terrible if Apple went mucking around trying to make > > the Unix filesystem layout "more logical". That would break many > > thousands of command-line and daemon Unix programs, and detract > > from one of the main selling points of the new system--that Unix > > is in there, if you look for it. > > It just occurred to me- Mac developers must redevelop everything, Adobe > will re-do Photoshop, they will re-develop ClarisWorks, FrameMaker, > Quark... > > ....but re-doing a Unix daemon for a market many times the original's > potential size is too much to ask? It's not too much too ask--provided the benefit is greater than the cost. The cost of keeping things as they are is not great. The benefits of compatibility with "standard Unix" are great. I can't imagine Rhapsody suffering any signigicant loss of market share because of the pathnames used for the standard Unix folders. Frankly, this issue is "mice nuts." -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 17 Jan 1997 00:22:10 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5bmgni$38s$1@brachio.zrz.TU-Berlin.DE> References: <acurylo-1601971109400001@van0217.tvs.net> In article <acurylo-1601971109400001@van0217.tvs.net> acurylo@inmediapresents.com (Alex Curylo) writes: > > What gets me is how, if all these super-neat features like this that the > Obj-C guys keep casually throwing out really do exist as described, why on > earth did the universe at large adopt C++ instead? That's the part Objective-C guys don't really understand. (Not that there aren't plenty of explanations, but that's not the same). Of course, it's not really that bad, gives us a 'free' competitive advantage. Marcel
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 17 Jan 1997 00:26:38 GMT Organization: ace dot net internet technologies Distribution: world Message-ID: <5bmgvu$qqf@darla.visi.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> Alex Curylo (acurylo@inmediapresents.com) wrote: : > and add methods you please, and every intance of NSString across the : > applicaiton gets the new methods, which, when combined with anonymous : > messaging, is very useful indeed... : What gets me is how, if all these super-neat features like this that the : Obj-C guys keep casually throwing out really do exist as described, why on : earth did the universe at large adopt C++ instead? What are you saying? Categories *do* exist. Trust me. As to your second question, I don't know. I think it has something to do with the Dilbert Principle. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system From: waqar@netcom.com (Waqar Malik) Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Message-ID: <waqarE44C34.6s2@netcom.com> Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> <jinx6568-1601971352540001@news.sover.net> Date: Thu, 16 Jan 1997 20:40:16 GMT Sender: waqar@netcom17.netcom.com Chris Johnson (jinx6568@sover.net) wrote: : In article <5b6dih$9bm@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu : (William Raphael Hix) wrote: : > One thing I'm pretty sure of is that the applications like tar, emacs, : > and especially cc, will not be present. This new OS will not survive : > without developer support, and I mean support by current Mac developers, : > not NeXT developers. Apple can't afford to upset its developers by : > giving away things that will in any way make users reluctant to buy new : > software. : I can't imagine any Mac user forgoing DropStuff or Stuffit Expander for : tar... or _anything_ for emacs (don't know what cc is, could somebody : describe?) The C compiler, I think NeXTSTEP uses gcc, which is free from GNU. : This isn't something for Mac developers to worry about. :) : Jinx_tigr : (aka Chris Johnson) Waqar
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 17:58:10 -0800 Organization: Modulation Message-ID: <32DEDCB2.24E6@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <5bll0l$me7@dfw-ixnews2.ix.netcom.com>, aisbell@ix.netcom.com > (Art Isbell) wrote: > > > Why? Various scripting languages are all the rage now. JavaScript, > > WebScript, VBScript, etc. plus what proponents sell as advanced > > 4th-generation languages (4GLs) which are usually interpreted. The Unix > > Read it carefully, I was taling about calling these things from the > command line, not the command line itself or using it as a person. IE, > programs should not have to call things by "pretending" to typing in CLI > commands. Exactly so. That's why an OS has a "kernel" and and API/BPI for invoking system services from within programs--no CLI required. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks From: ftruillot@iprolink.ch (Fabrice FT'e Truillot) Date: Fri, 17 Jan 1997 02:16:27 +0100 Message-ID: <19970117021627223550@ts26gep142.iprolink.ch> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> Organization: FT'e Masters Alex Curylo <acurylo@inmediapresents.com> wrote: > What gets me is how, if all these super-neat features like this that the > Obj-C guys keep casually throwing out really do exist as described, why on > earth did the universe at large adopt C++ instead? And why Microsoft = 80% of the personal computer market ? ;-) FT'e Il faut partir de haut pour sauter sur quelque chose. ________________________________________________________________________ Fabrice Truillot ftruillot@iprolink.ch
From: Dan Bongert <herkimer@cs.wisc.edu> Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: 17 Jan 1997 02:50:16 GMT Organization: University of WI, Madison -- Computer Sciences Dept. Message-ID: <5bmpd8$9d7@spool.cs.wisc.edu> References: <5aj8p3$rer@boursy.news.erols.com> <E3Fxyv.E3K@cam-ani.co.uk> <5amh2m$dao@nyheter.chalmers.se> well, if *i'm* not mistaken, some of the early sun stations used 68k processors, just like NeXT did (when it was still in the hardware business). > If I am not mistaken, it worked the other way too; NEXTSTEP would > work on some Sun workstations up to version 1.1, or something like > that. Supposedly because NEXTSTEP was developed on Suns. -- Dan Bongert | Hire the Morally Handicapped--It's More Fun dbongert@students.wisc.edu | National Institute for the Morally Handicapped herkimer@upL.cs.wisc.edu | http://www.upl.cs.wisc.edu/~herkimer
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 21:06:57 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DEDEC1.490C@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Johnson wrote: > > In article <5bbe59$8fh@crl.crl.com>, mcgredo@crl.com (Donald R. McGregor) wrote: > > It would be terrible if Apple went mucking around trying to make > > the Unix filesystem layout "more logical". That would break many > > thousands of command-line and daemon Unix programs, and detract > > from one of the main selling points of the new system--that Unix > > is in there, if you look for it. > > It just occurred to me- Mac developers must redevelop everything, Adobe > will re-do Photoshop, they will re-develop ClarisWorks, FrameMaker, > Quark... > > ....but re-doing a Unix daemon for a market many times the original's > potential size is too much to ask? 'A' Unix daemon? Nonono. All of them. Are you willing to foot the bill? Or do it yourself? Furthermore, I don't think market size is much of an incentive for groups like the FSF. The people who write those small and highly useful Unix things don't really care about the size of the market. If Apple screws up the layout, the Mac community will once again have to mess around with the executables, porting them to the Mac. The end result being, once again, the Mac getting everything later than everyone else. If Apple wants the new OS to be a useful Unix platform (and they should) then Unix power-users need to be able to type "make install" and have, say, Apache build and install properly, with a minimum of tweaking. They should not have to wade through makefiles and install scripts to fix Apple's bungled filesystem. If they need to do this, they'll use Solaris, Linux, or something else, and Apple will lose sales that they cannot afford to lose. -- Jonathan W. Hendry jon @ exnext . com
Date: Thu, 16 Jan 1997 22:11:04 -0600 From: mark@oaai.com Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Message-ID: <853471743.14007@dejanews.com> Organization: Deja News Usenet Posting Service References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> In article <milkweed-1601971618480001@port10.chester.smallmedia.com>, milkweed@plainfield.bypass.com (Anders Pytte) wrote: > > In article <5blksl$ruc@news.next.com>, MaRK_BeSSeY@NeXT.CoM wrote: > > > This is exactly what Objective-C protocols are for. They allow you to > > add methods to any existing class. This can even be done for classes > > that you don't have the source code to - can C++ do that? [Mark actually means to say Objective-C categories.] > I don't understand how this works. May one create a behavior just once, as > protocols, mix them into various objects, go back and change the behavior, > and have this change effect all classes to which the protocols have been > added? > As for the ability to add methods to existing classes, that is a > traditional feature of a subclass. What advantage do protocols add? The > class with added protocols is no different than a subclass in any sense I > can determine (unless perhaps it does not add an entire leaf to the > virtual tables). Categories allow you to add methods to an existing class without subclassing. This becomes useful when you haven't got access to the code which constructs objects you wish to manipulate, and so as a result, can't guarantee you'll always see the subclass you want to work with. Concrete example: I wish to create an object which can send arbitrary messages to Java objects and select subsets of these objects according to the values they return: getLastName LIKE 'ONY*' AND getActivationDate > '12/13/96' [NeXT users will recognize this as the EOQualifier object] Unfortunately, Java doesn't define a uniform set of methods which correspond to the concepts "like" and "<" for all possible object attributes types. With categories, I can add methods to String, Integer, Real, etc. and make all objects work with my framework - even those written long before I ever conceived of this new code. Without categories, my code will only work with special objects that return subclasses I define - MarksString, MarksInteger, MarksReal. In a more abstract sense, categories reduce coupling and increase cohesion in an OO design. Coupling is reduced because I don't have to fill all of my, say, UI code with references to MarksString, MarksInteger, or MarksReal on the off-chance that in some particularly funky app I may try to search my UI for all text widgets with a string value of "foo." Cohesion is enhanced because I can bundle my qualification engine and categories which enable qualification for all classes, into one package. Hope this clarifies! Mark -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 05:16:59 GMT Organization: Netcom Distribution: world Message-ID: <5bn20b$lmn@sjx-ixn6.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5bll0l$me7@dfw-ixnews2.ix.netcom.com>, aisbell@ix.netcom.com > (Art Isbell) wrote: > > > Why? Various scripting languages are all the rage now. JavaScript, > > WebScript, VBScript, etc. plus what proponents sell as advanced > > 4th-generation languages (4GLs) which are usually interpreted. The Unix > > Read it carefully, I was taling about calling these things from the > command line, not the command line itself or using it as a person. IE, > programs should not have to call things by "pretending" to typing in CLI > commands. As has been stated on several occasions, OPENSTEP programs aren't *required* to use Unix shell utilities. In fact, if they do, they certainly won't be portable to NT. But if I need to write a little app to do something useful under Mach only, then why not have the option of using something that's already well-tested rather than reinventing the wheel? -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 21:13:46 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5bn1qa$c3r@crl.crl.com> References: <5ami95$ol3@news.tuwien.ac.at> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> >Chris Johnson wrote: >> It just occurred to me- Mac developers must redevelop everything, Adobe >> will re-do Photoshop, they will re-develop ClarisWorks, FrameMaker, >> Quark... >> >> ....but re-doing a Unix daemon for a market many times the original's >> potential size is too much to ask? If it makes you feel better, call it the "Unix Backward Compatibility Box", just like the System 7 Compatibility box. You don't try to make a backward compatability box "better" by changing things around, do you? You try to make it _compatible_. Changing the layout of the filesystem or nuking a bunch of utilities would defeat the purpose of the compatibility box. When someone writes something better in Rhapsody, we'll switch over to that. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 17 Jan 1997 05:29:36 GMT Organization: Netcom Distribution: world Message-ID: <5bn2o0$lmn@sjx-ixn6.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> acurylo@inmediapresents.com (Alex Curylo) wrote: > What gets me is how, if all these super-neat features like this that the > Obj-C guys keep casually throwing out really do exist as described, why on > earth did the universe at large adopt C++ instead? You're a developer looking to adopt an object-oriented language. A.T.& T. is offering a spiffy new extension to C called C++. StepStone is offering another spiffy superset of C called Objective-C. Will you go with A.T.& T. or Step... who was that other vendor? -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 02:57:45 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R1701970257450001@news.erols.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au> <5bbuae$b14@news.xmission.com> <scottm-ya02408000R1401972248330001@news.erols.com> <5bkujj$rm5@duke.squonk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bkujj$rm5@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: >One difference between the MacOS and NeXTSTEP is that the MacOS >is really conceived of and envisioned as a personal computer. >One computer, which has one owner. > This is definitely true. >NeXTSTEP is designed for multiple users. In the world of multiple >users, I'm not so sure that the above is a good idea. It is >probably doable, but I think it'd be more confusing than helpful. > I agree with you. Unfortunately there are an awful lot of current Mac users who would be confused if they suddenly couldn't put things where they want. Of course the Finder-like program could handle the illusion of putting things where you want while you're running it. Didn't the original system and finder not really have folders (MFS) but the Finder made it look like it? This could even solve the creator code/file type thing I had mentioned. The actual files could have the extensions put on but the Finder 'browser' wouldn't show them unless you turned on that option (along with the CLI option). I had forgotten that the Finder is basically a file browser. This could run nicely on top of OpenStep and the NeXT interface could be run instead of the Finder for those who wanted to use it. Pretty brilliant huh? ;-) -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 05:00:49 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bn121$22l@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <jinx6568-1601971411390001@news.sover.net> jinx6568@sover.net (Chris Johnson) wrote: > dwy@ace.net (David Young) wrote: > > Have you ever even *used* a UNIX shell prompt? It's clear that > > you don't have any idea what you're talking about. > > Garance confirmed these observations, with the added detail that > the GNU implementations were less prone to being dumb hacks... > > Thus, I am less interested in finding out how you feel about it > as I am in asking Garance whether the standard NeXT stuff bears > more resemblance to the GNU stuff than the dumb hacks. I suspect > it must resemble the GNU or the unix-savvy NeXTians would be less > confident. So, Garance, is it so? important disclaimer: I'm not reading these advocacy groups as much as I was, because I'm back to work now and generally run out of hours in the day. So, for anyone seeing this, if you've asked me direct questions and are wondering why I don't answer, it might be because I'm not seeing your article... Some of the unix utilities that come with NeXTSTEP are the gnu versions (if nothing else, the "cc" is really "gcc" :-). Several gnu utilities are provided in addition to the "standard" unix versions. Thus, there is both "tar" and "gnutar". It was claimed that many of the unix utilities were slated for an upgrade at the same time the kernel got upgraded, but then that whole project got put on hold. (it was originally intended for NeXTSTEP release 4.0). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 00:55:59 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bn49f$bev@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > The existance of a lot of Unix utilities in Rhapsody would be a > tremendous disincentive to some Mac developers to port their software > to the new OS. Why, because they <gasp> may be useful? :) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 05:40:06 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bn3bm$22l@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Donald R. McGregor (mcgredo@crl.com) wrote: > : 3. I think all the unix utilities oughta be in there, in their > : full glory and grime. > > The existance of a lot of Unix utilities in Rhapsody would be a > tremendous disincentive to some Mac developers to port their > software to the new OS. Since Apple has said that it knows that > Mac developer support is critical to the success of this venture, > I don't think that the inclusion of utilities (like tar, emacs, > cc, ...) is guaranteed. It depends on the utility. Things like tar, gnutar, gzip, sed, perl, and various shells are bound to be there. To many things (such as the startup scripts) depend on them. Something like Emacs does not need to be included. No doubt it will be available, though, for those who like it. It's already true that the "user-version" of NeXTSTEP does not include cc. You have to buy the developer package for that, and given that Metrowerks has already signed up to make the compiler for Rhapsody then one expects that cc will not be included in any Rhapsody product. > As a workstation veteran and amatuer user of pipes, I'd like to > have grep and the like, but I'm not expecting it. Perhaps it > would be easy for Apple or a third party to add such functionality, > but I don't expect such utilities in the basic OS. If you were a veteran of administering workstations, you'd realize that it would be absurd to ship a unixy system without basic things such as shells and grep. > : 4. Unix may suck--all OSes do--but making a bunch of gratitous > : changes that would make Apple's Unix layer different from > : every other Unix would suck even more. > > This assumes that Rhapsody will have a Unix layer similar to the > BSD Unix emulation middle layer between NextStep and the Mach > kernal in OpenStep/Mach. This is true. That is the assumption. It is a reasonable assumption given the high-priority goal of shipping a product which works, and doing so as soon as practical. > Apple could use about anything to provide this functionality, > including a SysV Unix layer, or something based on Apple's > internal work. Yes, this would make it harder to port NeXTStep > apps to Rhapsody, but if they find a way which would make it > easier to port Mac apps, they might well do it. Forget NeXTSTEP applications (in the sense of the nice apps which have GUI interfaces). Doing something based on Apple's internal work, or based on SysV, is bound to slow down the project. The issue won't be whether some ancient NeXTSTEP application can run, the issue will be whether the system, Apple's own operating system, can boot up. If the goal is for Apple to prove it's macho by ripping out every last vestiage of unix, then they need to forget about NeXTSTEP and Rhapsody. Instead, they should go back to the morass which was Copland. My guess is that Apple has already decided against that. > : Casual, everyday users should never see Unix. Power users and > : developers are perfectly capable of dealing with the quirks > : of Unix, and removing or bastardizing Unix would be a tragedy > : of the first order, as well as a dumb business move. > > It's clear from Apple's plans to de-Unixize Rhapsody that the > ordinary user will see no signs of Unixness or CLI. Whether this > means that power users will be unable to summon a CLI capable of > at least file handling or developers will have to use some other > system call to do file removal or renaming is an open question. From the various press statements which have come out of Apple, there is not much of an opening for this question. It is certain that Apple will provide more user-friendly interfaces to some rough edges that are still seen in NeXTSTEP. It is certain that they have work to port NeXTSTEP (or at least OpenStep) to the PPC. It is pretty much certain that they also have work to port various Apple technologies (Quicktime Media Layer, etc) to Rhapsody. All of those are important projects with an obvious payoff. All of those will require time to do. It is also certain that if they don't deliver some kind of crediable operating system, running on their own hardware, by January 1998, then this whole exercise is going to be seen as a disaster. They *must* deliver a product. They can not go around taking on other big projects (like "ripping out unix") simply because someone *thinks* their life will be horrible if the executable for 'grep' is sitting on their hard disk. People keep thinking that Apple has plenty of time to go off on all sorts of exotic projects here. They do not. They must deliver a product this year (as a developer version), or they will look rather stupid. They have *plenty* of work to keep them busy without some of these nonsense projects. Why add "Work for the sake of Work" when they already have "Work for the sake of staying in business" to worry about? > I think it'll be 3 months before even Apple-NeXT is sure. They > do seem intent on replacing the Mach 2.5 kernal, so I think the > kernal decision needs to be made before the middle layer will be > finalized. There are some issues which will take at least a few months for Apple (and former NeXT) to work out. Hopefully they will conclude that they need to concentrate on producing a product, and on projects which have obvious benefits. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 05:11:30 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bn1m2$22l@duke.squonk.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> jinx6568@sover.net (Chris Johnson) wrote: > mcgredo@crl.com (Donald R. McGregor) wrote: > > It would be terrible if Apple went mucking around trying to > > make the Unix filesystem layout "more logical". That would > > break many thousands of command-line and daemon Unix programs, > > and detract from one of the main selling points of the new > > system--that Unix is in there, if you look for it. > > It just occurred to me- Mac developers must redevelop > everything, Adobe will re-do Photoshop, they will re-develop > ClarisWorks, FrameMaker, Quark... > > ....but re-doing a Unix daemon for a market many times the > original's potential size is too much to ask? It depends what you mean by "re-do". It is not too much to ask for better versions of the various unix daemons (bugs fixed, security improved, maybe some options added). However, it is too much work to simply shuffle the entire unix file system around just because someone thinks they have "a better way". The problem isn't just the work to do those changes, but that there are all kinds of packages on the net which think they know where everything is, and what it does. Many of those packages are provided for free, and thus it could be awhile before the maintainers get around to updating those packages. Basically, it'd be a lot of work for very little payback. Note that the world of unix has some experience with this, most notably the transition Sun made from SunOS (bsd-based) to Solaris (sysv-based). Many things have taken years to move from SunOS to Solaris, simply because there was a lot of work to switch to Solaris and nothing much to gain by doing it. If I remember right, the drive for Solaris started at about the same time system 7.0 was released. There are still shops which stick with SunOS, because it's not worth it to them to switch. Meanwhile, traditional Mac developers have at least some expectations of a payback if they rewrite their programs for the new system. They won't have to worry about (*^&^%&^ handles any more. They will have unicode support. They will have a much nicer development environment. They have preemptive multitasking. Applications are protected from each other (so a bug in one application or daemon can not write over memory for some other running application). There is certainly a lot of work involved, but at least you've got something to show for it when you're done. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
Date: Fri, 17 Jan 1997 04:01:14 -0600 From: szallies@energotec.de (Constantin Szallies) Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Message-ID: <853493588.22389@dejanews.com> Organization: Deja News Usenet Posting Service References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b2fok$det2@ddfservb.technet.net> <5b383g$esi@news.xmission.com> In article <5b383g$esi@news.xmission.com>, don@globalobjects.com wrote: > > Constantin Szallies wrote: > > And NO multiple inheritance can't be simulated by objective C's > > abibliy to forward messages. These forwarding is the same as > > delegation, you just don't have to write code like: > > Actually I don't feel that is quite correct--and this is only > a matter of opinion and is therefore debatable. But let me > explain what I mean... > > While creative use of the forwarding mechanism is not true > multiple implementation inheritance, it *does* allow > implementations to be shared amongst several objects (via > delegation), and that is a very close approximation of > multiple implementation inheritance. [cut] I agree in that multiple inheritance is not needed in Objective-C. But there are a couple differences between delegation (or forwarding in the sence of Objective-C which is the same with less code) and multiple inheritance. Inheritance is white-box reuse and delegation is black-box reuse. You can't access a delegates protected instance variables. But you can access the protected instance varibles of an inhertited class. Greetings Constantin Szallies szallies@energotec.de -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: becker@ps.lhag.de (Dirk Becker) Newsgroups: comp.sys.next.programmer Subject: NextStep 2.0 to 4.1 comparison? Date: Fri, 17 Jan 1997 11:18:56 +0100 Organization: Linotype-Hell AG Message-ID: <becker-1701971118560001@193.103.65.112> Are there any similarities between the APIs of NextStep 2.0 as installed on my Cube, and the current OpenStep / future Rhapsody? Was the migration more like search&replace NX by NS and add support for a bunch of new classes, or is it gone into a totally different direction? I won't shell out $5000 from my hobbyist etat to get an up-to-date developer release bound to a doomed hardware, and with pricier alternatives in the near future through Metrowerks and Apple. OTOH it would be nice to have an early look at the next MacOS ... Dirk
From: Yomama Sophat <neilr@inigo.us.dg.com> Newsgroups: comp.sys.mac.programmer.tools,comp.sys.m68k,comp.misc,gnu.utils,alt.comp.hardware,comp.lang.asm,comp.os.misc,comp.sys.next.programmer,comp.sys.misc Subject: Help: need info on Motrola "S" hex format Date: Fri, 17 Jan 1997 10:39:00 -0500 Organization: Data General Corporation, Westboro, MA Message-ID: <32DF9D14.6FD8@inigo.us.dg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Any information out there? I need to write a program that outputs such files. Thanks in advance.
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 17:21:32 GMT Organization: Netcom Distribution: world Message-ID: <5boces$kft@dfw-ixnews11.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <5bn20b$lmn@sjx-ixn6.ix.netcom.com> <maury-1701971146010001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5bn20b$lmn@sjx-ixn6.ix.netcom.com>, aisbell@ix.netcom.com (Art > Isbell) wrote: > > > As has been stated on several occasions, OPENSTEP programs aren't > > *required* to use Unix shell utilities. > > Yes I know, but also look at the many examples of those that _do_. We probably wouldn't have these examples to look at (and more importantly, *use*) if these shell utilities weren't available *and* their functionality wasn't duplicated in functional or class APIs. You made the point that if all the functionality of shell utilities were available in function or class libraries, then these shell utilities wouldn't be necessary for apps to use. This is a valid point, but one which hasn't been achieved yet. It's a worthy goal, but until that happens, don't rip out the shell utilities just to save a few MB of cheap disk space. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 11:40:37 -0500 Organization: Atria Software Message-ID: <maury-1701971140380001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> In article <5bmjkk$p15@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > Uh... maybe I'm getting my contestants mixed up. Who was it that didn't > want a hard drive littered with /bin and /etc and stuff? I think this is > a good argument for leaving them in. Actually it's a great arguement for getting rid of them. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 11:44:50 -0500 Organization: Atria Software Message-ID: <maury-1701971144500001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> In article <32DEDCB2.24E6@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > Exactly so. That's why an OS has a "kernel" and and API/BPI for invoking > system services from within programs--no CLI required. Exactly so, so why should be have the later at all unless you want it? If all the applications called the API's (notably if those API's were clean and OOPS based) there seems to be no use for the shell and utils except for scripting. However this does not appear to be what actually happens. Lots of code examples posted here to bolster the "we need grep because..." indeed do exactly this, stream their parameters to text and send them out to the shell. grep comes to mind, I'm sure you can think of other examples. Then they claim this is a good thing, that you can do this. My point is, and has been, that thse utilties, like every other one, should be directly accessable via API's, preferably OOPS based ones. Look, the NeXT is considered to be one of the best OS's about because of it's great OOPS libs for the GUI. Imagine if the same were true of _all_ calls. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 11:46:01 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-1701971146010001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <5bn20b$lmn@sjx-ixn6.ix.netcom.com> In article <5bn20b$lmn@sjx-ixn6.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > As has been stated on several occasions, OPENSTEP programs aren't > *required* to use Unix shell utilities. Yes I know, but also look at the many examples of those that _do_. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 11:50:37 -0500 Organization: Atria Software Message-ID: <maury-1701971150370001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> In article <5bn3bm$22l@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > If you were a veteran of administering workstations, you'd realize > that it would be absurd to ship a unixy system without basic things > such as shells and grep. Well who said anything about a Unixy system? Apple didn't buy NeXT for Unix, they bought if for OpenStep and the underlying OS (which, yes, is Unixy). > This is true. That is the assumption. It is a reasonable assumption > given the high-priority goal of shipping a product which works, > and doing so as soon as practical. Given. > If the goal is for Apple to prove it's macho by ripping out every I think Apple's only real interest in the project is to get a working OS that is clean and doesn't have warts. Seeing as OpenStep runs over NT, it's demonstratable that you can rip out ALL the Unix utils and end up with a working system. Maury
From: sugee@imap2.asu.edu Newsgroups: comp.sys.next.programmer Subject: Re: Cost of a NeXT Web Site? Date: 17 Jan 1997 17:15:20 GMT Organization: Arizona State University Message-ID: <5boc38$4dn@news.asu.edu> References: <5bjnet$b79@news.asu.edu> <5bk8vv$3im@news.digifix.com> Hello Scott, Although I didn't think to specifically ask for this, you provided great information to learn to help assess what the costs of doing things like this are. Knowing how long these projects can take, is an excellent start in the right direction and in fact help me to see what other aspects of the picture I should be inquiring about at also. See the clip of another follow-up post I did below. __________________ Hello Tim, Thank you for your reply. Please forgive me if my post was not clear enough. But, what I am very curious to find out, although I recognize that this is something which people may not be so willing to provide, is learning what NeXT and other developers are charging for these web sites and how much time they are taking to develop and what are exact or rough hourly charges. In other words, I would appreciate learning more about what the exact or estimated breakdown and total cost to the customer for something like this? Come to think of it, and something that another poster, a Scott A., was kind enough to offer, learning about what the development time of these sites would be great too along with this other information? This way, it can be compared to how much time and effort it would take using other tools on the market to try and accomplish the same or close to the same thing. I hope that this clarifies what I am asking. Cheer for the New Year! Sue <...my (Sue's) post deleted...> : Sue, I think you would have to be looking at a developers' license : (enterprise as they are calling it now) for $5000 and the WebObjects : product which will run you around $25,000 from my memories :) I am : not sure exactly what this gets you because there are issues of linking : to databases etc that could require extra costs but I think that $30,000 : will pretty much cover your up-front costs. : Tim Triemstra ....... TimT@ASIAtlanta.com : Alpha Star International, Atlanta GA USA Scott Anguish (sanguish@digifix.com) wrote: : On 01/15/97, sugee@imap2.asu.edu wrote: : > : >I doubt that many advocates and customers like Chylser, CyberSlice, : >Nissan, and etc. as the list goes on, will argue about the merits of : >using NeXT's Web technologies for deploying their Web sites. We have all : >heard plenty and are proud of what is being accomplished. : > : >However, what I haven't heard anything about, something which curiously : >dawned on me recently and after reviewing what some of these folks are : >doing, is the cost of implementing and deploying these Web Sites. Can : >anybody provide approximate costs or actual figures of sites like these? : >I do respect people's anonymity. : > : Thats likely not something that you're going to have much luck : finding out, the spectrum is pretty wide there. : There are some WebObjects projects like Stepwise (a : NEXTSTEP/OpenStep product registry) that are based on EOF and WOF and it : took perhaps 20-40 hours to implement. (The back end OpenStep UI has : probably taken about as long). Of course I've re-written it a number of : times now so thats a rather poor example. : I've written sample catalog applications in WebObjects in a matter : of a weekend. : However I know of _much_ larger scale projects that have been in : development for 6-8 months with a pretty good team of people on it (4-6).. : : -- : Scott Anguish DBS Online - http://www.dbs-online.com/DBS : sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: sugee@imap2.asu.edu Newsgroups: comp.sys.next.programmer Subject: Re: Cost of a NeXT Web Site? Date: 17 Jan 1997 17:17:17 GMT Organization: Arizona State University Message-ID: <5boc6t$4dn@news.asu.edu> References: <5bjnet$b79@news.asu.edu> <5bk8vv$3im@news.digifix.com> P.S. I can understand people being a bit tight lipped about this. However, if I am able to get a survey or cross-section, this would give me a fair idea I think. Scott Anguish (sanguish@digifix.com) wrote: : On 01/15/97, sugee@imap2.asu.edu wrote: : > : >I doubt that many advocates and customers like Chylser, CyberSlice, : >Nissan, and etc. as the list goes on, will argue about the merits of : >using NeXT's Web technologies for deploying their Web sites. We have all : >heard plenty and are proud of what is being accomplished. : > : >However, what I haven't heard anything about, something which curiously : >dawned on me recently and after reviewing what some of these folks are : >doing, is the cost of implementing and deploying these Web Sites. Can : >anybody provide approximate costs or actual figures of sites like these? : >I do respect people's anonymity. : > : Thats likely not something that you're going to have much luck : finding out, the spectrum is pretty wide there. : There are some WebObjects projects like Stepwise (a : NEXTSTEP/OpenStep product registry) that are based on EOF and WOF and it : took perhaps 20-40 hours to implement. (The back end OpenStep UI has : probably taken about as long). Of course I've re-written it a number of : times now so thats a rather poor example. : I've written sample catalog applications in WebObjects in a matter : of a weekend. : However I know of _much_ larger scale projects that have been in : development for 6-8 months with a pretty good team of people on it (4-6).. : : -- : Scott Anguish DBS Online - http://www.dbs-online.com/DBS : sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 17 Jan 1997 17:16:19 GMT Organization: Netcom Distribution: world Message-ID: <5boc53$kft@dfw-ixnews11.ix.netcom.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> milkweed@plainfield.bypass.com (Anders Pytte) wrote: > But i have a few concerns. Using categories do i have access to private > members? If so, I see a danger, in that I could develop a set of > categories which would become invalid when the purveyer of my library > modified private data or method members. Objective-C supports private, protected, and public instance variables, but all methods (member functions in C++-speak) are public. Of course, one must be aware of their existance to use them, so the interface documentation can "advertise" only those methods that one wishes to make public. Methods defined in categories are first-class methods - i.e., they have the same access to instance variables as the methods defined in the main implementation and can invoke all methods whether they're defined in the main implementation or in other categories. But a familiar caveat applies: those who use private, undocumented methods are likely to be burned if the original implementations of these private methods change. Instance variables cannot be renamed, removed, or added without causing lots of grief, so that's not likely to happen. > More often I have wanted to modify the behavior of an existing method in a > base class (say there is a bug in the library). Is there any way I do that > in Obj-C? Or would I need to change the library source? Glad you asked :-) We have found this to be one of the most powerful features of Objective-C. We have fixed bugs in some of NeXT's libraries using Objective-C's posing capability - a class can pose as another class so that any message sent to any object of the original class will be handled by the posing class, and any subclass object that inherits the from the posed class will use any method implemented by the poser that hasn't been overridden - i.e., the poser class replaces the posed class totally - its existence is transparent. This applies to messages sent internally within the library implementation as well!! Try that in C++ :-) Of course, there's a downside as well (the "no free lunch" principle is absolute :-) If you change the behavior of a method using posing, then you will likely break something in the library. Posing is implemented by subclassing the class to be posed (the buggy class in your example), overriding methods to be replaced (a superclass implementation can be invoked in the override if desired as with any subclass), and sending the posing class object a poseAsClass: message (each Objective-C class is a class object that can implement class methods and can thus receive messages): [PosedClass poseAsClass:[PosingClass class]] Posing has the same restriction as categories: no instance variables can be added. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Mystery bug from hell Date: 17 Jan 1997 11:06:19 GMT Organization: MHPCC Message-ID: <5bnmfb$7q1@kaopala.mhpcc.edu> I've got a bug that depends on the order in which I declare two fields in a global structure variable. My hunch is that I'm doing something wrong when declaring global varibles. Everything works when I declare a structure like this: typedef struct { char recordFD; char Field_1; char Field_2; } menu_struct; But the bug occurs when I declare it like this: typedef struct { char recordFD; char Field_2; char Field_1; } menu_struct; I have had wierd problems before from variables declared outside of a method's interface. But I don't know what I'm doing wrong. Here is a sketch of the program structure, in 3 abbreviated files: A header file, "global.h" is imported into all the other source code files: ----------------------------------------------------------------------------- #import <appkit/appkit.h> typedef struct { char recordFD; char Field_2; char Field_1; } menu_struct; void Assign_with_Function (); extern menu_struct m; ----------------------------------------------------------------------------- A file "Controller.m" contains the GUI methods, and has the bug: ----------------------------------------------------------------------------- #import "Controller.h" #import "global.h" menu_struct m; /* Home of the declaration */ @implementation Controller - mainMethod:sender { Assign_with_Function(); /* Assigning through a function call works fine */ [self Assign_with_Method:self]; /* Assigning through a method gives the bug */ return self; } - Assign_with_Method:sender { printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* produces: m.Field_1 = sprintf(&m.Field_1, "y"); printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* produces: m.Field_1 = y, m.Field_2 = sprintf(&m.Field_2, "y"); printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* THE BUG!! Now you get : m.Field_1 = return self; } @end ----------------------------------------------------------------------------- The function "Assign_with_Function()" is defined in its own file "Assign.c", and works fine: ----------------------------------------------------------------------------- #include "head.h" void Assign_with_Function () { sprintf(&m.Field_1, "y"); sprintf(&m.Field_2, "y"); } ----------------------------------------------------------------------------- The bug is that the variable "m.Field_1" loses its assigned value when "m.Field_2" is assigned. Any tips will be GREATLY appreciated. ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
Newsgroups: comp.sys.next.programmer From: tom@icgned.nl (Tom Hageman) Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Message-ID: <E3qLFp.K9D@icgned.nl> Sender: news@icgned.nl Organization: IC Group References: <32D18DED.277F@ntplx.net> <E3nHrL.1tB@cam-ani.co.uk> <0k20yMppj+2S091yn@mindlink.net> <5b0rno$48e@news.xmission.com> Date: Thu, 9 Jan 1997 10:35:49 GMT don@globalobjects.com (Don Yacktman) wrote: >stephen_ma@mindlink.net (Stephen Ma) wrote: >> [...] I'd like to ask one >> question though: occasionally I see code that uses expressions like >> >> @"string" >> @(..., ..., ...) >> >> What are these things? There's no mention of them in NeXT's >> Objective-C book. > >This is syntactic sugar--almost a macro. The first one creates >an NSString object with the specified value and the second creates >an NSArray populated with the comma delimited list of objects >between the parenthesis. Pretty simple stuff and a recent addition >to the compiler as of the creation of the NeXT FoundationKit. Really? (No question about the NSString construct, but this is the first I heard of the NSArray one.) When I tried to compile the following test code: --- @array.m --- #if (NS_TARGET_MAJOR <= 3) #import <foundation/NSString.h> #import <foundation/NSArray.h> #else #import <Foundation/Foundation.h> #endif void test() { id array = @(@"aap", @"noot", @"mies"); // test @(..., ...) } --- I got the following errors: cc -c @array.m @array.m: In function `test': @array.m:10: invalid identifier `@' @array.m:10: warning: initialization makes pointer from integer without a cast Using both the NS3.3 and OS/Mach 4.1 compiler. Maybe it does work with the OS/NT or the latest gcc compiler, I haven't checked. It is possible to get about the same effect by defining a macro like: #define @(objects...) [NSArray arrayWithObjects:objects, nil] but this would (a) use a gcc-specific preprocessor feature, and (b) it does not yield an array constant like @"string" yields a string constant. In the same vein: should @123 or @45.678 yield NSNumbers? :-) -- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ IC Group <tom@icgned.nl> (work) __/__/__/ "Ed is the standard text editor" __/ _/_/ -- Unix Programmer's Manual
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 17:28:44 GMT Organization: Netcom Distribution: world Message-ID: <5bocsc$kft@dfw-ixnews11.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > Seeing as OpenStep runs over NT, > it's demonstratable that you can rip out ALL the Unix utils and end up > with a working system. But you and I don't know whether OPENSTEP/Mach relies on Unix shell utilities and whether OPENSTEP/NT replaces this reliance with DOS utilities that are available under NT (probably not likely considering the paucity of functionality available with DOS utilities under NT compared with the richness Unix includes). OPENSTEP isn't a total self-contained cocoon. It depends on functionality offered by the underlying operating system. If you start ripping out this functionality, you may break things. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Greg_Anderson@afs.com (Gregory H. Anderson) Newsgroups: comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 17 Jan 1997 18:20:50 GMT Organization: Anderson Financial Systems Inc. Distribution: world Message-ID: <5bofu2$5ks@shelob.afs.com> References: <5boc53$kft@dfw-ixnews11.ix.netcom.com> A quick followup to one of Art's excellent comments. Art Isbell writes > Instance variables cannot be renamed, removed, or added without > causing lots of grief, so that's not likely to happen. More precisely, to write a category, you need access to the class's @interface (.h) file. If the original author adds an ivar, or changes the argument list for a method you have overridden, they must provide a fresh copy of the @interface. At that point, if you have set up a proper make-depend environment, your code will realize automatically that it needs to be recompiled. As to hiding private methods: The usual way to do this is by defining the private methods at the top of the @implementation module, rather than as part of the @interface. This is good enough to keep them away from casual hackers. A dedicated hacker, however, can run AppInspector and assemble a definitive list of avauilable methods for a class at runtime, including any categories or poseAs: methods that were loaded dynamically. This can be dangerous and desperate, but some of us have done it. 8^) Which brings me to my last point: Apple can end the desperation by RELEASING THE DAMN SOURCE CODE to the various Kits. You can get source for Delphi. You can get source for MFC. You can get source for almost any third-party object library. I know I've been a broken record about this topic for five years, but now is the time to change this policy. Everyone could get their work done a LOT faster. -- Gregory H. Anderson | "I wander'd off by myself, In the Crystal Ball/Star Gazer | mystical moist night-air, and from Anderson Financial Systems | time to time, Look'd up in perfect greg@afs.com (NeXTmail OK) | silence at the stars." Walt Whitman
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 1997 19:32:26 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5bok4a$q23@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: : : > The existance of a lot of Unix utilities in Rhapsody would be a : > tremendous disincentive to some Mac developers to port their software : > to the new OS. : : Why, because they <gasp> may be useful? :) Example, does the existance of tar, a reasonably able backup utility with a really unfriendly UI, make companies like Alladin or Dantz who make backup software more or less eager to port to Rhapsody? I think less likely, because the number of potential buyers for Stuffit is reduced by the existance of tar and freeware extentions. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 13:13:53 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bofh1$g3f@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> In article <maury-1701971144500001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > If all the applications called the API's (notably if those API's were > clean and OOPS based) there seems to be no use for the shell and utils > except for scripting. Or for the people who prefer using a CLI to a GUI in order to perform some tasks. > Lots of code examples posted here to bolster the "we need grep > because..." indeed do exactly this, stream their parameters to text > and send them out to the shell. grep comes to mind, I'm sure you can You don't have to send them out to the shell, you can fork 'grep' directly. grep isn't a bad example, actually. Even in our object-oriented world, plenty of things (such as mail folders) are stored as text, and some of the greps are incredibly fast at searching such files. The overhead of forking a process is often less than that of actual searching. (Take a look at the integrated Agrep/Glimpse text search engine. It's really nice.) Another good example might be using a Unix mail transfer agent to deliver mail. > Then they claim this is a good thing, that you can do this. My point > is, and has been, that thse utilties, like every other one, should be > directly accessable via API's, preferably OOPS based ones. It is certainly cleaner that way. I would like to see more Unix utilities have their core functionality folded out into separate libraries, with the CLI utils being mostly wrappers to those APIs. However, practically speaking, it is just plain a lot less work to put OOP wrappers around existing CLI programs. Maybe we will eventually see a bunch of Unix utils make the transition (for example, GNU has a regular-expression library that a number of their programs share), in reality wrappering CLI programs is often nearly as good and requires less effort. It might be a good strategy to put OOP wrappers around command-line utilities and then slowly turn things around and transition the utilities to wrappers around libraries. (OOP libraries may or may not be desirable, depending on how well you can abstract the interfaces away from particular languages. Unfortunately, some solutions to do this, like CORBA, are a lot uglier than language-dependent ones like Objective-C.) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 97 12:50:22 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan17125022@howard.one.net> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> In-reply-to: raph@porter.as.utexas.edu's message of 16 Jan 1997 20:07:06 GMT In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) writes: Donald R. McGregor (mcgredo@crl.com) wrote: : 3. I think all the unix utilities oughta be in there, in their : full glory and grime. The existance of a lot of Unix utilities in Rhapsody would be a tremendous disincentive to some Mac developers to port their software to the new OS. Since Apple has said that it knows that Mac developer support is critical to the success of this venture, I don't think that the inclusion of utilities (like tar, emacs, cc, ...) is guaranteed. I would guess that any developers who's contribution to the platform consists of things like grep and find isn't going to be that wonderful of a developer to have in any case. I'd rather see developers concentrate on _real_ problems, like decent workflow applications and games. On the other hand, if you _have_ to port things like grep to make the platform usable, that's a big disincentive for developers. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 17 Jan 97 12:56:37 Organization: Is a sign of weakness Distribution: world Message-ID: <SHESS.97Jan17125637@howard.one.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> In-reply-to: acurylo@inmediapresents.com's message of Thu, 16 Jan 1997 11:09:40 -0800 In article <acurylo-1601971109400001@van0217.tvs.net>, acurylo@inmediapresents.com (Alex Curylo) writes: What gets me is how, if all these super-neat features like this that the Obj-C guys keep casually throwing out really do exist as described, why on earth did the universe at large adopt C++ instead? To be frank, it's because Objective-C is too easy. No, wait, before you go "huh?", hear me out. Way Back When, apps were almost uniformly control-driven. We had flow charts, top-down design, etc, etc. The background of C++ is more control-driven, while the background of Objective-C (Smalltalk) was more event-driven. At the time, this was somewhat of a big concern, because you had to buy into a couple paradigm shifts all at once. Programming NeXT's AppKit is very Zen-like - rather than hunting things down and controlling them, you "float", waiting for things to happen. Objective-C in an event-driven environment was very easy to use, but it was too much of a change. Nowadays, most everything is event-driven ... and C++ just looks _horrid_. Unfortunately, it's really much too late to fix things. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: Greg_Anderson@afs.com (Gregory H. Anderson) Newsgroups: comp.sys.next.programmer Subject: Re: Mystery bug from hell Date: 17 Jan 1997 18:31:43 GMT Organization: Anderson Financial Systems Inc. Message-ID: <5bogif$5m5@shelob.afs.com> References: <5bnmfb$7q1@kaopala.mhpcc.edu> Lee Altenberg writes > [most of bug descrition snipped] > sprintf(&m.Field_1, "y"); This line is the problem. Remember, to the compiler, that "y" is a two-byte string: 'y' + NUL terminator. That has the effect of wiping out the next byte in the struct when you do the sprintf. You have to change that to m.Field_1 = 'y'; The only reason you don't get a SIGSEGV on the second assignment is that you have a three-byte struct which is padded to four automatically (except on m68k, which allows tight, odd alignments). -- Gregory H. Anderson | "I wander'd off by myself, In the Crystal Ball/Star Gazer | mystical moist night-air, and from Anderson Financial Systems | time to time, Look'd up in perfect greg@afs.com (NeXTmail OK) | silence at the stars." Walt Whitman
From: bettis@inetnebr.com (Mr. Jeremy Bettis) Newsgroups: comp.sys.next.programmer Subject: Re: Mystery bug from hell Date: 17 Jan 1997 12:32:30 -0600 Organization: Internet Nebraska Message-ID: <5bogju$ps7@falcon.inetnebr.com> References: <5bnmfb$7q1@kaopala.mhpcc.edu> NNTP-Posting-User: bettis altenber@acpub.duke.edu (Lee Altenberg) writes: >typedef struct >{ > char recordFD; > char Field_1; > char Field_2; >} menu_struct; Here is your problem: > sprintf(&m.Field_1, "y"); > sprintf(&m.Field_2, "y"); This is basic C. All strings are numm-terminated. So with you call sprintf it writes 2 bytes, 'y' and 0. One goes in the char Field_1 and the other tromps Field_2. make it. m.Field_1 = 'y'; m.Field_2 = 'y';
From: rdogra@mailserv.metro.mci.com (Rajnish Dogra) Newsgroups: comp.sys.next.programmer Subject: Re: Mystery bug from hell Date: 17 Jan 1997 19:44:23 GMT Organization: InternetMCI Message-ID: <5bokqn$6r4@news.internetmci.com> References: <5bnmfb$7q1@kaopala.mhpcc.edu> Hi, altenber@acpub.duke.edu (Lee Altenberg) wrote: >I've got a bug that depends on the order in which I declare two fields in a >global structure variable. My hunch is that I'm doing something wrong when >declaring global varibles. Everything works when I declare a structure like Rule No. 1 from Comp Sci Avoid using global variables. >this: > >typedef struct >{ > char recordFD; > char Field_1; > char Field_2; >} menu_struct; > >But the bug occurs when I declare it like this: > >typedef struct >{ > char recordFD; > char Field_2; > char Field_1; >} menu_struct; > >I have had wierd problems before from variables declared outside of a method's >interface. But I don't know what I'm doing wrong. Here is a sketch of the >program structure, in 3 abbreviated files: > >A header file, "global.h" is imported into all the other source code files: > >-------------------------------------------------------------------- --------- >#import <appkit/appkit.h> > >typedef struct >{ > char recordFD; > char Field_2; > char Field_1; >} menu_struct; > >void Assign_with_Function (); > >extern menu_struct m; > >The function "Assign_with_Function()" is defined in its own file "Assign.c", and >works fine: > >-------------------------------------------------------------------- --------- >#include "head.h" > >void Assign_with_Function () >{ > sprintf(&m.Field_1, "y"); > sprintf(&m.Field_2, "y"); >} >-------------------------------------------------------------------- --------- ==================================================================== > man sprintf PRINTF(3S) UNIX Programmer's Manual PRINTF(3S) NAME printf, fprintf, sprintf - formatted output conversion SYNOPSIS #include <stdio.h> int printf(const char *format, ...); int fprintf(FILE *stream, const char *format, ...); int sprintf(char *s, const char *format, ...); DESCRIPTION Printf places output on the standard output stream stdout. Fprintf places output on the named output stream. Sprintf places `output' in the string s, followed by the character `\0'. Either put a fixed length (e.g. char Field_1[2];) in your char. or do not use sprintf instead try this m.Field_2 = 'y'; P.S. Are you using FoundationKit. Rajnish Dogra NextStep Developer rdogra@delphi.com
From: Norbert Heger <bertl@hal.kph.tuwien.ac.at> Newsgroups: comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 17 Jan 1997 22:55:50 GMT Organization: Vienna University of Technology, Austria Message-ID: <5bp01m$sb4@news.tuwien.ac.at> References: <milkweed-1701970806260001@port5.chester.smallmedia.com> Originator: bertl@gemini Anders Pytte <milkweed@plainfield.bypass.com> wrote: > More often I have wanted to modify the behavior of an existing > method in a base class (say there is a bug in the library). Is > there any way I do that in Obj-C? Or would I need to change the > library source? There is a quite simple way. Subclass the base class, override the methods you want to improve and instruct the runtime system to use your class 'instead of' the base class: [ImprovedBaseClass poseAs:[BaseClass class]]; Note that it is necessary to perform this posing BEFORE any instances of the base class are allocated, otherwise they won't be kind of your subclass. - N.C. _________________________________________________________________ Norbert C. Heger <bertl@hal.kph.tuwien.ac.at> NEXTSTEP / OpenStep Software Development NeXTmail preferred, MIME is welcome Please finger for PGP public key
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Fri, 17 Jan 97 00:52:29 +0100 Organization: Warty Wolfs Message-ID: <9701162352.AA11370@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In article <5bihao$a0j@winx03.informatik.uni-wuerzburg.de>, rainer@wmax60.mathematik.uni-wuerzburg.de wrote: > > Maury Markowitz writes > > > I'm curious, why the NSxxx class names? I know the historical context, > > > but is this important today? Seems somewhat unpleasing to the eye. NS is a TLA for OPENSTEP. Um, NextSt... Oh well... Ah, opeNStep. > And I wish they had not. In Germany, "NS" usually refers to the > National Socialists (i.e. Nazis), when used in a term like > "NS-regime". Now, what is a NSWindow? That does it. This thread is now officially dead. :-) -- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ IC Group <tom@icgned.nl> (work) __/__/__/ "Any magic sufficiently advanced is indistinguishable __/ _/_/ from a perl script" -- Larry Wall, mangled
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 19:47:10 GMT Organization: Cygnus Support Message-ID: <5bokvv$8n2$1@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> Cc: raph@porter.as.utexas.edu In <5bok4a$q23@geraldo.cc.utexas.edu> William Raphael Hix wrote: > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > : > : > The existance of a lot of Unix utilities in Rhapsody would be a > : > tremendous disincentive to some Mac developers to port their software > : > to the new OS. > : > : Why, because they <gasp> may be useful? :) > > Example, does the existance of tar, a reasonably able backup utility with > a really unfriendly UI, make companies like Alladin or Dantz who make backup > software more or less eager to port to Rhapsody? I think less likely, > because the number of potential buyers for Stuffit is reduced by the > existance of tar and freeware extentions. > Uh.. yeah.. sure. The existance of tar and dump have both eliminated the need for any third party backup utilities on any flavor of Unix. And the existance of Wordpad.exe has completely eliminated the need for a Windows wordprocessor market. What are you smok'n? make sure you bring enough for all of us next time... -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 20:16:59 GMT Organization: Airwindows Message-ID: <jinx6568-1701971519160001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> <5bkh7r$big@darla.visi.com> <maury-1601971544430001@199.166.204.230> > In article <5bkh7r$big@darla.visi.com>, dwy@ace.net (David Young) wrote: > > it makes more sense to use the shell. mv, rm, ls are bad examples. > > awk, sed, cut, sort, and uniq are better examples. They're designed for > > bytestream manipulation, which is something that is pretty common in most > > programs. Certain things don't always model well as objects; very complex > > pattern matching comes to mind. Here is a serious question- how prevalent _is_ bytestream manipulation in the standard Mac software base? Certainly something like an IRC program lends itself to bytestream manipulation. It is just possible that things like video editors _can_ operate on bytestreams though clearly there is non-linear stuff you could do that begins to touch on other ways of handling data. On the other hand, how does one abstract a Photoshop CMYK image in layers with a selection outline on the cyan plane that is being used to do a feathered blur? I think, though I could be wrong, that even with databases and spreadsheets the linkages of something like ClarisWorks are stepping past the ability of a single byte stream to describe what is going on. I'm not even going to get _into_ OpenDoc as an argument- first, I don't understand it myself on a techical level, and second, it's not necessary to my argument as I suspect there is a _lot_ of Mac software out there which is not handling data in a way which a single byte stream can deal with. I frankly don't have the background which is why I'm asking, but I find it hard to believe that 'everything is a stream of bytes' in Photoshop 4.0 or Cyberdog or even MoviePlayer, and even Simpletext can embed images contained in the resource fork, making a more complex compound data type that wouldn't seem to lend itself to bytestream manipulation. Any opinons on this? Jinx_tigr (aka Chris Johnson)
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 19:20:48 GMT Organization: Global Objects Inc. Message-ID: <5b64qg$s70@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <5b50q7$39e@news.xmission.com> <32D6499E.1017@surf.net.au> <5b5n2j$9e8@castor.cca.rockwell.com> <abridge-1001970811540001@dcn131.dcn.davis.ca.us> abridge@wheel.dcn.davis.ca.us (Adam Bridge) wrote: > [...]. For a Mac user you drag something > to System Folder, drop it, and it gets put where it belongs. End of > installation for Extensions. The idea there's something that requires > heroic knowledge for installation isn't comforting. But, I suppose, a > good installer would take care of this. Practically every commercial software package (and a large number of freeware and shareware packages as well) are distributed as a ".pkg" file. To install, double click the file and the Installer.app will open it and give you a panel with info about the package (size, what it is, icon, etc.). Click the "Install button". You may be asked where you'd like to install the package (with a default given for the "typical installation"). If the package _must_ be installed to a particular place (UNIIX sometimes requires that) you won't be given the option. Then, you'll be asked to pick which architectures you wish to install, the default being only the architecture of the machine you're using. If you want to install for other architectures, though, you add them to the selections. (I do because I have m68k and x86 hardware running NEXTSTEP, for example.) After that, you get a little progress bar and the installation happens. (Some packages may ask for other information, too, but that is rare.) It is extremely easy to install and it is very nearly foolproof, especially if you just pick all the defaults. I don't think too many folks will find this onerous--and Apple may come out with something even better for Rhapsody. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: rdogra@mailserv.metro.mci.com (Rajnish Dogra) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 20:27:23 GMT Organization: InternetMCI Message-ID: <5bonbb$6r4@news.internetmci.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > > I think Apple's only real interest in the project is to get a working OS >that is clean and doesn't have warts. Seeing as OpenStep runs over NT, >it's demonstratable that you can rip out ALL the Unix utils and end up >with a working system. > >Maury No... As far I know NeXT ships (with OPENSTEP for NT) some if not all the unix utilities and even has Terminal.app. Rajnish Dogra NeXTStep Developer rdogra@delphi.com
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 14:06:19 -0800 Organization: Modulation Message-ID: <32DFF7DB.167B@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32DEDCB2.24E6@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > Exactly so. That's why an OS has a "kernel" and and API/BPI for invoking > > system services from within programs--no CLI required. > > Exactly so, so why should be have the later at all unless you want it? > If all the applications called the API's (notably if those API's were > clean and OOPS based) there seems to be no use for the shell and utils > except for scripting. > > However this does not appear to be what actually happens. Lots of code > examples posted here to bolster the "we need grep because..." indeed do > exactly this, stream their parameters to text and send them out to the > shell. grep comes to mind, I'm sure you can think of other examples. > > Then they claim this is a good thing, that you can do this. My point > is, and has been, that thse utilties, like every other one, should be > directly accessable via API's, preferably OOPS based ones. And for the most part, they are (but not OOP-based, admittedly). Grep is after all a program. It is not a monolithic one. It works by calling library functions--that any program can call. The reason for the CLI is that it is sometimes easier to write a short program using the CLI (especially for a one-time use) than it is to write the equivalent C program. This is partly because the CLI is optimized for doing system admin stuff, partly because it's interpreted instead of compiled, and partly because it has only data type: a stream of bytes. > Look, the NeXT is considered to be one of the best OS's about because of > it's great OOPS libs for the GUI. Imagine if the same were true of _all_ > calls. This would make it more difficult to use C, FORTRAN, COBOL, BASIC, RPG, Assembly and other non-OO languages with the OS. Plus, it would make it more difficult to use OO languages whose object models were not compatible with the one used to implement the kernel and libraries. This is one of the reasons some people are complaining about Objective-C: it's object model is not compatible with that of C++, for example. How would a C++ program deal with a system call that expected an Objective-C class (or Smalltalk class) as one of the parameters (that is, the class itself, as an object--not one of its instances)? And what about Smalltalk BlockClosures? Or Ada Task types? Or CLOS multimethods? And the differences between OO languages with respect to type compatibility rules can also be problematic. One could perhaps use CORBA/SOM/DSOM to address such issues. But CORBA exacts a noticeable performance penalty. The initial version of Java might also have been a good choice, since I can't think of anything it has offhand that is hard to represent in other OO languages (although the non-OO langauges would still have problems). But the new version supports reflection and "inner classes," which would cause problems for C++. On the other hand, it's rather easy to interface to C from other languages. The only issues that arise are differences in String representation and multidimensional array structure--and the latter is not likely to be an issue in the case of system calls, and the former is not that hard to deal with. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 20:30:52 GMT Organization: Airwindows Message-ID: <jinx6568-1701971533060001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au> <5bbuae$b14@news.xmission.com> <scottm-ya02408000R1401972248330001@news.erols.com> <5bkujj$rm5@duke.squonk.net> <scottm-ya02408000R1701970257450001@news.erols.com> In article <scottm-ya02408000R1701970257450001@news.erols.com>, scottm@nic.com (Scott Maxwell) wrote: > option). I had forgotten that the Finder is basically a file browser. This > could run nicely on top of OpenStep and the NeXT interface could be run > instead of the Finder for those who wanted to use it. Pretty brilliant huh? > ;-) Think of the Finder as a file browser/window manager/task switcher which operates on a 'desktop' paradigm- basically, if you have papers on your desktop one can overlap the other. You still get to read and work with underlying ones, by pulling them out and putting them on the top, and you can keep an eye on a mostly-buried corner of a 'paper' if it is showing changing content. In the 'Finder' proper, you can get to it with a single grab- i.e. if you downloaded something and wanted to drag it somewhere, and you are in an application, you click and drag on the part of the icon you can see, and it switches to the Finder, already dragging the thing. You switched- but not in two actions, switch/grab and drag, just one. When clicking on windows in other apps often it will _not_ put the click through to the app at first, because such a click might be inadvertent- this is not set in stone, it's a conscious decision by the designers, and could be otherwise. I believe the Finder handles the layering of windows on the screen, calling apps to redraw their windows in given regions. This is easily ignored by us Mac users because it is very good at giving the illusion that stuff just magically works ;) I bet there are Mac users out there who have never heard of regions and believe the screen draws entire windows, it's just that the one on the top covers underlying ones ;) The finder is pretty cool, really. Odds are Rhapsody will incorporate a lot of it. But be aware that it may not be the obvious use of copied appearance and layout- for instance, if the NeXT paradigm doesn't make much of this, it might grow to be extremely NeXT-like appearance... that just happens to handle layered windows and direct manipulation very naturally and well. (P'raps it already does- I've not been lucky enough to actually use it.) Jinx_tigr (aka Chris Johnson)
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:20:48 -0500 Organization: Atria Software Message-ID: <maury-1001971421040001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> In article <5b4kbm$642@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > You apparently aren't a programmer. There are gobs of well-written > utilities around And most of them aren't standard parts of Unix, who's standard parts vary widely from Unix release to release, and vary in quality from passable to horrid. These are the exact items I'm talking about. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 14:22:16 -0500 Organization: Atria Software Message-ID: <maury-1001971422310001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> In article <mckinnon-1001970053450001@mckinnon.tezcat.com>, mckinnon@tezcat.com (Chuck McKinnon) wrote: > Just go the next step (pun intended) and make the Applications folder > the required place for .apps and make the system treat it as such. This > would make even more sense for new/consumer user: it makes sense. > All apps go in the Applications folder, [duh!] and the new system will > get what it need. > > Or is this too simple? Too inflexible anyway. I like putting my apps where I like them, I have a number of drag and drop ones on my desktop for instance. Maury
From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 16:36:48 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> In-Reply-To: <maury-1701971144500001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 17-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. > > Exactly so. That's why an OS has a "kernel" and and API/BPI for invoking > > system services from within programs--no CLI required. > > Exactly so, so why should be have the later at all unless you want it? > If all the applications called the API's (notably if those API's were > clean and OOPS based) there seems to be no use for the shell and utils > except for scripting. Because you need the shell and the utils in order for the operating system to boot in a flexible way that can be maintained by a system administrator. Furthermore, there are a large number of Unix server applications which are based off of those utilities. Rhapsody will be able to run all of the Internet server software being developed for Unix and will incorperate the efforts of Mac developers as they start porting to Rhapsody as well. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 1997 20:44:49 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5booc1$qj@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : raph@porter.as.utexas.edu (William Raphael Hix) wrote: : > The existence of a lot of Unix utilities in Rhapsody would be a : > tremendous disincentive to some Mac developers to port their : > software to the new OS. Since Apple has said that it knows that : > Mac developer support is critical to the success of this venture, : > I don't think that the inclusion of utilities (like tar, emacs, : > cc, ...) is guaranteed. : : It depends on the utility. Things like tar, gnutar, gzip, sed, : perl, and various shells are bound to be there. To many things : (such as the startup scripts) depend on them. Too many things under a NeXT system depend on them. The only UNIXness Apple has really committed to is kernal level stuff like SMP, protected memory, etc. The only NeXT specific stuff they've firmly committed to is OpenStep, which need not depend on the BSD middle layer in OpenStep/Mach, as demonstrated by OpenStep/NT and OpenStep/Solaris. Does tar exist on OpenStep/NT? : : > As a workstation veteran and amateur user of pipes, I'd like to : > have grep and the like, but I'm not expecting it. Perhaps it : > would be easy for Apple or a third party to add such functionality, : > but I don't expect such utilities in the basic OS. : : If you were a veteran of administering workstations, you'd realize : that it would be absurd to ship a unixy system without basic things : such as shells and grep. : : > This assumes that Rhapsody will have a Unix layer similar to the : > BSD Unix emulation middle layer between NextStep and the Mach : > kernal in OpenStep/Mach. : : This is true. That is the assumption. It is a reasonable assumption : given the high-priority goal of shipping a product which works, : and doing so as soon as practical. I am a veteran of workstation administration, at least at the workgroup level. It certainly would be absurd to ship a UNIX system without shells and grep, but again we don't know for sure how unixy the middle layer will be. Can you point me at press info which guarantees the existence of the BSD middle layer? Personally I'd love for all of BSD to be present. But I think the assumption that it will be there could prove false. : > Apple could use about anything to provide this functionality, : > including a SysV Unix layer, or something based on Apple's : > internal work. Yes, this would make it harder to port NeXTStep : > apps to Rhapsody, but if they find a way which would make it : > easier to port Mac apps, they might well do it. : : Forget NeXTSTEP applications (in the sense of the nice apps : which have GUI interfaces). Doing something based on Apple's : internal work, or based on SysV, is bound to slow down the : project. The issue won't be whether some ancient NeXTSTEP : application can run, the issue will be whether the system, : Apple's own operating system, can boot up. : : If the goal is for Apple to prove it's macho by ripping out every : last vestige of unix, then they need to forget about NeXTSTEP and : Rhapsody. Instead, they should go back to the morass which was : Copland. My guess is that Apple has already decided against that. Apple has said that they bought NeXT for OpenStep and WebObjects. I'm not sure this necessarily means NeXTstep (OpenStep/Mach). If Apple goes with a Solaris kernal (one of a lot of options under consideration), wouldn't it be easier to use OpenStep/Solaris, which has SysV Unix under the hood. They certainly could port BSD to whatever kernal they choose, but what if a different choice of middle layer improves compatibility with current Mac applications. The (time) cost - benefit analysis might favor a new middle layer. : > It's clear from Apple's plans to de-Unixize Rhapsody that the : > ordinary user will see no signs of Unixness or CLI. Whether this : > means that power users will be unable to summon a CLI capable of : > at least file handling or developers will have to use some other : > system call to do file removal or renaming is an open question. : : From the various press statements which have come out of Apple, : there is not much of an opening for this question. It is certain : that Apple will provide more user-friendly interfaces to some rough : edges that are still seen in NeXTSTEP. It is certain that they : have work to port NeXTSTEP (or at least OpenStep) to the PPC. It : is pretty much certain that they also have work to port various : Apple technologies (Quicktime Media Layer, etc) to Rhapsody. All : of those are important projects with an obvious payoff. All of : those will require time to do. : : It is also certain that if they don't deliver some kind of credible : operating system, running on their own hardware, by January 1998, : then this whole exercise is going to be seen as a disaster. They : *must* deliver a product. They can not go around taking on other : big projects (like "ripping out unix") simply because someone : *thinks* their life will be horrible if the executable for 'grep' : is sitting on their hard disk. Hmm, seems we're reading the same statements very differently. To my mind, the assault Apple is planning on the Unixness is clear from Hancock and Amelio's comments. It sounds like by the time of the unified release, the GUI will be much more familiar to Mac users than NeXT users, certainly more than cleaning some rough edges. The question is whether the de-unixizing will be cosmetic or deeper. As someone who's life would be better with grep on my hard disk, I hope that such features will still be accessible if you want to use it, but I'm far from certain. I agree that they face time pressure but they also face pressure from current Mac users to produce a system which is at least familiar. : People keep thinking that Apple has plenty of time to go off on : all sorts of exotic projects here. They do not. They must deliver : a product this year (as a developer version), or they will look : rather stupid. They have *plenty* of work to keep them busy without : some of these nonsense projects. Why add "Work for the sake of : Work" when they already have "Work for the sake of staying in : business" to worry about? : : > I think it'll be 3 months before even Apple-NeXT is sure. They : > do seem intent on replacing the Mach 2.5 kernal, so I think the : > kernal decision needs to be made before the middle layer will be : > finalized. : : There are some issues which will take at least a few months for : Apple (and former NeXT) to work out. Hopefully they will conclude : that they need to concentrate on producing a product, and on projects : which have obvious benefits. This is certainly true. But the question remains, obvious benefit to whom. The set of projects which benefit current NeXTStep users is not identical to the projects which benefit the vastly larger community of current Mac users. I think that Apple will expend the majority of its effort on pleasing the latter group. This will result in disappointment for the current NeXT users who want NeXTStep for PPC, with Quicktime and a few other technologies. The question is how much disappointment. I don't think Rhapsody will please the people who want NeXTStep 5. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: jmeacham@meacham.jlc.net (The Rev. James David Meacham) Newsgroups: comp.sys.next.programmer Subject: DevTools 3.0 on 3.2 black installation? Date: 18 Jan 1997 01:39:08 GMT Organization: JLC-net, Milford NH Message-ID: <5bp9jt$kl4@mozart.jlc.net> Hi All, I'm trying to get into some programming on my NeXTStation. I'm a more or less complete novice, and I'm getting my feet wet with C. Problem is, that none of the things I need (cc, etc.) are in the user release 3.2. Is it possible to succesfully install the dev tools from my 3.0 disk and use them on my 3.2 installation? any suggestions would be appreciated. Peace, James -- The Rev. James David Meacham First Unitarian Congregational Society of Wilton Center, NH e-mail:jmeacham@meacham.jlc.net 603-654-9518 (Church) 603-654-9590(Home) 603-654-2248(fax) Church Home Page: http://www.jlc.net/~jmeacham/index.html Personal Home Page: http://www.jlc.net/~jmeacham/jameshome.html
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 17 Jan 1997 17:35:49 -0800 Organization: Cygnus Solutions Message-ID: <qdn2u7u5my.fsf@blues.cygnus.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> milkweed@plainfield.bypass.com (Anders Pytte) writes: > I can see how messing with instance variables would cause alot of > grief since all clients would need to be recompiled for correct > binding - thereby defeating a main advantage of Obj-C. [...] > Wouldn't the same follow with changes to methods? Even if the method > tables are not static, releases of a library would still need > consistent method tables offsets, right? I believe that each method name is mapped to a unique hash code in the interpreter, which is used to look up the method itself in a hashtable during message dispatch. The result is that adding and deleting new methods won't cause any offsets to go screwy. > Compile-time binding would seem necessary to know the correct data > offsets for mixed classes. Is this why Obj-C doesn't support > multiple inheritence? All the Obj-C developer snot like "better off > without it" and "I really don't miss it" sounds like sour grapes to > me. I'm not convinced that adding MI to Objective-C would be that difficult to do, although I suspect that it would be slow, since you'd effectively be performing a `respondsTo:' for each superclass. Note that MI is inherently ambiguous in a dynamic Objective-C model, and I doubt that any decision on how to satisfy the ambiguities is going to please everyone. If multiple superclasses implement the same method, which one do you pick? Do you only execute one or all of them? If all of them, do you return the results of the last one (or first one) or somehow make all the results available? During message dispatch, if one of the superclasses implements a generic `forward:' method, should you execute it or check the other superclasses for the method itself? What if two superclasses implement `forward:'? Any answers to those questions are *not* going to satisfy everyone, which is one reason why C++ programmers occasionally complain about the MI choices and end up hacking around them. It's also why Objective-C (and Smalltalk, and Java, and ...) effectively chose to let the programmer decide what the best inheritance scheme is. In any event, you're better off without it. I really don't miss it. :-) > The Obj-C community has listed a number of positive features, but I > find many of those features to suffer from significant limitations, > and they have not convincingly countered arguments in favor of C++. That's fair. IMHO, you use whatever language you're most comfortable with. Like I've said elsewhere, C++ is a great implementation of C. I'm not convinced that it's a very good object-oriented language, but that's because it doesn't have many of the Smalltalk-like features that I've come to appreciate in an OOL. -- Stephen L. Peters speters@cygnus.com PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "What, do you think soup is a biped?" -- Crow, MST3K
From: Phil Stripling <philip@remove.crl.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 21:50:58 GMT Organization: CRL Dialup Internet Access Message-ID: <5bos82$ccr@nexp.crl.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya02368000080197223631 0001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> <jinx6568-1601971352540001@news.sover.net> <waqarE44C34.6s2@netcom.com>: Organization: The Civilized Explorer Distribution: Waqar Malik <waqar@netcom.com> wrote: : : I can't imagine any Mac user forgoing DropStuff or Stuffit Expander for : : tar... or _anything_ for emacs (don't know what cc is, could somebody : : describe?) Well, thank goodness emacs has already been ported to the Mac, so I don't have to forgo it. It's _very_ handy to have identical text editing capabilities on my Mac and my UNIX dial up. thankyouverymuch. -- Phil Stripling |Sorry to make it difficult to reply The Civilized Explorer |but you know what needs to be removed http://www.cieux.com/~philip/
From: tbrown@netset.com (Ted Brown) Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: Fri, 17 Jan 1997 21:14:14 -0500 Organization: NetSet Internet Services -- Columbus, Ohio Message-ID: <tbrown-ya023580001701972114140001@news.netset.com> References: <5aubl0$aql@abel.ic.sunysb.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5aubl0$aql@abel.ic.sunysb.edu>, rlarson@semlab5.sbs.sunysb.edu (Richard K. Larson) wrote: >I realize that a gazillion issues with NeXTSTEP/Rhapsody are up in the air at >the moment, but is there any sense out there about how easy/difficult it is >going to be to move existing NS applications to Rhapsody? For example, > > - if Apple changes from Mach 3.2 to Nukernel, will that entail significant >reprogramming, > - what about the QuickDraw/DisplayPS issue? > - etc. > >I mostly interested in how the possible choices now facing Apple will impact >on the issue of moving over. Obviously it won't be possible to say "it'll be >easy" vs. "it'll be hard" at this stage. A microkernel change should pose much of a problem You can already move from OpenStep/Mach to OpenStep/NT. If Apple wants Rhapsody to be OpenStep compliant, they can't change all that much. It's unclear if Apple will do so or not (but it seems silly to not conform). I would imagine that even if Apple uses QuickDraw GX as the base imaging system, there will be a transparent access to a DPS->GX converter, so older OpenStep programs can run w/o modification. -- Ted Brown tbrown@netset.com
From: "Gregory H. Anderson" <greg@afs.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Fri, 17 Jan 1997 21:18:26 -0500 Organization: Anderson Financial Systems Inc. Message-ID: <32E032F1.3D7@afs.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Pytte wrote: > I can see how messing with instance variables would cause alot of grief > since all clients would need to be recompiled for correct binding - > thereby defeating a main advantage of Obj-C. (If i am incorrect, correct > me so my mental model of how the language is implemented improves). > Wouldn't the same follow with changes to methods? Even if the method > tables are not static, releases of a library would still need consistent > method tables offsets, right? No, because method tables are not maintained that way in the ObjC runtime. All method tables are constructed on the fly as extensible HashTables. There is no C++ style VMT. But ivars ARE maintained as a set of nested structs (one per class), which is why the compiler does need to know their offsets. > But the same flexibility would also make implementing multiple inheritence > rather difficult, I imagine. Compile-time binding would seem necessary to > know the correct data offsets for mixed classes. Is this why Obj-C doesn't > support multiple inheritence? All the Obj-C developer snot like "better > off without it" and "I really don't miss it" sounds like sour grapes to > me. I think it really boils down to the fact that the Objective C runtime metaclass information makes no allowance for MI, just as it has no way to point to a list of class variables (although it does have a pointer to a list of class _methods_). Both _could_ be added to the metaclass structs, but the Keepers of the Language have seen fit not to. The lack of class vars has always bothered me, but I wasn't about to go mucking in the runtime. That said, I really don't miss MI, whether or not someone thinks I would be better off without it. I find objects-owning-objects (which I described the other day) and delegation/forwarding sufficient. > I found the concept of the "poser" class pretty interesting. Thanks for > filling me in. From all I have heard, though, I would still not conclude > that Obj-C is a superior language in a preponderence of categories. The > Obj-C community has listed a number of positive features, but I find many > of those features to suffer from significant limitations, and they have > not convincingly countered arguments in favor of C++. Gotta disagree with you there. Why do you think Java is so much more like Objective C than C++ (except for certain syntacical conventions)? Greg
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 18 Jan 1997 02:14:34 GMT Organization: Cygnus Support Distribution: world Message-ID: <5bpbma$evv$1@majipoor.cygnus.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> Cc: milkweed@plainfield.bypass.com Note: My reply is in generic tone, NOT specific working code. My Objective C method names may not be exact (I've used smalltalk far more than Obj-C, and much more recently). I'm conveying the overall concepts, not specific implimentations. In <milkweed-1701971832020001@port12.chester.smallmedia.com> Anders Pytte wrote: > In article <5boc53$kft@dfw-ixnews11.ix.netcom.com>, aisbell@ix.netcom.com > (Art Isbell) wrote: > > > > Objective-C supports private, protected, and public instance variables, > > but all methods (member functions in C++-speak) are public. Of course, one > > must be aware of their existance to use them, so the interface documentation > > can "advertise" only those methods that one wishes to make public. > > > > Methods defined in categories are first-class methods - i.e., they have > > the same access to instance variables as the methods defined in the main > > implementation and can invoke all methods whether they're defined in the main > > implementation or in other categories. But a familiar caveat applies: those > > who use private, undocumented methods are likely to be burned if the original > > implementations of these private methods change. Instance variables cannot > > be renamed, removed, or added without causing lots of grief, so that's not > > likely to happen. > > I can see how messing with instance variables would cause alot of grief > since all clients would need to be recompiled for correct binding - > thereby defeating a main advantage of Obj-C. (If i am incorrect, correct > me so my mental model of how the language is implemented improves). > Wouldn't the same follow with changes to methods? Even if the method > tables are not static, releases of a library would still need consistent > method tables offsets, right? > I think you're still thinking like C++. In C++ the class is really a structure like entity (I forget the EXACT end structure.. it's something conceptually like: struct this-class { struct memberfuncs { int *foo(); void *bar(); .... etc .... }; struct membervars { ... etc ... }; } Thus, to call foo, you need to know what the offset in the class structure is for that first pointer to a member function, because that's how structure references work. As a result, to do something like: (*aPointer).foo(); aPointer must be of a type whose class defines a foo member function, so that the type information for aPointer includes a struct offset for the foo pointer-to-a-function. You do NOT have generic object pointers in C++. You have "pointers to an ancestor which is the least common denominator of generic behavior". Any member function you wish to invoke in your 'youngest' classes via a generic pointer must be implimented in a class that they all inherit from. Objective-C does NOT work this way. In Objective-C, the struct that describes a class is more like this: struct this-class { ivar-list-type *ivars; method-list-type *methods; } (actually, the two datums are in 1 Part of the Obj-C runtime is taking the [anObject message], and looking through the class' list of methods (each node of the list contains the method selector ("name") and a pointer to the function that impliments it), and making a call to the right function. Therefore, you don't need to know any offset. You get a runtime dynamic binding of a message to a piece of code to run. For this "tax", you get true dynamic/generic message ability. A generic object id can recieve _any_ message (if it doesn't have a method, or inherit a method, for that message, the runtime invokes [self doesNotRespondTo]; ), and in order to have 2 objects that will respond to the same generic [randomObjectId thisMessage]; call, they do not have to inherit that method from a common ancestor. In fact, they could be the only two classes in the entire tree that have methods with that name. (many C++ advocates incorrectly say that "since every Obj-C object inherits from 'Object', it's the same thing".. but it's not.. in order to get the 'same thing' in C++, you not only need to have everyone inherit from the same 'Object' class, 'Object' would have to define every possible method (implimented or not)) That's why you don't have to worry about adding methods. When you load the class structure into memory, you load in the list of methods.. and when you load in the library that extends the class, you're just adding to that method list. Classes that pose don't worry about it because they just have a different list of methods, and instead of invoking "doesNotRespondTo" for methods they don't impliment, they probably just pass it on to the class they're posing as, or load that classes list of methods into their own list.. or something :-) ... Why is it different for Ivars? Because Ivars aren't handled by the Runtime. Everything of the form "[anObjectOrID message:selector]" is turned in to a call to the Objective C runtime functions. But in a method body, you don't access instance variables that way. You reference them just like local variables in C .. so they're handled by the compiler at compile time... thus, you can't change/redirect the list of Ivars. (though, if you play with the actual class structure, you can dynamically access ivars .. but that's not the 'typical' access mechanism..it's not a very programmer-friendly interface). > But the same flexibility would also make implementing multiple inheritence > rather difficult, I imagine. Compile-time binding would seem necessary to > know the correct data offsets for mixed classes. Is this why Obj-C doesn't > support multiple inheritence? All the Obj-C developer snot like "better > off without it" and "I really don't miss it" sounds like sour grapes to > me. > Again, I believe it has more to do with "following the smalltalk model of objects", where Smalltalk found Multiple Inheritance unnecessary (they did add it to smalltalk at one point, and later removed it). Thus, Objective-C never bothered with it. Compile-time binding is necessary for MI in a static-structure based class environment like C++. Implimenting the basics of MI into the Objective-C language probably isn't too hard to do, it has just never been considered necessary by those who created/control the language. > I found the concept of the "poser" class pretty interesting. Thanks for > filling me in. From all I have heard, though, I would still not conclude > that Obj-C is a superior language in a preponderence of categories. The > Obj-C community has listed a number of positive features, but I find many > of those features to suffer from significant limitations, and they have > not convincingly countered arguments in favor of C++. > Well, for one, there's only a very few new additions to the syntax/semantics of the language and its operators. It's basically the message construct ('[anObject aMessage:selector'), and the @ directives for the different pieces of defining a class (@implimentation, etc). C++ has an aditional semantic meaning for TONS of operators, and thus a new syntax for quite a few of those operators. This makes C++ a bit more arcane. You can learn everything you need to know about things that are new in Obj-C over C in a short chapter. I'm not sure _anybody_ really comprehends everything that C++ has changed since it stopped being C. For two, C++ uses a very static and limited concept of messaging, as described above. It's basically nothing more than a structure full of pointers to functions, and a compiler that finds which of your ancestors owns the function of that name. Objective-C also has a structure with a list of functions, but it's a dynamic list, not static. Dynamic binding also gives you greater flexability. For three, the mapping of Objective-C statements to C statements (ie. a message maps to a single function call) tends to be lower than mapping C++ statements to C statements, because of all of those new semantics applied to existing operators. Basically, in the same way Smalltalk is a dream for rapid prototyping, so is Objective-C (and yet, since it's also a compiled language, not an enterpreted environment, it's also good for deploying discrete end products). C++'s static overhead (overhead to the programmer, not the CPU), on the otherhand, does not lend itself to this. Obj-C also lends itself to smaller footprint executables, and simpler class hierarchy trees/designs, because the dynamism lends itself to cleaner interobject/interclass interfaces. Which all lends itself better to small, elegant, concise coding. Not to mention the general "feel" of programming in the two languages (I've done more C++ than Obj-C, by the way). My .sig could have "Obj-C" in place of Smalltalk. I'm sure some person more familiar with Objective C than I will come along and clear up the specifics of my post, I've probably made more than few detail errors... but the general concepts I think are in place. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 18 Jan 1997 02:11:43 GMT Organization: Netcom Distribution: world Message-ID: <5bpbgv$m6@sjx-ixn8.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> rdogra@mailserv.metro.mci.com (Rajnish Dogra) wrote: > maury@softarc.com (Maury Markowitz) wrote: > > I think Apple's only real interest in the project is to get a working OS > >that is clean and doesn't have warts. Seeing as OpenStep runs over NT, > >it's demonstratable that you can rip out ALL the Unix utils and end up > >with a working system. > No... > As far I know NeXT ships (with OPENSTEP for NT) some if not all the unix > utilities and even has Terminal.app. OPENSTEP/NT Deployment includes only a small subset of typical Unix utilities with the Developer version including additional utilities necessary to build apps, many (all?) of which are GNU utilities. Unfortunately, Terminal isn't included, but sh, the Bourne shell, is included. It runs in the Windows Command tool, a lame excuse for a terminal application. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 17:05:57 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DFF7C5.2090@steeldriving.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> <5bkh7r$big@darla.visi.com> <maury-1601971544430001@199.166.204.230> <jinx6568-1701971519160001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Johnson wrote: > On the other hand, how does one abstract a Photoshop CMYK image in > layers with a selection outline on the cyan plane that is being used to do > a feathered blur? For Photoshop/Painter, the bitstream manipulation equivalent would be plug-ins. Only that Photoshop plug-ins are far more complex and more limited in usability - writing an application that can use a Photoshop plug-in is non-trivial. -- Jonathan W. Hendry jon @ exnext . com
Date: Fri, 17 Jan 1997 18:32:02 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Distribution: world Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <milkweed-1701971832020001@port12.chester.smallmedia.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> Organization: Milkweed Software In article <5boc53$kft@dfw-ixnews11.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > Objective-C supports private, protected, and public instance variables, > but all methods (member functions in C++-speak) are public. Of course, one > must be aware of their existance to use them, so the interface documentation > can "advertise" only those methods that one wishes to make public. > > Methods defined in categories are first-class methods - i.e., they have > the same access to instance variables as the methods defined in the main > implementation and can invoke all methods whether they're defined in the main > implementation or in other categories. But a familiar caveat applies: those > who use private, undocumented methods are likely to be burned if the original > implementations of these private methods change. Instance variables cannot > be renamed, removed, or added without causing lots of grief, so that's not > likely to happen. I can see how messing with instance variables would cause alot of grief since all clients would need to be recompiled for correct binding - thereby defeating a main advantage of Obj-C. (If i am incorrect, correct me so my mental model of how the language is implemented improves). Wouldn't the same follow with changes to methods? Even if the method tables are not static, releases of a library would still need consistent method tables offsets, right? But the same flexibility would also make implementing multiple inheritence rather difficult, I imagine. Compile-time binding would seem necessary to know the correct data offsets for mixed classes. Is this why Obj-C doesn't support multiple inheritence? All the Obj-C developer snot like "better off without it" and "I really don't miss it" sounds like sour grapes to me. I found the concept of the "poser" class pretty interesting. Thanks for filling me in. From all I have heard, though, I would still not conclude that Obj-C is a superior language in a preponderence of categories. The Obj-C community has listed a number of positive features, but I find many of those features to suffer from significant limitations, and they have not convincingly countered arguments in favor of C++. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 23:54:11 GMT Organization: Indiana University, Bloomington Message-ID: <5bp3f3$1j2@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> NNTP-Posting-User: glhansen In article <maury-1701971140380001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >>I've been tearing my hair out the last couple days dealing with >>HP-UX, Hewlett-Packard's version of Unix. They made a raft of >>gratitious filesystem changes that added NOTHING to the value >>of the OS, except to make it difficult to work with in a multivendor >>Unix environment. >In article <5bmjkk$p15@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> Uh... maybe I'm getting my contestants mixed up. Who was it that didn't >> want a hard drive littered with /bin and /etc and stuff? I think this is >> a good argument for leaving them in. > > Actually it's a great arguement for getting rid of them. I just don't understand you, Maury. You complain about HP making gratuitous changes in the file system that does nothing but make it difficult to work in a multivendor Unix environment, and then advocate Apple making gratuitous changes in the filesystem that does nothing but make it difficult to work in a multivendor Unix environment. The only reason I can see for that is you have a vendetta against Unix and oppose compatibility on general principles. It sure doesn't seem to be for functional reasons. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: 18 Jan 1997 00:13:58 GMT Organization: MHPCC Message-ID: <5bp4k6$7q1@kaopala.mhpcc.edu> References: <5aubl0$aql@abel.ic.sunysb.edu> Cc: rlarson@semlab5.sbs.sunysb.edu One possible clue to this answer can be found by clicking on the apple icon at <http://www.next.com/Pubs/Documents/Download/> "All OpenStep documentation applies to Rhapsody! That means you can develop OpenStep applications today and simply recompile them when Rhapsody is released." In <5aubl0$aql@abel.ic.sunysb.edu> Richard K. Larson wrote: > I realize that a gazillion issues with NeXTSTEP/Rhapsody are up in the air at > the moment, but is there any sense out there about how easy/difficult it is > going to be to move existing NS applications to Rhapsody? For example, > > - if Apple changes from Mach 3.2 to Nukernel, will that entail significant > reprogramming, > - what about the QuickDraw/DisplayPS issue? > - etc. > > I mostly interested in how the possible choices now facing Apple will impact > on the issue of moving over. Obviously it won't be possible to say "it'll be > easy" vs. "it'll be hard" at this stage. > > Thanks! > > -Richard Larson > > -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Fri, 17 Jan 1997 22:40:51 -0500 Organization: TofuSoft Message-ID: <jchan-ya023580001701972240510001@news.apk.net> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <qdn2u7u5my.fsf@blues.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit I thought multiple inheritance could be 'implemented' by using Obj-C protocols and embedding several classes within a single class (pardon me if this is wrong - I've only started studying Obj-C for the last two days). This is quite similiar to Java's implements keyword(?). --- The Evil Tofu (Only Human)
From: TheCopyCatShop@NA.net Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5bp5g6$drj@mtinsc01-mgt.ops.worldnet.att.net> Control: cancel <5bp5g6$drj@mtinsc01-mgt.ops.worldnet.att.net> Date: Sat, 18 Jan 1997 03:30:37 +1 Organization: Copy Shop Message-ID: <cancel.5bp5g6$drj@mtinsc01-mgt.ops.worldnet.att.net> References: <5bp5g6$drj@mtinsc01-mgt.ops.worldnet.att.net> EMP/ECP spam cancelled by hweede@berlin.snafu.de. This is an ongoing spam whose Breidbart index already is above 20. See my report "TheCopyCatShop" or "summary of auto-cancels" in news.admin.net-abuse.bulletins. Subject was: CD R Media Low Prices.
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 1997 20:44:22 GMT Organization: The University of Calgary Distribution: world Message-ID: <5boob6$1k0s@ds2.acs.ucalgary.ca> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <5bn20b$lmn@sjx-ixn6.ix.netcom.com> <maury-1701971146010001@199.166.204.230> <5boces$kft@dfw-ixnews11.ix.netcom.com> In article <5bn20b$lmn@sjx-ixn6.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > As has been stated on several occasions, OPENSTEP programs aren't > *required* to use Unix shell utilities. In fact, an OPENSTEP program would be required to *not* rely on these utilities. OPENSTEP can be hosted on a variety of platforms, many of which do not include the utilities (or even the shell.) Nothing is going to prevent developers from doing inane things. There will be applications which break the UI guidelines, access hardware directly, delete documents created with competitor's products, rely on bugs in the API, and so forth. The best you can do is to recommend against it and raise a fuss when it does happen. Leave the utilities in place for those who care to use them. Make them invisible to those who would rather pretend they didn't exist. Rewrite the ones that desperately need it (perhaps starting with sendmail...) and we can all live together in peace. -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: rr@xs4all.nl (rr) Newsgroups: comp.sys.next.programmer Subject: old NeXTStep version and PPP Date: Sat, 18 Jan 1997 02:11:46 +0100 Organization: XS4ALL, networking for the masses Message-ID: <rr-1801970211460001@ztm07-20.dial.xs4all.nl> Hi, This may not be the right place for these questions... My excuses in advance. I have a NeXTCube running an old version of NeXTSTep (2.x). I want to get my email with it. I also have a modem that came with it ( HSD InterFax 24/96 NX -not much but ok for just email, Iguess) I not sXXt about UNIX. I'm having a lot of trouble getting this setup to work for me. I want to get/send email. That's not too much to ask for such a beatifull machine. I gather I have to set up uucp. I find the manual not very clear on this, but maybe I'm just stupid. I'm also wondering if there is a version of PPP that will work with this old version of NeXTSTep. Does anybody know this ? Also, last the Cube with this version of NeXTStep doesn't seem to read macintosh-floppies the manual says it can with the help of some software, but doesn't state what or where to get it. Does anybody know this ? help is much appreciated, Rodney
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 20:57:30 GMT Organization: Global Objects Inc. Message-ID: <5bop3q$lul@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : In article <5bm1pa$i8u@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > : > : > The existance of a lot of Unix utilities in Rhapsody would be a > : > tremendous disincentive to some Mac developers to port their software > : > to the new OS. > : > : Why, because they <gasp> may be useful? :) > > Example, does the existance of tar, a reasonably able backup utility with > a really unfriendly UI, make companies like Alladin or Dantz who make > backup software more or less eager to port to Rhapsody? I think less > likely, because the number of potential buyers for Stuffit is reduced > by the existance of tar and freeware extentions. Maybe, but I don't believe it. There was a program for NEXTSTEP-- a commercial app which sold for around $100--called enTar.app. It was basically a GUI wrapper around tar. But that GUI was a lot friendlier to use than tar itself. Those of us who were UNIX propellerheads and didn't mind using tar used tar. All the plain Joe NEXTSTEP users who didn't want to deal with UNIX (and even some of the propellerheads) bought enTar because it was easier to use, kept you in the GUI, and so on. I don't think the existence of tar in the system kept anyone from producing commercial software for backups. (There's also SafetyNet.app, by the way, in the same market area, so I don't think that tar's existence squelched any apps.) Oh, and there's also the freeware Opener.app, too. :-) [By the way, one thing I liked about enTar is that it gave you a browser window into the .tar file so that you could select specific files for extraction. That alone would make it worth buying for most people; recovering a single file from a .tar file never was, IMHO, a fun thing to do with the CLI. This is a place where the GUI was definitely an improvement worth paying for.] I think that argument extends to all the UNIX utilities. They're nice for those who know them and don't mind the unfriendly interface, but for the typical Mac user, they'll not be a good solution. Those users will buy third party software, which will likely mean a GUI. Another example, the free "sc" program (_S_preadsheet _C_alculator) didn't keep me from buying (and using) several NEXTSTEP spreadsheet apps! sc is nice for what it is, but the commercial apps are better supported, easier to use, and so I'll pay for them because of my increased productivity. Also, the spreadsheet apps added to the capabilities of "sc", and that added value (plus the support) is something most people will pay for...meaning there is always a market. The same sort of thing is true with a lot of commercial apps already in existence in the Windows/Mac market--there are freebies out there, but typically that doesn't keep the commercial vendors from selling similar apps. How many free screen savers are out there? And how many people bought AfterDark anyway? So: existence of UNIX utilities probably won't make a hill of beans' worth of difference to a Mac user. They'll still buy the GUI apps. Heck, I'm a UNIX propellerhead and I still buy a lot of GUI apps that duplicate UNIX command functionality--because they make me more productive than the CLI does. On the other hand, I use the CLI daily for tasks that would otherwise be too cumbersome to do in the GUI. Productivity is up when you use the right tool for the job... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: GX versus DPS (a Trivial example) Date: Fri, 10 Jan 1997 15:44:01 -0500 Organization: Atria Software Message-ID: <maury-1001971544160001@199.166.204.230> References: <jcr.852594456@idiom.com> <mmunz-0601971958520001@slc-dial-32.inconnect.com> <jcr.852636452@idiom.com> <mmunz-0801972323330001@slc-dial-65.inconnect.com> <jcr.852844537@idiom.com> <5b42oo$ebp@news.xmission.com> In article <5b42oo$ebp@news.xmission.com>, don@globalobjects.com wrote: > (2) When you compare x86 and m68k series, you find that Motorola's > FP performance is better than that of an equivalent Intel CPU. This was certainly true up to and including the 486, but seems to be no longer true for the newer Intel processors. > So you can count on DPS to take full advantage of the FPU! In fact, Can it run at all without it? I mean usefully. Maury
From: Charles F Waltrip <waltrip@aurora.jhuapl.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 18:12:12 -0500 Organization: The Johns Hopkins University Applied Physics Lab Message-ID: <32E0074B.2C67@aurora.jhuapl.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > [...] > Well who said anything about a Unixy system? Apple didn't buy NeXT > for Unix, they bought if for OpenStep and the underlying OS (which, > yes, is Unixy). > [...] > > I think Apple's only real interest in the project is to get a > working OS that is clean and doesn't have warts. Seeing as OpenStep > runs over NT, it's demonstratable that you can rip out ALL the Unix > utils and end up with a working system. > Well, yesssss. Yes, Apple bought NeXT for OpenStep and the underlying OS. And, yes, OpenStep doesn't depend on the particular underlying OS that Apple bought. And, yes, you can rip out all the UNIX utils and, provided you replace them with something that provides equivalent functionality, you can end up with a working system. I realize that, in saying they CAN do that, you are not necessarily advocating that they actually DO it. I believe that it would be no problem that Apple/OpenStep depends on the existence of those UNIX utilities for its operation. However, it would be a major problem that Apple/OpenStep depends on the direct use of those utilities for system administration. NeXT made efforts to avoid direct use of UNIX utilities such as Netinfo Manager for network management (a pretty good--but not insanely great--application), Preferences Manager, Print Manager, etc. It was a good start but this sort of thing is somewhat pedestrian compared to other, more exotic interests. The effort seems to have been largely abandoned in favor of more interesting technologies. Dirt and warts remain. Are they much worse than the dirt and warts in MacOS or Windows 95/NT? I think they are worse but not much worse. I think the shipping Apple/OpenStep will have to be much better in this respect than MacOS or Windows 95/NT. This is a first impression item that it is important NOT to have to overcome with later improvements/fixes. Ease of administration is a HUGE plus for the entire spectrum of users...from the home user to the Fortune 500 CIO. In fact, there ARE a lot of nice non-UNIX utilities and services that you get with OpenStep/Mach that you don't get when with, say, OpenStep/NT. Hopefully, many or all of them will find their way into Apple/OpenStep. (Edit/Mail/Digital Librarian/Fax-Print Integration/...) In the pre-Apple days, this newsgroup had a thread advocating an OpenStep Lite. I advocated an OpenStep Heavy for NT that included providing a lot of the system features, apps and utilities present in OpenStep/Mach but missing in NT. I still think it's a good idea. But perhaps it will show up for both Win 95/NT as OpenStep Heavy that includes the features, apps and utilities that will show up in OpenStep/Apple. Now THERE'S something that would make it exciting to be a Product Manager. Chuck ____________ Charles F. Waltrip Opinions expressed are my own. The Johns Hopkins University Applied Physics Laboratory email: waltrip@zephyr.jhuapl.edu phone: (410) 792-6596 fax: (410) 792-5597
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Fri, 17 Jan 1997 15:15:34 -0600 Organization: mementech, inc. Message-ID: <32DFEBF6.1072E12A@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > Uh... maybe I'm getting my contestants mixed up. Who was it that > > didn't want a hard drive littered with /bin and /etc and stuff? > > I think this is a good argument for leaving them in. > > Actually it's a great arguement for getting rid of them. What argument? Please leave some context in your quoted material guys. [followups trimmed back to advocacy groups, for the sake of the poor people in *.programmer who have work to do...] -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 17:32:12 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DFFDEC.74E@steeldriving.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : Why, because they <gasp> may be useful? :) > > Example, does the existance of tar, a reasonably able backup utility with > a really unfriendly UI, make companies like Alladin or Dantz who make backup > software more or less eager to port to Rhapsody? I think less likely, > because the number of potential buyers for Stuffit is reduced by the > existance of tar and freeware extentions. There's a Mac program that handles tar, that was free (I think). Did Dantz or Aladdin die out when that came out, about 5 years ago? -- Jonathan W. Hendry jon @ exnext . com
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 1997 23:00:23 GMT Organization: ace dot net internet technologies Message-ID: <5bp0a7$ouv@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> <5bkh7r$big@darla.visi.com> <maury-1601971544430001@199.166.204.230> <jinx6568-1701971519160001@news.sover.net> Chris Johnson (jinx6568@sover.net) wrote: : Here is a serious question- how prevalent _is_ bytestream manipulation : in the standard Mac software base? I'd imagine pretty common. See below. : : Certainly something like an IRC program lends itself to bytestream : manipulation. It is just possible that things like video editors _can_ : operate on bytestreams though clearly there is non-linear stuff you could : do that begins to touch on other ways of handling data. What's a video editor? A program that deals with a video stream. cat foo.avi |avi2mpeg | mpegscale 0.7 > foo.mpeg I'm not saying that's better or worse than a graphical interface, but i can see where it'd be useful. : On the other hand, how does one abstract a Photoshop CMYK image in : layers with a selection outline on the cyan plane that is being used to do : a feathered blur? I think, though I could be wrong, that even with : databases and spreadsheets the linkages of something like ClarisWorks are : stepping past the ability of a single byte stream to describe what is : going on. This is the reason we have applications and the clipboard, or on NEXTSTEP, services. Select a square of a bitmap in, say, NXPaint, or something, and do Services -> Photoshop -> Gaussian Blur.. It'd be good. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: Encryption Message-ID: <E3tB8n.IL@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <5b37rh$ss5@lastactionhero.rs.itd.umich.edu> Date: Fri, 10 Jan 1997 21:48:23 GMT jdevlin@umich.edu wrote: > > Moreover, NEXT owns a patent on Fast Elliptic Encryption (FEE) - a > cryptosystem which, according to reported hints from Steve Jobs, the NSA > regards as more secure than PGP. (The NSA was rumored to be one of NEXT's > larger customers ...) I am not sure if NeXT owns the patent or NeXTs mathematics guru...Richard Crandall (hey..maybe he's one of the reasons why Mathematica has always remained available for NeXTSTEP). Side Note: Elliptic Encryption can provide more unique keys with shorter key length the public key systems based on primes. Richard found a way to remove all divisions in the EE encryption and could replace the with simple plus and mius operations. Thuse it is called FEE. FEE is more secure then PGP since it can take a 40bit key and will cause the same amount of "cracking" headache as a 120bit PGP (ok..these numbers are wrong I would have to look them up...but you get the idea) At ObejctWorld'95 NeXT officially said that they will provide an encrption API with release 4.0. We all know they didn't. And we all know that encryption is a hairy issues in some countries (e.g. US, France) > > SUGGESTION: Apple should include a documented interface for encryption > in both Mail.app and WorkspaceManager, and allow customers to load their > favorite cryptographic engine as a bundle. This IMHO was planned and hopefully will be deliverd. > Moreover, Apple should follow > MIT's example and make a FEE bundle available on their website to anyone in > the United States and make the Objective-C implementation of the algorithm > available without restriction as an ascii file. Between FEE and PGP, This is unlikely since the implementation is something they can sell (to NSA for example) As far as I know the algorithm is described in some paper by Richard Crandall..but I am not sure if all the details of the implementation are available. But then..if it is patented you would not be allowed to implement it. > virtually everyone would have access to military grade encryption with a > consistent and well thought out GUI. This is why I won't happen :-) Governments are afraid of encryption and still hope that people will remain dumb enough to believe the claim that encryption prohibition is just to keep the "bad guys" from using it. "Bad guys" don't care if it is prohibited. Its the "good guys" who are the target. Aloha Tomi
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Thu, 09 Jan 1997 19:04:56 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32D587A8.5ECB@steeldriving.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit <followups trimmed to limit ecological damage> Maury Markowitz wrote: > > In article <5b39sm$2u9@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > > stuff which is used by the OS itself... > > My mom's HD is 80Meg. So now we get to buy a new HD to store files > she'll never use. Hmmmm. Something tells me your Mom won't be running out to buy the new OS. -- Jonathan W. Hendry President, Steel Driving Software, Inc. OpenStep, Delphi, and Java Consulting in Cincinnati http://www.steeldriving.com
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 18 Jan 1997 08:04:15 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bq05v$7t9@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Example: does the existance of tar, a reasonably able backup > utility with a really unfriendly UI, make companies like Alladin > or Dantz who make backup software more or less eager to port to > Rhapsody? I think less likely, because the number of potential > buyers for Stuffit is reduced by the existance of tar and freeware > extentions. I don't think it effects them one bit. For one, most Mac users are used to Stuffit. They are not used to opening a unix window, and then figuring out all the options on tar. They will be much more likely to spend another $30 for a new version of Stuffit than bothering with tar. For two, Stuffit includes a very nice user interface. It is a "finder interface" to your compressed archive. Tar, by itself, is relatively crude. A front-end to tar might be competition to Stuffit, but tar by itself simply can not compete. For three, *I* don't use tar as a backup utility, and I'm more familar with tar than the average mac user is. I would very much prefer to have something like "Diskfit" for my NeXTSTEP system, and I've been using NeXTSTEP for years. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 00:33:42 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5b4kbm$642@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> In article <maury-0901971045180001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > Standard applications can current assume that Unix is not installed. I > run about 100 applications on my Macs, and not a single one of them calls > anything remotely like Unix. Sure having the utilities allows a lazy > programmer to do less work, but I don't see this as a goal. You apparently aren't a programmer. There are gobs of well-written utilities around, and it's utterly senseless to rewrite them from scratch, especially considering that they have already gone through extensive testing/debugging cycles. Why should an application have code to send mail when it can call an existing mail transport agent? Why should it have code to search files for text when there are already grep programs which are optimized to within an inch of their lives to do this? Etc. Sure, you could make the utilities optional, but if app developers can't assume that they're there, they're not likely to opt to use them, and will end up rewriting lots of things. And when it comes down to it, all the Unix utilities comprise a relatively small portion of the total disk usage. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 18 Jan 1997 06:30:31 GMT Organization: Global Objects Inc. Message-ID: <5bpqm7$lul@news.xmission.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> "Gregory H. Anderson" <greg@afs.com> wrote: > That said, I really don't miss MI, whether or not someone thinks I would > be better off without it. I find objects-owning-objects (which I > described the other day) and delegation/forwarding sufficient. Ya know, the GOF book (Patterns book mentioned here earlier) even says that object composition is more important than inheritance. Which is what the Obj-C people have been saying all along. And that book is written from more of a C++ viewpoint, but it is also written by some people who really know what they are talking about! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 01:01:03 GMT Organization: University of Sheffield, UK Message-ID: <5b44cf$s7g@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> In-Reply-To: <maury-0901971623200001@199.166.204.230> On 01/09/97, Maury Markowitz wrote: > Oh, true enough, but there's a quality and quantity thing. I mean, do I > need all the .conf files? How about the shells and all the support stuff > for them? man pages? > Shells you certainly want, as the OS (as it is at the moment) depends on them. Man pages are not installed as standard (you have to explicitly install the Documentation package). .conf files... hmm, can't say I've ever touched them myself, and I can't see more than half a dozen of them. Again, looks like the system depends on them though. I certainly agree it would be good if AppLE could tidy come of this up... in the fullness of time :-) (Back to this "get something out of the door ASAP theme) > Yeah, but all that stuff adds up a lot in size. I'd personally rather > not have it installed unless I want it. > I'm not sure how much superfluous stuff there really is... much of the space is taken up with things like libraries (20+MB in /usr/lib), the kernel etc. The Bourne shell, for example, is only 120K. The whole of NEXTSTEP, absolute minimum installation, takes up less than 100MB I believe. I don't know just how much MacOS uses, but if you added enough extras to give you the same functionality (i.e. you'd have to add internet connectivity, a number of applications for system administration etc), I wonder if you'd be in the same ballpark? Say 50MB? Or am I being wildly "pessimistic" (I may be, I have no idea... I have a copy of an upgrade for 7.5.5 here, but can't work out the sizes of the relevant files). > Absolutely, and they should get to install it off the same CD. > As others have pointed out, I suspect that so many things would depend on whatever you would like to be made optional that the majority of users would end up having to install this stuff later anyway, after the inconvenience of finding out the hard way that they did need it. At a time when, as I said before, it seems to be difficult to find a hard drive smaller than 1GB, for the sake of a few tens of MB at the most, it doesn't seem worth worrying about "wasted space". (Your concerns about hiding things from the user are fair enough, and I hope others have shown that NeXT had already taken effective steps to address that -- hopefully AppLE can now take a few steps further). Best wishes, mmalc. --
From: jbf@frazer.com (James B. Frazer) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 10 Jan 1997 01:20:37 -0500 Organization: The Internet Access Company, Inc. Message-ID: <jbf-ya023580001001970120370001@news.tiac.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b44cf$s7g@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b44cf$s7g@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > The whole of NEXTSTEP, absolute minimum installation, takes up less than > 100MB I believe. I don't know just how much MacOS uses, but if you added > enough extras to give you the same functionality (i.e. you'd have to add > internet connectivity, a number of applications for system administration > etc), I wonder if you'd be in the same ballpark? My system partition, with the 7.5.5 OS and a minimal set of Unixy utilities, runs to 90MB. Now that's somewhat inflated by my PowerPC architecture; perhaps the equivalent would be 60-70 MB on a 680x0. That's close enough so that Mac fans shouldn't fret. And, believe me, those Unix utilities replace a great many small Mac applications. Barney
From: dlehn@crib.bevc.blacksburg.va.us (David I. Lehn) Newsgroups: comp.sys.next.programmer Subject: OpenStep game development Date: 18 Jan 1997 10:02:35 GMT Organization: Virginia Tech Message-ID: <5bq73r$e18$1@solaris.cc.vt.edu> How are developers supposed to do OpenStep game programming? Apple has *Sprocket. M$ has Direct*. OpenStep has... Is Apple going to push Sprockets for Rhapsody? If you want code to be portable then you end up developing your own layer so you can have DirectX, Sprockets/QuickDraw/QD3D, GNUstep stuff, etc depending on platform. This is either less than ideal or a business opportunity. ;) Perhaps Apples code will work on M$ platforms as OS/NT does now. But that leaves GNUstep portability left to keeping up with non-OpenStep APIs. Maybe NeXT/Apple engineers will sit down and develop great OpenStep extensions to handle sound,various input devices,3D, speach,network,buffered drawing,etc. GNUstep support as well would make apps very portable. -dave --- David I. Lehn <dlehn@vt.edu> | http://www.vt.edu:10021/D/dlehn/ Computer Engineering Student @ Virginia Tech in sunny Blacksburg, VA
Date: Sat, 18 Jan 1997 02:22:10 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <milkweed-1801970222100001@port5.chester.smallmedia.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> Organization: Milkweed Software In article <32E032F1.3D7@afs.com>, greg@afs.com wrote: > No, because method tables are not maintained that way in the ObjC > runtime. All method tables are constructed on the fly as extensible > HashTables. There is no C++ style VMT. But ivars ARE maintained as a set > of nested structs (one per class), which is why the compiler does need > to know their offsets. If i'd thought more carefully I would have realized some kind of method selector would be necessary to support the messaging schemes that'd been described to me. I should have known as I've built that sort of method dispatching on top of other languages in the past. So what kind of relationship exists between the number of methods in a class, the depth of subclassing, and the time to resolve a method call? > Gotta disagree with you there. Why do you think Java is so much more > like Objective C than C++ (except for certain syntacical conventions)? C++ _is_ getting old. But I don't think Java was designed for the purpose of creating large class libraries or large or time-critical systems (even aside from the fact that it is currently implemented as an interpreted language). It's design - like Obj-C - reflects restrictive requirements of an underlying layer as well as the latest thoughts about good programming. I would mourn the loss of stack based objects, mix in classes, and operator overloading as much as I would revel in untyped messaging and other benefits of run-time binding (some of which I suspect can lead to as much chaos as the arcane aspects of C++). In some ways C++ is more pure and abstract because you don't worry about the runtime overhead of creating objects of any little thing and stacking zillions of them in a list (with compile-time binding most such methods duck the virtual tables). I guess if I were to use Obj-C/Next I would still do part of my development in C++. I think the idea of building an OS as an extensible class library is superb, and my sense is that _that_ is what makes Next/OpenStep such a dynamite environment, more than a particular choice of language. I can see that Obj-C was designed to support just such an arrangement - would be much messier with C++. Most of the advantages of Obj-C that have been pointed out to me bear directly on this arrangement. But this is a different issue than merely comparing the features of two languages. Indeed, how often do we choose languages just on the basis of their ideal qualities, abstracted from the realities of our enterprises? Next has delivered a solution more than a language. The advantages of Obj-C don't seem as striking outside of that context. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 18 Jan 1997 04:04:57 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R1801970404580001@news.erols.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au> <5bbuae$b14@news.xmission.com> <scottm-ya02408000R1401972248330001@news.erols.com> <5bkujj$rm5@duke.squonk.net> <scottm-ya02408000R1701970257450001@news.erols.com> <jinx6568-1701971533060001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <jinx6568-1701971533060001@news.sover.net>, jinx6568@sover.net (Chris Johnson) wrote: > Think of the Finder as a file browser/window manager/task switcher >which operates on a 'desktop' paradigm- basically, if you have papers on >your desktop one can overlap the other. > I do understand the Finder. I've been using it for 12 years. :-) > I believe the Finder handles the layering of windows on the screen, >calling apps to redraw their windows in given regions. This is easily >ignored by us Mac users because it is very good at giving the illusion >that stuff just magically works ;) I bet there are Mac users out there who >have never heard of regions and believe the screen draws entire windows, >it's just that the one on the top covers underlying ones ;) > But, since this new Finder wouldn't have to worry about dealing with drawing windows, notifying programs, etc. it can just act as the user interface and disguise whatever unixness may be left underneath. > The finder is pretty cool, really. Odds are Rhapsody will incorporate a >lot of it. But be aware that it may not be the obvious use of copied >appearance and layout- for instance, if the NeXT paradigm doesn't make >much of this, it might grow to be extremely NeXT-like appearance... that >just happens to handle layered windows and direct manipulation very >naturally and well. (P'raps it already does- I've not been lucky enough to >actually use it.) > But if the Finder was handling windows and such then if you quit it (which is relatively simple) and were setiched to your application your windows and such still work. Then when you've quit the last running program the Finder will relaunch itself. Shouldn't be too hard to implement on Rhapsody. -Scott -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 18 Jan 1997 06:53:36 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5bps1g$7t9@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <5booc1$qj@geraldo.cc.utexas.edu> raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: > : raph@porter.as.utexas.edu (William Raphael Hix) wrote: > : > This assumes that Rhapsody will have a Unix layer similar to > : > the BSD Unix emulation middle layer between NextStep and the > : > Mach kernal in OpenStep/Mach. > : > : This is true. That is the assumption. It is a reasonable > : assumption given the high-priority goal of shipping a product > : which works, and doing so as soon as practical. > > I am a veteran of workstation administration, at least at the > workgroup level. It certainly would be absurd to ship a UNIX > system without shells and grep, but again we don't know for sure > how unixy the middle layer will be. Can you point me at press > info which guarantees the existence of the BSD middle layer? If I did, would it do any good? Did you read the interview with Avie? Let's be serious, all of us here are just stating our opinions, none of which will prove anything. The only thing that will be proof is the shipping system, and we have several months before we see that. However, none of us have any intention of shutting up for a few months, so we'll go round-and-round rehashing our opinions and our assumptions. None of them will be proof, they will only be opinions and assumptions. > : It is also certain that if they don't deliver some kind of credible > : operating system, running on their own hardware, by January 1998, > : then this whole exercise is going to be seen as a disaster. They > : *must* deliver a product. They can not go around taking on other > : big projects (like "ripping out unix") simply because someone > : *thinks* their life will be horrible if the executable for 'grep' > : is sitting on their hard disk. > > Hmm, seems we're reading the same statements very differently. > To my mind, the assault Apple is planning on the Unixness is > clear from Hancock and Amelio's comments. I've been reading as many interviews from Apple people as I can find, and I really do think you're picking up the wrong message from the initial comments given by Hancock and Amelio. However, it is also possible that I'm the one getting them wrong. It is also possible that whichever position they truly mean right *now*, that what we will actually get will be different than what they initially expected. > It sounds like by the time of the unified release, the GUI will > be much more familiar to Mac users than NeXT users, certainly > more than cleaning some rough edges. The GUI, yes. I expect that someone looking at a screen shot of a Rhapsody system is more likely to think "That's a Mac" than "That's a NeXTSTEP system". To me this means they replace the dock and File Viewer with something that looks much like the finder (they might have some options to get the NeXTSTEP look, but the standard look will be Mac-ish). This says nothing about ripping out unix. They *have* said things like "NeXTSTEP has done a good job of hiding Unix from the user, but there's still some rough edges. We intend to finish the job". If the job is *hiding* unix, then the job is not *eradicating* unix. Of course, it's still true that all of this is subject to change, as everyone at Apple sits down to work out the details. And I'm sure there are political battles going on inside of Apple over the same issues that they go on in this newsgroup. > The question is whether the de-unixizing will be cosmetic or > deeper. As someone who's life would be better with grep on my > hard disk, I hope that such features will still be accessible if > you want to use it, but I'm far from certain. I agree that they > face time pressure but they also face pressure from current Mac > users to produce a system which is at least familiar. If there is no common task which requires a user to learn Unix, then the user does not have to care that Unix might also happen to be on the hard disk. I agree that Apple has the goal you say it has, but that goal does not require the removal of /bin, /usr, and all the rest of unix. All it requires is more work done at the GUI level, so no user is required to open a Unix shell. > : There are some issues which will take at least a few months for > : Apple (and former NeXT) to work out. Hopefully they will conclude > : that they need to concentrate on producing a product, and on projects > : which have obvious benefits. > > This is certainly true. But the question remains, obvious benefit > to whom. The answer, in my opinion, is "to everyone". Hiding unix is a significant benefit to long-time Mac users, and doesn't really hurt anyone else. Ripping out unix will hurt everyone, including Mac users, because it means Apple needs to start a project to replace all the things which are handled at the Unix layer. The delay hurts everyone, including Apple. And it helps --- who? Not all that many people. I understand that some people might bitch about unix being there, but does it actually *help* them to remove it? > The set of projects which benefit current NeXTStep users is not > identical to the projects which benefit the vastly larger community > of current Mac users. I think that Apple will expend the majority > of its effort on pleasing the latter group. I do too. And I think they should. That does not mean they have to let users dictate low-level implementation details. It just means that a Mac user should not need lots of training sessions to learn how to use a Rhapsody system. However, they have made it clear that some things are going to change. That's the whole point of having a new system. If everything is *exactly* the same as the old system, then you haven't accomplished anything. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: bchin@us.net (Bill Chin) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep 2.0 to 4.1 comparison? Date: 18 Jan 1997 16:08:22 GMT Organization: US Net - MD,DC,VA ISP - info@us.net Message-ID: <5bqshm$e0m@news.us.net> References: <becker-1701971118560001@193.103.65.112> becker@ps.lhag.de (Dirk Becker) wrote: >Are there any similarities between the APIs of NextStep 2.0 as >installed on my Cube, and the current OpenStep / future Rhapsody? >Was the migration more like search&replace NX by NS and add >support for a bunch of new classes, or is it gone into a totally >different direction? It would be wrong to say that the OPENSTEP API's have "gone into a totally different direction." However, there are some significant changes, and IMHO, the alterations were for the better. The basics are pretty much the same, however. Yes, replace NX with NS, but also add in a new root class, autorelease memory pools, class clusters, new classes (NSString), etc. To see for yourself, check this URL out: http://www.next.com/Pubs/PubsCatalog.html Be sure to see the AppKit and Foundation References (downloadable). Also see the OpenStep spec at: ftp://ftp.next.com/pub/OpenStepSpec/ -- Bill Chin - bchin@us.net - NeXTmail/MIME welcomed
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Librarian replacement Date: 10 Jan 1997 14:18:42 GMT Organization: University of Sheffield, UK Message-ID: <5b5j42$bh7@bignews.shef.ac.uk> One of the really useful apps that's always shipped with NS is Librarian. Now, as I understand it, it'll be difficult to port to the new OS since it's dependent on the defunct IndexingKit? So, we may need a replacement? Fortunately the IR world has advanced substantially since Librarian was developed, so I wondered, would it be possible to wrap a GUI around Glimpse or somesuch? Best wishes, mmalc. --
From: jesjones@halcyon.com (Jesse Jones) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Bad mouthing templates Date: Thu, 09 Jan 1997 22:03:30 -0800 Organization: Jet City Studios, Inc Distribution: world Message-ID: <jesjones-ya023580000901972203300001@news.halcyon.com> References: <5b1omq$adg@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5b1omq$adg@nntp1.apple.com>, Michael D. Rossetti <rossetti@apple.com> wrote: > In article <5asdoo$7us@dfw-ixnews8.ix.netcom.com> Art Isbell, > aisbell@ix.netcom.com writes: > > Templates are a hack to deal with C++'s strict typing that aren't needed > >in Objective-C (hope my lack of full understanding of templates isn't showing > >too much :-) An Objective-C collection can contain objects of any type and > >can even include objects of different types without the need to resort to > >some sort of template mechanism. > > > > I believe that perhaps the better way to phrase this might be: Templates > are a hack to provide type safety in C++'s that isn't needed in > Objective-C... Like Eiffel C++ was designed to make writing production quality code easier. A large part of this is static type checking which at compile time checks *all* your code for type mismatches. In a language with less static type checking you need to execute each code path in your application to get the same result. For a large application this is very difficult. Like Eiffel C++ provides compile time polymorphism to achieve additional flexibility without sacrificing type safety. In C++ this is done with templates which are useful for much more than just container classes. For example, in C++ it's as easy to write a templatized FFT as one hardcoded for a specific type. Yet the template version allows you to use floats, doubles, long doubles, or even a big float class. I can only remember seeing three half-way valid criticisms of templates: 1) Templates cause massive code. This can happen very easily with naive implementations, but it can be largely alleviated by using non-template base classes and partial specialization. 2) It's difficult to write exception safe template code since any method of the parameterized class can throw an exception. This is also overblown: with care and experience with exception handling safe code can be written. 3) Templates force the compiler to slog thru much more code thereby reducing compile speeds. This can be dealt with by not using MSVC, by using non-template base classes, and by forward referencing template classes in headers. It's my understanding that the ANSI committe has blessed seperate compilation for templates so this will hopefully become moot. I keep seeing Objective-C advocates claiming that it makes writing programs much easier. That may well be true, but the hard part of programming is not coding it's making the program do what it's supposed to do, perform well, and gracefully handle errors. C++ makes this easier because the language and the philosophy emphasize catching problems at compile time. Maintaining backward compatibility with C does make C++ less safe than it would otherwise have been, but in the hands of a skilled engineer it's a powerful and effective tool. --Jesse
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: 18 Jan 1997 18:16:36 GMT Organization: Netcom Distribution: world Message-ID: <5br424$o2i@dfw-ixnews4.ix.netcom.com> References: <5aubl0$aql@abel.ic.sunysb.edu> <tbrown-ya023580001701972114140001@news.netset.com> tbrown@netset.com (Ted Brown) wrote: > If Apple wants Rhapsody to be OpenStep compliant, they can't change all > that much. It's unclear if Apple will do so or not (but it seems silly to > not conform). I would imagine that even if Apple uses QuickDraw GX as the > base imaging system, there will be a transparent access to a DPS->GX > converter, so older OpenStep programs can run w/o modification. I bet that most OPENSTEP apps rarely directly access DPS directly. It's all covered up by NSApplication, NSView, and NSWindow. So these apps don't really know or care what imaging system is underneath. There are some classes of apps that probably do access DPS extensively (e.g., drawing apps), but these are probably a small fraction of existing NS/OS apps. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: "Gregory H. Anderson" <greg@afs.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Sat, 18 Jan 1997 17:17:21 -0500 Organization: Anderson Financial Systems Inc. Message-ID: <32E14BF1.7D13@afs.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Pytte wrote: > So what kind of relationship exists between the number of methods in a > class, the depth of subclassing, and the time to resolve a method call? In general, the time to resolve a method is dependent on how long it takes to turn the string representation of the method name into a hash key, then use that key to search the class's hash table. Each class has its own hash table, so they tend not to get too big. It's certainly faster than a linear search, but I don't have Knuth in front of me to determine the general performance of hash lookups. The effect of depth of subclassing depends on how far down the search goes. Basically, the Objective C runtime dispatcher starts at the current class and keeps chasing down the superclass hierarchy until something (or nothing) responds to the method. The superclass is part of the metaclass information, so that is a direct pointer. It is important to note that for tight loops with frequent, invariant method calls, you can get the method address outside the loop, then call it inside with a syntax that is equivalent to a straight function. This is said to provide a 3x speedup, on average, versus repeated dynamic resolution. Finally, I mentioned in a prior message that ivars are stored in a set of nested structs -- which is the reason you can't add ivars on the fly -- but I shold have pointed out that you can work with them dynamically. That is how InterfaceBuilder works, for example. If you know an ivar exists by name, you can use the runtime system to perform indirect value access and assignment. > I would mourn the loss of stack based objects, mix in classes, and > operator overloading as much as I would revel in untyped messaging and > other benefits of run-time binding (some of which I suspect can lead to as > much chaos as the arcane aspects of C++). Stack based objects that clean themselves up at the end of an execution block would be a nice figure. Intriguingly, that WAS part of StepStone's original implementation, but NeXT never supported it. Operator overloading is one of those things you either love or hate, in my experience. I can take or leave it. I've seen too many C++ classes where it's done poorly or unintuitively. > But this is a different issue than merely comparing the features of two > languages. Indeed, how often do we choose languages just on the basis of > their ideal qualities, abstracted from the realities of our enterprises? > Next has delivered a solution more than a language. Full agreement. If only NeXT had had the wisdom to sell it that way. One of the most frustrating things about NeXT's marketing approach over the years was to sell the technology per se, rather than targeting solutions to customers. I hope Apple does not make the same mistake. Greg
From: "Gregory H. Anderson" <greg@afs.com> Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: Sat, 18 Jan 1997 17:29:47 -0500 Organization: Anderson Financial Systems Inc. Message-ID: <32E14EDB.7A4E@afs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Art Isbell wrote: > I bet that most OPENSTEP apps rarely directly access DPS directly. > It's all covered up by NSApplication, NSView, and NSWindow. So these > apps don't really know or care what imaging system is underneath. > There are some classes of apps that probably do access DPS extensively > (e.g., drawing apps), but these are probably a small fraction of > existing NS/OS apps. Allow me to share a recent posting to Semper Fi on this topic that got me thinking: "Hey, I publish NEXTSTEP-based DTP and word processing applications. How much PS code _do_ they contain?" I had never really counted before. Here is what I found. PasteUp and WriteUp contain 365 lines of source which use PSwraps. (If you missed the earlier discussion, these are pre-defined C functions that 'wrap' PS operators. For example, 'PSmoveto(1,1)' is equivalent to '1 1 moveto'.) Of those, 102 are simple gsave/grestore pairs (to preserve drawing contexts), so there are really only 263 lines of "meaningful" PS code. The majority of that is related to PasteUp's shape and line-drawing capabilities, NOT page composition. There are also 21 new AFS-defined PSwrap functions containing 134 lines of direct PostScript for common operations like underlining, arrows, special tokens, text frames, and selection knobs. In addition, there are 108 lines of Display PostScript calls. Of these, 11 are related to event-handling. Another 63 are DPSprintf operations that only apply to putting special code on the output stream for four-color separations and RGB->CMYK translation. (Yes, PasteUp creates service-bureau-ready separations, including crop marks, emulsion up/down, etc.) So there you go: In the application categories that you might expect to be the most PS-intensive on the platform, that is our total exposure to PostScript operations. Sounds manageable, doesn't it? Greg
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 18 Jan 1997 22:39:11 GMT Organization: Global Objects Inc. Message-ID: <5brjef$cg4@news.xmission.com> References: <AEEFE2B6-491909@204.246.66.19> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <milkweed-1501970042260001@port5.chester.smallmedia.com> <kmrG7VK00iV945mAVH@andrew.cmu.edu> <5brdnj$65l@copland.udel.edu> chao@copland.udel.edu (John David Chao) wrote: > Charles W Swiger <cs4w+@andrew.cmu.edu> said: > > >Sure. Obj-C itself does not support MI or operator-overloading, but > >Obj-C++ does. People using pure Obj-C generally seem to use forwarding > > I haven't heard of Obj-C++. Is Metrowerks going to have a compiler for it? > How does it compare to Obj-C? It is just a compiler that can compile both Obj-C and C++. Which gives the interesting possibility of mixing Obj-C and C++ code in the same file. You cannot write an object in a combination of Obj-C and C++, it is one or the other, but you _can_ send messages from one type of object to the other, facilitating the mixing of two different kinds of objects. This is good because it lets you make a design incorporating both kinds of objects so that you can control the tradeoffs between dynamic and static OOP--or simply interface legacy C++ code to an Obj-C interface. If you want to see a good sized example of this mixture, the MiscKit has MiscTableScroll which uses a C++ engine but has an Obj-C Facade wrapped around it. ("Facade" as in the GOF pattern...) Source is part of the kit and is free, of course. This is a pretty good example, too, IMHO, since it is complex enough to really show a practical usage rather than a simple, little, contrived example. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
Date: Sat, 18 Jan 1997 17:59:13 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Distribution: world Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <milkweed-1801971759130001@port5.chester.smallmedia.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> Organization: Milkweed Software In article <5br3p8$o2i@dfw-ixnews4.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > The depth of subclassing probably directly affects the time to resolve a > method call the first time a method is invoked on an object (or probably on > any instance of a class), but because of method caching, the resolution time > of subsequent invocations probably isn't proportional to subclassing depth. > I don't know how method caching is implemented, but I've read that the > average method invocation, although somewhat slower than a C function call, > isn't much slower (whatever "much" means :-) ... > Objective-C supports ducking the message dispatch process as well. > Programmers can ask for the pointer to the function that implements a method > and use that if performance is an issue such as in large loops. > > There's no reason why C++ programmers wouldn't continue to use their C++ > code and their C++ skills to write Model and maybe Controller classes in C++. Okay, I am impressed. Thanks for taking the time to detail the virtues of Obj-C. > But we're talking about Rhapsody development, aren't we? This will use > OPENSTEP libraries and their extensions (Apple technologies). So Objective-C > should be pretty striking in this context. With this as the subtext, yes. Perhaps I missed the germination of this thread where that subtext was made explicit. An OS interface using runtime-binding of objects is a good idea and benefits from a language like Obj-C or Java. But in certain contexts, compile-time binding, multiple inheritance, operator overloading, stack-based objects, etc., have great virtue (which members of the Obj-C community who contribute to this thread have been loath to acknowledge for reasons that mystify me). Is someone trying to sell me something? Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: Sat, 18 Jan 1997 18:49:44 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Distribution: world Message-ID: <wmsK6M600iWR86WqhE@andrew.cmu.edu> References: <5aubl0$aql@abel.ic.sunysb.edu> <tbrown-ya023580001701972114140001@news.netset.com> <5br424$o2i@dfw-ixnews4.ix.netcom.com> In-Reply-To: <5br424$o2i@dfw-ixnews4.ix.netcom.com> > tbrown@netset.com (Ted Brown) wrote: > >> If Apple wants Rhapsody to be OpenStep compliant, they can't change all >> that much. It's unclear if Apple will do so or not (but it seems silly to >> not conform). I would imagine that even if Apple uses QuickDraw GX as the >> base imaging system, there will be a transparent access to a DPS->GX >> converter, so older OpenStep programs can run w/o modification. From http://www.macos.apple.com/macos/releases/rhapsody/faq.rhap.html: "Q: Will Rhapsody support Display PostScript, QuickDraw GX, or some hybrid? A: Apple intends to adopt the PostScript imaging model for Rhapsody and migrate the best of our existing graphic technologies to that model, including ColorSync and GX typography. This will provide front-to-back PostScript support for publishing developers and customers. Technical details of QuickDraw and QuickDraw GX integration are still under investigation." -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Sat, 18 Jan 1997 18:56:09 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <AmsKANu00iWRQ6WrYw@andrew.cmu.edu> References: <AEEFE2B6-491909@204.246.66.19> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <milkweed-1501970042260001@port5.chester.smallmedia.com> <kmrG7VK00iV945mAVH@andrew.cmu.edu> <5brdnj$65l@copland.udel.edu> In-Reply-To: <5brdnj$65l@copland.udel.edu> Excerpts from netnews.comp.sys.next.programmer: 18-Jan-97 Re: Mult. Inh. in Objective.. by John David Chao@copland. >> Sure. Obj-C itself does not support MI or operator-overloading, but >> Obj-C++ does. People using pure Obj-C generally seem to use forwarding > > I haven't heard of Obj-C++. Is Metrowerks going to have a compiler for it? > How does it compare to Obj-C? ObjC++ == ObjC + C++. I don't know what Metrowerks is doing, but an ObjC++ compiler understands both ObjC and C++, so you can compile source which was written in either (or both 'simultaneously') languages. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: pecora@zoltar.nrl.navy.mil (Lou Pecora) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 11:59:43 GMT Organization: Naval Research Lab Message-ID: <pecora-1701970700340001@esp225.nrl.navy.mil> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDF93.7CA5@concentric.net> > Alan L. Lovejoy |==============================================| > Smalltalk Consultant | Beware of Geeks bearing GIFs! | > alovejoy@concentric.net |==============================================| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HAHAHAHAHAHAHA. I like it. Lou Pecora code 6343 Naval Research Lab Washington DC 20375 USA == My views are not those of the U.S. Navy. == ------------------------------------------------------------ Check out the 4th Experimental Chaos Conference Home Page: http://natasha.umsl.edu/Exp_Chaos4/ ------------------------------------------------------------
From: sanguish@digifix.com Newsgroups: comp.sys.next.advocacy,comp.sys.next.announce,comp.sys.next.hardware,comp.sys.next.software,comp.sys.next.misc,comp.sys.next.sysadmin,comp.sys.next.bugs,comp.sys.next.programmer Subject: NEXTSTEP/OpenStep Resources on the Net Supersedes: <475852914532@digifix.com> Date: 19 Jan 1997 04:57:55 GMT Organization: Digital Fix Development Message-ID: <413853649874@digifix.com> Topics include: Stepwise NEXTSTEP/OpenStep Information WWW site eduSTEP WWW site NeXT Computer, Inc. WWW site comp.sys.next newsgroups related newsgroups comp.sys.next newsgroups mailing list ftp sites NeXTanswers Stepwise NEXTSTEP/OpenStep Information WWW site =============================================== This online community resource includes - ISV company pages - ISV product descriptions - NEXTSTEP Developer Directory - NEXTSTEP Community WhitePages - Mailing List archives and information You can connect via the world wide web at: http://www.stepwise.com/ Suggestions or comments can be directed to me at sanguish@digifix.com If you would like to get your company and product information on Stepwise, please contact me at sanguish@digifix.com. eduSTEP WWW site ================ http://www.nmr.embl-heidelberg.de/eduStep/ eduStep aims to provide up-to-date information on: - NextStep tools and projects for scientists. - Third-party products interesting for the educational and scientific community (with educational discounts noted, where they exist). - A listing of resellers and shops interested in working with customers in the educational community. - Conferences, meetings, workshops - Major projects, such as SciTools, EMBL's project to develop a NextStep scientific work environment - Status reports on GNUStep, a freely-available implementation of OpenStep now being developed NeXT Computer, Inc. WWW site ============================ http://www.next.com comp.sys.next.* newsgroups ========================== news:comp.sys.next.advocacy This is the "why NEXTSTEP is better (or worse) than anything else in the known universe" forum. It was created specifically to divert lengthy flame wars from .misc. news:comp.sys.next.announce Announcements of general interest to the NeXT community (new products, FTP submissions, user group meetings, commercial announcements etc.) This is a moderated newsgroup, meaning that you can't post to it directly. Submissions should be e-mailed to next-announce@digifix.com where the moderator (Scott Anguish) will screen them for suitability. Archives are available by ftp at ftp://ftp.stepwise.com/pub/Next_Announce_Archives Messages posted to announce should NOT be posted or crossposted to any other comp.sys.next groups. news:comp.sys.next.bugs A place to report verifiable bugs in NeXT-supplied software. Material e-mailed to Bug_NeXT@NeXT.COM is not published, so this is a place for the net community find out about problems when they're discovered. This newsgroup has a very poor signal/noise ratio--all too often bozos post stuff here that really belongs someplace else. It rarely makes sense to crosspost between this and other c.s.n.* newsgroups, but individual reports may be germane to certain non-NeXT- specific groups as well. news:comp.sys.next.hardware Discussions about NeXT-label hardware and compatible peripherals, and non-NeXT-produced hardware (e.g. Intel) that is compatible with NEXTSTEP. In most cases, questions about Intel hardware are better asked in comp.sys.ibm.pc.hardware. Questions about SCSI devices belong in comp.periphs.scsi. This isn't the place to buy or sell used NeXTs--that's what .marketplace is for. news:comp.sys.next.marketplace NeXT stuff for sale/wanted. Material posted here must not be crossposted to any other c.s.n.* newsgroup, but may be crossposted to misc.forsale.computers.workstation or appropriate regional newsgroups. news:comp.sys.next.misc For stuff that doesn't fit anywhere else. Anything you post here by definition doesn't belong anywhere else in c.s.n.*--i.e. no crossposting!!! news:comp.sys.next.programmer Questions and discussions of interest to NEXTSTEP programmers. This is primarily a forum for advanced technical material. Generic UNIX questions belong elsewhere (comp.unix.questions), although specific questions about NeXT's implementation or porting issues are appropriate here. Note that there are several other more "horizontal" newsgroups (comp.lang.objective-c, comp.lang.postscript, comp.os.mach, comp.protocols.tcp-ip, etc.) that may also be of interest. news:comp.sys.next.software This is a place to talk about [third party] software products that run on NEXTSTEP systems. news:comp.sys.next.sysadmin Stuff relating to NeXT system administration issues; in rare cases this will spill over into .programmer or .software. Related Newsgroups ================== news:comp.soft-sys.nextstep Like comp.sys.next.software and comp.sys.next.misc combined. Exists because NeXT is a software-only company now, and comp.soft-sys is for discussion of software systems with scope similar to NEXTSTEP. news:comp.lang.objective-c Technical talk about the Objective-C language. Implemetations discussed include NeXT, Gnu, Stepstone, etc. news:comp.object Technical talk about OOP in general. Lots of C++ discussion, but NeXT and Objective-C get quite a bit of attention. At times gets almost philosophical about objects, but then again OOP allows one to be a programmer/philosopher. (The original comp.sys.next no longer exists--do not attempt to post to it.) Exception to the crossposting restrictions: announcements of usenet RFDs or CFVs, when made by the news.announce.newgroups moderator, may be simultaneously crossposted to all c.s.n.* newsgroups. Getting the Newsgroups without getting News =========================================== Thanks to Michael Ross at antigone.com, the main NEXTSTEP groups are now available as a mailing list digest as well. next-nextstep next-advocacy next-announce next-bugs next-hardware next-marketplace next-misc next-programmer next-software next-sysadmin object lang-objective-c (For a full description, send mail to listserv@antigone.com). The subscription syntax is essentially the same as Majordomo's. To subscribe, send a message to *-request@lists.best.com saying: subscribe where * is the name of the list e.g. next-programmer-request@lists.best.com The ftp sites ============= ftp://ftp.next.peak.org - The main site for North American submissions formerly ftp.cs.orst.edu ftp://ftp.informatik.uni-muenchen.de: - (Peanuts) Located in Germany. ftp://ftp.dn.net/pub/next - Peanuts mirror in the US ftp://terra.stack.urc.tue.nl - (Dutch NEXTSTEP User Group) ftp://cube.sm.dsi.unimi.it - (Italian NEXTSTEP User Group) ftp://ftp.nmr.embl-heidelberg.de/pub/next - eduStep ftp://ftp.next.com: - See below ftp.next.com and NextAnswers@next.com ===================================== [from the document ftp://ftp.next.com/pub/NeXTanswers/1000_Help] Welcome to the NeXTanswers information retrieval system! This system allows you to request online technical documents, drivers, and other software, which are then sent to you automatically. You can request documents by fax or Internet electronic mail, read them on the world-wide web, transfer them by anonymous ftp, or download them from the BBS. NeXTanswers is an automated retrieval system. Requests sent to it are answered electronically, and are not read or handled by a human being. NeXTanswers does not answer your questions or forward your requests. USING NEXTANSWERS BY E-MAIL To use NeXTanswers by Internet e-mail, send requests to nextanswers@next.com. Files are sent as NeXTmail attachments by default; you can request they be sent as ASCII text files instead. To request a file, include that file's ID number in the Subject line or the body of the message. You can request several files in a single message. You can also include commands in the Subject line or the body of the message. These commands affect the way that files you request are sent: ASCII causes the requested files to be sent as ASCII text SPLIT splits large files into 95KB chunks, using the MIME Message/Partial specification REPLY-TO address sets the e-mail address NeXTanswers uses These commands return information about the NeXTanswers system: HELP returns this help file INDEX returns the list of all available files INDEX BY DATE returns the list of files, sorted newest to oldest SEARCH keywords lists all files that contain all the keywords you list (ignoring capitalization) For example, a message with the following Subject line requests three files: Subject: 2101 2234 1109 A message with this body requests the same three files be sent as ASCII text files: 2101 2234 1109 ascii This message requests two lists of files, one for each search: Subject: SEARCH Dell SCSI SEARCH NetInfo domain NeXTanswers will reply to the address in your From: line. To use a different address either set your Reply-To: line, or use the NeXTanswers command REPLY-TO If you have any problem with the system or suggestions for improvement, please send mail to nextanswers-request@next.com. USING NEXTANSWERS BY FAX To use NeXTanswers by fax, call (415) 780-3990 from a touch-tone phone and follow the instructions. You'll be asked for your fax number, a number to identify your fax (like your phone extension or office number), and the ID numbers of the files you want. You can also request a list of available files. When you finish entering the file numbers, end the call and the files will be faxed to you. If you have problems using this fax system, please call Technical Support at 1-800-848-6398. You cannot use the fax system outside the U.S & Canada. USING NEXTANSWERS VIA THE WORLD-WIDE WEB To use NeXTanswers via the Internet World-Wide Web connect to NeXT's web server at URL http://www.next.com. USING NEXTANSWERS BY ANONYMOUS FTP To use NeXTanswers by Internet anonymous FTP, connect to FTP.NEXT.COM and read the help file pub/NeXTanswers/README. If you have problems using this, please send mail to nextanswers-request@next.com. USING NEXTANSWERS BY MODEM To use NeXTanswers via modem call the NeXTanswers BBS at (415) 780-2965. Log in as the user "guest", and enter the Files section. From there you can download NeXTanswers documents. FOR MORE HELP... If you need technical support for NEXTSTEP beyond the information available from NeXTanswers, call the Support Hotline at 1-800-955-NeXT (outside the U.S. call +1-415-424-8500) to speak to a NEXTSTEP Technical Support Technician. If your site has a NeXT support contract, your site's support contact must make this call to the hotline. Otherwise, hotline support is on a pay-per-call basis. Thanks for using NeXTanswers! _________________________________________________________________ Written by: Eric P. Scott ( eps@toaster.SFSU.EDU ) and Scott Anguish ( sanguish@digifix.com ) Additions from: Greg Anderson ( Greg_Anderson@afs.com ) Michael Pizolato ( alf@epix.net ) Dan Grillo ( dan_grillo@next.com )
From: jq@papoose.quick.com (James E. Quick) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 11 Jan 1997 13:00:23 -0500 Organization: PHCS Message-ID: <5b8kfn$3f4@papoose.quick.com> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <maury-1001971422310001@199.166.204.230> In article <maury-1001971422310001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: > Too inflexible anyway. I like putting my apps where I like them, I have >a number of drag and drop ones on my desktop for instance. Even under the current NeXT implementation, you can have apps appear to be installed any place, even if they are installed some other place. No matter what the Rhapsody looks like, this will still be possible. -- ___ ___ | James E. Quick jq@quick.com / / / | Private HealthCare Systems NeXTMail O.K. \_/ (_\/ | Systems Integration Group (617) 895-3343 ) | "I don't think so," said Rene Descartes. Just then, he vanished.
Newsgroups: comp.sys.next.programmer From: spill@netcom.com (David Stein) Subject: Interfacing OpenStep program to Telnet... Message-ID: <spillE48LHs.CMu@netcom.com> Organization: Netcom On-Line Services Date: Sun, 19 Jan 1997 03:53:52 GMT Sender: spill@netcom2.netcom.com I need to know the following: Can I use Telnet from within an OpenStep application? I will be writing a program which communicates (unattended) with a Cisco access-server, and we communicate with these things via telnet. So, does OpenStep offer a (programmer's, not command line) interface to telnet? Or, am I left to do a fork/exec and communicate with telnet through pipes? Also, I have another question: Can I make calls directly to the NT or Mach Unix API's (where applicable) from within an OpenStep app? Any help is appreciated. Thank You. David Stein spill@netcom.com tevey. So now I'm wondering, can I load NS on the laptop and then load Win/95 under it to access my office productivity stuff - or should I get the SoftPC emulator? What do I need to do/can I get both NS and Win/95 on the same box, preferably Win/95 running in a window under NS. Another line of questions has to do with development. NEXTSTEP native vs OPENSTEP. Is there an OPENSTEP developer product for Intel boxes and do I want it instead of NS native? Is it the product that has a future?? Another line of questioning - is NS 3.3 Developer the latest/greatest still for Intel boxes (if OPENSTEP is the way to go - which version?). Lastly, a RFO (Request For Opinions) as to which is better as of today: Buy a new Intel box and put NS/OPENSTEP on it - or wait to purchase until some hot Apple/NEXT combo hits the market. Of particular interest to me is in the realm of laptops, but also interested in opinions generally. Look forward to hearing all the opinions on this hot topic. Feel free to email me directly at rwarner@prv.com - will summarize to the net. Rich
From: "Gregory H. Anderson" <greg@afs.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Sat, 11 Jan 1997 13:23:48 -0500 Organization: Anderson Financial Systems Inc. Message-ID: <32D7DAB4.1114@afs.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael D. Rossetti wrote: > This is an interesting way to implement multiple inheritance. I guess > this approach must mean that 'multiple inheritance' in Objective C is > limited to only one base class and one 'proxy' class - is that correct? I look at MI simulation in Objective-C somewhat differently than the direction this thread has taken. Here is something I posted to the Semper.Fi mailing list last week. Greg =========== It is fairly common to have objects "own" other objects that they instantiate upon creation, and destroy upon their own destruction. For example (I'm using 3.3 terminology here), the NeXT TextField class is a Control (a subclass of View) which owns a TextFieldCell to handle its contents (editing, validation, and formatting). In C++, you might declare TextField as one class that inherits from two others (View and Cell). In Objective-CC, you inherit from one, and use it to manage an instance of the other. In usage, the Cell can be returned to a caller, and then messages can be sent directly to it: [[myTextField cell] setStringValue:"foo"] But for convenience, the most frequent messages destined for the cell are also defined in the Control, so [myTextField setStringValue:"foo"] would be equivalent. (The TextField version of this message would simply forward the string value to the cell.) There are two nifty benefits to this approach. First, you don't have to worry about name-space conflicts between the merged classes. Second, you can substitute a different cell object or cell class at runtime, thus changing the apparent behavior without recompiling the TextField class.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 19 Jan 1997 02:18:32 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bshs8$e5n@csugrad.cs.vt.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> In article <jinx6568-1601971303370001@news.sover.net>, jinx6568@sover.net (Chris Johnson) wrote: > Way too simple for me, I'm afraid, I would find that disgustingly > restrictive. The notion of an 'Applications', 'Documents' etc folder, is > horribly Win-like, not something I could deal with. (Win-like???? Are we talking about the same Windows? You know, that operating system that likes to dump files everywhere on your drive? Windows does NOT have a mandatory Applications folder or anything like that.) Try dealing with it and you'll find you'll be able to. I don't understand why you want to scatter your applications all over the filesystem. I don't know anyone who does this. Even the Mac people tend to put everything in the Applications folder or a subdirectory of it. (Or on the Desktop, but the Desktop is not part of the filesystem under NEXTSTEP, and it doesn't really matter anyway as you can store links to files anywhere in the filesystem on the desktop using an extension.) And if you want to organize things better using subdirectories, fine, you can put applications in subdirectories of the standard folders and the Workspace will find them. If you don't like those subdirectories being stored in /LocalApps instead of your home directory, make links to them. Or store them on your File Viewer shelf. > My root folders are > along the lines of 'video', 'writing' etc, not categories that are frankly > only useful to the computer itself. You can make subdirectories of, say, LocalApps with names like Video and Writing to store applications related to those tasks. And if, for some reason, you want to put the video-related applications in the same folder as your QuickTimes or whatever, that's trivial too. Just have the Installer dump the apps in the regular directory, and create links to them wherever you want to see them. It takes no more effort than choosing where to install an app in the first place. > "Applications"? What good does that do me? You know, those things that you run? I personally am not interested in keeping my word processor in the same folder as all my word-processing documents.. I don't even keep all my documents in the same folder.. that's sorting by type and I sort by topic. I think you're just making a big deal over nothing, just because it's different. You complain that your freedom has been taken away, but you don't really need it; NEXTSTEP has perfectly acceptable substitutes. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 09:06:15 GMT Organization: Global Objects Inc. Message-ID: <5b50q7$39e@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> Ferret <ferret@surf.net.au> wrote: > mmalcolm crawford wrote: > > Let's see; *including the C compiler (bi-fat), /bin takes 4.7MB; > > /etc 800k, usr/bin 6.5MB, /usr/etc 3.1MB... when it's difficult these days to > > buy a disk < 1GB, this is not exactly *big*. And remember much of this is > > stuff which is used by the OS itself... > > > > I am having difficulty understanding your prejudice here -- what all this > > stuff represents is effectively what I (assume) MacOS has in its /System > > folder, it's just spread around a bit more (perhaps something for AppLE to > > address, though doing so might break a lot of stuff), and with a more obscure > > nomenclature. > > Here are the files that make my Mac go in the system folder: > Finder - the basis of the OS > System - what makes the finder go > Control Panels - filled with all sorts a crap that I throw in there > Extentions - same as control panels > Fonts - pretty obvious > Preferences - ditto > > No /usr or /etc or any of that crut, The point is that the "crud" in /usr and /etc is a combination of Extensions and System--NEXTSTEP needs that stuff to run. You never have to look at it yourself if you don't want to. (I like the mechanic and hood comparison. Yes, the ugly user-unfriend- liness of UNIX is there. NEXTSTEP hides it with a more than adequate hood and _you_ have to lift that hood to see it. Most users never will. End of story. You can't just throw out the engine and expect the car to run, you know. You can't delete your System folder and expect your Mac to work very well. And Blow away /etc or /usr and your NeXT won't boot. Most users won't mess with the engine, System, or /usr and /etc and will never need to--and the "hood" hides the complexity. The mechanics of the world know it is there, though, and just love to play in the dirt and grime... :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 19 Jan 1997 02:24:37 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bsi7l$ecd@csugrad.cs.vt.edu> References: <5ami95$ol3@news.tuwien.ac.at> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> <jinx6568-1601971352540001@news.sover.net> In article <jinx6568-1601971352540001@news.sover.net>, jinx6568@sover.net (Chris Johnson) wrote: > In article <5b6dih$9bm@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu > (William Raphael Hix) wrote: > > One thing I'm pretty sure of is that the applications like tar, emacs, > > and especially cc, will not be present. > > Apple can't afford to upset its developers by giving away things that > > will in any way make users reluctant to buy new software. > I can't imagine any Mac user forgoing DropStuff or Stuffit Expander for > tar... Me neither.. but maybe a graphical interface to tar that acts just like those Mac apps. > or _anything_ for emacs Developers might. Many programmers love Emacs because of its extensibility. (They even have a Mac version, you know.. so I doubt Apple's going to leave _that_ out of Rhapsody.) > (don't know what cc is, could somebody describe?) The C compiler. Apple could very well leave that out.. wouldn't want to give people a free alternative.. though I don't think that even the GNU C compiler with Obj-C extensions will be able to link in CodeWarrior object files or the OpenStep libraries, so I don't think they would gain much by leaving it out; it's mostly useful for command-line stuff. And leaving it out would be a big problem for Unix people, since most Unix software is distributed in source form only (every Unix system comes with a C compiler, except for some commercial implementations who have discovered that they can charge extra for the compiler). -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 11 Jan 1997 18:36:30 GMT Organization: Global Objects Inc. Message-ID: <5b8mje$nam@news.xmission.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> <5b52nv$39e@news.xmission.com> <jesjones-ya023580001001972219400001@news.halcyon.com> jesjones@halcyon.com (Jesse Jones) wrote: > Do you agree that it's better, as a general rule, to find > errors as soon as possible? Yes. But I prefer a language in which the tendency is to have fewer errors up front. I find that most of my Objective-C code "just works" because the simplicity of the language means I don't tend to make as many mistakes. This is nothing to do with which one I am most familiar with--C++ is a harder language to use (even if you're good at both) and hence there are more errors up front. The syntax is more complex, so it is easier to forget little details. My point is that in my experience, most of the errors that the C++ compiler is catching for me are errors I wouldn't make in the first place if I was using Objective-C, and which is better-- catching the error as soon as possible or never making the error at all? That's just my experience, as one who has used both languages. Having used both, the question of which I would rather use is a no-brainer. I'd like to know if other people who have used _both_ languages _extensively_ feel the same as I do or not. I don't want to hear from people who have only used one or the other or who have not used them both a lot; there would be too much bias in the answer to get what I'm looking for here. > I can see how a more dynamic language can lead to a simpler class design: > I've made careful use of dynamic_cast in my C++ code and been pleased with > the results. However I don't think this is worth sacrificing static type > safety for. I want my code to be as solid and robust as possible. A > language where an object may or may not be able to handle a method call > seems like a giant step backward. It really isn't. It allows great flexibility in a design. Just like C++ operator overloading, there are times when it is a very good thing and there are times when it is a bad idea. The same goes with Objective-C's dynamic features. When abused, they can cause problems. A good programmer with a good design will use them right [that goes for dynamism and overloading]. I've found the repercussions of bad programming in Objective-C to be a lot less serious, though, especially from a maintenance point of view, which I already mentioned. > I must have missed those zillion discussions of why Objective-C > is a better OOPL than C++. Care to elaborate? I haven't the time. Look at the archives of comp.lang.objective-c or search dejanews for comparisons of the two. There's more there than you'll want to waste time on reading... > As I said before simple to write doesn't mean a language is suitable for > software engineering. BASIC makes it easy to bang out code, but very few > would claim that it's suitable for large commercial quality projects. I > would claim (and I know I'm not alone) that C is, at best, barely adequate > for software engineering. C++ has added a lot to the language with most of > the additions focused on making it easier to write large robust systems. > What has Objective-C done to meet this goal? I think it has done the same thing as C++, but with more simplicity. That alone, to me, makes it better. It has a lot of features which, if you take advantage of them, will produce code more robust than what C++ will give you. And for a much lower price. > C++ was not haphazardly designed There are many who would argue that point. I've heard it described as "warts on warts" by more than one C++ programmer. > and it doesn't "promote arcane usage and bad style". Again, depends upon who you talk to. I'm not talking about Obj-C fans, either. I've met several C++ fans who will say this. > The worst C++ code is written by old time C hackers who don't > grasp OOD and the evils of the preprocessor. That goes for any OO language. C++ just makes it easier to do that. It is possible to write bad code in Objective-C, too, but you usually have to work harder to accomplish it. > Slamming C++ because its a big > language is absurd: the language was written for professional developers > who can relatively easily learn the mechanics of the language. There are > valid criticisms of C++, but they're almost entirely due to backward > compatibility with C. That's not what a lot of professionals I've talked to have said. It takes years to become a truly proficient C++ programmer, and it takes days to learn the guts of Objective-C. If two tools accomplish the same thing but one takes orders of magnitude longer to learn, I think that should tell you something. After using both, I don't feel that C++'s complexity buys you anything significant over Obj-C except for maybe a bigger training budget. > [...] A much better book IMO is "Object Oriented Software > Construction" by Bertand Meyer. [...]. Yeah, that's a good book, too. Well, it sounds like your experience is a bit different than mine and hence your opinions will be different; so be it. Have you extensively used Objective-C, though? After using both you might feel different, assuming you haven't. If you have, I'd like to hear specifics about what you don't like. Two final points: (1) Objective-C does do type checking and the compiler will let you know about objects that can't understand certain messages. You can have checking baed on object type (ie, inheritance chain): View *rectangle; [If you assign an object that isn't an instance of View or one of its subclasses, you get an error. If you send a message that "View" doesn't respond to, you also get a compiler error.] Or you can have it done by protocol: id <View> rectangle; [If you assign a class that doesn't implement the "View" protocol, you get a compiler error; if you send a message not in the "View" protocol, you get another error. When you define an object with a protocol, it is an error to not define every method in that particular protocol.] The dangerous one is to do this, but there are times (actually rather rare) where this is appropriate: id rectangle; [You can assign any object and send any defined message without getting a compiler error. Usually, this is used for delegate objects where you may only want to implement a partial interface, since you don't care about certain notifications or behavioral modifications. In those cases, you always use -respondsTo: before sending the message, though. That's appropriate, since if the method isn't implemented, then the writer wanted that message to be ignored. This really improves the API of a framework; using the OPENSTEP frameworks for a while will teach you why.] So you aren't really giving up the static types you love so much-- a point which keeps getting lost in these discussions--but you are gaining a lot of dynamic abilities, which have positive effects on (a) design, (b) code production, and (c) code maintenance. It seems to me that this is an improvement. And yes, when I write Objective-C I do use the static types a lot. Additionally, I mix C++ and Objective-C. C++ works quite well for tightly integrated objects that work together as an engine. (ie, you don't need the dynamism, because you don't need or want its flexibility.) A good example of this is the MiscTableScroll, which is an Objective-C GUI object for NEXTSTEP which is meant to display DB columns and rows. The Objective-C stuff is really just a Facade over the C++ engine underneath, which does all the real work. And it turns out that that is a case where C++ has proven to be a very good tool. Source code for that is in the MiscKit; the docs for the Obj-C Facade are at: http://www.misckit.com/Documentation/Classes/MiscTableScroll.html Warning: that's a 300k document, and misckit.com is on a 28.8k... That's probably the most complex object in the MiscKit, because it can do so much. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 10 Jan 1997 02:50:30 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5b4apm$al2@usenet.rpi.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > My mom's HD is 80Meg. So now we get to buy a new HD to store > files she'll never use. Hmmmm. Your mother has a PowerMac with an 80-meg disk? Really? And if she has a 68K-based, then she wasn't going to be running *any* of the new operating system choices that Apple was considering. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 19 Jan 1997 02:34:07 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bsipf$l4g@csugrad.cs.vt.edu> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> In article <jinx6568-1601971429460001@news.sover.net>, jinx6568@sover.net (Chris Johnson) wrote: > > Mac users should note that the desktop on NEXTSTEP, when using an > > extension like Fiend, is _not_ part of the filesystem. Every icon you > > see on the desktop resides somewhere else, like aliases. > That's interesting- this is within the app wrapper, correct? No.. err, actually, it depends on what "this" means. With Fiend, if you drag something onto the desktop, it remembers what the path for the file is and displays that file's icon. (Actually, Fiend is more general, you can drop icons for things inside applications onto the desktop too.) But if you are asking there the icon images are stored, the images for a document are stored in the app wrapper for whatever apps is selected as the default opener for that document. If you change the default app, the file's icon changes. > Where are drive icons kept? There are no drive icons. Unix drives look like folders; they're mounted directly into the filesystem wherever you want (and have permission to put them). For example, you could have all your users' directories stored on another drive and mount it as the /Users folder. You literally can't tell what drive a folder is stored on unless you open up an inspector. There are some generic icons for removable media like floppy disks and CD-ROMs that the File Viewer uses instead of a folder icon when you insert one; those are probably stored in the Workspace's app wrapper. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Date: 19 Jan 1997 02:38:23 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bsj1f$llh@csugrad.cs.vt.edu> References: <petrichE3Ct2r.3AJ@netcom.com> <maury <maury-1401 <maury-1601971527030001@199.166.204.230> In article <maury-1601971527030001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > > multiple sections supported by Mach-O are a straightforward extension of > > the venerable a.out format, which had precisely three sections: TEXT, > > DATA, and BSS. > Ahhhhhhh. So (you see this coming), why did it stop there? Because (you see this coming) the forked-file concept sucks and app wrappers are better. :) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer Subject: Re: Interfacing OpenStep program to Telnet... Date: 19 Jan 1997 02:47:54 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bsjja$nvs@csugrad.cs.vt.edu> References: <spillE48LHs.CMu@netcom.com> In article <spillE48LHs.CMu@netcom.com>, spill@netcom.com (David Stein) wrote: > I need to know the following: Can I use Telnet from within an > OpenStep application? I will be writing a program which communicates > (unattended) with a Cisco access-server, and we communicate with these > things via telnet. So, does OpenStep offer a (programmer's, not command > line) interface to telnet? Not to telnet specifically. > Or, am I left to do a fork/exec and communicate with telnet through pipes? You can use an NSTask object, which wrappers the fork/exec process, can set up a pipe, and can return either NSFileHandles or NSPipes to stdin/stdout/stderr. (Among other things.) I think that NSTask is a NeXT-specific extension of the OpenStep spec, so I suppose you can't count on it existing in other implementations. I don't know about NSFileHandle or NSPipe. > Also, I have another question: Can I make calls directly to the > NT or Mach Unix API's (where applicable) from within an OpenStep app? Sure. Just link the appropriate libraries in and call them like usual. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Rami Gideoni <rami_gideoni@aisys.co.il> Newsgroups: comp.sys.mac.programmer.tools,comp.sys.m68k,comp.misc,gnu.utils,alt.comp.hardware,comp.lang.asm,comp.os.misc,comp.sys.next.programmer,comp.sys.misc Subject: Re: Help: need info on Motrola "S" hex format Date: Sun, 19 Jan 1997 09:57:40 +0200 Organization: AISYS Message-ID: <32E1D3F4.313D@aisys.co.il> References: <32DF9D14.6FD8@inigo.us.dg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Yomama Sophat <neilr@inigo.us.dg.com> Yomama Sophat wrote: > > Any information out there? I need to write a program that outputs such > files. Thanks in advance. Hi, Send me your fax number and I'll fax it over to you. -- Rami Gideoni WWW : http//www.aisys-usa.com/fromrami.htm ------------------------------------------- Disclaimer: This message does not necessarily reflect the company's opinion - just my own humble one.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 10 Jan 1997 09:39:11 GMT Organization: Global Objects Inc. Message-ID: <5b52nv$39e@news.xmission.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> jesjones@halcyon.com (Jesse Jones) wrote: > I keep seeing Objective-C advocates claiming that it makes writing programs > much easier. That may well be true, but the hard part of programming is not > coding it's making the program do what it's supposed to do, perform well, > and gracefully handle errors. C++ makes this easier because the language > and the philosophy emphasize catching problems at compile time. Maintaining > backward compatibility with C does make C++ less safe than it would > otherwise have been, but in the hands of a skilled engineer it's a powerful > and effective tool. Wow. This is amazing. And he really believes what he's saying! <RANT> With C++ my productivity hits rock bottom, at least when compared to what I can crank out in Objective C. And even with all the type checking the compiler is doing for me, I find my code quality is in the dumps with C++, as compared to Objective-C. Yeah, that picky compiler keeps me busy all right. Bow down to the needs of the compiler and satisfy its every whim. I like Objective C becase it reduces clutter in the system's design and is simply a better OO implementation (for reasons that have been hashed out zillions of times before). Let's face it: a large C++ project versus a large Objective-C project, what are the differences? * That picky C++ compiler means I can hire twice as many programmers and take twice as long to get it written. And even then it probably won't work right anyway. So much for stamping the bugs early on. The simplicity of Objective-C keeps most of those bugs from happening in the first place, because it is easier to write! Besides, a good design will, by nature, help reduce the bugs in the product. You should never trust a compiler to make up for flaws in a bad design, which is what I see far too many C++ programmers doing. (Not all are that way, thank heavens, but in practice the "compiler will spot the bugs" attitude often leads to this outcome.) * My resulting app will be much larger because of unnecessary code bloat caused by lack of dynamism. The design will bloat as well, as I work around language deficiencies. [To do effective GUI work you need to have a certain amount of dynamism. In C++, this means you re-invent your own mini runtime each time. In Objective-C, where you start with a runtime, you save yourself that much effort. Less code usually means fewer bugs, as far as I've seen.] * The C++ _may_ run a little faster, since I don't have the overhead of the runtime--but not as much as you'd think because of that code bloat and the less-than-optimal design the compiler's pickiness forces me to use. * C++ has all these nifty features (syntactic sugar) that I can use to increase my productivity. Too bad that the next guy that comes along--to maintain my code--can't figure out what the hell I did. Most Objective-C code is very nearly self documenting. The simpler designs mean the maintenance guys can come in and quickly find and fix problems. If there are any. You could argue that good and bad programming styles affect this comparison--and yes they sure do--but C++ promotes arcane usage and bad style because of its haphazard design whereas Objective-C does a lot to help promote good design. Plus, how many syntax elements does C++ add to C? Has anyone ever sat down and counted? Compare Objective-C's number--I think it is in the _teens_. So which is going to be easier to debug? And I could keep going...but I think my bias is obvious. Why? I've used both and I _know_ which one works better. As a final point, which OO environment has faster execution speed on like hardware and is more time tested and proven: NEXTSTEP or Taligent? Does anything more have to be said? That's two large systems of similar complexity, and one seems to be doing just a little bit better than the other, now, wouldn't you think? And while languge isn't the only reason for that particular situation, you can't blame management on that one. NeXT is notorious for being one of the most poorly managed companies ever, at least according to its many "enemies" and even a large portion of its advocates. Yes, with all that mismanagement, their product has _still_ survived, in spite of all they have done to apparently try and kill it off! That really says something to me about the product's quality! Of course, after using the product and those of competitors, I know firsthand why it is so great. You really have to give it a chance to "get it", and once you do, you'll never want to go back... </RANT> As I sign off, I will say that a good design is paramount, no matter which language you choose. A lot of Objective C projects have failed, too, because of that. I _strongly_ suggest Bruce Webster's book, "Pitfalls of Object Oriented Programming." That's the wise voice of sad experience speaking there. May we all read and learn from it and avoid those traps! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 11 Jan 1997 18:33:56 GMT Organization: Netcom Distribution: world Message-ID: <5b8mek$9sp@sjx-ixn3.ix.netcom.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> <5b52nv$39e@news.xmission.com> <jesjones-ya023580001001972219400001@news.halcyon.com> jesjones@halcyon.com (Jesse Jones) wrote: > In article <5b52nv$39e@news.xmission.com>, don@globalobjects.com wrote: > > With C++ my productivity hits rock bottom, at least when compared > > to what I can crank out in Objective C. And even with all the > > type checking the compiler is doing for me, I find my code quality > > is in the dumps with C++, as compared to Objective-C. Yeah, that > > picky compiler keeps me busy all right. Bow down to the needs of > > the compiler and satisfy its every whim. > And what whims are we talking about? Requiring that the method exists for > the object it's invoked on? Requiring that pointer assignments be between > compatible types? Reasonable requirements at first blush, but ones that can be overly restrictive for a dynamic system. And, as you probably know, requirements that are met by Objective-C compilers when static typing is used as it should be in most cases. But in those cases in which the type of an object shouldn't be restricted at compile-time, Objective-C's id type is designed for this situation. Objects typed to id should be asked whether they respond to a method or conform to a protocol before sending a message, so if the object doesn't respond, this fact is caught at run-time and handled accordingly with no loss of safety. Of course, the compiler doesn't protect against poor programming techniques that would allow an object to be sent a message to which it cannot respond, so the tradeoff is one of safety against flexibility. In many cases, choosing flexibility is a big win; in other cases, it's not. > Do you agree that it's better, as a general rule, to find errors as soon > as possible? Sure, but if needed flexibility is sacrificed in the process, then finding errors later, at run-time, and dealing with them at that point is sufficient. > I can see how a more dynamic language can lead to a simpler class design: > I've made careful use of dynamic_cast in my C++ code and been pleased with > the results. However I don't think this is worth sacrificing static type > safety for. I want my code to be as solid and robust as possible. A > language where an object may or may not be able to handle a method call > seems like a giant step backward. This is a red herring as I've pointed out. Objective-C provides run-time support for determining whether an object can handle a message. C++ programmers are familiar with dealing with run-time errors - exceptions. Dealing with unimplemented messages at run-time is no different. Some would argue that continuing to use an early-binding, static language at a time when distributed programming and other innovative technologies that require greater flexibility are gaining popularity is adherence to the status quo and inappropriate. A language designed for system programming, maximum safety, and good performance is difficult to adopt to a more dynamic problem domain. Applying further bandaides to try to simulate a more dynamic behavior becomes a process of diminishing returns which is where C++ seems to be now. > I must have missed those zillion discussions of why Objective-C is a better > OOPL than C++. Care to elaborate? It's difficult to have zillions of discussions when zillions know C++ side and only a few know Objective-C :-) I don't like to characterize any language as "better" than another. Most languages were designed for particular purposes and are appropriate for those purposes. But using Objective-C to write an operating system or C++ to write a distributed, extensible application may both be examples where better language choices exist. > I > would claim (and I know I'm not alone) that C is, at best, barely adequate > for software engineering. I agree. ANSI C is an improvement over K.& R. C. C++ has added a lot to the language with most of > the additions focused on making it easier to write large robust systems. I agree that C++ is certainly a better ANSI C. > What has Objective-C done to meet this goal? Objective-C is based on ANSI C as is C++. If one believes that object-oriented design can, in general, make writing and maintaining large, robust systems easier (I do), then many believe that Objective-C implements more completely those features generally acknowledged as characterizing object-oriented languages like Smalltalk. Objective-C's run-time supports both flexibility and robustness. > C++ was not haphazardly designed I don't believe it was, but it wasn't designed for many of the purposes that it is being used for. The extensions that have been grafted onto C++ have made the language so complex that using it well has become very difficult. and it doesn't "promote arcane usage and > bad style". Programmers promote arcane usage and bad style, but C++ seems to support such problems more readily than languages with simpler syntax and feature sets like Objective-C. > Slamming C++ because its a big > language is absurd: the language was written for professional developers > who can relatively easily learn the mechanics of the language. Many feel that using a very complex language like C++ or Ada is an impediment. It's easy to understand this. If most people must buy and comprehend large books or attend programming courses to master a language, then I think that the language complexity is bound to impact negatively on programmer productivity and code quality. There are > valid criticisms of C++, but they're almost entirely due to backward > compatibility with C. And Objective-C shares these weaknesses. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: "Dirk P. Fromhein" <Dirk.Fromhein@watershed.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: Sat, 11 Jan 1997 14:08:04 +0500 Organization: Watershed Technologies, Inc. Message-ID: <32D75874.37DD@watershed.com> References: <5b1omq$adg@nntp1.apple.com> <jesjones-ya023580000901972203300001@news.halcyon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > backward compatibility with C does make C++ less safe than it would > otherwise have been, but in the hands of a skilled engineer it's a powerful > and effective tool. I would like to point out the last line... "a skilled engineer" To a "skilled engineer" the *elimitation* of "type-saftety" is a powerful and effective tool. Take a look on Wall Street, most trading apps are done in SmallTalk. I've also worked with complete trading systems done in Objective-C. We have apps at are at about 200K lines of code (yeah yeah, I know a bad measurement) that currently have 0 crash/critical, 0 Major bugs (in Objective-C) (five full time engineers). Our sister project done in C++ with twice the number of engineers has over 600 crash/critical, and some ungodly number of Major bugs. (We have five levels of rating bugs). We are going to go production in a few weeks, they... It comes down to the quality of your people... I also find that C++ forces "odd" Object Models. Any change to the Object Model in C++ after coding begins is a MAJOR effort... I have not foud this to be the case with Objective-C, but that might just be what I have seen. Dirk Fromhein df@watershed.com
From: racecarr@soltec.com (Tony M. Carr) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 18 Jan 1997 22:11:38 -0600 Organization: Race Carr Unlimited Message-ID: <racecarr-ya02408000R1801972211380001@news.cu.soltec.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bq05v$7t9@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > raph@porter.as.utexas.edu (William Raphael Hix) wrote: > > Example: does the existance of tar, a reasonably able backup > > utility with a really unfriendly UI, make companies like Alladin > > or Dantz who make backup software more or less eager to port to > > Rhapsody? I think less likely, because the number of potential > > buyers for Stuffit is reduced by the existance of tar and freeware > > extentions. > > I don't think it effects them one bit. > Especially since tar doesn't do any compression, it simply lumps many files into one file. That's why so many files on the internet have *.tar.gz file names. They're run through tar then through gzip to compress the tar file. There will definitely be a market for Stuffit & Retrospect under Rhapsody. Tony C. -- Tony M. Carr Veteran of the Psychic War
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 11 Jan 1997 20:15:27 GMT Organization: ace dot net internet technologies Message-ID: <5b8scv$6ue@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: [in regards to UNIX shell utilities] : The problem is that I believe this will lead to dependance on them, and : let's face it, a lot of what's in there is not all that great code. I think developers shouldn't be given APIs or frameworks because this will lead to dependence on them. Next thing you know they'll be wanting compilers. Computers shouldn't have operating systems, because, let's face it, what's in there isn't all that great code. : Yes, but the quality of these applications varies, some is passable, : lots os terrible. rm doesn't even ask you to confirm, let alone allow you : to rescue the items. It's not lazy coders that's the problem, it's the : code that exists from years ago that is. Now demoing at MacWorld! It's the person without a clue whatsoever! Have you ever even *used* a UNIX shell prompt? It's clear that you don't have any idea what you're talking about. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 11 Jan 1997 20:17:15 GMT Organization: ace dot net internet technologies Distribution: world Message-ID: <5b8sgb$6ue@darla.visi.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bigews.shef.ac.uk> <maury-0901971624340001@199.166.204.230> <5b4b90$9u8@dfw-ixnews12.ix.netcom.com> <maury-1001971419440001@199.166.204.230> : > This system will continue to : > work fine with the various System 7 upgrades and isn't a system that Apple : > has targeted for Rhapsody. : : Exactly the problem. Damn. You mean my Apple //e won't run Rhapsody either? Apple sucks. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: Mike <indigo2@washdc.mindspring.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Sun, 19 Jan 1997 06:48:42 +0000 Organization: MindSpring Enterprises Message-ID: <32E1C3C0.3E5A@washdc.mindspring.com> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan M. Urban wrote: > > In article <jinx6568-1601971429460001@news.sover.net>, jinx6568@sover.net (Chris Johnson) wrote: [...] > > Where are drive icons kept? > > There are no drive icons. Unix drives look like folders; they're > mounted directly into the filesystem wherever you want (and have > permission to put them). For example, you could have all your users' > directories stored on another drive and mount it as the /Users > folder. You literally can't tell what drive a folder is stored on > unless you open up an inspector. I'm not so sure I understand this completely. Tell me if I'm wrong, but if this is the case, then I could have four 2Gb hard drives all mounted at the same place in the file system and it would appear that I have one 8Gb hard drive, right? And the OS will know when one fills up and begin using available space on the next drive? And I could just keep on growing my hard drive? Could I set things up so that, using the four drive example above, two of the drives are a mirror of the other two? And if I pulled one of the drives, things would keep humming along? Are these just fantasies of mine because I don't understand what you're saying? Mike
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 10 Jan 1997 21:50:09 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5b6dih$9bm@geraldo.cc.utexas.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <E3spt1.B9u@free.fdn.fr> Fabien_Roy@free.fdn.org wrote: : As a programmer, I rely on the presence of /bin /usr/bin etc... stuff. : I prefer to do this: system("df -i /Disk|grep dev > /tmp/df.result"); than to : rewrite the df code. Then I can proceed the /tmp/df.result file to see how : many inodes used/free on the local disk thus avoiding the "out of inodes" : message. : Stripping those UNIX tools would make developing software much more : difficult. As a long time UNIX user, I sometimes find myself yearning for grep, or sed, or f77? or ... on my Mac. And in the little time I've spent on NeXT systems, I found NeXT to be the user-friendliest UNIX. But I don't think that makes OpenStep user-friendly enough to be the NeXT-MacOS. Hancock and Amelio have said that additional effort will be made to de-UNIXize Rhapsody, including a "Advanced Macintosh Look & Feel". Whether this means replacing the file manager with something Finder-like or a more extensive revision including replacing the kernal, etc., we'll have to wait and see. The UNIX commands everyone is so concerned about fall into 3 categories, Applications, (tar, emacs, ...), Core OS functions (passwd, mount, ...), and System services (df, cp, rm, mkdir, ...). Every OS provides some form of the later 2 sets. For example, Apple will provide a system-wide file removal function for developers to use, even if it not the Unix rm. A principle difference between UNIX and MacOS is the ability of a user, from a CLI, to access such system services. Certainly, such a CLI will be completely optional in Rhapsody. The question is how far does de-UNIXize go? Is hiding it from novice users enough, or does it need to disappear completely? We'll all have to wait a few months to know, since I doubt it's even been completely decided by the Apple-NeXT system software team. One thing I'm pretty sure of is that the applications like tar, emacs, and especially cc, will not be present. This new OS will not survive without developer support, and I mean support by current Mac developers, not NeXT developers. Apple can't afford to upset its developers by giving away things that will in any way make users reluctant to buy new software. Yes, I know that this will break the current NeXTStep and its applications, but this in not NeXTStep 5 we're discussing, but MacOS 8. A lot of this thread is "NeXT wouldn't do ..." or "That would break existing NeXT applications", but it's not NeXT doing it, it's Apple. We'll see what the amalgamation of Apple and NeXT produces. It'll be a much different OS than either the Mac or NeXT adherents expect. I'm hopeful, but I expect any CLI to be an application you buy or at least download. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: Dave Griffiths <dave@prim.demon.co.uk> Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Sun, 19 Jan 1997 12:11:52 GMT Organization: Primitive Software Ltd. Message-ID: <1997Jan19.121152.449@prim.demon.co.uk> References: <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <milkweed-1501970042260001@port5.chester.smallmedia.com> <kmrG7VK00iV945mAVH@andrew.cmu.edu> In article <kmrG7VK00iV945mAVH@andrew.cmu.edu> Charles W Swiger <cs4w+@andrew.cmu.edu> writes: > >There are some nice aspects to Java (especially the package hierarchy >for multiple namespaces), but it is not nearly as mature as Obj-C and >the object libraries available for Obj-C. Let's not forget that there is no standard "object library" for Obj-C. Obj-C by itself is pretty useless, you need at least either the Object or NSObject class. The latter came into being, what, two years ago? Not sure what the Gnu people are doing, but that might constitute a third version. I would argue that Java is as mature as the Foundation Kit and is certainly being used by a lot more people. Dave
From: Dave Griffiths <dave@prim.demon.co.uk> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Sun, 19 Jan 1997 11:56:33 GMT Organization: Primitive Software Ltd. Message-ID: <1997Jan19.115633.364@prim.demon.co.uk> References: <MWRon-0701972046550001@aumi3-a03.ccm.tds.net> <32D33F89.7C0E@watershed.com> <5b1j73$fr3@sjx-ixn2.ix.netcom.com> In article <5b1j73$fr3@sjx-ixn2.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) writes: > > NeXT apparently recently released support for mixing Java and Objective-C >to the extent that a class implemented in one language could be subclassed in >the other language, so this might be a reasonable approximation if it works >seamlessly. I don't have any details about this, so maybe I just dreamed it >:-) As I understand it, it's not quite seamless. If you have a Java subclass of an Obj-C class, the Java code cannot access the superclass instance variables directly. But a lot of people would consider that a good thing. Dave
From: toon@gaea.titan.org (Greg Titus) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 20 Jan 1997 07:33:13 -0800 Organization: Omni Development, Inc. Message-ID: <5c037p$57q@gaea.titan.org> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <5bmhl7$qqf@darla.visi.com> I'm skpping over several parts of your post because I think they've been adequately answered elsewhere. Anders Pytte (milkweed@plainfield.bypass.com) wrote: : I don't understand how this works. May one create a behavior just once, as : protocols, mix them into various objects, go back and change the behavior, : and have this change effect all classes to which the protocols have been : added? Not directly. Protocols are inheritence of interface, not of implementation. Java's concept of interfaces is similar. To combine implementation functionality you would generally use object composition under Obj-C. : May the classes to which you have added a set of protocols be passed to : methods that take as an argument any classes containing that particular : set of protocals? If not yes to all the above then there is really no : equivalence to multiple inheritence. It isn't equivalent to multiple inheritence, as you can see above. Protocols are a more natural construct than MI in a couple of the patterns in which MI might be used by C++ programmers. In Obj-C, of course, you can send any object to any method if you are not using static typing; what you are really asking is whether you can use static typing with protocols to make the compiler check that you aren't sending any messages to an an object not in the protocol.... Yes, you can. The Objective-C syntax looks like: - (void)aMethod:(id <ProtocolName>)argThatConformsToProtocol; or more complicated: - (void)anotherMethod:(SomeSuperClass <Foo, Bar, Baz> *)arg; The first method takes an argument that conforms to the ProtocolName protocol, the second takes an argument that is a SomeSuperClass or subclass thereof, and also conforms to the Foo, Bar, and Baz protocols. (Of course, if SomeSuperClass conforms to all these protocols itself, you aren't gaining anything by this declaration. You'd use this kind of thing where you wanted to make sure the method was called with only the subset of subclasses that responded to the messages you wanted.) Also, protocols are first class objects, and you can test at runtime whether an object conforms to a protocol (similar to the way you can ask an object whether it implements a particular method). - (BOOL)conformsToProtocol:(Protocol *)aProtocol; ---Greg --------------------- Greg Titus Omni Development Inc.
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: Doesn't anyone know about power management? Date: 20 Jan 1997 16:41:52 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5c078g$325i@news.doit.wisc.edu> Hi, I have posted several times asking for any information anyone might have on the interface the kernel has with the APM bios, since NeXT won't provide it (though I am still working on them). I have yet to recieve ANY information. It seems surprising that *no one* else has even looked into this. Please, if you have any insights or information about the way the mach kernel in 3.3 and 4.x deals with power management, I would appreciate the info. I would like to try to write a driver to improve the performance, as well as providing working suspend/resume, particularly for Toshiba Tecras. I have downloaded the APM specs and for the most part understand how the bios portion should work, it's just that the kernel has some built in routines that aren't published which interface with the bios. Thanks -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Mon, 20 Jan 1997 15:55:37 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E4BDKr.7nC@cam-ani.co.uk> References: <SHESS.97Jan17125637@howard.one.net> > In article <acurylo-1601971109400001@van0217.tvs.net>, > acurylo@inmediapresents.com (Alex Curylo) writes: > What gets me is how, if all these super-neat features like this > that the Obj-C guys keep casually throwing out really do exist as > described, why on earth did the universe at large adopt C++ > instead? Why did the universe accept DOS? MSWord? Manual insert/eject floppies? VHS videos? people buy what they're told to buy. Even programmers (who should be smarter than average) follow the crowd. Most don't want to stand up and shout about making things better. In article <SHESS.97Jan17125637@howard.one.net> shess@one.net (Scott Hess) writes: > The background of C++ is more control-driven, while the > background of Objective-C (Smalltalk) was more event-driven. At the > time, this was somewhat of a big concern, because you had to buy into > a couple paradigm shifts all at once. My first reaction to C++ was "this isn't OO". In C++ the objects exist within the code. In Objective C the code exists within the objects. It makes all the difference. >Programming NeXT's AppKit is very Zen-like Giving up the flow of control is the greatest step forwards a programmer can make. "he who would hold it in his grasp loses it". once released you build objects which ARE things. They have behaviour which DOES things. the code becomes irrelevant. Actually my favourite quote at the moment is "to gain knowledge, add something every day. to gain wisdom remove something everyday." or to missquote "to gain code, add something every day. to gain a program remove something everyday." "to gain features, add something every day. to gain a functioanality remove something everyday." "to gain programming staff, add something every day. to gain a customers remove something everyday." $an
From: Michael Hudson <sorry.no.email@nowhere.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Mon, 20 Jan 1997 16:48:33 +0000 Organization: University of Leicester, UK Message-ID: <32E3A1E1.7BC@nowhere.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have just read in excess of twenty posts about "Multiple Inheritance (Re: NextStep & Mac Frameworks)" that discussed the relative merits of Objective-C and C++. Not one of these mentioned templates. Does Objective-C have templates? While we're about it, are the following features present, absent or irrelevant? (I'm not implying that I couldn't live without them all; I'm just curious) RTTI Exceptions The STL Function overloading User defined type conversions I apologise if I'm being uncultured, but C++ is my only language. -- Regards, Michael Hudson Please don't email this address - it's not mine.
From: "Thomas E. Zak" <tzak@earthlink.net> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Mon, 20 Jan 1997 11:49:26 -0500 Organization: Ford Motor Company Message-ID: <32E3A216.794B@earthlink.net> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <32E1C3C0.3E5A@washdc.mindspring.com> <0msZFYq00iWTM1J=5W@andrew.cmu.edu> <32E21849.265F@washdc.mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike wrote: > > Charles William Swiger wrote: > > > > Excerpts from netnews.comp.sys.next.advocacy: 19-Jan-97 Hard Drive as > > Folders? (was.. by Mike@washdc.mindspring.c <Speaking of Unix style fileststems...> ... If two people use the computer, can they map the same > hard drive to two different points in the file system? > Speaking about Unix in general, rather than Next, or whatever this thread started with.. If you mean linking the entire hard drive at two different points in the file system, NO. But you can link the hard drive at one point and use symbolic links (aliases) to make it appear that it is in two locations. If you mean link different partitions in separate locations, then yes, it is possible and happens quite often. Under Unix you are able to take fractions of drives or multiple drives and treat them as a single entity. > If I had a 2Gb drive with two 1Gb partitions, would I be able to have > one partition mapped into the file system for user A's account and the > other partition mapped into the file system for user B's account? That'd > be nice: neither user could muck around with the other's documents. > Although I see some problems with that if they had to share certain > files. No, I don't believe that you can have two drives with the same name, swapping between them based on userid. It would make it difficult for the superuser to handle them, since his account must be able to access both drives. The way that this is handled would be to have 2 or 3 separate drives (assuming you want to limit the space usage of the users). For example /machinename/u/personA (home directory of person A) /machinename/u/personB (home directory of person B) /machinename/projects ( common files and programs) the file permissions for those drives ( which are set the same way as folders and files ), would say that only person A (and root)has permission to read or write files in the personA directory. Likewise for person B and his directory. Finally the project directory should be readable and writeable by everybody in this project group (each user belongs to one or more groups). A simplified explanation of Unix permissions: drives, folders, files, links(aliases),devices(tape, cdrom, printers) all have the same base set of permisisons permisions for the owner (everything is owned by somebody) permissions for the group (everything has a group it belongs to ) permissions for everybody ( if you're not the onwer and you're not in the same group, then this means you ) The possible permissions are read: can look at the object write: can edit or delete the object execute: can use the object - run an executable program/script - look at the contents for drives/folders So if you don't want somebody mucking around in your stuff, you set the permissions so they cannot. > > This leads me to think that in a networked environment, I would be able > to mount hard drives from other computers into my file system when I > start up, right? Sort of like automounting servers on a Macintosh > network. > Basic NFS (network file system) mounting is done at startup, or whenever you restart the nfs daemons. That will mount the drives of other machines onto your machine. Automounting under Unix has a different meaning. This means that the drives are NOT mounted on startup, They are mounted only when you try to access them, and once you leave those drives idle for a certain time, they are automatically unmounted. > > > Tell me if I'm wrong, but if this is the case, then I could have four 2Gb > > > hard drives all mounted at the same place in the file system and it would > > > appear that I have one 8Gb hard drive, right? And the OS will know when one > > > fills up and begin using available space on the next drive? And I could just > > > keep on growing my hard drive? > > > > > > Could I set things up so that, using the four drive example above, two > > > of the drives are a mirror of the other two? And if I pulled one of the > > > drives, things would keep humming along? > > > > What you are asking for are logical volumes and mirroring. NEXTSTEP > > currently does not support either one, although it would be nice if it > > did. Why don't you make that suggestion to Apple? > > Ahhh. Logical volumes. That's what I want. Would it be difficult for the > guys at NeXT to get logical volumes supported? Are logical volumes a > fairly common part of other operating systems? What would happen if one > of the hard drives that makes up a logical volume takes a dive? Seems > like that would present some pretty sticky problems! > Not being a system administrator, I don't know all of the details. However, you can take four 2GB drives and make them appear as an 8Gb drive. But if you want to change that setup by adding or removing drives, it is a pain in the rear, and you will often have to repartition the drives. If you wanted to add or remove mirroring, that shouldn't be much of a problem, but removing one out of a set of mirrored drives is generally considered an error that needs to be fixed. -- Tom Zak Sterling Technology tzak@earthlink.net
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 19 Jan 1997 17:39:51 GMT Organization: Rockwell Avionics - Collins Message-ID: <5btm97$i2m@castor.cca.rockwell.com> References: <5bq73r$e18$1@solaris.cc.vt.edu> Cc: dlehn@crib.bevc.blacksburg.va.us A direct to screen API does exist for NeXTstep but it is not portable for obvious reasons to other OpenStep/Hardware combinations. Buffered drawing is no problem with OpenStep (this is the default). Sound, speech, networking are all "built in". In particular, network gaming is AWESOME via nextstep. 3D is an interesting problem. The 3D support in NeXTstep (Renderman) is powerful but slow. Most 3D games will have to write their own engine on any platform. The lack of OpenGL on NeXTstep is a portability problem. See various public domain "GameKits" available via ftp.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Sun, 19 Jan 1997 16:50:01 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <omsdQ9600iWn07yXo0@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <32E1C3C0.3E5A@washdc.mindspring.com> <0msZFYq00iWTM1J=5W@andrew.cmu.edu> <32E21849.265F@washdc.mindspring.com> In-Reply-To: <32E21849.265F@washdc.mindspring.com> Excerpts from netnews.comp.sys.next.advocacy: 19-Jan-97 Re: Hard Drive as Folders? .. by Mike@washdc.mindspring.c > > However, when you look at '/' or where some filesystem device is located > > in the WorkSpace, you do in fact see a pretty icon that represents what > > the device is, and you can put new icon files at the top directory of > > whatever device it is if you want to change what that drive looks like. > > Good. I'd hate to think what I would do without all my Simpsons icons! > But wait a second. If two people use the computer, can they map the same > hard drive to two different points in the file system? Yes. That's what you normally do with removable media like a Zip or Jazz drive. Normal hard disks are normally mounted in fixed positions at boot time, and their filesystems stay in the same places for all users. You don't have to mount them like that that if you don't want to, but then they are treated more like removable media in that the console user has permission to do anything to that filesystem, whereas permenently-mounted drives have the standard Unix filesystem permissions enforced. > If I had a 2Gb drive with two 1Gb partitions, would I be able to have > one partition mapped into the file system for user A's account and the > other partition mapped into the file system for user B's account? Yes. > That'd be nice: neither user could muck around with the other's documents. > Although I see some problems with that if they had to share certain > files. The normal Unix permissions allow you to share files with other users according to the control of user, group, and other (aka world) permissions. > This leads me to think that in a networked environment, I would be able > to mount hard drives from other computers into my file system when I > start up, right? Sort of like automounting servers on a Macintosh > network. Of course-- NEXTSTEP comes with NFS, which lets all machines act as both a fileserver client and a fileserver server. [ ... ] >> What you are asking for are logical volumes and mirroring. NEXTSTEP >> currently does not support either one, although it would be nice if it >> did. Why don't you make that suggestion to Apple? > > Ahhh. Logical volumes. That's what I want. Would it be difficult for the > guys at NeXT to get logical volumes supported? Are logical volumes a > fairly common part of other operating systems? What would happen if one > of the hard drives that makes up a logical volume takes a dive? Seems > like that would present some pretty sticky problems! That type of functionality is becoming more common, although it's often sold as an add-on product, and yes-- getting it to work reliably even through otherwise-fatal drive crashes is somewhat tricky. > After reading my current issue of SciAm, I'm fully confident that NeXT > is going to kick some ass and give all us Mac people some really slick > stuff. I hope so too, although you should realize that NeXTizens are hoping to see some important things come from the Apple side of the deal.... :-) -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Dirk Vleugels <vleugels@do.isst.fhg.de> Newsgroups: comp.sys.next.programmer Subject: SPARC OpenStep & GCC Date: 19 Jan 1997 23:01:32 +0100 Organization: FhG ISST Dortmund, Germany Sender: vleugels@po Message-ID: <y7yhgkd5npf.fsf@do.isst.fhg.de> Hi, i installed OpenStep 1.0 on a Creator2 running Solaris 2.5.1, and i'm quite impressed. Question: I do have the header files NS* & stuff + the shared libraries: total 12108 lrwxrwxrwx 1 root other 14 Jan 19 03:25 libAppKit.so -> libAppKit.so.1* -rwxr-xr-x 1 bin bin 4282152 Aug 9 03:13 libAppKit.so.1* lrwxrwxrwx 1 root other 18 Jan 19 03:25 libFoundation.so -> libFoundation.so.1* -rwxr-xr-x 1 bin bin 1346060 Aug 3 04:04 libFoundation.so.1* lrwxrwxrwx 1 root other 20 Jan 19 03:25 libObjcSelector.so -> libObjcSelector.so.1* -rwxr-xr-x 1 bin bin 363328 Aug 3 04:04 libObjcSelector.so.1* lrwxrwxrwx 1 root other 18 Jan 19 03:25 libidlRuntime.so -> libidlRuntime.so.1* -rwxr-xr-x 1 bin bin 32508 Aug 3 04:04 libidlRuntime.so.1* lrwxrwxrwx 1 root other 12 Jan 19 03:24 libobjc.so -> libobjc.so.1* -rwxr-xr-x 1 bin bin 119316 Aug 3 04:04 libobjc.so.1* drwxr-xr-x 3 bin bin 512 Jan 19 03:25 locale/ Is it possible to develop software with the free GCC? Do i need the AppBuilder? I couldn't find a SUN ObjC compiler + OpenStep SDK. Any hints (please reply also by mail)? Dirk -- "It's 206 ms to Chicago, we've got a full disk of GIFs, half a meg of hypertext, it's dark, and we're wearing sunglasses." "Click it." -- <bluesbros@bluesbros.com>
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 20 Jan 1997 17:46:21 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c0b1d$aiu@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : raph@porter.as.utexas.edu (William Raphael Hix) wrote: : > Example: does the existence of tar, a reasonably able backup : > utility with a really unfriendly UI, make companies like Alladin : > or Dantz who make backup software more or less eager to port to : > Rhapsody? I think less likely, because the number of potential : > buyers for Stuffit is reduced by the existence of tar and freeware : > extensions. : : I don't think it effects them one bit. : : For one, most Mac users are used to Stuffit. They are not used to : opening a unix window, and then figuring out all the options on : tar. They will be much more likely to spend another $30 for a new : version of Stuffit than bothering with tar. : : For two, Stuffit includes a very nice user interface. It is a : "finder interface" to your compressed archive. Tar, by itself, is : relatively crude. A front-end to tar might be competition to : Stuffit, but tar by itself simply can not compete. : : For three, *I* don't use tar as a backup utility, and I'm more : familar with tar than the average mac user is. I would very much : prefer to have something like "Diskfit" for my NeXTSTEP system, : and I've been using NeXTSTEP for years. Then you are essentially arguing that tar is of little use? If this is so, then why bother including it on everyone's disk? But I think this has become too fixated on tar. These are the issues that Apple faces with respect to such Unix utilities. There will be developer pressure on Apple to not duplicate the functions of 3rd party applications. Even before the new OS, Apple's usurpation of functionality was one of the main complaints from developers. Apple is particularly beholden to their developers now since without developer support, Rhapsody is OpenStep/PPC. In general, there are 2 extreme cases. Case #1, Unix utility A does everything (perhaps with a freeware wrapper) and so is a replacement for Mac Software B. In this case the Mac software developer never ports the application. There will be pressure on Apple to drop such functions. Case #2, the Unix utility A is a "poor" substitute for Mac application B. In this case, what is the point of including this utility in the OS? Unix compatibility comes the reply. Well, how important is Unix compatibility? It's clear from this thread that to NeXT users it's essential. But how much does this matter to the Mac community that Apple is pitching Rhapsody to? Would they rather have the system take up less space or have Unix compatibility 99% of them would never use. The feelings of NeXT users (none of whom have compatible hardware) are secondary to the 10-100 times larger Mac community. What about find? Should Apple leave the Unix find when we know they're going to include their new V-Twin search engine and Find File. Well, the V-Twin certainly replaces find if you are a GUI user, but what about CLI and scripts? Will Apple leave find for the 1% of users who might want to use their Mac like a Unix box? Naturally, every real example is somewhere in between, but both of the extreme cases argue against strong Unix compatibility. It will be interesting to see how Apple resolves this. Perhaps some add-on Unix compatibility, even from a 3rd party. Apple will need to compromise to fit Rhapsody to the needs of Mac users, and I fear that such compromises will come at the cost of NeXT users expectations. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Date: 19 Jan 1997 23:01:08 GMT Organization: The University of Calgary Message-ID: <5bu93k$ka6@ds2.acs.ucalgary.ca> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> Alan Lovejoy (alovejoy@concentric.net) wrote: > > With the CLI tools under Unix, sending a message in C is a one-liner: > > > > system("echo 'This is the contents of the message.^D' | mail -s 'My > > Subject' '<cs4w@andrew.cmu.edu>'"); > The same could be done in C without using the system() > function. But it would be ugly and awkward by comparison. > However, the fault lies both with C and with the standard C > library. There is no inherent fault of C or C++ that would make this awkward. The fact that the standard C library doesn't include a cross platform standard mail API isn't exactly unique. Very few standard language libraries do. > In some other programming language, such as Smalltalk (hey, you > knew this was coming, right?), coding the above could be as > simple as: > > MailTool > sendMessage: 'This is the contents of the message.' > withSubject: 'My Subject' > to: '<cs4w@andrew.cmu.edu'. Whereas in Objective-C this becomes unbearably complicated? [ MailTool sendMessage: "This is the contents of the message." withSubject: "My Subject" to: "<cs4wandrew.cmu.edu>" ] ; ... both examples assume that somebody has provided the hypothetical MailTool API, which AFAIK isn't a standard piece of either language. > If it were this simple in C (for everything, not just sending > mail), then perhaps the system() function would be used much > less. Yes, it's true, if there were an API function or method for every conceivable purpose life would be very easy. There isn't. There probably will never be. In the mean time, the system() function can be VERY handy if you know that your target system fully supports the tools you intend to use. -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: 20 Jan 1997 17:07:22 GMT Organization: Airwindows Message-ID: <jinx6568-2001971209430001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <32E1C3C0.3E5A@washdc.mindspring.com> <5bulhh$7ch@csugrad.cs.vt.edu> In article <5bulhh$7ch@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > And the OS will know when one fills up and begin > > using available space on the next drive? And I could just keep on > > growing my hard drive? > That sounds like RAID to me.. where the OS treats multiple drives like > one and stripes files across all of them. NEXTSTEP doesn't have that.. > though Apple should add it if they want to compete with NT in the server > market. Actually that's a separate issue- the logical volume does not necessarily stripe (indeed this might be a bad thing in case one of the disks goes down), it would work like the disks were large blocks of space to use, and would assemble them into one logical volume. The striping is for extremely fast read and write (note that access times will not be particularly better, just throughput). Finally, mirroring (obviously) is a sort of failsafe, using two disks and doubling the data. I believe RAID is a very specific implementation of these things and not simply the existence of striping/logical volumes/etc. The Mac already has all this as third-party (FWB Toolkit), though it would be nice to see it as part of the system software. It seems a pity to step on FWB's toes that way... but if I'm offered this stuff stock I won't spend too much time feeling sorry for FWB. *shrug* Jinx_tigr (aka Chris Johnson)
Date: Sun, 19 Jan 1997 18:18:31 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <milkweed-1901971818310001@port5.chester.smallmedia.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <32E14BF1.7D13@afs.com> Organization: Milkweed Software In article <32E14BF1.7D13@afs.com>, greg@afs.com wrote: > Stack based objects that clean themselves up at the end of an execution > block would be a nice figure. Intriguingly, that WAS part of StepStone's > original implementation, but NeXT never supported it. Operator > overloading is one of those things you either love or hate, in my > experience. I can take or leave it. I've seen too many C++ classes where > it's done poorly or unintuitively. I remember coding floating point arithmetic using SANE procedure calls in Lisa Pascal during the earliest days of Macintosh development. That created relatively unreadable code - I'm sure no one misses those days. Now if I want to do alot of fixed point arithmetic (or complex or vector or matrix or topological...) I guess I would prefer using familiar operators. Although I appreciate the generalization, i neither love nor hate operator overloading, but I recognize a class of problems to which they are ideally suited. Once almost any language feature has been around long enough people will compile examples of misuse. We strain to create languages that make bad programming impossible, but I think the only cure is simply good programming practices. In any event, thanks for your good natured remarks. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: HisMajesty <fatjelly@mbox2.singnet.com.sg> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Mon, 20 Jan 1997 21:08:32 +0800 Organization: The WatchTower Message-ID: <32E36E50.2769@mbox2.singnet.com.sg> References: <5ami95$ol3@news.tuwien.ac.at> <32E1C3C0.3E5A@washdc.mindspring.com> <0msZFYq00iWTM1J=5W@andrew.cmu.edu> <32E21849.265F@washdc.mindspring.com> <5bum0h$9us@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We seem to have some conflict in opinions about locical partition of volumes here. Can anyone confirm?
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 14:10:06 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0fue$2e7@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> In article <5c0b1d$aiu@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > In general, there are 2 extreme cases. Case #1, Unix utility A does > everything (perhaps with a freeware wrapper) and so is a replacement for > Mac Software B. In this case the Mac software developer never ports > the application. There will be pressure on Apple to drop such functions. There probably aren't very many of these. Most of the Unix utilities are rather simple. A typical Mac application will duplicate the functionality of a number of Unix ones, with a nice graphical interface to boot. > Case #2, the Unix utility A is a "poor" substitute for Mac application B. > In this case, what is the point of including this utility in the OS? Unix > compatibility comes the reply. Well, how important is Unix compatibility? > It's clear from this thread that to NeXT users it's essential. But how > much does this matter to the Mac community that Apple is pitching Rhapsody > to? Would they rather have the system take up less space or have Unix > compatibility 99% of them would never use. The feelings of NeXT users > (none of whom have compatible hardware) are secondary to the 10-100 times > larger Mac community. Umm, Unix is important for people who want to run servers, you know. There is a lot of server-related software out there for Unix. A lot of it won't work if you throw out random utilities that are generally assumed to exist on a Unix platform. Do you want to see Rhapsody have an impact in the corporate environment? Not everyone is a home user. (And remember, Unix is the only thing that currently competes with Windows NT. Just being able to say that their operating system is Unix gets Apple's foot in the door with the corporate types, most of whom regard the Mac as a toy when it comes to high-end servers.) > What about find? Should Apple leave the Unix find when we know they're > going to include their new V-Twin search engine and Find File. Well, the > V-Twin certainly replaces find if you are a GUI user, but what about CLI and > scripts? Will Apple leave find for the 1% of users who might want to > use their Mac like a Unix box? Why not? All these Unix utilities don't take up much space. Crippling a Unix system isn't worth the effort. The _only_ consideration is whether the existence of these utilities will hurt developers with similar products, and I don't think that this is a serious problem. I doubt 'find' is going to replace V-Twin for desktop use, but there are plenty of sysadmins and shell scripts who use it. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 20 Jan 1997 14:35:44 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0heg$jud@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> In article <5c04e3$gh9@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > In article <32E30DB4.7126@concentric.net>, > Alan Lovejoy <alovejoy@concentric.net> wrote: > >Yes, the system() function is a necessity in today's world. > >I think the goal of Rhapsody (and all Unixes) should be to continuously > >make it less so over time. Perhaps one day... > Why? Which is better? Accessing system services via distributed message passing, and dynamically loading and unloading object bundles into a running process's context? Or forking and exec'ing a shell to execute a new process, with all its associated overhead, and communicating with stream-based I/O that needs to be parsed into data structures? I like the former approach a lot better. Not that I'm advocating ripping Unix utilities out, or even saying that you shouldn't write apps which call utilities via a system() call. (Unlike some other people on this group...) Far from it. I love Unix and the Unix command line. I just think it would more elegant if most of the Unix functionality were wrappered with objects. Then the utilities could slowly be rewritten into object libraries, so that instead of having programs with object wrappers, you have programs which are thin wrappers around the objects. (Like 'ls' messaging a FileList object or something.) If you design the object wrappers well, you won't even have to change the application code that calls them. The replacement objects will have the same interface as the wrappers; the wrappers would have a system() call implementation, but you wouldn't be able to tell. Then you could either use command-line programs the way you're used to, or programatically interface to the OOP API directly from applications. In practice, the way I think this would happen is Unix utilities being rewritten one-by-one so that they depend on little libraries instead of integrated code, and then making those libraries object-oriented. (It might be better to put object wrappers around C libraries so that you can still access their APIs from C or some non-OOP language if you want.) During the long conversion process, there would still be no problem with writing apps which call programs via object wrappers using the system() call. Comments? Do other Unix hackers think this is the way Unix should evolve? The big problem is something that someone else has mentioned.. The object models of different languages do not agree. I'd love it if everything was based on Obj-C objects, but C++ has a tough time with them. You can use things like CORBA, but it makes ugly compromises to preserve language-independence (nowhere near as elegant as PDO), IMHO, and imposes a performance penalty. I can't think of a good solution to this problem as long as insufficiently dynamic OOP languages like C++ are in common use. (Dynamic ones have a much easier time talking to each other's objects directly.) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: 20 Jan 1997 14:41:03 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0hof$7hv@csugrad.cs.vt.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32E21849.265F@washdc.mindspring.com> <5bum0h$9us@csugrad.cs.vt.edu> <32E36E50.2769@mbox2.singnet.com.sg> In article <32E36E50.2769@mbox2.singnet.com.sg>, fatjelly@mbox2.singnet.com.sg wrote: > We seem to have some conflict in opinions about locical partition of > volumes here. Can anyone confirm? Well, where someone else's statements differ from mine, I'm probably wrong. :) Some of the questions have implementation-dependent answers, and I'm not familiar with all implementations. It could be possible that some things I said couldn't be done actually can be done under some operating systems. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 20 Jan 1997 14:51:35 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0ic7$ppv@csugrad.cs.vt.edu> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> In article <32E3A1E1.7BC@nowhere.com>, none wrote: > Does Objective-C have templates? No. They're not generally regarded as necessary in a runtime messaging system. In fact, to hear my C++ friends complain, they hurt you more than they help you.. > While we're about it, are the following features present, absent or > irrelevant? (I'm not implying that I couldn't live without them all; I'm > just curious) > RTTI Objective-C's runtime is better than RTTI. > Exceptions I hear C++ does some slick things with exceptions. The OpenStep Foundation Kit has an NSException object you can use, but exceptions aren't built into the language. > The STL Most if not all of this functionality is subsumed into the Foundation Kit. > Function overloading I don't think so. > User defined type conversions Absent. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:16:17 -0500 Organization: Atria Software Message-ID: <maury-2001971516170001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> In article <0mrz3kS00iVGI9e7EM@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: > Because you need the shell and the utils in order for the operating > system to boot in a flexible way that can be maintained by a system > administrator. Great, so have a shell that calls the OOPS libs. In fact, have lots of them. > Furthermore, there are a large number of Unix server applications which > are based off of those utilities. And which ones would the average Mac user want? Remember, there's 25 million Macs out there, and I'd be willing to bet that 90% of them could care less. Notice how "overwhelming" POSIX support was wanted under NT for instance. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:02:03 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-2001971502040001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <5bn20b$lmn@sjx-ixn6.ix.netcom.com> <maury-1701971146010001@199.166.204.230> <5boces$kft@dfw-ixnews11.ix.netcom.com> In article <5boces$kft@dfw-ixnews11.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > We probably wouldn't have these examples to look at (and more > importantly, *use*) if these shell utilities weren't available *and* their > functionality wasn't duplicated in functional or class APIs. Balogna. There are neither Unix utils built into the Mac OS, nor are there any OOPS libs either. Nevertheless the exact examples given here of why you need the utils already exist on the Mac in "pure" form - ie, not a shell to a Unix utils. This point is simply invalid. > You made the point that if all the functionality of shell utilities were > available in function or class libraries, then these shell utilities wouldn't > be necessary for apps to use. This is a valid point, but one which hasn't > been achieved yet. It's a worthy goal, but until that happens, don't rip out > the shell utilities just to save a few MB of cheap disk space. That's not quite my point, although it's one of them. The main complaint is that as long as these utilities exist, so will code that accesses them. This is bad for the users, for the system, and most of all, for the developer. Why the developer? Well none of these utilities exist on the OpenStep/NT platform either to my (limited) knowledge, which means if you use them you thus are unable to run under that system. A OOPS lib, even one that is simply a shell for underlying Unix code is inherently portable, as OpenStep itself amply proves. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:06:20 -0500 Organization: Atria Software Message-ID: <maury-2001971506200001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <5bofh1$g3f@csugrad.cs.vt.edu> In article <5bofh1$g3f@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Or for the people who prefer using a CLI to a GUI in order to perform > some tasks. Agreed. > You don't have to send them out to the shell, you can fork 'grep' > directly. Yes yes, but it's the same process to the developer for all intents and purposes. Instead of "run this query object" it's "flatten this object's search string to text, fire up grep, process the strings that come back into objects again and then display them". > grep isn't a bad example, actually. Even in our > object-oriented world, plenty of things (such as mail folders) are > stored as text Whereas a OOPS based search engine (lots of which exist and Apple's will almost certainly appear in this new uber-OS) do all the same and more, from direct calls. > It is certainly cleaner that way. I would like to see more Unix > utilities have their core functionality folded out into separate > libraries, with the CLI utils being mostly wrappers to those APIs. Well this is all I am asking for. > However, practically speaking, it is just plain a lot less work to put > OOP wrappers around existing CLI programs. Hey, fair enough. If that's the solution, so be it. And yet, I see no one doing this, do you? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:07:31 -0500 Organization: Atria Software Message-ID: <maury-2001971507310001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> In article <5bonbb$6r4@news.internetmci.com>, rdogra@mailserv.metro.mci.com (Rajnish Dogra) wrote: > As far I know NeXT ships (with OPENSTEP for NT) some if not all the unix > utilities and even has Terminal.app. Really?? Uggg. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:14:36 -0500 Organization: Atria Software Message-ID: <maury-2001971514370001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> In article <32DFF7DB.167B@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > This would make it more difficult to use C, FORTRAN, COBOL, BASIC, RPG, > Assembly and other non-OO languages with the OS. You make that sounds like a bad thing. But seriously, this strikes me as a problem for data-processing like tasks only. The entire GUI is already OOPS lib based, and I don't see anyone crying over that. Do you? Although I haven't even used ObjC on the NeXT platform yet, I understand that many (all) of the above languages already exist. Are they all limited to creating programs that run from the CLI only? If not, it seems this isn't much of a problem after all. > more difficult to use OO languages whose object models were not compatible > with the one used to implement the kernel and libraries. Only in their current form. Apple's got more and more code being based on SOM, which has no such limitation. > One could perhaps use CORBA/SOM/DSOM to address such issues. But CORBA exacts > a noticeable performance penalty. Well I might be missing something here, but I always believed that if your compiler talked SOM, there was no inherent overhead. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:22:48 -0500 Organization: Atria Software Message-ID: <maury-2001971522480001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> In article <5bshs8$e5n@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > (Win-like???? Are we talking about the same Windows? You know, that > operating system that likes to dump files everywhere on your drive? > Windows does NOT have a mandatory Applications folder or anything like > that.) How can you possibly say that after blasting me over not wanting /bin on my drive! > I don't understand why you want to scatter your applications all over > the filesystem. Because it's MY file system. You don't have to like it, do what you wish. > I don't know anyone who does this. Even the Mac > people tend to put everything in the Applications folder or a > subdirectory of it. Balogna, I can't think of a single Mac I've every had the pleasure of using that had all of it's programs arranged such, and that's a large number of Macs (in the hundreds). That's just _wrong_. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:25:06 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-2001971525060001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> In article <ImsZy1y00iWT41JBZF@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > But that's not what you're arguing about-- you seem to be claiming that > it is wrong for a program to execute a CLI utility to perform some task. > And that's silly. Why don't you show me how you'd use system calls on > any OS you'd like to send email? Ever heard of MAPI? Sure you have. > system("echo 'This is the contents of the message.^D' | mail -s 'My > Subject' '<cs4w@andrew.cmu.edu>'"); Who's parameters have likely been "strung out" from objects running under OpenStep. I'd rather just pass the object, thank you. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:29:13 -0500 Organization: Atria Software Message-ID: <maury-2001971529140001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> In article <cmshmdm00iVE09CsxH@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > I disagree strongly. I do not believe the standard C library should > have to implement every conceivable command that is available via a > fork()/exec() or system() call. For gossakes, people, there is > something to be said for a manageable API instead of throwing everything > including the kitchen sink into the "standard system library". What "standard system library"? Who's arguing for that? No one that I can see. As far as I can tell, we're all arguing for a bunch of small shared libs. Geez. > For example, system("/bin/rm -rf /tmp/My_Programs_Temp_Dir/*.ckp") is myQuery.Find Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:30:27 -0500 Organization: Atria Software Message-ID: <maury-2001971530280001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> In article <5bumdc$evr@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Really, there's no point in ripping out Unix. Yes there _is_: a) easier on the programmers b) more cross platform Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:27:43 -0500 Organization: Atria Software Message-ID: <maury-2001971527440001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> In article <5bu93k$ka6@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca (Blake Stone) wrote: > ... both examples assume that somebody has provided the > hypothetical MailTool API, which AFAIK isn't a standard piece of > either language. Once again: that doesn't mean it shouldn't be. MAPI... MAPI... MAPI.... > Yes, it's true, if there were an API function or method for every > conceivable purpose life would be very easy. There isn't. So wait, they all exist in the form of CLI utils, but it's impossible to make them in API form. Is it just me? Maury
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 15:45:11 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0lgn$r2b@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> <maury-2001971507310001@199.166.204.230> In article <maury-2001971507310001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5bonbb$6r4@news.internetmci.com>, > rdogra@mailserv.metro.mci.com (Rajnish Dogra) wrote: > > As far I know NeXT ships (with OPENSTEP for NT) some if not all the unix > > utilities and even has Terminal.app. > Really?? Uggg. No, not really. It would be pointless to port a Unix environment over to NT; OpenStep doesn't need it. They only ported a few things. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:19:14 -0500 Organization: Atria Software Message-ID: <maury-2001971519140001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> In article <5bp3f3$1j2@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > I just don't understand you, Maury. You complain about HP making > gratuitous changes in the file system that does nothing but make it > difficult to work in a multivendor Unix environment, and then advocate > Apple making gratuitous changes in the filesystem that does nothing but > make it difficult to work in a multivendor Unix environment. Ahhhh, close except for that last line there. In fact, that's the "non important part to be added later". It's only the NeXT-ites that give two hoots about this, the VAST majority of the users of the resulting OS will be Mac users and they simply don't care about the later. > The only reason I can see for that is you have a vendetta against Unix and > oppose compatibility on general principles. It sure doesn't seem > to be for functional reasons. That's right, it's all illogical. And the sky is indeed green on my planet. Happy now? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:26:20 -0500 Organization: Atria Software Message-ID: <maury-2001971526200001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> In article <32E296A4.4261@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > MailTool > sendMessage: 'This is the contents of the message.' > withSubject: 'My Subject' > to: '<cs4w@andrew.cmu.edu' One must assume the existence of an object storing much of this data even in the Unix case. Thus the line would become something to the effect of... myMessage.send; Maury
From: toon@gaea.titan.org (Greg Titus) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 20 Jan 1997 12:02:07 -0800 Organization: Omni Development, Inc. Message-ID: <5c0ivv$7e4@gaea.titan.org> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> Michael Hudson <sorry.no.email@nowhere.com> writes: >I have just read in excess of twenty posts about "Multiple Inheritance >(Re: NextStep & Mac Frameworks)" that discussed the relative merits of >Objective-C and C++. >Does Objective-C have templates? Nope. Don't need 'em. Templates are a hack to get around the limitations in C++'s strong binding. When you want to manipulate objects in a generic way in Objective-C you just declare your arguments as "id" (any object), and the same method works for everything instead of the compiler making multiple copies of the code for every type of object you might use. >While we're about it, are the following features present, absent or >irrelevant? (I'm not implying that I couldn't live without them all; I'm >just curious) >RTTI RunTime Type Information, definitely. Classes, methods, selectors, and protocols are all first class objects. You can ask whether an object responds to a particular message, or set of messages (protocol), or is of a particular class, et cetera. There is enough information so that it is trivial to take a string entered in the user interface, say "foo", and find whether an object responds to a setFoo: method, if so call it, if not check to see if thee object contains an instance variable named foo, and if so set a new value directly into the object. This breaks encapsulation, of course, but is useful in situations where you want complete control over an object - this is how Interface Builder does its live GUI binding. >Exceptions Yep. Wrapped in objects, even. Get passed back across Distributed Objects connections, even. >The STL No, a lot of equivalent functionality is in NeXT's Foundation framework. >Function overloading >User defined type conversions Nope. These lose a lot of their utility when type isn't so important, as in C++. >I apologise if I'm being uncultured, but C++ is my only language. C++ and Objective-C can be used together, also - even mixed into the same file, and compiled with the -ObjC++ flag, which supports the superset of the two languages syntax. (The class hierarchies of ObjC and C++ can not be mixed, but they can message one another. Every so often I've used this to good effect, generally writing a low level calculation engine in C++ (complex numbers, or matrices, say) and the rest of the code in ObjC. The only place C++ really shines, IMHO, is in these very small, self-contained worlds where lots of small inline functions and operator overloading makes it into more of a macro language than an OOP language.) --Greg -------------------- Greg Titus Omni Development Inc. toon@omnigroup.com
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:13:30 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E3D1EA.7F8F@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > In article <5c0b1d$aiu@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > > > What about find? Should Apple leave the Unix find when we know they're > > going to include their new V-Twin search engine and Find File. Well, the > > V-Twin certainly replaces find if you are a GUI user, but what about CLI and > > scripts? Will Apple leave find for the 1% of users who might want to > > use their Mac like a Unix box? Actually, Apple should let all those people who want Unix hang. Who cares if they buy Solaris, or Windows NT, or run linux on a cheap Pentium? Who needs em. Apple doesn't need new markets, right? Their current markets are doing *just fine*. They're doing just fine on their own. Selling to them home users, schools, and artists. Oh, that's right. Apple's marketshare is dwindling. Apple's traditional markets are moving to Windows. Schools, homes, graphics professionals. Evidently, Apple must not be selling what people want anymore. Apple isn't even holding on to their *current* customers. I think Apple should spend some time to find out exactly what users want. *Not* current Mac users. Former Mac users. Mac users who have left the Mac for NT, Solaris, Linux, IRIX, whatever. Obviously, Apple can't grow their marketshare selling to current Mac owners. Apple has to design Rhapsody for former Mac owners. Then they have to make it clear that Rhapsody is what they really wanted, and that they should come back. An Intel port of Rhapsody would make this easier. Let's see. Apple has about 6% marketshare. If Apple can successfully sell to the 1% of users who want Unix, that would give Apple 7% marketshare. A 16% increase in Mac marketshare. Furthermore, it's an increase, which Apple hasn't seen in many moons. If Apple can grab back the graphics professionals who are using NT, they could probably add another .5%. If Apple can grab webserver marketshare from WinNT, that might account for another .5%. (This would likely be easier if Apple shipped Rhapsody on Intel). That'd increase Mac marketshare by another 1%. -- Jonathan W. Hendry jon @ exnext . com
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 16:21:24 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c0nkk$r0l@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1701971144500001@199.166.204.230> <5bofh1$g3f@csugrad.cs.vt.edu> <maury-2001971506200001@199.166.204.230> In article <maury-2001971506200001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5bofh1$g3f@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > grep isn't a bad example, actually. Even in our > > object-oriented world, plenty of things (such as mail folders) are > > stored as text > Whereas a OOPS based search engine (lots of which exist and Apple's will > almost certainly appear in this new uber-OS) do all the same and more, > from direct calls. Of course. Direct calls are better as long as you still have a CLI you can use. I'm just saying that when you're doing a bunch of streams processing, there isn't as much of a need to have a pure object library. You can convert from objects to streams and back again without much difficulty. What's hard is when a CLI program takes complex input and produces complex output which needs to be parsed. _That_ is a good candidate for ripping out its guts and putting them in a library. > > It is certainly cleaner that way. I would like to see more Unix > > utilities have their core functionality folded out into separate > > libraries, with the CLI utils being mostly wrappers to those APIs. > Well this is all I am asking for. There is a slow trend in this direction. It's happening first with programs which need to do common things. For example, GNU now has a separate library for doing regular expression searches because so many of its utilities need to do that. I hope to see more of this in the future. > > However, practically speaking, it is just plain a lot less work to put > > OOP wrappers around existing CLI programs. > Hey, fair enough. If that's the solution, so be it. And yet, I see no > one doing this, do you? By "this" do you mean OOP wrappers around CLI programs? If so, then I would say that most NEXTSTEP programs which call CLI programs use OOP wrappers around those programs. They may not be complete wrappers, only ones that embed the subset of the CLI program's functionality needed by the app. I'd like to see more of the public-domain developers putting their wrappers in separate libraries and making those separately available, so we can all benefit from them. Certainly, _I_ would do so if I wrote an app that used a lot of CLI functionality. (I haven't yet, but there are a few things I've been considering.) I think that in general, NEXTSTEP programmers are pretty good about proper OOP design. However, I don't think that even most OOP programmers have really gotten into this "objectware" concept. Even under NEXTSTEP, you don't see as many pure object libraries being distributed as you should; too many things are still folded into applications. This needs to change. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: bwanga@cats.ucsc.edu (Timothy A. Seufert) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sun, 19 Jan 1997 19:04:44 -0800 Organization: Evil Geniuses For A Better Tomorrow, Inc. Distribution: world Message-ID: <bwanga-1901971904450001@metricom37.ucsc.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> In article <maury-1601971549250001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: >In article <5bll0l$me7@dfw-ixnews2.ix.netcom.com>, aisbell@ix.netcom.com >(Art Isbell) wrote: > >> Why? Various scripting languages are all the rage now. JavaScript, >> WebScript, VBScript, etc. plus what proponents sell as advanced >> 4th-generation languages (4GLs) which are usually interpreted. The Unix > > Read it carefully, I was taling about calling these things from the >command line, not the command line itself or using it as a person. IE, >programs should not have to call things by "pretending" to typing in CLI >commands. Why not? In the current MacOS, many programs send Apple events to the Finder to do some things. Why not use functionality that's debugged and optimized? If I need to copy a file from within my program, I'd sure like to be able to do it just by exec'ing cp. It's almost guaranteed to be better thought out than any copy algorithm I might come up with offhand (believe it or not, optimized file copying is not totally trivial!). I don't have to worry about handling all the possible pathological error conditions either, because cp will take care of that for me. I really don't see why you've got such a huge problem with having a UNIX environment present in Rhapsody. It doesn't really take up much space, it adds a large amount of functionality, it will attract developers with UNIX products, etc., etc. If it's effectively hidden from the user who doesn't want to ever see a bash prompt, then it's fine to have it there. -- +-----------------------------------------------------------+ |Tim Seufert, bwanga@cats.ucsc.edu | UselessWastedSpace(tm) | | "I never give them hell. I just tell the truth, and they | | think it is hell." -Harry S Truman | +-----------------------------------------------------------+
From: bchin@us.net (Bill Chin) Newsgroups: comp.sys.next.programmer Subject: Re: Doesn't anyone know about power management? Date: 20 Jan 1997 21:46:13 GMT Organization: US Net - MD,DC,VA ISP - info@us.net Message-ID: <5c0p35$hak@news.us.net> References: <5c078g$325i@news.doit.wisc.edu> giddings@menominee.chem.wisc.edu (Michael Giddings) wrote: >It seems surprising that *no one* else has even looked into this. Please, if >you have any insights or information about the way the mach kernel in 3.3 and >4.x deals with power management, I would appreciate the info. I would like >to try to write a driver to improve the performance, as well as providing >working suspend/resume, particularly for Toshiba Tecras. I'm not surprised no one has responded. Not many people run NS/OS on laptops, and those that do probably disable APM to get it to work right. half :-) and half :-( >I have downloaded the APM specs and for the most part understand how the bios >portion should work, it's just that the kernel has some built in routines >that aren't published which interface with the bios. I've looked at the APM specs also, and started to look into how Linux handles APM. However, since NeXT hides the APM support, one will have to hack the kernel to change this. Since it works reasonably well on the NEC Versa E I use, there hasn't been enough incentive to look further. :-) At least Apple/NeXT will have to correct some of this to make it work on Mac laptops. -- Bill Chin - bchin@us.net - NeXTmail/MIME welcomed
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 22:00:19 GMT Organization: The University of Calgary Message-ID: <5c0ptj$cvm@ds2.acs.ucalgary.ca> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> William Raphael Hix (raph@porter.as.utexas.edu) wrote: > In general, there are 2 extreme cases. > ... > Case #1, Unix utility A does everything (perhaps with a > freeware wrapper) and so is a replacement for Mac Software B. > ... What about people who are used to Software B and like it? > Case #2, the Unix utility A is a "poor" substitute for Mac application B. > In this case, what is the point of including this utility in the OS? > ... What about people who cannot justify the expense of application B? Fractal Design's Dabbler is a poor substitute for their full Painter package, and yet both are sold by the same company! Lastly, as you point out, these are both extreme cases and not representative of the general case. Generalizing from extremes does not tend to yield anything of value. For example, it would be pointless to try to educate a person who already knows everything, and equally pointless to try to educate a person who cannot learn anything. Does this prove that education is pointless? > Well, how important is Unix compatibility? It's clear from > this thread that to NeXT users it's essential. Only because a UNIX derrivative is the underlying operating system. If you get rid of it, you'll need to replace it with another real operating system. Any suggestions? Windows NT? Another UNIX? Or should Apple attempt to develop another operating system from the ground up while ignoring their dwindling share of the market? > But how much does this matter to the Mac community that Apple > is pitching Rhapsody to? Would they rather have the system > take up less space or have Unix compatibility 99% of them would > never use. Replace that with "never knowingly use" and the answer becomes obvious. 99% percent of the Mac users I know never invoke NewHandle directly, so why not remove it from the API to save disk space? > The feelings of NeXT users (none of whom have compatible > hardware) ... Try to avoid making this an Us vs. Them thing. It would be awfully nice to have a sense of community instead of a raging war. Of course some NeXT users do not have hardware compatible with the forthcoming Rhapsody. For that matter, a hell of a lot of Mac users will not have compatible hardware, either. > ... are secondary to the 10-100 times larger Mac community. The feelings of both are moot compared to the technical realities of hosting the OPENSTEP API or a derrivative thereof in a short time frame. There is every reason in the world to believe that the NeXT savvy are more likely to be in tune with these realities than the Mac savvy, no matter how much larger the latter group is. That being said, there sure are a lot of opinions being bandied about as solid technical facts. Time will tell just exactly where we're headed, and I'm eagerly awaiting the results. -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: Mon, 20 Jan 1997 17:15:54 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <4msyuOu00iV0M52s5o@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> In-Reply-To: <5c0heg$jud@csugrad.cs.vt.edu> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 CLI utils vs. objects (was .. by Nathan M. Urban@csugrad. > In practice, the way I think this would happen is Unix utilities being > rewritten one-by-one so that they depend on little libraries instead of > integrated code, and then making those libraries object-oriented. (It > might be better to put object wrappers around C libraries so that you > can still access their APIs from C or some non-OOP language if you > want.) During the long conversion process, there would still be no > problem with writing apps which call programs via object wrappers using > the system() call. > > Comments? Do other Unix hackers think this is the way Unix should > evolve? I believe it is unfeasible to write sensible API's for every conceivable Unix utility and to replace all of the expressive power of the shell. There are roughly 1200 executables in my path; about 100 or so are already available as functions via the BSD 4.3 system call API, which leaves over a thousand left. I have no objection to people writing a good OO API to encapsulate the functionality currently provided by popular tools like grep and find-- I think it's a good idea. But people seem to think that simply providing such an API means that the /bin/grep and /bin/find utilities aren't needed anymore, and that claim makes no sense, for reasons that I've explained in other articles. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 16:58:44 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E3EA94.142F@exnext.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <0mrz3kS00iVGI9e7EM@andrew.cmu.edu>, Charles W Swiger > <cs4w+@andrew.cmu.edu> wrote: > > Furthermore, there are a large number of Unix server applications which > > are based off of those utilities. > > And which ones would the average Mac user want? Remember, there's 25 > million Macs out there, and I'd be willing to bet that 90% of them could > care less. Notice how "overwhelming" POSIX support was wanted under NT > for instance. Considering that Apple can't survive by just pleasing current Mac users, this isn't a very good argument. Apple cannot gain marketshare by catering to the tastes of a rapidly shrinking user base. They have to start working on people who aren't Mac users. To do that, Apple has to figure out why they're not Mac users. For some significant population, this is going to be because they need Unix. Apple cannot afford to ignore this market. BTW, POSIX support has little to do with Unix utilities. It's more of a C API issue, IIRC. The idea was that if you write to the POSIX api, you can more easily recompile on another OS. IIRC, using POSIX features means you cannot use native features. You probably couldn't write a POSIX app on NT that used a Windows GUI, for instance. The lack of supporting Unix programs probably hurt it, too. -- Jonathan W. Hendry jon @ exnext . com
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: Mon, 20 Jan 1997 15:23:40 -0800 Organization: Modulation Message-ID: <32E3FE7C.404A@concentric.net> References: <maury-0801971641590001@199.166.204.230> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> <4msyuOu00iV0M52s5o@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 CLI utils vs. > objects (was .. by Nathan M. Urban@csugrad. > > In practice, the way I think this would happen is Unix utilities being > > rewritten one-by-one so that they depend on little libraries instead of > > integrated code, and then making those libraries object-oriented. (It > > might be better to put object wrappers around C libraries so that you > > can still access their APIs from C or some non-OOP language if you > > want.) During the long conversion process, there would still be no > > problem with writing apps which call programs via object wrappers using > > the system() call. > > > > Comments? Do other Unix hackers think this is the way Unix should > > evolve? > > I believe it is unfeasible to write sensible API's for every conceivable > Unix utility and to replace all of the expressive power of the shell. > There are roughly 1200 executables in my path; about 100 or so are > already available as functions via the BSD 4.3 system call API, which > leaves over a thousand left. > > I have no objection to people writing a good OO API to encapsulate the > functionality currently provided by popular tools like grep and find-- I > think it's a good idea. But people seem to think that simply providing > such an API means that the /bin/grep and /bin/find utilities aren't > needed anymore, and that claim makes no sense, for reasons that I've > explained in other articles. Some people apparently are advocating _replacing_ the CLI utilities with library APIs. But I am not one of them. I want both the CLI and its commands, AND the library utility functions. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 17:48:37 -0500 Organization: Atria Software Message-ID: <maury-2001971748370001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> In article <32E3D1EA.7F8F@exnext.com>, jon@exnext.com wrote: > Actually, Apple should let all those people who want Unix hang. No one here is advocating that, regardless of the labels you wish to brand us with. I have said all along that Apple should continue to develop Unix compatibility, perhaps even make it better, but that the VAST majority of Mac users won't use it, and that's going to be the VAST majority of the new OS's users. If you want the Unix command-line utilities, install them. If you don't, don't. Why has this possibility whipped the Unix people into such a frenzy? It's not the Arguments include... a) Unix utils make it easier to develop But not as easy as OOPS libs with the same functionality b) Unix utils make it easier to port the applications But only to other Unixen, to NT it certainly hurts c) Unix utils make it easier to administer Only because it depends on them no, it doesn't under NT d) It allows you do run all this great Unix software Which the VAST majority of it's users don't want anyway e) > Who > cares if they buy Solaris, or Windows NT, or run linux on a cheap > Pentium? Who needs em. That's a sophomoric argument and you know it. > Apple doesn't need new markets, right? Their current markets are doing > *just fine*. They're doing just fine on their own. Selling to them home > users, schools, and artists. No, but Unix's market share isn't exactly growing by leaps and bounds either, even with all the interest in the Internet saving it. > Oh, that's right. Apple's marketshare is dwindling. Apple's > traditional markets are moving to Windows. Schools, homes, graphics > professionals. Oh yeah, and NeXT's superior technology will help a lot here. Just look at how successful it was when they sold machines running it. As every Apple owner will tell you - technology doesn't create markets. > Evidently, Apple must not be selling what people want > anymore. But Apple DOES sell Unixen now, and no one's buying them either. This is not an argument for Unix. > I think Apple should spend some time to find out exactly what > users want. *Not* current Mac users. Former Mac users. Mac users > who have left the Mac for NT, Solaris, Linux, IRIX, whatever. Total Mac ownership continues to grow, that's not an issue. The issue is that the rest of the market grows faster. > Let's see. Apple has about 6% marketshare. If Apple can successfully > sell to the 1% of users who want Unix, that would give Apple 7% > marketshare. Uhhh, what? Win has 70% of the market, Apple 6% (in new sales) and the other 25% is divided up among all the rest. Even if that's all Unix, 1% of that is only .25% of the overall market. Maybe I'm missing something, but I'd like to see your explanation of this number. > If Apple can grab back the graphics professionals who are using > NT, they could probably add another .5%. If Apple can grab > webserver marketshare from WinNT, that might account for another > .5%. (This would likely be easier if Apple shipped Rhapsody > on Intel). That'd increase Mac marketshare by another 1%. And how do any of these revolve around having the Unix shell utils in their current form rather than an updated one? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 17:52:26 -0500 Organization: Atria Software Message-ID: <maury-2001971752260001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971144500001@199.166.204.230> <5bofh1$g3f@csugrad.cs.vt.edu> <maury-2001971506200001@199.166.204.230> <5c0nkk$r0l@csugrad.cs.vt.edu> In article <5c0nkk$r0l@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Of course. Direct calls are better as long as you still have a CLI you > can use. Agreed, so there should be lots and lots of shells for you to use. > I'm just saying that when you're doing a bunch of streams > processing, there isn't as much of a need to have a pure object library. But people aren't doing a lot of streams processing except in very specific areas. And even in these areas I don't think using an OOPS library is any worse, notably if it's got all the extras like published interfaces and such. > You can convert from objects to streams and back again without much > difficulty. Yeah, but WHY? > By "this" do you mean OOP wrappers around CLI programs? No, _replacing_ the code with OOP shared libs. > However, I don't think that even most OOP programmers have really > gotten into this "objectware" concept. Even under NEXTSTEP, you don't > see as many pure object libraries being distributed as you should; too > many things are still folded into applications. This needs to change. Hmmmm. Suggestions? In general, how common is it to be able to reach into application xxx under NeXT OS and play around with it's objects? Can you do this at all? Maury
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 18:35:16 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Qmt04oO00iV0M52u8d@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> In-Reply-To: <32E3158E.5785@concentric.net> Excerpts from netnews.comp.sys.next.advocacy: 19-Jan-97 Re: MacWorld Exclusive: App.. by Alan Lovejoy@concentric. >>> The same could be done in C without using the system() function. But it >>> would be ugly and awkward by comparison. However, the fault lies both >>> with C and with the standard C library. >> >> I disagree strongly. I do not believe the standard C library should >> have to implement every conceivable command that is available via a >> fork()/exec() or system() call. For gossakes, people, there is >> something to be said for a manageable API instead of throwing everything >> including the kitchen sink into the "standard system library". > > Two words: code reuse. Code reuse is a principle which states that it is usually easier and better to use preexisiting code rather than reinvent the wheel by re-writing functionality that is already available. I understand what code reuse means. Do you? Apparently not, because you are arguing that we should not reuse the preexisting code available in the form of the Unix utilities, and should instead write APIs and an implementation in the C system library for all of those utilities. That is the opposite of "code reuse"! > Now, whether such utility methods should be part of the **standard library** > for the C language is a different issue than whether they should be available > in some standard Unix library. I want them somewhere. If you want to make > an issue of which library they should be in, fine. I have other things I'd > rather worry about. I don't care which library they are in either. The point is, regardless of what it's called or whether it's just one or several libraries-- there is no point at all of creating tens of thousands of system calls to replace the Unix command line utilities unless that mammoth API is available on all of the hardware/operating system combinations that you're replacing the Unix CLI utilities, otherwise programmers won't be able to depend on all of the API being available, which would make it far less useful. Besides which, why don't you try to estimate the number of developer-years such a task would require? Then divide by the number of developers Apple has available-- do you think such a project would be released in this millenium? I don't. >> Furthermore, I don't believe that a programming API is always the best >> way of invoking complex behaviors when such behaviors are more easily >> defined and described using the CLI of a shell. >> >> For example, system("/bin/rm -rf /tmp/My_Programs_Temp_Dir/*.ckp") is >> easier to do than the way you would have to scan through directory >> entries and do wildcard expansion no matter what language you used. And >> this was only a trivial example-- I could give far more involved >> examples which involve shell functionality that is not trivial at all to >> duplicate in the form of a complete, robust, and bug-free API. > > Are you trying to say that C is not always the best language to use? I would agree with statement, yes-- in fact, I consider that to be an obvious concept. There is a wide range of problem domains, and there will never be one single computer language which is better than all other computer languages for every possible problem. [ ... ] >> "Could be"? Heck, you _could_ do the same in C or any other langauge if >> that MailTool API was standardly available for that language. > > Yes. > > But writing the MailTool class will be easier in Smalltalk or Objective-C > than it would be in C or C++. And using it in a Smalltalk IDE is just as > easy as using the CLI "mail" command. Okay, I'm willing to agree with that to an extent. However, your Smalltalk IDE is not going to be able to provide the flexibility behind the shell, such as emailing all files ending in '.gif' to somebody in the way that: system("tar cf - *.gif | mail .... ) ...would do. [ ... ] >> My point was that an API for the majority of external commands is not >> available. Nor would creating such API for every command be practical >> or even desirable. > > I agree is't not available. And until it is, the CLI is necessary. And > a CLI would still be a good idea after such a library was available, > because it's a programming language (and the typical GUI is not). I agree with this, too. > However, I think such a library of useful utility classes/methods is very > desirable. Sure it is. In fact, that's one of the reasons why OpenStep is pretty cool. > Code reuse: it's a good idea. Again, writing a new library which provides functionality already implemented by Unix command-line tools is the precise opposite of code reuse. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 17:38:22 -0500 Organization: Atria Software Message-ID: <maury-2001971738220001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> <maury-2001971507310001@199.166.204.230> <5c0lgn$r2b@csugrad.cs.vt.edu> In article <5c0lgn$r2b@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > No, not really. It would be pointless to port a Unix environment over > to NT; OpenStep doesn't need it. They only ported a few things. That's what I thought. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 17:57:24 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-2001971757240001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <bwanga-1901971904450001@metricom37.ucsc.edu> In article <bwanga-1901971904450001@metricom37.ucsc.edu>, bwanga@cats.ucsc.edu (Timothy A. Seufert) wrote: > Why not? In the current MacOS, many programs send Apple events to the > Finder to do some things. Why not use functionality that's debugged and > optimized? I said read it carefully, something it appears few are willing to do. AppleScript works on PUBLISHED interfaces over top of OBJECTS. As does any other OSA compatible scripting system, MacPERL for instance. This is exactly what I have been talking about all along this thread. How could you have missed this point? > If I need to copy a file from within my program, I'd sure like to be able > to do it just by exec'ing cp. It's almost guaranteed to be better thought > out than any copy algorithm I might come up with offhand Not YOU, the Unix that it came with. Really now, is this concept so hard to understand that I have to repeat it every single day for about two WEEKS now? Read it again: I am not asking for the removal of Unix I am not asking for the removal of utilities I _am_ asking for a system in which these utilities are in the forms of OOPS shared libs with published interfaces. Come now, that's not so bad is it? If it's not, how is it that you think that I'm possibly suggesting that you'd have to rewrite cp? > I don't have to > worry about handling all the possible pathological error conditions > either, because cp will take care of that for me. Ditto, but you get an object back instead of a string that looks different from everything that you call. > I really don't see why you've got such a huge problem with having a UNIX > environment present in Rhapsody. Sigh. I'm not, nor have I ever. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: Mon, 20 Jan 1997 18:01:14 -0500 Organization: Atria Software Message-ID: <maury-2001971801140001@199.166.204.230> References: <5aj8p3$rer@boursy.news.erols.com> <E3Fxyv.E3K@cam-ani.co.uk> <5amh2m$dao@nyheter.chalmers.se> <5bmpd8$9d7@spool.cs.wisc.edu> In article <5bmpd8$9d7@spool.cs.wisc.edu>, Dan Bongert <herkimer@cs.wisc.edu> wrote: > well, if *i'm* not mistaken, some of the early sun stations used > 68k processors, > just like NeXT did (when it was still in the hardware business). I ran a lab of them. Sun 3/50's, based around the 68030. SLOOOWWWWWW. Maury
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer Subject: Emacs for OpenStep Date: Tue, 21 Jan 1997 15:53:55 -0500 Organization: Demiurge Development Group Message-ID: <32E52CE3.1A0B@friday.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone successfully compiled Emacs for OpenStep-- the Emacs w/the full-blown NS UI? [It requires installation of the NS 3.3 developer tools under OS 4.1-- not something I have the resources to do]. BTW: I installed the package from next-ftp.peak.org, but it just gives a bus error upon launch. thanks, b.bum
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 00:09:11 GMT Organization: Netcom Distribution: world Message-ID: <5c11f7$3po@dfw-ixnews5.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-1701971144500001@199.166.204.230> <5bofh1$g3f@csugrad.cs.vt.edu> <maury-2001971506200001@199.166.204.230> <5c0nkk$r0l@csugrad.cs.vt.edu> <maury-2001971752260001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In general, how common is it to be able to reach into application xxx > under NeXT OS and play around with it's objects? Can you do this at all? Depends :-) If an app includes a single statement that registers one of its objects as a distributed objects server, then a client process can access that server object and any other objects accessible via the server object. Or if an app is designed to be extensible by dynamically loading code at run-time, then this distributed objects registration statement can be included in the loaded code thus making certain of the app's objects available to clients. We use this approach to drive OPENSTEP's InterfaceBuilder as a distributed objects server even though it was never designed to operate this way :-) -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 19:12:48 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mmt0c0i00iV0052yVd@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> In-Reply-To: <maury-2001971516170001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Because you need the shell and the utils in order for the operating >> system to boot in a flexible way that can be maintained by a system >> administrator. > > Great, so have a shell that calls the OOPS libs. > In fact, have lots of them. "Calls the OOPS libs" how? Are you talking about having the system boot using a precompiled executable? If so, remember that we already went through the reasoning why that's not as good as having the system boot be configurable via an interpreted shell. >> Furthermore, there are a large number of Unix server applications which >> are based off of those utilities. > > And which ones would the average Mac user want? Who cares whether the current average Mac user would want them or not, so long as the ability to run those applications has no negative implications to that Mac user besides $3 worth of disk space? Rhapsody has the potential to sell to a large number of markets that Apple has never been successful in before-- such as corporate MCCA, Internet/Intranet usage, the server market, web technology, the important areas of higher education (ie, graduate CS/IS/Math programs :-), and so forth. Basicly, Rhapsody will cover all of the areas where Unix is popular, and hopefully will also make inroads into the normal business environment which is currently dominated by Microsoft Windows. Assuming, of course, that Apple doesn't do anything _completely_ braindamaged-- which is the only description I have for the suggestion of ripping Unix out of Rhapsody. Don't you Mac advocates want Rhapsody to be used by people who are currently using other operating systems? Or would you rather have Apples' market share shrink even further? Just to satisfy the bigotry of Unix-haters? How stupid can you get? If prior experience hadn't taught me not to ask for the impossible, I would love to hear a rational explanation of why certain people would rather do _anything_ to not see, hear, or (gasp) use Unix-- including sacrificing performance, functionality, and the potential to claim small but very important areas of the computer market. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:50:41 -0800 Organization: Modulation Message-ID: <32E404D1.24FA@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <maury-2001971526200001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32E296A4.4261@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > MailTool > > sendMessage: 'This is the contents of the message.' > > withSubject: 'My Subject' > > to: '<cs4w@andrew.cmu.edu' > > One must assume the existence of an object storing much of this data > even in the Unix case. Thus the line would become something to the effect > of... > > myMessage.send; Your comment leaves me baffled. I fail to understand your point. Perhaps you could elaborate? -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 18:06:34 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E3FA7A.5DEA@exnext.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <maury-2001971527440001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <5bu93k$ka6@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca > (Blake Stone) wrote: > > Yes, it's true, if there were an API function or method for every > > conceivable purpose life would be very easy. There isn't. > > So wait, they all exist in the form of CLI utils, but it's impossible to > make them in API form. > > Is it just me? Where exactly do you intend to call the API from? -- Jonathan W. Hendry jon @ exnext . com
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:45:39 -0800 Organization: Modulation Message-ID: <32E403A3.788@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> <maury-2001971514370001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32DFF7DB.167B@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > This would make it more difficult to use C, FORTRAN, COBOL, BASIC, RPG, > > Assembly and other non-OO languages with the OS. > > You make that sounds like a bad thing. It's a bad thing if you want to attract customers who intend to use those languages, and don't want to change. Personally, I think those languages are seriosly sub-optimal in many ways and for many usages, but Apple can't afford to alienate potential customers. > But seriously, this strikes me as a problem for data-processing like > tasks only. The entire GUI is already OOPS lib based, and I don't see > anyone crying over that. Do you? OpenStep is a framework for writing GUI-based apps. If such frameworks exist for C, FORTRAN, COBOL, BASIC, RPG or Assembly (I don't think they do in all cases), then those frameworks are not compatible with OpenStep. And a COBOL shop would be interested in porting their existing apps over to Rhapsody, which would mean porting over their existing framework(s) for doing GUI apps (if they have such). And the original question wasn't the API for OpenStep, but rather the API to the kernel and the standard UNIX utilities. Those had better be accessible to COBOL and FORTRAN, or else a large and important base of potential customers will not use Rhapsody (I wish they'd change languages, but they won't). > Although I haven't even used ObjC on the NeXT platform yet, I > understand that many (all) of the above languages already exist. Are they > all limited to creating programs that run from the CLI only? If not, it > seems this isn't much of a problem after all. Don't know. I'm not all that familiar with NextStep/OpenStep per se. > > more difficult to use OO languages whose object models were not compatible > > with the one used to implement the kernel and libraries. > > Only in their current form. Apple's got more and more code being based > on SOM, which has no such limitation. Good. > > One could perhaps use CORBA/SOM/DSOM to address such issues. But CORBA exacts > > a noticeable performance penalty. > > Well I might be missing something here, but I always believed that if > your compiler talked SOM, there was no inherent overhead. I've heard differently. But I could be wrong. I'd be happy to wrong on this pont, actually. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 21 Jan 1997 00:26:04 GMT Organization: Indiana University, Bloomington Message-ID: <5c12es$3ej@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> NNTP-Posting-User: 1073745024 In article <5c0heg$jud@csugrad.cs.vt.edu>, Nathan M. Urban <nurban@vt.edu> wrote: >In article <5c04e3$gh9@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> In article <32E30DB4.7126@concentric.net>, >> Alan Lovejoy <alovejoy@concentric.net> wrote: > >> >Yes, the system() function is a necessity in today's world. > >> >I think the goal of Rhapsody (and all Unixes) should be to continuously >> >make it less so over time. Perhaps one day... > >> Why? > >Which is better? Accessing system services via distributed message >passing, and dynamically loading and unloading object bundles into a >running process's context? Or forking and exec'ing a shell to execute >a new process, with all its associated overhead, and communicating with >stream-based I/O that needs to be parsed into data structures? I like >the former approach a lot better. I couldn't care less. Unless there were some obvious benefits to show for it. But the message I've been getting from an admittedly lukewarm following of the thread is that the people who want to change this mostly want to change it for aesthetics, or "just because". Will it make a noticeable difference in performance or flexibility? >Not that I'm advocating ripping Unix utilities out, or even saying that >you shouldn't write apps which call utilities via a system() call. >(Unlike some other people on this group...) Far from it. I love Unix >and the Unix command line. I just think it would more elegant if most >of the Unix functionality were wrappered with objects. Then the >utilities could slowly be rewritten into object libraries, so that >instead of having programs with object wrappers, you have programs Oh, I'd have no problem with that. Just as long as I can keep my system() call, I don't care how it's implemented (as long as performance doesn't suffer). system() is the easiest way I've ever seen to pass messages to the shell. Compare that with, say, writing a MacOS program that passes messages via AppleScript. Does NeXT do it any better? >Comments? Do other Unix hackers think this is the way Unix should >evolve? The big problem is something that someone else has >mentioned.. The object models of different languages do not agree. >I'd love it if everything was based on Obj-C objects, but C++ has a >tough time with them. You can use things like CORBA, but it makes ugly One thing I'm reasonably certain of is system() and the shells won't change much in any way, shape, or form until there's a universal and backwards-compatible way to pass objects around. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: tbutler@tfs.net (Travis Butler) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 18:10:14 -0600 Organization: The Wandering Powerbook... Message-ID: <AF09658696681B35E3@travis.tfs.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> In article <32DEDEC1.490C@exnext.com>, "Jonathan W. Hendry" <jon@exnext.com> wrote: <Snipped part about how taking out the standard (but IMHO obtuse) Unix OS directory structure would cause problems for porting standard Unix utilities> >If Apple wants the new OS to be a useful Unix platform >(and they should) Here is the main point where you and I part company. I don't *want* the new OS to be a 'useful Unix platform' if it comes at the expense of the Mac's ease of use. I didn't buy a Unix box; I bought a Mac. If I'd wanted to buy a Unix box, I could have plunked down less cash than I spent on my Mac and bought a cheap Intel box running linux/X. I bought a Mac because I *wanted* a Mac, not a Unix box. The *reason* I want a Mac is so that I wouldn't have to deal with the hassles of a CLI-based OS like Unix or DOS/Windows. So I wouldn't *have* to deal with /bin, /usr and /etc, commands like "ls", "mv", "chmod," and suchlike. I hate to put words in other people's mouths, but I imagine that's the same reason a lot of the Mac users in this debate bought Macs. If you could make Unix functionality a part of the new OS without *forcing* users to deal with these things, so they wouldn't need to see or use them unless they really *wanted* to, then I wouldn't mind. But what I saw of NeXTstep a few years ago didn't work that way, and the comments I've seen here suggest that it hasn't changed in this respect. >then Unix power-users need to be able >to type "make install" and have, say, Apache build and install >properly, with a minimum of tweaking. Great, for Unix power-users. But I ask: how many Unix power-users are there in relation to the Mac user base? In a thread a while back, a linux proponent clamed hundreds of thousands of linux users as an argument for Unix as a broad-based OS. My reply was, hundreds of thousands compared to how many millions upon millions of Windows users on the same hardware platform? In other words, linux makes up what percentage of the OS base on the Intel platform? 5%? Less? In fact, taking the personal computer market as a whole, Unix and variants make up what percentage of the user base? Sorry, I'm starting to ramble here. My point is: Should you complicate or burden the user experience of 95% of the user base to benefit the 5% that actually make use of the Unix power features? I think that's a mighty poor tradeoff for a general-purpose OS. >They should not have to >wade through makefiles and install scripts to fix Apple's bungled >filesystem. Let me turn the question around: Should Joe Average User have to wade through Unix arcanum just to use the computer, when he doesn't know or care what 1/4 of the things mean, let alone how to use them -- just so that the small percentage of Unix gurus can easily run install scripts? I'll say it again... the vast majority of Rhapsody users will be *current Mac users*, NOT Unix users. The OS needs to be biased towards *those* users -- who bought Macs because they are simpler and easier to use, and didn't want to learn computer arcanum. I also take issue with calling it "Apple's bungled filesystem." I agree the technical underpinnings of HFS need to be reworked, to get rid of glitches like the allocation block size hassle on large volumes. And the System Folder could use some tweaking -- the Extensions folder is getting overcrowded with a bunch of vaguely-related files, and needs to get a cleanup in the same way that System 7's folder structure cleaned up the cluttered System Folder of System 6. But with that minor caveat, I think that FROM THE USER'S STANDPOINT, the current MacOS directory structure is both more flexible and more user-friendly: All OS-related items are kept in a single folder, with clearly labeled and reasonably meaningful subfolders, and the user can arrange the rest of the disk -- applications, documents, and all -- pretty much as he pleases. >If they need to do this, they'll use Solaris, Linux, >or something else, and Apple will lose sales that they cannot >afford to lose. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ I'd like to know your reasoning here. Your philosophy -- keeping arcane directory names and hierarchies that are cryptic and non-intuitive for most users, for the convenience of 'Unix power-users' -- is IMHO just about diametrically opposed to the philosophy that drove the creation of the Mac, and the user philosophy underlying almost everything Apple has done with the Mac since: The user should be able to use the computer to just get things done, with a *minimum* of computer arcanum. Even if your philosophy would pull in high-end technical people who favor Unix, that's still a tiny percentage of the market -- and if it alienates Apple's original (and much larger) market in the process, that's a recipe for sending Apple down the tubes. Remember, a common complaint from Mac users has been that the system is getting *too* complex -- not that it's not complex enough. Travis Butler (The Professor, formerly of Myth and Magick!, Lawrence, KS; tbutler@tfs.net, now from the Wandering Powerbook; <http://www.tfs.net/personal/tbutler/>; Mac page <http://www.tfs.net/business/tbutler/>) ...Cats are the proof of a higher purpose to the universe.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 19:35:30 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <8mt0xGe00iV0I52lR_@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> In-Reply-To: <maury-2001971519140001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> The only reason I can see for that is you have a vendetta against Unix and >> oppose compatibility on general principles. It sure doesn't seem >> to be for functional reasons. > > That's right, it's all illogical. And the sky is indeed green on my > planet. Happy now? No, not really. I was assuming that I had been debating someone who had a sensible rationale behind their arguments. If you were being sarcastic (I'll admit to not being sure, since your arguments to date don't make a whole lot of sense, IMHO): could you stop congratulating yourself over this latest witty remark long enough to provide the logical rationale behind your argument? -Chuck PS: And I thought the NeXT newsgroups had some strange people! Are all Mac advocates like this? How do normal Mac users put up with it? Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: Event handling during tight loop Date: 20 Jan 97 18:08:10 GMT Organization: University of Massachusetts, Amherst Message-ID: <32e3b48a.0@192.33.12.30> Hey, I've got a tight loop in a program, and I'd like for it to be interuptable by hitting a button. Without using threads, can somebody help me with this procedure? Do I use [NXApp getNextEvent], and then find an NX_MOUSEDOWN and manually check the coordinates to see if they hit the button? -- -jon klein jklein@freon.artificial.com Caper will do it for me.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 19:46:14 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <gmt17KG00iV0A52nk5@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> In-Reply-To: <maury-2001971530280001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Really, there's no point in ripping out Unix. > > Yes there _is_: > > a) easier on the programmers Removing functionality cannot _possibly_ make programming easier. You can always decide to not use some API if you don't want to, but not having an API available at all means that you will have to do more work if/when you needed that functionality. > b) more cross platform I'd question whether this is true, too. You can find versions of 'grep' for almost every computer system available today. Ditto for most other popular Unix tools: tar, diff, sh, etc, etc. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 00:38:00 GMT Organization: Cygnus Support Message-ID: <5c1358$k5v$1@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> Cc: maury@softarc.com In <maury-2001971530280001@199.166.204.230> Maury Markowitz wrote: > In article <5bumdc$evr@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > Really, there's no point in ripping out Unix. > > Yes there _is_: > > a) easier on the programmers > b) more cross platform Not really. If you're developing GUI apps, you can already completely ignore the Unix API and tools. Openstep offers enough OS abstraction that you should be able to do any GUI app without touching Unix _if_you_want_to_. And that should be completely cross platform. So, it's no more easier on the programmers nor more cross platform supporting to rip out the Unix tools/layer. Compared to everything else in Openstep/Mach, the unix things like /bin, etc, are rather small. Ripping them out wont get you much in the way of disk space nor anything else, and it will only cost you in functionality and flexability. Now, if you as a programmer WANT to use the Unix tools, why shouldn't you be allowed to? (just like "if you as a user WANT to use the unix CLI and tools, why shouldn't you be allowed to?") It is dubious at best to assert that someone should be FORCED to write to any API, or limited to any set of user tools, solely for religious reasons (even if the chosen tools are better.. users and programmers have the right to choose). -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 20:04:25 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Emt1MN_00iV0052vBl@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> In-Reply-To: <maury-2001971522480001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> (Win-like???? Are we talking about the same Windows? You know, that >> operating system that likes to dump files everywhere on your drive? >> Windows does NOT have a mandatory Applications folder or anything like >> that.) > > How can you possibly say that after blasting me over not wanting /bin on > my drive! Because the two issues are unrelated? [ ... ] >> I don't understand why you want to scatter your applications all over >> the filesystem. > > Because it's MY file system. You don't have to like it, do what you wish. Well, if you want to scatter your applications around even though it makes your computer less functional and harder for other people to use, you can. I don't see why anyone would want to make their computer harder to use, but then, that's just my preference for thinking rationally showing through.... >> I don't know anyone who does this. Even the Mac >> people tend to put everything in the Applications folder or a >> subdirectory of it. > > Balogna, I can't think of a single Mac I've every had the pleasure of > using that had all of it's programs arranged such, and that's a large > number of Macs (in the hundreds). That's just _wrong_. No, it's not, although I am unsurprised to discover that a Mac advocate has not had exposure to large computer networks administered by an organization. For example, CMU has hundreds of Macs in the clusters with a very consistent filesystem layout. Most Mac users here like the idea, so they generally arrange their computers in similar ways to the cluster machines-- and there are well over 1000 Macs on campus here. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 20:15:43 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Distribution: world Message-ID: <0mt1Wzm00iV0E52z4v@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <bwanga-1901971904450001@metricom37.ucsc.edu> <maury-2001971757240001@199.166.204.230> In-Reply-To: <maury-2001971757240001@199.166.204.230> Excerpts from netnews.comp.sys.next.programmer: 20-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. > I am not asking for the removal of Unix > I am not asking for the removal of utilities > I _am_ asking for a system in which these utilities are in the forms of > OOPS shared libs with published interfaces. At the risk of repeating myself: Why don't you try to estimate the number of developer-years writing OOPS shared libraries to replace the thousand-odd Unix utilities would take? Then divide by the number of developers Apple has available-- do you think such a project would be released in this millenium? I don't. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 17:49:58 -0800 Organization: Modulation Message-ID: <32E420C6.17B7@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 19-Jan-97 Re: MacWorld > Exclusive: App.. by Alan Lovejoy@concentric. > >>> The same could be done in C without using the system() function. But it > >>> would be ugly and awkward by comparison. However, the fault lies both > >>> with C and with the standard C library. > >> > >> I disagree strongly. I do not believe the standard C library should > >> have to implement every conceivable command that is available via a > >> fork()/exec() or system() call. For gossakes, people, there is > >> something to be said for a manageable API instead of throwing everything > >> including the kitchen sink into the "standard system library". > > > > Two words: code reuse. > > Code reuse is a principle which states that it is usually easier and > better to use preexisiting code rather than reinvent the wheel by > re-writing functionality that is already available. > > I understand what code reuse means. Do you? > > Apparently not, because you are arguing that we should not reuse the > preexisting code available in the form of the Unix utilities, and should > instead write APIs and an implementation in the C system library for all > of those utilities. That is the opposite of "code reuse"! Ahem. Now whose being offensive? Here's the most offensive part: you're wrongly attributing to me a position I have never stated, and in fact disagree with: namely, that the CLI utility commands should not be used, or should be eliminated. If the code in the UNIX shell commands were refactored and abstracted into utility functions with a standard API, the universe of reusable code would be increased. (And of course, the original shell commands would still be available with the same functionality and external interfaces). I hope this is clear, and does not need any further proof. > > Now, whether such utility methods should be part of the **standard library** > > for the C language is a different issue than whether they should be available > > in some standard Unix library. I want them somewhere. If you want to make > > an issue of which library they should be in, fine. I have other things I'd > > rather worry about. > > I don't care which library they are in either. > > The point is, regardless of what it's called or whether it's just one or > several libraries-- there is no point at all of creating tens of > thousands of system calls to replace the Unix command line utilities > unless that mammoth API is available on all of the hardware/operating > system combinations that you're replacing the Unix CLI utilities, > otherwise programmers won't be able to depend on all of the API being > available, which would make it far less useful. So no OS should ever provide a library that has any function not also available on any other OS? Or just not available on any other Unix? And a technical point: a function in a library is not a system call. It's only a system call if the function actually runs as part of the kernel, in the kernel address space, with kernel permissions. And finally, I'm advocating that ALL Unixes should have this new library of functions based on the CLI utilities. If a program uses one of these functions, it becomes Unix dependent. The same is true if the program uses system() to invoke a Unix shell command. In both cases, the problem can be fixed by porting the function/command to the non-Unix OS. If you want to write an OS-independent program, you don't make OS-specific calls. So what else is new? > Besides which, why don't you try to estimate the number of > developer-years such a task would require? Then divide by the number of > developers Apple has available-- do you think such a project would be > released in this millenium? I don't. Again, you are attributing to me a position I have not stated and disagree with. I said this was an ideal goal, that should be pursued as time permits. I fully agree that Apple cannot afford to do this now, and probably should not attempt to do it alone without the help and support of the Unix community as a whole. > >> Furthermore, I don't believe that a programming API is always the best > >> way of invoking complex behaviors when such behaviors are more easily > >> defined and described using the CLI of a shell. > >> > >> For example, system("/bin/rm -rf /tmp/My_Programs_Temp_Dir/*.ckp") is > >> easier to do than the way you would have to scan through directory > >> entries and do wildcard expansion no matter what language you used. And > >> this was only a trivial example-- I could give far more involved > >> examples which involve shell functionality that is not trivial at all to > >> duplicate in the form of a complete, robust, and bug-free API. > > > > Are you trying to say that C is not always the best language to use? > > I would agree with statement, yes-- in fact, I consider that to be an > obvious concept. There is a wide range of problem domains, and there > will never be one single computer language which is better than all > other computer languages for every possible problem. Agreed. > [ ... ] > >> "Could be"? Heck, you _could_ do the same in C or any other langauge if > >> that MailTool API was standardly available for that language. > > > > Yes. > > > > But writing the MailTool class will be easier in Smalltalk or Objective-C > > than it would be in C or C++. And using it in a Smalltalk IDE is just as > > easy as using the CLI "mail" command. > > Okay, I'm willing to agree with that to an extent. However, your > Smalltalk IDE is not going to be able to provide the flexibility behind > the shell, such as emailing all files ending in '.gif' to somebody in > the way that: > > system("tar cf - *.gif | mail .... ) > > ...would do. Well, Smalltalk does have the equivalent of the C system() function. And one could implement some classes and methods that could do the above almost as concisely--including the equivalent of the piping of the output of tar to the input of mail. But I'm not advocating the elimination of the shell or of the system() function, so there's nothing to argue about that I see. > [ ... ] > >> My point was that an API for the majority of external commands is not > >> available. Nor would creating such API for every command be practical > >> or even desirable. > > > > I agree is't not available. And until it is, the CLI is necessary. And > > a CLI would still be a good idea after such a library was available, > > because it's a programming language (and the typical GUI is not). > > I agree with this, too. > > > However, I think such a library of useful utility classes/methods is very > > desirable. > > Sure it is. In fact, that's one of the reasons why OpenStep is pretty cool. > > > Code reuse: it's a good idea. > > Again, writing a new library which provides functionality already > implemented by Unix command-line tools is the precise opposite of code > reuse. I'm not suggesting rewriting the shell commands from scratch. I'm suggesting taking the existing code and a) for every command, there should be an equivalent library function (this is relatively easy), and b) **some** of the C functions that are currently private to the various shell commands should be exposed for reuse by the other commands, and by application programs. This not only **reuses** the existing code, but makes it more reusable. In doing the above, one would probably want to change some of the abstracted function so that they would be more generic (less specific to the context in which they were originally written). One may also discover that various commands "reinvent the wheel." Such could be modified to call on shared utility functions, resulting in yet more reuse. How is this bad? (Other than it takes time. I say it's an ideal goal. Paying for it is another issue. Apple can't afford this for now). -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 01:33:51 GMT Organization: Indiana University, Bloomington Message-ID: <5c16dv$586@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> NNTP-Posting-User: 1073745024 In article <maury-2001971530280001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5bumdc$evr@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> Really, there's no point in ripping out Unix. > > Yes there _is_: > >a) easier on the programmers >b) more cross platform I don't understand this. How could it be more cross-platform by removing compatibility with one of two major platforms outside the MacOS? As for easier on the programmers, I think Be has the right idea. It's POSIX-compliant (or nearly so) for compatibility reasons, but once developers start programming the Be way, they don't want to keep using the POSIX way. Unix compatibility has nothing to do with making it easy to program. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Date: 21 Jan 1997 01:53:43 GMT Organization: The University of Calgary Message-ID: <5c17j7$1e44@ds2.acs.ucalgary.ca> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <maury-2001971527440001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: > MAPI... MAPI... MAPI.... Everybody agrees that a standard mail API would be nice. The point is not that it wouldn't be useful the point is that THERE ISN'T ONE. MAPI is a Win32 specific API, and a poorly thought out one at that. Yes, I've written for it. I'd rather spawn a shell task to send mail than write MAPI code again. > So wait, they all exist in the form of CLI utils, but it's > impossible to make them in API form. Has anyone said it's impossible? The key points are: * They all EXIST in the form of CLI utilities * It would be POSSIBLE to write them in API form Apple has 6 months to get a developer's release out. In that time do you honestly believe they're going to design, write, test, and document an API to replace all of UNIX's command line functionality? If so, you're sorely mistaken. If so and you're in a position to make decisions about software project planning, you're actively dangerous. I would love to see a brilliant OO API for every conceivable need, but I'm not holding my breath waiting for it to happen. -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: antispam@apple.com (Cary Farrier (farrier@apple.com)) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: Mon, 20 Jan 1997 19:55:55 -0800 Organization: Apple Computer, Inc. Message-ID: <antispam-2001971955550001@farrca.apple.com> References: <5btm97$i2m@castor.cca.rockwell.com> <AF08223B-1FFD9@198.68.42.204> <5bv009$r6r@news.xmission.com> In article <5bv009$r6r@news.xmission.com>, don@globalobjects.com wrote: > As a game developer, the possibilities are exciting, and I hope this > isn't all just wishful thinking. I've been wrong before, but I > really, really hope this is one of the times I'm right. :-) We will be bringing the Apple Game Sprockets to Rhapsody. In creating the Sprockets originally we listened to developers and they told us what they would like to have in a Game SDK from us, and that is what they got. I see no reason for us to do otherwise this time around. Right now we're doing investigations into what is going to be required to bring the Sprockets to Rhapsody. If anyone would like to share their opinions with us, we'd be happy to hear it. Currently we have the following Sprockets: DrawSprocket: a full-screen graphics API. Supports multiple buffering, page flipping, blitters, direct-to-screen access, resolution & color depth changing, etc. GoggleSprocket: works together with DrawSprocket to provide device-independent stereoscopic imaging. Currently supported devices are StereoGraphics SimulEyes (LCD Glasses), Virtual i/O iGlasses (a head-mounted display), Sanyo 3DLCD (way cool, 3D with no special glasses), and anaglyph (red/blue comic book glasses). InputSprocket: device-independent input from joysticks, foot pedals, flight-sticks, etc. NetSprocket: an easy interface for creating networked games. Hides protocol details and allows players on different protocols to be in the same game. SoundSprocket: 3D sound. "Positions" a sound in 3-space around the listener. Has special effects such as doppler shift. I imagine that we will be bringing most, if not all, to Rhapsody in some form. The official Apple games website is at <http://devworld.apple.com/dev/games>. The unofficial site that we (the Sprocket engineers) operate is at <http://www.unsupported.com>. There is a mailing list called mac-games-dev that you can join if you are interested in the current discussions happening among Mac games developers. On unsupported.com there is a link to the sign-up page (a web form) for the mailing list. -> Cary -- ---------------------------------------------------------------------- Cary Farrier, aka Mr. Draw Sprocket Software Engineer, Apple Game Technology Group farrier@apple.com Visit the Apple Games Website at <http://dev.info.apple.com/games>
From: antispam@apple.com (Cary Farrier (farrier@apple.com)) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: Mon, 20 Jan 1997 19:35:19 -0800 Organization: Apple Computer, Inc. Message-ID: <antispam-2001971935190001@farrca.apple.com> References: <5bq73r$e18$1@solaris.cc.vt.edu> In article <5bq73r$e18$1@solaris.cc.vt.edu>, dlehn@vt.edu wrote: > Is Apple going to push Sprockets for Rhapsody? Yep. We're looking into the technical aspects right now. -> Cary -- ---------------------------------------------------------------------- Cary Farrier, aka Mr. Draw Sprocket Software Engineer, Apple Game Technology Group farrier@apple.com Visit the Apple Games Website at <http://dev.info.apple.com/games>
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:15:49 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1cd5$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > > nurban@vt.edu wrote: > > Really, there's no point in ripping out Unix. > > Yes there _is_: > > a) easier on the programmers > b) more cross platform Wow. Those are exactly the reasons to *not* rip it out. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:31:31 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1daj$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <32E3D1EA.7F8F@exnext.com>, jon@exnext.com wrote: > > > Actually, Apple should let all those people who want Unix hang. > > No one here is advocating that, regardless of the labels you > wish to brand us with. I have said all along that Apple should > continue to develop Unix compatibility, perhaps even make it > better, but that the VAST majority of Mac users won't use it, > and that's going to be the VAST majority of the new OS's users. > > If you want the Unix command-line utilities, install them. > If you don't, don't. Why has this possibility whipped the Unix > people into such a frenzy? Apparently you think that everyone who does not agree with you is "whipped into a frenzy". Given the number of articles you've posted on this topic, you're more in a frenzy than anyone else. In any case, there are some (but not all) of those unix utilites which are used during system bootup, or system shutdown, or other system functions which *all* users will expect to have. I suppose they could separate out the ones they really *need*, and have an optional installation package for the rest. To me this seems like a lot of work, but maybe it isn't too bad. If they want to do this, it won't bother me much -- assuming the system still boots up of course. One thing that might help is to point out that some of this separate already exists, There are a lot of unix utilities which are in the developer package, and not the "NeXTSTEP user" package. So, maybe the current NeXTSTEP situation isn't quite as bad as you think it is, because some of the stuff is already separated into optional packages. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: Tue, 21 Jan 1997 00:08:47 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E44F5F.6C31@exnext.com> References: <5btm97$i2m@castor.cca.rockwell.com> <AF08223B-1FFD9@198.68.42.204> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lawson English wrote: > > Erik M. Buck > > <embuck@palmer.cca.rockwell.com> said: > > >A direct to screen API does exist for NeXTstep but it is not portable for > >obvious reasons to other OpenStep/Hardware combinations. > > > > That is very strange. The Mac has always allowed direct-drawing to the > video buffer via an API that is consistent with all video hardware that > works on the Mac, regardless of who makes it. "Regardless of who makes it"??? Pfft. As if the differences between Apple Macs and PowerComputing Macs are even remotely as large as the differences between NeXT's, Intel boxes with arbitrary video cards, HP workstations, and Sparcs. Not friggin' likely. Or are you talking about monitors? -- Jonathan W. Hendry jon @ exnext . com
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.misc Subject: Re: GX versus DPS (a Trivial example) Date: 13 Jan 1997 18:16:05 -0700 Organization: Primenet Services for the Internet Message-ID: <AF002F9A-37DE@198.68.42.216> References: <jcr.852636452@idiom.com> nntp://news.primenet.com/comp.sys.mac.programmer.misc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="Cyberdog-AltBoundary-000510B3" Content-Transfer-Encoding: 7bit --Cyberdog-AltBoundary-000510B3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [I've added comp.sys.mac.programmer.misc to the discussion] John C. Randolph <jcr@idiom.com> said: >mmunz@inconnect.com (Mark Munz) writes: > >>In article <jcr.852594456@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: > >>[ lots of source code of GX & DPS- snip] [code for generic GX curve shape drawing app found online at Apple's GX site] > >>First, if it's Apple source code, there's no telling how verbose it really >>is (Apple has yet to provide a nice, clean, tight piece of sample code >>ever). > >Good point. I remember the examples in Inside Macintosh from my system >6.x days. > All of the lines are useful. They do a LOT of work for you. And save an AWFUL lot of work later on... >>Second, it appears that the GXShape can be retained and used later, but >>the DPS object is hard-coded MoveTo, LineTo. This appears to be a more >>object oriented approach for GX. A more accurate comparison would be to >>create an object in DPS that you could keep around and that could draw >>itself at different rotations and such. > >Actually, if I were following the usual practice in NEXTSTEP coding, I'd have >defined a Shape class, which had orientation, color, etc. attributes, >which any View could use. (Note to non-NeXT programmers: a View in >NeXTSTEP >is an object which renders part of the contents of a window, and receives >the events that occur within that part. Views have a clipping boundary, >they have a postscript drawing context, they can draw themselves to the >screen, or to the printing machinery.) > Note to non-GX programmers: GX shape objects are objects found in the GX shape object database and referenced by the shape "pointer" returned by a GXNewShape call or moral equivalent. GX shapes contain references to 9 GX objects: type, geometry, fill, style, ink, transform, attributes, owner count, tag list. These are stored in an optimized database referenced via the GX "pointer." The transform object contains one or more references to view objects which the object is drawn into during a "DrawShape(myShape)" call. The transform object can be applied to the geometric points describing the geometry of the shape OR be used as a generic transform to translate/rotate/etc. shape without changing the internal description of the shape (allows for a poor man's undo to be implemented merely by resetting transform matrix to the 'identity' transform). Each view object has its OWN transform matrix to be applied after the shape object's transform is applied. View objects can be off-screen bitmaps, the Mac desktop, windows, or any portion of the preceding. View objects can be nested within other view objects, and each transform object for each view is applied in an inside-out manner until the final view's transform is applied, followed by the view device object's transform, which applies any device-specific modifications needed to render the view. >Incidentally, I coud have created a userpath in the DPS server, if I >wanted it to stick around. userpaths take advantage of the font-caching >system, and they're very fast. > GX shapes not only "cache" the information mentioned above, but also any calculations that are performed when drawing/pre-drawing the shape. Bit-map caching is allowed and is only part of the info stored and the GX database could be ( and no doubt has been) designed to optimally cache shape-type-specific info. There are 8 pre-defined graphical shapes: points, lines, rectangles, polygons, curves, paths, and pictures, as well as 3 text shapes: text, glyph and layout. No other types need be defined, IMHO, since a picture is a list of shapes, including other pictures. I can guarantee that GX shapes are going to be drawn as fast, if not faster, than DPS user paths due to the optimized-database nature of GX as opposed to the interpreted nature of DPS. Even if DPS contained a CPU-specific compiler that compiled the user path into a native-code code-snippet, the strategy used by GX would allow for hand-tuned optimizations for each shape-type, whereas the DPS way would not. >>Third, it also looks like the printing code is generic enough to cover all >>the GX printing - it's quite possible to have a library call that you'd >>pass a GXPicture to and that's that. > Exactly. Also consider what you are getting when you pass a "page" reference to the GX printing calls: Each GX print job includes: page count -number of pages to print. format list -list of page formats, 1 to a page. Shape list -list of pages, each of which is actually a GX picture shape. Remember that a picture shape is a list of one or more GX shapes, including other GX pictures. When GX printing starts, a user/application is allowed to select/preselect one or more print extensions. Print extensions can walk the shape list of the print job and apply GX calls to any/all GX shapes found in any/all pages (among hundres of other capabilities). For instance, you can have a printer extension that would grab every GX shape of type gxCurve on every other page and replace the curve with the Korean equivalent of "Your text goes here" along the path of the curve, color it using R =3D 25, G =3D 200, B =3D 150, and rotate the resulting curved-text by 30 degrees, skew it and apply a user-selected 3D perspective to it, before passing the print job on to the next printing extension. >>Fourth, the lines of source code is valid for some things, but the >>question is - how much native code is generated by the DPS lines. And how >>fast is each one. That's what is really important. > >I will also mention, that the example I wrote previously is using the >single-operator PS library calls, which is not the most efficient way >to do this. I could also have written my rendering code in PS, and >run it through pswrap to generate a binary object sequence. > I'll mention that the GX example app is using the optimized GX database calls and is already in code native to the CPU. Can't get any faster than that, IMHO, without writing your own custom drawing routines using a native compiler/assembler. >>Fifth, I believe one of the advantages of GX (from what I've been told) is >>that it is extensible and that DPS requires a change in the definition of >>DPS language (with a backward compatible interpreter for odl stuff) for >>additions to it. > >PS is a threaded intrepeted language. What could possibly be more >extensible? > >If I write: > >/rectpath > { > /x exch def > /y exch def > /w exch def > /h exch def > newpath > x y moveto > w 0 rlineto > 0 h rlineto > w neg 0 rlineto > closepath > } bind def > >Then rectpath works just like it had always been there. > If you want to add to or extract data from rectpath from within an Obj-C call, do you have to define your own data handlers or is generic methods that works for any path? WIth GX, if you want to extract/reset the geometry of a GXPath shape, you can do so using one of the GXSetXX/GXGetXX methods. E.G.: GXGetPaths( aShape, aPathDataPtr); or GXSet Paths( aShape, aPathDataPtr); You can also edit the data in-place using various calls. You can also convert a shape type from one type to the other: E.G., a layout shapes takes specific font and language info and a text-string and converts it into an auto-kerned, auto-ligatured, etc., text-string of the appropriate language using information found in the GX font. If you want to hand-tune these features, say by applying your own kerning, you can. If you convert the layout shape to a glyph shape, the default info specified in the GX font is used to provide you with a shape whose individual glyphs can be transformed, for things like applying the glyph shape to a path. Since a glyph shape is a standard GX shape object, any/all attributes can be modified to affect the shape-as-a-whole, allowing you to apply rotations/skews/perspectives/co= lors/transforms/composit-modes to the entire text after you've made it follow the arbitrary curve. Remember that this info is *ALWAYS* (memory allowing) stored in shape-optimized form within the GX database for optimized redrawing -and that it includes a lot more than just bitmaps and DPS-type cache info. This is a database optimized SPECIFICALLY for these kinds of records, remember? >In fact, I know of research projects where people used postscript to add >functionality to servers and device drivers, that had nothing to do with >graphics. It is a turing-complete programming language. You can write >a LISP interpreter in it if you like! > Cool. You can embed any information that you want in a user-defined tag within a GX shape object. You can specify that PostScript commands be used instead of the generic GX layout commands for rendering a specific shape. If you wanted, you could create a driver that would preprocess the tag-info to implement any old thing you wanted to, within the domain of the capabiltiies of GX drivers talking to PS drivers/non-PS printers, including passing along the PS LISP interpreter code as found in a GX shape user-tag. >-jcr > >>There are lots of things wrong with GX, but there are lots of things right >>with it.. > >>Just my two cents. > >>Mark Munz > There's nothing really wrong with GX save that Apple never supported it properly. MY two cents... -----------------------------------------------------------------------= -- Windows: Tumor-causing, teeth-staining, smelly, puking habit. -----------------------------------------------------------------------= -- --Cyberdog-AltBoundary-000510B3 Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-000510B4" Content-Transfer-Encoding: 7bit --Cyberdog-MixedBoundary-000510B4 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>[I've added comp.sys.mac.programmer.misc to the discussion] John C. Randolph <<jcr@idiom.com> said: >mmunz@inconnect.com (Mark Munz) writes: > >>In article <<jcr.852594456@idiom.com>, jcr@idiom.com (John C. Randolph) wrote: > >>[ lots of source code of GX & DPS- snip] [code for generic GX curve shape drawing app found online at Apple's GX site] > >>First, if it's Apple source code, there's no telling how verbose it really >>is (Apple has yet to provide a nice, clean, tight piece of sample code >>ever). > >Good point. I remember the examples in Inside Macintosh from my system >6.x days. > All of the lines are useful. They do a LOT of work for you. And save an AWFUL lot of work later on... >>Second, it appears that the GXShape can be retained and used later, but >>the DPS object is hard-coded MoveTo, LineTo. This appears to be a more >>object oriented approach for GX. A more accurate comparison would be to >>create an object in DPS that you could keep around and that could draw >>itself at different rotations and such. > >Actually, if I were following the usual practice in NEXTSTEP coding, I'd have >defined a Shape class, which had orientation, color, etc. attributes, >which any View could use. (Note to non-NeXT programmers: a View in >NeXTSTEP >is an object which renders part of the contents of a window, and receives >the events that occur within that part. Views have a clipping boundary, >they have a postscript drawing context, they can draw themselves to the >screen, or to the printing machinery.) > Note to non-GX programmers: GX shape objects are objects found in the GX shape object database and referenced by the shape "pointer" returned by a GXNewShape call or moral equivalent. GX shapes contain references to 9 GX objects: type, geometry, fill, style, ink, transform, attributes, owner count, tag list. These are stored in an optimized database referenced via the GX "pointer." The transform object contains one or more references to view objects which the object is drawn into during a "DrawShape(myShape)" call. The transform object can be applied to the geometric points describing the geometry of the shape OR be used as a generic transform to translate/rotate/etc. shape without changing the internal description of the shape (allows for a poor man's undo to be implemented merely by resetting transform matrix to the 'identity' transform). Each view object has its OWN transform matrix to be applied after the shape object's transform is applied. View objects can be off-screen bitmaps, the Mac desktop, windows, or any portion of the preceding. View objects can be nested within other view objects, and each transform object for each view is applied in an inside-out manner until the final view's transform is applied, followed by the view device object's transform, which applies any device-specific modifications needed to render the view. >Incidentally, I coud have created a userpath in the DPS server, if I >wanted it to stick around. userpaths take advantage of the font-caching >system, and they're very fast. > GX shapes not only "cache" the information mentioned above, but also any calculations that are performed when drawing/pre-drawing the shape. Bit-map caching is allowed and is only part of the info stored and the GX database could be ( and no doubt has been) designed to optimally cache shape-type-specific info. There are 8 pre-defined graphical shapes: points, lines, rectangles, polygons, curves, paths, and pictures, as well as 3 text shapes: text, glyph and layout. No other types need be defined, IMHO, since a picture is a list of shapes, including other pictures. I can guarantee that GX shapes are going to be drawn as fast, if not faster, than DPS user paths due to the optimized-database nature of GX as opposed to the interpreted nature of DPS. Even if DPS contained a CPU-specific compiler that compiled the user path into a native-code code-snippet, the strategy used by GX would allow for hand-tuned optimizations for each shape-type, whereas the DPS way would not. >>Third, it also looks like the printing code is generic enough to cover all >>the GX printing - it's quite possible to have a library call that you'd >>pass a GXPicture to and that's that. > Exactly. Also consider what you are getting when you pass a "page" reference to the GX printing calls: Each GX print job includes: page count -number of pages to print. format list -list of page formats, 1 to a page. Shape list -list of pages, each of which is actually a GX picture shape. Remember that a picture shape is a list of one or more GX shapes, including other GX pictures. When GX printing starts, a user/application is allowed to select/preselect one or more print extensions. Print extensions can walk the shape list of the print job and apply GX calls to any/all GX shapes found in any/all pages (among hundres of other capabilities). For instance, you can have a printer extension that would grab every GX shape of type gxCurve on every other page and replace the curve with the Korean equivalent of "Your text goes here" along the path of the curve, color it using R =3D 25, G =3D 200, B =3D 150, and rotate the resulting curved-text by 30 degrees, skew it and apply a user-selected 3D perspective to it, before passing the print job on to the next printing extension. >>Fourth, the lines of source code is valid for some things, but the >>question is - how much native code is generated by the DPS lines. And how >>fast is each one. That's what is really important. > >I will also mention, that the example I wrote previously is using the >single-operator PS library calls, which is not the most efficient way >to do this. I could also have written my rendering code in PS, and >run it through pswrap to generate a binary object sequence. > I'll mention that the GX example app is using the optimized GX database calls and is already in code native to the CPU. Can't get any faster than that, IMHO, without writing your own custom drawing routines using a native compiler/assembler. >>Fifth, I believe one of the advantages of GX (from what I've been told) is >>that it is extensible and that DPS requires a change in the definition of >>DPS language (with a backward compatible interpreter for odl stuff) for >>additions to it. > >PS is a threaded intrepeted language. What could possibly be more >extensible? > >If I write: > >/rectpath > { > /x exch def > /y exch def > /w exch def > /h exch def > newpath > x y moveto > w 0 rlineto > 0 h rlineto > w neg 0 rlineto > closepath > } bind def > >Then rectpath works just like it had always been there. > If you want to add to or extract data from rectpath from within an Obj-C call, do you have to define your own data handlers or is generic methods that works for any path? WIth GX, if you want to extract/reset the geometry of a GXPath shape, you can do so using one of the GXSetXX/GXGetXX methods. E.G.: GXGetPaths( aShape, aPathDataPtr); or GXSet Paths( aShape, aPathDataPtr); You can also edit the data in-place using various calls. You can also convert a shape type from one type to the other: E.G., a layout shapes takes specific font and language info and a text-string and converts it into an auto-kerned, auto-ligatured, etc., text-string of the appropriate language using information found in the GX font. If you want to hand-tune these features, say by applying your own kerning, you can. If you convert the layout shape to a glyph shape, the default info specified in the GX font is used to provide you with a shape whose individual glyphs can be transformed, for things like applying the glyph shape to a path. Since a glyph shape is a standard GX shape object, any/all attributes can be modified to affect the shape-as-a-whole, allowing you to apply rotations/skews/perspectives/co= lors/transforms/composit-modes to the entire text after you've made it follow the arbitrary curve. Remember that this info is *ALWAYS* (memory allowing) stored in shape-optimized form within the GX database for optimized redrawing -and that it includes a lot more than just bitmaps and DPS-type cache info. This is a database optimized SPECIFICALLY for these kinds of records, remember? >In fact, I know of research projects where people used postscript to add >functionality to servers and device drivers, that had nothing to do with >graphics. It is a turing-complete programming language. You can write >a LISP interpreter in it if you like! > Cool. You can embed any information that you want in a user-defined tag within a GX shape object. You can specify that PostScript commands be used instead of the generic GX layout commands for rendering a specific shape. If you wanted, you could create a driver that would preprocess the tag-info to implement any old thing you wanted to, within the domain of the capabiltiies of GX drivers talking to PS drivers/non-PS printers, including passing along the PS LISP interpreter code as found in a GX shape user-tag. >-jcr > >>There are lots of things wrong with GX, but there are lots of things right >>with it.. > >>Just my two cents. > >>Mark Munz </FONTFAMILY></X-FONTSIZE><X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PAR= AM>Palatino</PARAM>> There's nothing really wrong with GX save that Apple never supported it properly. MY two cents... -----------------------------------------------------------------------= -- Windows: Tumor-causing, teeth-staining, smelly, puking habit. -----------------------------------------------------------------------= --</FONTFAMILY></X-FONTSIZE> --Cyberdog-MixedBoundary-000510B4-- --Cyberdog-AltBoundary-000510B3--
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 06:48:45 GMT Organization: Digital Fix Development Message-ID: <5c1osd$c0s@news.digifix.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> In-Reply-To: <5c0b1d$aiu@geraldo.cc.utexas.edu> On 01/20/97, William Raphael Hix wrote: >Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: >: raph@porter.as.utexas.edu (William Raphael Hix) wrote: >: > Example: does the existence of tar, a reasonably able backup >: > utility with a really unfriendly UI, make companies like Alladin >: > or Dantz who make backup software more or less eager to port to >: > Rhapsody? I think less likely, because the number of potential >: > buyers for Stuffit is reduced by the existence of tar and freeware >: > extensions. >: >: I don't think it effects them one bit. >: >: For one, most Mac users are used to Stuffit. They are not used to >: opening a unix window, and then figuring out all the options on >: tar. They will be much more likely to spend another $30 for a new >: version of Stuffit than bothering with tar. >: >: For two, Stuffit includes a very nice user interface. It is a >: "finder interface" to your compressed archive. Tar, by itself, is >: relatively crude. A front-end to tar might be competition to >: Stuffit, but tar by itself simply can not compete. >: >: For three, *I* don't use tar as a backup utility, and I'm more >: familar with tar than the average mac user is. I would very much >: prefer to have something like "Diskfit" for my NeXTSTEP system, >: and I've been using NeXTSTEP for years. > >Then you are essentially arguing that tar is of little use? (jumping ahead, you mention that this is too fixated on tar... the comments I've kept that in mind, and I think that these comments are probably safe enough in a general sense to be applied more widely.) Sounds to me that what he's saying is that its too clumsy for most casual users to learn, and that there is a market for a front end to it. Tar is of a great use to many people out there, isn't that obvious since almost everyone is adding its functionality and there are free versions of it available? >If this is >so, then why bother including it on everyone's disk? Why? Well, lets see.. Its a universally available tool on ALL machines, without depending on owning a third party product. This means that an Apple user who downloads something from the Net has a tool to start from. Same can be said for compress, ftp, telnet, etc... >But I think this >has become too fixated on tar. These are the issues that Apple faces with >respect to such Unix utilities. There will be developer pressure on Apple >to not duplicate the functions of 3rd party applications. There was an invited speaker who stood up at a WWDC conference and said that (and I'm paraphrasing here) "companies should stay out of the way and not make products they KNOW Apple is going to make. They should also not expect apple to buy their technology from them if that happens." Now, you need to take this with a grain of salt, since it was JLG that said this, and his kabillion dollar BE deal is obviously at clear odds with this statement. >Even before the >new OS, Apple's usurpation of functionality was one of the main complaints >from developers. Apple is particularly beholden to their developers >now since without developer support, Rhapsody is OpenStep/PPC. > >In general, there are 2 extreme cases. Case #1, Unix utility A does >everything (perhaps with a freeware wrapper) and so is a replacement for >Mac Software B. In this case the Mac software developer never ports >the application. There will be pressure on Apple to drop such functions. > Then they need to "value add" to their products. Even if they drop it from the OS CD, anyone can compile it for it, and still give it away. If they pressure Apple to drop basic functionality like this, then Apple should tell them to take a leap. >Case #2, the Unix utility A is a "poor" substitute for Mac application B. >In this case, what is the point of including this utility in the OS? Because its required by those who don't have the commercial product. Hell, better drop Edit.app from the release, its a RTF text editor, and the word processor people are going to scream. >Unix >compatibility comes the reply. Well, how important is Unix compatibility? Very. >It's clear from this thread that to NeXT users it's essential. But how >much does this matter to the Mac community that Apple is pitching Rhapsody >to? Oh, you mean like those piddly companies that have fortune 500 status? You know, those Enterprise installations Apple HAS to get to get back into the corporate market? Do you ever get a tar file that you want to uncompress over the net? Is Apple going to prohibit any freeware that might infringe on the little developer applications? > Would they rather have the system take up less space or have Unix >compatibility 99% of them would never use. The feelings of NeXT users >(none of whom have compatible hardware) are secondary to the 10-100 times >larger Mac community. Well, scr*w you too. Apple has said today that OpenStep for other platforms will continue to live, so suddenly alot more people become relevant due to hardware compatibility. And again, what if an Enterprise application running on OpenStep/Solaris or OpenStep/Intel require these tools? Someone needs a new machine, Apple doesn't ship with the essential tools, so we better just buy another Intel box with OpenStep/Intel on it. > >What about find? Should Apple leave the Unix find when we know they're >going to include their new V-Twin search engine and Find File. Well, the >V-Twin certainly replaces find if you are a GUI user, but what about CLI and >scripts? Will Apple leave find for the 1% of users who might want to >use their Mac like a Unix box? > Do you have ANY proof of your 1% number? Are you just grabbing at air? OK.. Apple removes a whole boatload of unix tools.... which means that those users who want to do things like run off-the-net stuff like Apache, INN, sendmail, all those other great Unix server programs are going to have to go through a hoop routine to install it? Will Apple prohibit compiling and distribution of find then? Who gets hurt by Apple including it? And what if someone writes a really cool freeware utility that uses find... do they have to supply it? >Naturally, every real example is somewhere in between, but both of the >extreme cases argue against strong Unix compatibility. Yeah, compatibility is bad. :-| CyberDog is bad. It hurts Eudora and other mail companies, better kill it now. sendmail, that might piss off a mail-gateway company ppp - hell, someone might want to make a commercial version ftp, sed, awk, perl, - all useful, but might tread on someone's toes, gotta kill them. ftpd, httpd, Apache, INN - all server products that will compete with other products. They're free here, gotta kill them too. Where do you stop? >It will be >interesting to see how Apple resolves this. Perhaps some add-on Unix >compatibility, even from a 3rd party. And lets not forget it will be free. >Apple will need to compromise >to fit Rhapsody to the needs of Mac users, and I fear that such >compromises will come at the cost of NeXT users expectations. > If Apple is at all serious about Cross-compatibility and the Enterprise, then they'd be stupid to remove unix utils (and all they'd be doing is making them harder to get, lets face it, they all supply source on the net). -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:10:38 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1c3e$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > I just don't understand you, Maury. You complain about HP > > making gratuitous changes in the file system that does nothing > > but make it difficult to work in a multivendor Unix environment, > > and then advocate Apple making gratuitous changes in the > > filesystem that does nothing but make it difficult to work in > > a multivendor Unix environment. > > Ahhhh, close except for that last line there. In fact, that's > the "non important part to be added later". It's only the > NeXT-ites that give two hoots about this, the VAST majority of > the users of the resulting OS will be Mac users and they simply > don't care about the later. I think Mac users will care if the operating system is not delivered. It's not so much that I care about the unix underpinnings of the current NeXTSTEP product, however I do think those underpinnings provide many useful abilities. If Apple does not use Unix to do those things, then they will have more work to do (one way or another). I do think the abilities are important, and I do not think it would be brilliant of Apple to start reinventing a lot of wheels simply so they can say "Well, we kept Unix off our hardware!". Too much work, for too little payback. I'm also of the opinion that if they *do* keep the unix underpinnings, then they should pick a layout for Unix which already exists, instead of dreaming up a new one. Note that they do not have to stick with NeXT's BSD-style layer to do this, they could also use a layout that mimics Solaris or AIX. The important point is that the unix layer should look a lot like something which already exists. The reason for this, to me, is that there are many packages with nice little configure scripts which will break if Apple dreams up some new layout for unix. I see this as creating work for everyone, including Apple, and for no good reason. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:14:47 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1cb7$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <maury-2001971529140001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > What "standard system library"? Who's arguing for that? No one > that I can see. As far as I can tell, we're all arguing for a > bunch of small shared libs. Uh, and how is that different from a standard system library? The fact that you'll break up one "standard system library" into many "small" shared libs? Well, unix already has several standard libs, and it's the collection which is considered the "standard system library". It is not a single file. And where would you put these small, shared libs? If you're talking MacOS, you will be forced to put them in the extensions folder. If we're talking Unix, you'll be forced to put them in /usr/lib. The difference does not seem all that profound to me. (note that if you install the "small libs" in the separate folders of various applications, then those libs are no longer "shared"...) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:26:11 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1d0j$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> <maury-2001971507310001@199.166.204.230> <5c0lgn$r2b@csugrad.cs.vt.edu> <maury-2001971738220001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5c0lgn$r2b@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > No, not really. It would be pointless to port a Unix environment > > over to NT; OpenStep doesn't need it. They only ported a few > > things. > > That's what I thought. Of course, they don't need it with WindowsNT because WindowsNT already has those facilities implemented. If Apple is going to throw out the Unix layer, then they will have to recreate all of it. They can't fall back to "the native OS", because they are the ones who have to provide the native OS. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 03:03:29 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1bm1$nhr@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: > : For three, *I* don't use tar as a backup utility, and I'm more > : familar with tar than the average mac user is. I would very much > : prefer to have something like "Diskfit" for my NeXTSTEP system, > : and I've been using NeXTSTEP for years. > > Then you are essentially arguing that tar is of little use? If > this is so, then why bother including it on everyone's disk? It is of little use, to me, as a backup utility. It is of great use, to me, for downloading (or uploading) distributions of various packages. I don't think it would replace stuffit for Mac-ish things, but at the same time Stuffit won't replace tar for unixy packages (not unless Aladdin makes a version of stuffit for all unix platforms, which I have actually asked them to do at times). > But I think this has become too fixated on tar. These are the > issues that Apple faces with respect to such Unix utilities. > There will be developer pressure on Apple to not duplicate the > functions of 3rd party applications. My guess is that you'll get the same response (from me, anyway :-) for any other unix utility that you care to name. The utilities are useful (and many are used by the system itself -- which means it needs to be part of the distribution), but they are not what Mac users would want. If you chose something other than tar, it's going to boil down to the same issues. > Even before the new OS, Apple's usurpation of functionality was > one of the main complaints from developers. I would say this is less of a problem with these unix utilities than with full-blown GUI applications. Apple can use the unix utilities for it's own (system) purposes, but third-party developers can do the "real Mac-way" versions. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: stanj@cs.stanford.edu (Stan Jirman) Newsgroups: comp.sys.next.programmer Subject: dynamic_cast in C++ Date: 21 Jan 1997 08:01:27 GMT Organization: Stanford University Message-ID: <5c1t4n$sdd@nntp.Stanford.EDU> Hello, C++ supposedly supports dynamic casting, like Accord *pAccord = dynamic_cast<Accord *>(item); Well, I don't seem to be able to get it to work. I looked in the g++ sources, and it is there, but when I use the above line, it complains about the function "dynamic_cast" not being defined. What do? Thanks, - Stan --- Nature photography: http://www-leland.stanford.edu/~stanj NeXTmail and MIME: stanj@cs.stanford.edu
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 13 Jan 97 21:41:08 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan13214108@slave.one.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <Pine.SGI.3.94.970107150251.22376D-100000@ranvier> <gmares-1301970024540001@newshost.cyberramp.net> In-reply-to: gmares@cyberramp.net's message of Mon, 13 Jan 1997 00:24:54 -0500 In article <gmares-1301970024540001@newshost.cyberramp.net>, gmares@cyberramp.net (Gabe Mares) writes: I got used to proportional thumbs with GS/OS, and missed them when I moved to a Mac. After using a Mac for years, I find the proportional thumbs disconcerting in WinNT 4.0. I guess it's what you're used to. FWIW, I believe I read in "Tog on Interface" that Apple's user testing showed that proportional thumbs confused many users, which would explain why that feature didn't make it over to the Macintosh. OTOH, I have seldom seen anything more confusing than the old Windows non-proportional scrollbars and how they always were telling me "Hey, dummy, more text at the bottom", and when you scrolled down there ... nothing! [Related: Whoever thought to add that wonderful extra page or so of blank at the end of things? So helpful.] In any case, I think you're right, proportional scrollbars are entirely an experience issue. I can't imagine a means of honestly measuring the difference between proportional and non-proportional for inexperienced users. Either would seem confusing :-). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 04:29:38 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c1gni$nhr@duke.squonk.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> tbutler@tfs.net (Travis Butler) wrote: > In article <32DEDEC1.490C@exnext.com>, > "Jonathan W. Hendry" <jon@exnext.com> wrote: > > <Snipped part about how taking out the standard (but IMHO obtuse) Unix OS > directory structure would cause problems for porting standard Unix > utilities> > > > If Apple wants the new OS to be a useful Unix platform > > (and they should) > > Here is the main point where you and I part company. I don't > *want* the new OS to be a 'useful Unix platform' if it comes > at the expense of the Mac's ease of use. a) some of us just want it to be a useful platform, and we see Unix as providing some very useful features. It's not unix per se that we want, it's the features. Apple could provide all those features without unix, but (I feel) that would be a major project. One that they do not have the time to tackle right now. b) certainly NeXTSTEP users do not want Unix at the expense of ease-of-use. In some of the early interviews with Ellen Hancock, she said something like "NeXTSTEP has done a good job of hiding Unix from the user. However, there are still some rough spots, and we intend to complete the job". I, for one, think that's a very good approach. I do not want to force anyone to learn a unix shell in order to do their work. At the same time, I think it'd be stupid to hobble the system as a whole by removing Unix, and I think it would be too large of a project to talk about rewriting that functionality in some other form. > The *reason* I want a Mac is so that I wouldn't have to deal with > the hassles of a CLI-based OS like Unix or DOS/Windows. So I > wouldn't *have* to deal with /bin, /usr and /etc, commands like > "ls", "mv", "chmod," and suchlike. I hate to put words in other > people's mouths, but I imagine that's the same reason a lot of > the Mac users in this debate bought Macs. The thing to realize is that most NeXTSTEP users do not use the CLI at all. I know of at least a few NeXTSTEP users who have run NeXTstations for at least four years now, and they still don't know any unix. None at all. I would expect that the user interface will only get better in Rhapsody, and that no owner of a personal system will ever have to learn any Unix. At the same time, there are other situations where Unix will come in very handy. These are in server configurations, or in multi-user configurations. (Note: I run some Mac labs here at RPI, and there are several features of Unix that I'd *really* like to have on those machines). > If you could make Unix functionality a part of the new OS without > *forcing* users to deal with these things, so they wouldn't need > to see or use them unless they really *wanted* to, then I wouldn't > mind. But what I saw of NeXTstep a few years ago didn't work that > way, and the comments I've seen here suggest that it hasn't > changed in this respect. Hmm. Odd. What kind of things were you doing that you need to have terminal windows open? --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: dami@cui.unige.ch (Laurent Dami) Newsgroups: comp.sys.next.programmer Subject: Re: Doesn't anyone know about power management? Date: 21 Jan 1997 08:47:56 GMT Organization: University of Geneva - CUI Message-ID: <5c1vrs$ktg@uni2f.unige.ch> References: <5c078g$325i@news.doit.wisc.edu> <5c0p35$hak@news.us.net> In article <5c0p35$hak@news.us.net>, Bill Chin <bchin@us.net> wrote: >giddings@menominee.chem.wisc.edu (Michael Giddings) wrote: >>It seems surprising that *no one* else has even looked into this. Please, if >>you have any insights or information about the way the mach kernel in 3.3 and >>4.x deals with power management, I would appreciate the info. I would like >>to try to write a driver to improve the performance, as well as providing >>working suspend/resume, particularly for Toshiba Tecras. > >I'm not surprised no one has responded. Not many people run NS/OS on laptops, >and those that do probably disable APM to get it to work right. For info: I'm using NS on a NEC Versa P laptop, and APM works just fine. I just suspend/resume very often, and never met any problem. But I know nothing about the kernel internals, sorry. ========================================================================= Laurent DAMI | tel: +41 (22) 705 76 63 Centre Universitaire d'Informatique | secr: +41 (22) 705 77 70 24, rue General-Dufour | fax: +41 (22) 705 77 80 1211 Geneve 4 | email: dami@cui.unige.ch SWITZERLAND | WWW: http://cuiwww.unige.ch/~dami =========================================================================
From: gad@eclipse.its.rpi.edu (Garance A. Drosehn) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 21 Jan 1997 05:19:18 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Distribution: world Message-ID: <5c1jkm$5di@usenet.rpi.edu> References: <antispam-2001971935190001@farrca.apple.com> antispam@apple.com (Cary Farrier (farrier@apple.com)) writes: > dlehn@vt.edu wrote: > > > Is Apple going to push Sprockets for Rhapsody? > > Yep. We're looking into the technical aspects right now. Ah, I'm glad to hear this! -- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: tbrown@netset.com (Ted Brown) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 22:07:53 -0500 Organization: NetSet Internet Services -- Columbus, Ohio Message-ID: <tbrown-ya023580002001972207530001@news.netset.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> <maury-2001971514370001@199.166.204.230> <32E403A3.788@concentric.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <32E403A3.788@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: >OpenStep is a framework for writing GUI-based apps. If such frameworks exist >for C, FORTRAN, COBOL, BASIC, RPG or Assembly (I don't think they do in all >cases), then those frameworks are not compatible with OpenStep. And a COBOL >shop would be interested in porting their existing apps over to Rhapsody, which >would mean porting over their existing framework(s) for doing GUI apps (if they >have such). Just because you've got a application in COBOL doesn't mean that when you port the app to another platform you want to write the entire GUI code in COBOL (even if it was originally written so for the other platform). What you want to do is provide a seemless jump from the new GUI code to the old COBOL code that is the core of the program. The new GUI code should be coded in something that best suits the job (which is prolly not COBOL). OpenStep seems to do well in this regard, as it's easy to craft the GUI code. There were several stories of Sci Computing Fortran programs being ported to NeXTSTEP, getting a GUI in the processs. The old event code was ripped out, and called from Obj-C. Result: a much better interface and few changes to old code. I could see some obtuse programs making the port harder, in that case you're prolly going to be fighting the port no matter what the target platform. -- Ted Brown tbrown@netset.com
From: ehutch@hypnos.norden1.com (E. Hutchinson) Newsgroups: comp.sys.next.programmer,misc.jobs.offered,ill.jobs,mi.jobs Subject: Career Position:NEXTSTEP/Obj C/ILL Date: 21 Jan 1997 14:27:56 GMT Organization: Norden 1 Communications Message-ID: <5c2jpc$b6o@tofu.alt.net> Programmer/analyst/developer NEXTSTEP--------------------Commercial experience Objective C-----------------Commercial experience EOF-------------------------A plus Career Position-------------Benefits & bonus Area------------------------Greater Chicago area To Be Considered------------Send or mail resume. -- ehutch@norden1.com (419) 893-6367 [fax] Omni Search (419) 893-6334 [voice] 1310 Craig Maumee, Ohio 43537
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 97 09:05:58 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan21090558@howard.one.net> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> In-reply-to: maury@softarc.com's message of Mon, 20 Jan 1997 17:48:37 -0500 In article <maury-2001971748370001@199.166.204.230>, maury@softarc.com (Maury Markowitz) writes: Arguments include... a) Unix utils make it easier to develop But not as easy as OOPS libs with the same functionality I'm getting _somewhat_ tired of this particular point, and I've not seen anyone really rebutt it, so ... The choice is _not_ "The standard Unix utilities" vs "OOPS libs with the same functionality". Why not? 1) The Unix tools were designed as one-shot packages. For the most part, a particular tool (say, find(1)), is not designed as a generalized library with a command-line wrapper. Instead, it is designed so that the program executes once. Loosely put, the programs are not reentrant, and thus in most cases cannot be easily wrapped into a library. 2) The Unix tools are (quite frankly) not nearly well enough rounded to be made into a generalized library. If you're willing to have a library who's _only_ operation is to search a file for a regular expression and spit out a stream of matches, that's great. Unfortunately, I suspect that most people will want to interact with the execution more. For instance, your program may want to modify how many matches, it interactively receive lines and pass/fail them based on something other than a regex. 3) The Unix tools (or, more precisely, the _GNU_ Unix tools) attempt to be portable. This is a means of allowing their potential audience to be larger than any one platform, as most platforms don't have enough userbase to warrant extensive development. The first two points mean that a generalized, well-designed set of OOP libraries implementing the same set of functionality as a particular set of Unix command-line utilities will take 2-4 times the effort to develop. My experience indicates that that is a _conservative_ estimate. The effort required is likely to be open-ended. The third point means that we only have a small subset of the possible programmers who would have any incentive to work on the problem. Since these OOP libraries won't as easily portable outside of MythOS, anyone not on that platform won't have incentive to work on them. So, we have perhaps 10% of the man-hours applied to a problem that 3x harder than it needs to be. It's _very_ unlikely that this is going to happen. Last point? The water is very muddied, here. In my work I _very_ seldom use Unix utilities from C code. It just doesn't make sense, as the impedance mismatch is too great. I make _extensive_ use of Unix utilities while developing code, though, and I often write scripts which tie together Unix utilities (including other scripts) into a relatively seemless whole. In some sense Unix itself is one of my tools. Each specific operation I've done in Unix probably would be slicker if it had a GUI counterpart. On the other hand, any package which had that many functions would be impossible to understand (if you can't _find_ the operation, it might as well not exist), and I doubt there's any incentive to write a GUI version of various essentially one-shot operations, so that GUI version will never be written in any case. [In practice: A GUI grep-like program would be useful to many people. A GUI program to find all *.h files which contain the phrase "Public Interface" and then use their path relative to a given absolute as a basis to create a symlink in another directory is probably _not_ going to happen. Partially, this is because such a program would require so much flexibility that it will probably require a scripting language, at which point it might as well be a shell script, or even a "lambda" version (a single command-line tied together with pipes).] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: ENGELHART.M@applelink.apple.com (Michael Engelhart) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 21 Jan 1997 15:07:02 GMT Organization: Apple Computer, Inc. Distribution: world Message-ID: <ENGELHART.M-2101971010080001@17.128.202.195> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> In article <acurylo-1601971109400001@van0217.tvs.net>, acurylo@inmediapresents.com (Alex Curylo) wrote: > What gets me is how, if all these super-neat features like this that the > Obj-C guys keep casually throwing out really do exist as described, why on > earth did the universe at large adopt C++ instead? Same reason the universe at large bought into Microsoft Windows... :-)
From: ENGELHART.M@applelink.apple.com (Michael Engelhart) Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 21 Jan 1997 15:13:42 GMT Organization: Apple Computer, Inc. Message-ID: <ENGELHART.M-2101971016510001@17.128.202.195> References: <SHESS.97Jan17125637@howard.one.net> <E4BDKr.7nC@cam-ani.co.uk> > people buy what they're told to buy. Even programmers (who should be > smarter than average) follow the crowd. Most don't want to stand up and > shout about making things better. i think you're a little mislead...programmers aren't following the crowd, they're following the money trail that leads to the crowd... Programming is still a way to make money for most people so unless you've found a way to make a living using (until now) alternative OSes like NeXT, you've most likely moved on to Windows or some other crowd based technology... Mike Engelhart
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 15:26:12 GMT Organization: University of Sheffield, UK Message-ID: <5c2n6k$1l8@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> In-Reply-To: <AF09658696681B35E3@travis.tfs.net> On 01/21/97, Travis Butler wrote: > The *reason* I want a Mac is so that I wouldn't have to deal with the > hassles of a CLI-based OS like Unix or DOS/Windows. So I wouldn't *have* to > deal with /bin, /usr and /etc, commands like "ls", "mv", "chmod," and > suchlike. I hate to put words in other people's mouths, but I imagine > that's the same reason a lot of the Mac users in this debate bought Macs. > <sigh> This is exactly why many people use NEXTSTEP. > If you could make Unix functionality a part of the new OS without *forcing* > users to deal with these things, so they wouldn't need to see or use them > unless they really *wanted* to, then I wouldn't mind. But what I saw of > NeXTstep a few years ago didn't work that way, and the comments I've seen > here suggest that it hasn't changed in this respect. > I know of many NEXTSTEP users who don't know anything about Unix, and never will. They tend not to post here, though. What exactly was it about your encounter that gave you the idea that you *needed* a CLI. When was this? Best wishes, mmalc. --
Date: Tue, 21 Jan 1997 09:51:08 -0600 From: dtapp@dilan.com Subject: NSCalendarDate woes Newsgroups: comp.sys.next.programmer Message-ID: <853860675.19197@dejanews.com> Organization: Deja News Usenet Posting Service Hello, all. I'm trying to use the NSDate and NSCalendarDate classes to set up some WHERE clauses for an SQL server. I'm having troubles with the "all events that happened yesterday" and "all events since midnight" options. I'm not that experienced with these two classes, and I'm getting two different types of bad results. First, this "yesterday" code throws an exception. (Note the code is a little more verbose than necessary; due to my debugging efforts: #define RIGHT_NOW [[ NSDate date ] \ dateWithCalendarFormat:@"%Y%m%d%H%M%S" timeZone: nil] . . . if ( [ dateType isEqual: @"yesterday" ] ) { NSCalendarDate *now = RIGHT_NOW, *yesterday = nil; NSString *yesterdayString = nil; yesterday = [ now addYear: 0 month: 0 day: -1 hour: 0 minute: 0 second: 0 ]; yesterdayString = [ yesterday descriptionWithCalendarFormat: @"%Y%m%d" ]; return [ NSString stringWithFormat: @"events.start >= '%@000000' and " @"events.stop <= '%@235959'", yesterdayString, yesterdayString ]; } This second snippet of code works ok, but returns inconsistent results. If I run it at about 9:00 in the evening, it tries to select tomorrow's records! (I have the correct time zone preference set.) if ( [ dateType isEqual: @"since midnight" ] ) { return [ NSString stringWithFormat: @"events.start >= '%@000000'", [ RIGHT_NOW descriptionWithCalendarFormat: @"%Y%m%d" ]]; } Regards, - Dan -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 15:46:30 GMT Organization: Airwindows Message-ID: <jinx6568-2101971048510001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> In article <5c0fue$2e7@csugrad.cs.vt.edu>, nurban@vt.edu wrote among other things: > In article <5c0b1d$aiu@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote among other thing: > > Case #2, the Unix utility A is a "poor" substitute for Mac application B. > > In this case, what is the point of including this utility in the OS? Unix > > compatibility comes the reply. Well, how important is Unix compatibility? > > It's clear from this thread that to NeXT users it's essential. But how > > much does this matter to the Mac community that Apple is pitching Rhapsody > > to? Would they rather have the system take up less space or have Unix > > compatibility 99% of them would never use. The feelings of NeXT users > > (none of whom have compatible hardware) are secondary to the 10-100 times > > larger Mac community. Er, as you know, our installer programs allow 'full installs' and 'partial installs' and 'custom installs'. Why wouldn't the Unix programs- all of the hairy little buggers! be part of a really full install? Might even still fit on one CD- and if not, never mind 'HD being cheap', CD-Rom substrates in bulk are _really_ cheap. > Why not? All these Unix utilities don't take up much space. Crippling > a Unix system isn't worth the effort. The _only_ consideration is > whether the existence of these utilities will hurt developers with > similar products, and I don't think that this is a serious problem. I > doubt 'find' is going to replace V-Twin for desktop use, but there are > plenty of sysadmins and shell scripts who use it. I agree with Nathan. Completely. Because we do have good installers, and this is an ideal situation for a good installer. Preloads would be a more interesting situation and I daresay if the utilities are truly auxiliary they would not be included on mass-market preloads. But you could probably download them as desired. Jinx_tigr (aka Chris Johnson)
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 10:57:14 -0500 Organization: Atria Software Message-ID: <maury-2101971057140001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> In article <32E3EA94.142F@exnext.com>, jon@exnext.com wrote: > Considering that Apple can't survive by just pleasing current > Mac users, this isn't a very good argument. Yes, but stating that offering a Unix will expand market share is just as bad an argument. Apple _has_ offered Unix to customers for many years now, and it's been pretty much glued to the shelves. Unix alone will not expand Apple's market share whatsoever. > Apple cannot gain > marketshare by catering to the tastes of a rapidly shrinking > user base. A solid OS alone, one that's fast and powerful, has the ability to indeed stop that erosion, perhaps reverse it. > They have to start working on people who aren't > Mac users. So which market do they go after? The PC market doesn't want Unix any more than the Mac market does. > To do that, Apple has to figure out why they're > not Mac users. For some significant population, this is going > to be because they need Unix. Apple cannot afford to ignore > this market. I agree, and they already offer multiple solutions into this market, all of them rarely used. The "opposite", MAE, does indeed seem to be doing OK though. > BTW, POSIX support has little to do with Unix utilities. I know, but my point is that such support has been offered by other OS's as well, and has been pretty much ignored. If you want Unix, you buy Unix. If you don't, you don't. That's pretty much it. Offering Unix as a "feature" will no more expand Apple's market share now than in the past. Maury
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 15:55:08 GMT Organization: Airwindows Message-ID: <jinx6568-2101971057300001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> In article <Qmt04oO00iV0M52u8d@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Again, writing a new library which provides functionality already > implemented by Unix command-line tools is the precise opposite of code > reuse. Here is a thought for other Mac people- perhaps the Unix command-line tools are best suited for _programs_ using them, not humans. It seems that for networking in particular, it's pretty easy to set things up so everything is a stream of bytes like Unix wants. Given that there are situations where data types are more complex, given that we already have code and APIs and programs to do the fancy stuff, is there any reason _not_ to let things which are already a stream of bytes _be_ a stream of bytes and let the Unix code (say, the GNU stuff Garance speaks well of) handle it? Jinx_tigr (aka Chris Johnson)
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 97 09:17:44 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan21091744@howard.one.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> In-reply-to: sanguish@digifix.com's message of 21 Jan 1997 06:48:45 GMT In article <5c1osd$c0s@news.digifix.com>, sanguish@digifix.com (Scott Anguish) writes: On 01/20/97, William Raphael Hix wrote: >Case #2, the Unix utility A is a "poor" substitute for Mac >application B. In this case, what is the point of including this >utility in the OS? Because its required by those who don't have the commercial product. Hell, better drop Edit.app from the release, its a RTF text editor, and the word processor people are going to scream. I'm prepared to release a commercial windowing system, if only we can get them to drop the current windowing system. I'd also be willing to get people together to release a commercial file system (again, only if they drop the current filesystems). Oh, probably should drop TCP/IP again, because there are some people who don't use it (and we already have commercial versions of that :-). Ah, well, now _there's_ an argument. _With_ the Unix utilities, FutureMac would be more useful to more people without having to spend additional bucks. Perhaps there will even be people out there who think it's stupid to have a Mac windowing system, when they just want to use Emacs in a text window. Apalling, isn't it? :-). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 10:02:15 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E4DA77.3678@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <5bumdc$evr@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > Really, there's no point in ripping out Unix. > > Yes there _is_: > > a) easier on the programmers So NT is easier to program than, say, BSD Unix? Not likely. Especially if the program you're working on came from a Unix platform. > b) more cross platform Again, not likely. -- Jonathan W. Hendry jon @ exnext . com
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 10:21:41 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E4DF05.7E8F@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32E3D1EA.7F8F@exnext.com>, jon@exnext.com wrote: <snip< > > Who > > cares if they buy Solaris, or Windows NT, or run linux on a cheap > > Pentium? Who needs em. > > That's a sophomoric argument and you know it. No, it's really not. Apple needs to increase marketshare. Thus, it needs to sell to people who currently would run Solaris, NT, or linux. > > Apple doesn't need new markets, right? Their current markets are doing > > *just fine*. They're doing just fine on their own. Selling to them home > > users, schools, and artists. > > No, but Unix's market share isn't exactly growing by leaps and bounds > either, even with all the interest in the Internet saving it. And why is Unix's market share not growing? Because it doesn't have the general-purpose apps or ease-of use of, say, Windows NT. Rhapsody should provide both of these things. I also have to wonder what the Unix share would look like if Linux was included. > > Oh, that's right. Apple's marketshare is dwindling. Apple's > > traditional markets are moving to Windows. Schools, homes, graphics > > professionals. > > Oh yeah, and NeXT's superior technology will help a lot here. Just look > at how successful it was when they sold machines running it. This isn't about NeXT. This is about Apple, and the fact that Apple is losing marketshare. > As every Apple owner will tell you - technology doesn't create markets. This is true. However, Apple's failing in existing markets. Apple no longer has a compelling advantage in these markets. And there are other existing markets that Apple has no presence in. > > Evidently, Apple must not be selling what people want > > anymore. > > But Apple DOES sell Unixen now, and no one's buying them either. This > is not an argument for Unix. Apple's current Unix offerings are AIX. Which suffers from the same problems as other plain Unixes: no mass-market software, poor ease-of-use. Rhapsody with a Unix layer would suffer from neither of these problems. > > I think Apple should spend some time to find out exactly what > > users want. *Not* current Mac users. Former Mac users. Mac users > > who have left the Mac for NT, Solaris, Linux, IRIX, whatever. > > Total Mac ownership continues to grow, that's not an issue. The issue > is that the rest of the market grows faster. Yeah. I know of two macs. They're sitting in a closet in Connecticut. But are Mac owners replacing their old Macs with new Macs, or PCs? It seems like the answer is PC's. > > Let's see. Apple has about 6% marketshare. If Apple can successfully > > sell to the 1% of users who want Unix, that would give Apple 7% > > marketshare. > > Uhhh, what? Win has 70% of the market, Apple 6% (in new sales) and the > other 25% is divided up among all the rest. Even if that's all Unix, 1% > of that is only .25% of the overall market. > > Maybe I'm missing something, but I'd like to see your explanation of > this number. It came from the post I was following-up. They said something about the 1% of users who want Unix. Nothing scientific about it. ;) The point is that it may seem like very few people want Unix. But very few people want Macs. The Unix market may be small, but Apple cannot afford to turn away anything that could increase their marketshare. When you've only got 6%, even a .5% increase is worthwhile. And if Apple doesn't grab that market, Microsoft will. Which Apple definitely cannot afford. > > If Apple can grab back the graphics professionals who are using > > NT, they could probably add another .5%. If Apple can grab > > webserver marketshare from WinNT, that might account for another > > .5%. (This would likely be easier if Apple shipped Rhapsody > > on Intel). That'd increase Mac marketshare by another 1%. > > And how do any of these revolve around having the Unix shell utils in > their current form rather than an updated one? Webservers: It'd be a lot easier to recompile a webserver and other related tools if the Unix environment hasn't been mangled. The ability to use tools that were developed on Linux, without having to hack makefiles, is a big plus. For graphics? Eh, it might not matter. -- Jonathan W. Hendry jon @ exnext . com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:34:49 -0500 Organization: Atria Software Distribution: world Message-ID: <maury-2101971134490001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971144500001@199.166.204.230> <5bofh1$g3f@csugrad.cs.vt.edu> <maury-2001971506200001@199.166.204.230> <5c0nkk$r0l@csugrad.cs.vt.edu> <maury-2001971752260001@199.166.204.230> <5c11f7$3po@dfw-ixnews5.ix.netcom.com> In article <5c11f7$3po@dfw-ixnews5.ix.netcom.com>, aisbell@ix.netcom.com (Art Isbell) wrote: > Depends :-) If an app includes a single statement that registers one of > its objects as a distributed objects server, then a client process can access > that server object and any other objects accessible via the server object. Fair enough. > Or if an app is designed to be extensible by dynamically loading code at > run-time, then this distributed objects registration statement can be > included in the loaded code thus making certain of the app's objects > available to clients. Right. > We use this approach to drive OPENSTEP's > InterfaceBuilder as a distributed objects server even though it was never > designed to operate this way :-) Hmmm. You actually call code right out of IB? Cool. And is this all networkable by default, or is this a "user" process that's logged in running locally. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:33:39 -0500 Organization: Atria Software Message-ID: <maury-2101971133390001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <maury-2001971527440001@199.166.204.230> <32E3FA7A.5DEA@exnext.com> In article <32E3FA7A.5DEA@exnext.com>, jon@exnext.com wrote: > Where exactly do you intend to call the API from? Directly from a program, like you do with all the other Unix API's. That program may be a CLI shell, it may not. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:41:51 -0500 Organization: Atria Software Message-ID: <maury-2101971141510001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu> In article <Mmt0c0i00iV0052yVd@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > > Great, so have a shell that calls the OOPS libs. > > In fact, have lots of them. > > "Calls the OOPS libs" how? With a program. You know, those funky "API" things. > Are you talking about having the system boot using a precompiled > executable? No, I'm talking about having a OOPS shared library of some form on the disk, rather than a CLI executable program that you fork off. That's it. > If so, remember that we already went through the reasoning > why that's not as good as having the system boot be configurable via an > interpreted shell. And it still could be. Is this really so strange? I am truly baffled at the number of questions I'm getting about this that seem to be confused about what I am suggesting. > Who cares whether the current average Mac user would want them or not Riiiiight. In fact, let's install NT on their drives too. VMS while we're at it. Have you heard of the term "distributed costs"? > so long as the ability to run those applications has no negative > implications to that Mac user besides $3 worth of disk space? Do you mean aside from the fact that code written to use them is thus not portable by definition? > Rhapsody has the potential to sell to a large number of markets that > Apple has never been successful in before-- such as corporate MCCA, > Internet/Intranet usage, the server market, web technology, the > important areas of higher education (ie, graduate CS/IS/Math programs > :-), and so forth. Basicly, Rhapsody will cover all of the areas where > Unix is popular, and hopefully will also make inroads into the normal > business environment which is currently dominated by Microsoft Windows. Great, so have a check box in Custom Install that states "Install Unix shell utilities" and you can do all of this? This is getting really repetitive. > Assuming, of course, that Apple doesn't do anything _completely_ > braindamaged-- which is the only description I have for the suggestion > of ripping Unix out of Rhapsody. Who said anything about ripping Unix out of Rhapsody?!? READ THE THREAD! > Don't you Mac advocates want Rhapsody to be used by people who are > currently using other operating systems? Or would you rather have > Apples' market share shrink even further? Just to satisfy the bigotry > of Unix-haters? How stupid can you get? Yes, in fact I want it to make their hard drives explode and erase all their existing code too. I want it to not run any Mac software either, and offer limited compatibility to the C64 only, in 22x20 screen resolution. Come on people, READ THE THREAD! > If prior experience hadn't taught me not to ask for the impossible Which is what I feel when I ask people to read the thread. Maury
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 16:33:39 GMT Organization: University of Sheffield, UK Message-ID: <5c2r53$3i3@bignews.shef.ac.uk> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> In-Reply-To: <maury-2101971057140001@199.166.204.230> On 01/21/97, Maury Markowitz wrote: > So which market do they go after? The PC market doesn't want Unix any > more than the Mac market does. > Umm, this jars a little with the success of Linux... Best wishes, mmalc. --
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:49:51 -0500 Organization: Atria Software Message-ID: <maury-2101971149510001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> In article <8mt0xGe00iV0I52lR_@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > If you were being sarcastic (I'll admit to not being sure, since your > arguments to date don't make a whole lot of sense, IMHO): Right. If the posts here are any indication, it's because people simply aren't reading them. I have stated for no less that TWO WEEKS the same points over and over, and to date I've seen only ONE person figure it out. Your reply is doubly insulting, something I am rather rapidly tiring off. While admonishing me for not being able to "debate", it's clear in the message I was replying to that you had not even understood what I had written. > stop congratulating yourself over this latest witty remark long enough > to provide the logical rationale behind your argument? I have repeatedly, including the message you replied to that generated this remark. I'm tired of being called a moron because... a) I don't need Unix shells on my machine b) I don't want Unix shells on my machine c) I think the whole system would work better with shared libraries rather than forked command line utilties Maury
From: ralsina@ultra7.unl.edu.ar (Roberto Alsina) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 16:56:35 GMT Organization: Universidad Nacional de San Luis - Argentina Message-ID: <slrn5e9tda.kp7.ralsina@ultra7.unl.edu.ar> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <racecarr-ya02408000R1801972211380001@news.cu.soltec.com> In article <racecarr-ya02408000R1801972211380001@news.cu.soltec.com>, Tony M. Carr wrote: >In article <5bq05v$7t9@duke.squonk.net>, Garance A Drosehn ><gad@eclipse.its.rpi.edu> wrote: > >> raph@porter.as.utexas.edu (William Raphael Hix) wrote: >> > Example: does the existance of tar, a reasonably able backup >> > utility with a really unfriendly UI, make companies like Alladin >> > or Dantz who make backup software more or less eager to port to >> > Rhapsody? I think less likely, because the number of potential >> > buyers for Stuffit is reduced by the existance of tar and freeware >> > extentions. >> >> I don't think it effects them one bit. >> >Especially since tar doesn't do any compression, it simply lumps many files >into one file. That's why so many files on the internet have *.tar.gz file >names. They're run through tar then through gzip to compress the tar file. >There will definitely be a market for Stuffit & Retrospect under Rhapsody. > >Tony C. > Just as a comment: making a big file and then compressing it usually gives a better compression ratio than the pkzip compress-and-then-lump strategy. I don't know how the Mac compressors do it, though. Also: doing it that way is a *very* fundamental part of Unix philosophy (combine small progs that do only one thing). For example, a few months ago, somebody released a prog called bzip that compressed 25-30% better than gzip. So, I instantly got a 25% improvement in my compressed files. Regards. >-- >Tony M. Carr >Veteran of the Psychic War -- ("\''/").__..-''"`-. . Roberto Alsina `9_ 9 ) `-. ( ).`-._.`) ralsina@unl.edu.ar (_Y_.)' ._ ) `._`. " -.-' Centro de Telematica _..`-'_..-_/ /-'_.' Universidad Nacional del Litoral (l)-'' ((i).' ((!.' Santa Fe - Argentina
From: rickg@sunsoft.eng.sun.com (Richard Goldstein) Newsgroups: comp.sys.next.programmer Subject: Re: SPARC OpenStep & GCC Date: 21 Jan 1997 08:45:09 -0800 Organization: SunSoft, Inc. Sender: rickg@upuaut Message-ID: <ku7wwt7j7u2.fsf@upuaut> References: <y7yhgkd5npf.fsf@do.isst.fhg.de> In-reply-to: Dirk Vleugels's message of 19 Jan 1997 23:01:32 +0100 From: Dirk Vleugels <vleugels@do.isst.fhg.de> Newsgroups: comp.sys.next.programmer Date: 19 Jan 1997 23:01:32 +0100 Organization: FhG ISST Dortmund, Germany Hi, i installed OpenStep 1.0 on a Creator2 running Solaris 2.5.1, and i'm quite impressed. Question: I do have the header files NS* & stuff + the shared libraries: .... Is it possible to develop software with the free GCC? Do i need the AppBuilder? I couldn't find a SUN ObjC compiler + OpenStep SDK. Haven't tried, but my guess is no, based on the lack of standard ABI for languages like C++ & ObjC. The Sun ObjC compiler is the same as the C++ compiler, look for that on the CD. rick -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Richard M. Goldstein richard.goldstein@Eng.Sun.COM 64-bit Linkers, Libs & Executables SunSoft, Inc. "Without time we pick up all the streams, and find the leaves that drift out inbetween..." -Kirkwood
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:29:15 -0500 Organization: Atria Software Message-ID: <maury-2101971129150001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> <maury-2001971514370001@199.166.204.230> <32E403A3.788@concentric.net> In article <32E403A3.788@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > It's a bad thing if you want to attract customers who intend to use those > languages, and don't want to change. It was a joke. Regardless all of these languages are available on the Mac, some (if not all) on NeXT, all of them on the PC etc. It seems there's no problem here. > OpenStep is a framework for writing GUI-based apps. If such frameworks exist > for C, FORTRAN, COBOL, BASIC, RPG or Assembly (I don't think they do in all > cases), then those frameworks are not compatible with OpenStep. Only for now. Apple has stated that Java will be a "first class" language upon release, how they do this may open the API to other languages as well. SOM is one possibility for instance, which is typically available with both OOPS wrappers (for SOM itself) and non-OOPS calls for other cases (CFM for instance). > And the original question wasn't the API for OpenStep, but rather the > API to the kernel and the standard UNIX utilities. Not in my case, my _only_ interest is the utilities. The kernel is fine the way it is, and there are lots and lots of direct calls to other Unix API's that seem just fine the way they are too. This thread is specifically about those utilities, they should be better. > I've heard differently. But I could be wrong. I'd be happy to wrong on this > pont, actually. Me too, but I don't really know for sure either. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:51:45 -0500 Organization: Atria Software Message-ID: <maury-2101971151450001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <gmt17KG00iV0A52nk5@andrew.cmu.edu> In article <gmt17KG00iV0A52nk5@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Removing functionality cannot _possibly_ make programming easier. And there is is again, a clear indication that you have either not read the posts, or are incapable of understanding them. > can always decide to not use some API if you don't want to, but not > having an API available at all means that you will have to do more work > if/when you needed that functionality. Find a message in which I propose that the API's should be removed. In fact, I've been constantly and unwaveringly suggesting that all of them should indeed be API's, when in the current case they are not. > I'd question whether this is true, too. You can find versions of 'grep' > for almost every computer system available today. Ditto for most other > popular Unix tools: tar, diff, sh, etc, etc. Yes, but they don't come installed by default, so it's a moot point. If you use grep and port, you provide grep. So much for code reuse. Maury
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Remote cvs and .nib wrappers Date: 21 Jan 97 11:23:55 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Jan21112355@slave.one.net> I have a situation, here. The project has a core engine which is currently running on NeXTSTEP, OpenStep/Mach, OpenStep/NT, and StepStone (for Windows 3.1). Unfortunately, even with only two active developers, keeping everyone up-to-speed on changes is becoming a problem, especially because we aren't at a single site. Right now we effectively swap code trees every month or so, and each run FileMerge to look over the diffs. This is annoying. Right now I can easily enough get things set up in cvs so that I can share the engine between the NeXTSTEP and OpenStep/Mach versions, on my local network. The problem still comes up when I go to OpenStep/NT, though. Since this is what computers are good at ... I've been exploring the remote features of cvs. Unfortunately, it seems that remote cvs doesn't work in combination with wrappers, so cvs can't handle .nib files in the repository. Has anyone gotten that working? Fortunately, the engine itself does not use .nib files, and the OS/Mach and OS/NT .nibs are starting to diverge already (with good reason :-). So I may be able to work around the problem by segregating the project somewhat. Still, though, I'd rather it Just Worked. Thanks, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 12:03:45 -0500 Organization: Atria Software Message-ID: <maury-2101971203450001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> In article <5c1358$k5v$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > If you're developing GUI apps, you can already completely ignore the Unix API > and tools. Openstep offers enough OS abstraction that you should be able to > do any GUI app without touching Unix _if_you_want_to_. And that should be > completely cross platform. Good so far. > So, it's no more easier on the programmers nor more cross platform supporting > to rip out the Unix tools/layer. But the code that does call it is indeed not cross platform. Whereas if the same code was provided in standard libraries it would be. Which portion do you not understand: a) it's easier to have API's than use streams? b) if you're in an OOPS paradigm you'd like to stay there? c) if you use system() you're not cross platform? d) shared libs run in the application's space, thus requiring less demands of the OS to be nicely MT? I mean, what is so terribly difficult to grasp about any of these points? > Compared to everything else in > Openstep/Mach, the unix things like /bin, etc, are rather small. Ripping > them out wont get you much in the way of disk space nor anything else, and it > will only cost you in functionality and flexability. No one has _ever_ advocated their complete removal. The other posts and my own have suggested making OOPS based versions of the same thing. I have mentioned this in every letter I've posted for the last three days, how can everyone continue to miss this point? > Now, if you as a programmer WANT to use the Unix tools, why shouldn't you be > allowed to? Sure, knowing full well what the issues are. And as a programmer, if you want to avoid the problems, shouldn't you be able to? Yes? Then why can't you now without having to write all the code yourself? > (just like "if you as a user WANT to use the unix CLI and tools, why > shouldn't you be allowed to?") It is dubious at best to assert that someone > should be FORCED to write to any API, or limited to any set of user tools, > solely for religious reasons (even if the chosen tools are better.. users and > programmers have the right to choose). What religious reasons? Can you point to them? What is "religious" about wanting to stay in an OOPS paradigm? Or wanting to have the features of the Unix utilities in a cross platform form? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:57:14 -0500 Organization: Atria Software Message-ID: <maury-2101971157140001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c16dv$586@dismay.ucs.indiana.edu> In article <5c16dv$586@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >a) easier on the programmers > >b) more cross platform > > I don't understand this. How could it be more cross-platform by removing > compatibility with one of two major platforms outside the MacOS? Because none of the other platforms have the same utilities installed by default? Quick, where is find on my NT box? > As for easier on the programmers, I think Be has the right idea. It's > POSIX-compliant (or nearly so) for compatibility reasons, but once > developers start programming the Be way, they don't want to keep using the > POSIX way. Unix compatibility has nothing to do with making it easy to > program. I agree, but something that's OOPS all the way is easier than something that's 1/2 and 1/2 wouldn't you say? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 12:09:42 -0500 Organization: Atria Software Message-ID: <maury-2101971209420001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <maury-2001971529140001@199.166.204.230> <5c1cb7$nhr@duke.squonk.net> In article <5c1cb7$nhr@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > Uh, and how is that different from a standard system library? It's OOPS based, has a self-published interface, is cross platform, runs in the application rather than needing to be forked. That's how. > The fact that you'll break up one "standard system library" into > many "small" shared libs? Well, unix already has several standard > libs, and it's the collection which is considered the "standard > system library". It is not a single file. Here I am wondering how you came to this conclusion. > /usr/lib. The difference does not seem all that profound to me. Asside from the fact that it would say "InputSproket shared library" rather than "grep"? Or that programs could call them directly rather than forking? Or that they would have OOPS interfaces? > (note that if you install the "small libs" in the separate folders > of various applications, then those libs are no longer "shared"...) Only if your OS doesn't support it. That's an argument for registering them. Maury
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: Allow other apps in front duing modal session? Date: 21 Jan 97 01:33:22 GMT Organization: University of Massachusetts, Amherst Message-ID: <32e41ce2.0@192.33.12.30> Thanks to those who responded to my previous post -- a modal session turns out to be just the thing I needed. My only peeve is that I can't use other apps while the modal session is running. Actually, I can click on them and send events to them, but I can't get the windows from another app to the front of the screen. Due to the nature of of 'modal', I suspect that there is nothing I can do -- if there is, please tell me about it! Thanks! -- -jon klein jklein@freon.artificial.com Caper will do it for me.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 12:12:03 -0500 Organization: Atria Software Message-ID: <maury-2101971212030001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bonbb$6r4@news.internetmci.com> <maury-2001971507310001@199.166.204.230> <5c0lgn$r2b@csugrad.cs.vt.edu> <maury-2001971738220001@199.166.204.230> <5c1d0j$nhr@duke.squonk.net> In article <5c1d0j$nhr@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > Of course, they don't need it with WindowsNT because WindowsNT > already has those facilities implemented. Really? I don't seem to have a /bin on my NT system. Nor grep. So exactly how does NT include all of the Unix shell utilities again? What, you mean with API's? > throw out the Unix layer Why would they do that? Who's asking them too? Maury
From: andy@amtmtc.demon.co.uk (Andy Templeman) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 17:42:58 +0000 Organization: Not Known Message-ID: <199701211742586676963@amtmtc.demon.co.uk> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: > Because you need the shell and the utils in order for the operating > system to boot in a flexible way that can be maintained by a system > administrator. Macs have traditionally been touted as systems where you don't need a system administrator. A lot of home users are not C.S. savvy and want the new system to be as simple to install and administer as system 7 is, with the advantages that a protected & pre-emptive system can give. -- ................................................................. "Come Here! You've got my tankard" - Poldark on Mopeds .................................................................
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 21 Jan 1997 16:08:58 GMT Organization: The University of Iowa Message-ID: <5c2pmq$fec@flood.weeg.uiowa.edu> References: <5c0ivv$7e4@gaea.titan.org> From article <5c0ivv$7e4@gaea.titan.org>, by toon@gaea.titan.org (Greg Titus): > Michael Hudson <sorry.no.email@nowhere.com> writes: > >>I have just read in excess of twenty posts about "Multiple Inheritance >>(Re: NextStep & Mac Frameworks)" that discussed the relative merits of >>Objective-C and C++. > >>Does Objective-C have templates? > > Nope. Don't need 'em. Templates are a hack to get around the limitations in > C++'s strong binding. When you want to manipulate objects in a generic way in > Objective-C you just declare your arguments as "id" (any object), and the > same method works for everything instead of the compiler making multiple > copies of the code for every type of object you might use. This is completely wrong. Templates support type-safe containers and are about the farthest thing from a hack. In most languages, you cannot create an array type, or any container with similar properties, yourself. You can create rough approximations but nothing with the same expressive power as a built-in array type. In C++, you can achieve the generic array mechanism above by defining an array "class" of void * and casting where necessary. > >>While we're about it, are the following features present, absent or >>irrelevant? (I'm not implying that I couldn't live without them all; I'm >>just curious) > >>Exceptions > > Yep. Wrapped in objects, even. Get passed back across Distributed Objects > connections, even. Of course this could be done for any language via macros or other non- standard extensions. The beauty of standardized exceptions, whether in C++, Java, or Standard ML, is that they are well-defined in the context of other language features, libraries, and compiler error reporting and optimizations. >>Function overloading >>User defined type conversions > > Nope. These lose a lot of their utility when type isn't so important, as in > C++. This is not true either, as I think any Prolog programmer would tell you. Overloading is simply giving the same name to different realizations of the same logical construct, allowing the programmer to tailor routines to specific cases while maintaining overall conceptual clarity. With overloading, you remember the logical part (e.g., "Draw()") and the compiler selects the routine. This is not much different than overriding a method. User-defined conversions give you the ability to define what the compiler already does for the built-in types. If I define a Fraction type, I would like to define conversions from integers, etc, >>I apologise if I'm being uncultured, but C++ is my only language. > > C++ and Objective-C can be used together, also - even mixed into the same > file, and compiled with the -ObjC++ flag, which supports the superset of > the two languages syntax. This is probably not part of the language definition of Objective-C, but a particular implementation. There is no guaranteed that every compiler vendor can or will provide such features. -mc
Date: Tue, 21 Jan 1997 13:04:10 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Distribution: world Subject: Re: NextStep & Mac Frameworks Message-ID: <milkweed-2101971304100001@port1.chester.smallmedia.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> Organization: Milkweed Software In article <ENGELHART.M-2101971010080001@17.128.202.195>, ENGELHART.M@applelink.apple.com (Michael Engelhart) wrote: > > What gets me is how, if all these super-neat features like this that the > > Obj-C guys keep casually throwing out really do exist as described, why on > > earth did the universe at large adopt C++ instead? > > Same reason the universe at large bought into Microsoft Windows... :-) This is simplistic enough to be downright wrong. The succes of C++ is not due to better marketing, nor market leverage, nor due to a bad business decision by IBM, nor due to lower cost of software or platform/hardware than the competition, etc. Skip this lengthy defense of C++ if you like, but you might be interested in why someone like me still uses it. C++ made it largely on its own merits. C++ made good sense in the context of the evolution of computer languages and still has more life than many give credit for. It is still evolving with better environments, compilers, and linkers and debugging that provide for integrated development, sophisticated warnings/error detection, global analysis and other features that answer many of the criticisms leveled against it. Because C++ has a very low runtime overhead and is easily extensible (_cheaply_ extensible), it can still have a vital role in software development. It can extended with little effort to provide runtime type checking and assertion, and many other features that more modern languages boast. Although it lacks runtime binding, there are advantages in using a language neutral binding interface. One of the most common criticisms is that it is too large (linguistic bloat). But awareness of good programming practices keeps one using a restrictive, safe subset of the language. The only really dire problem, in practice, in my opinion, is lack of transparent garbage collection (made very difficult to implement by the allowance for pointer arithmetic). I have read (and greatly enjoyed) Joyner's 3rd edition of "A Critique of C++", and did not find a single inaccurate statement in it. If I were starting a new project on a platform that had very strong support for Eiffel, that would be my choice of language. I would love to get rid of header files, have assertion and other runtime debugging integrated into my language. I really aprreciate all of Eiffel's qualitues. But Obj-C and Java (so far) have far too many limitations for the sort of development I do. Joyner's critique suffers certain flaws in assumption, however. No weight is assigned to the practical likelyhood of individual flaws actually impacting on a software development project. A year or so ago I completed a term as lead programmer for a 9+ programmer-year project (whose product I am now maintaining), and would like to make the following observations. I have managed projects in Pascal and Object Pascal with similar experiences (perhaps I am a lousy manager!!!). I would list the relative importance of the factors that complicated our project as follows. 1. Poor code organization and structure (including poor encapsulation, naming, lack of documentation, etc.). I am refering here maintenence difficulties that result from bad judgements and habits of less experienced programmers in implementing code internal to their own modules. This could have been alleviated by consistent code review and "micro-management" but in our case that very likely would have cost more than did the resulting maintenence headaches. I have heard said that good code organization is easier with say Obj-C, but lets face it folks, here the burden is mostly on the programmer. Even in Eiffel it is up to the coder to make good use of require and ensure, to use good names, and clear language in the "is" clause, and to make correct encapsulation decisions. 2. Changes to (advances in) and bugs in target OS and development environment. Well, look, I suppose we could have targeted a more boring platform and used a stagnant development environment. This factor can be managed by (when possible) postponing upgrades until major product releases, and avoiding beta quality tools. But sometimes (as was the case in our project when Metrowerks appeared) the advantages of upgrading outweigh the costs. We spent alot of time porting stuff first to Object Master, then to Metrowerks, and through one upgrade of MacApp (now a second after the product release). But C++ was and still is the best supported language for our target. We would have sufferd more using viable alternatives (and VisualBasic, etc., were not viable). 3. Training. C++ is harder to learn than most alternatives. However, learning new or changed OS and development environment has been _far_ more coslty to us (all the team members had experience with C, most with C++). I personally have never had any trouble adjusting to a new language (in every case I can think of at this moment, I have used a language "feature" of a new language as a programming "technique" in a previous language). Good code design is hard to teach, but I have found that C++ does not get in the way. 4. Memory managment related errors. I isolate this factor from other types of bugs because of its severity, and the difficulty of detection. This was not nearly as bad a problem as it could have been because we made exhaustive use of assertion. But it was certainly a significant factor, especially when code was modified by a person other than the author and who incorrectly understood the "contract" or intended purpose/parameter requirements of a method. Thus this could have been alleviated by better code organization, mentioned above. There are lots of instances where pointer arithmetic makes for both readable and efficient code, although I admit this amounts to only slight justification for lack of garbage collection. 5. All other factors mentioned in Joyner's critique. We had no problem avoiding the sorts of ambiguities Joyner complains about. We didn't even have to discuss them. It took us all of a few minutes to implement tools for assertion, and MacApp provided other tools for runtime error detection. Some of the critiques have been made obsolete by new compilers and linkers. Maintaining header files was boring but not very time consuming. Etc., etc. Conclusion. So here is my point. Most the "linguistic" advantages of other languages over C++ are _small_ compared to other factors active in the business of software development. With the one exception of garbage collection, I think Joyner's (and other's) critiques, though correct, are alarmist and exagerated in importance; I agree with Stroustrup, that the flaws of C++ are acceptable. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Date: Tue, 21 Jan 1997 10:34:28 -0500 Organization: Atria Software Message-ID: <maury-2101971034290001@199.166.204.230> References: <petrichE3Ct2r.3AJ@netcom.com> <maury <maury-1401 <maury-1601971527030001@199.166.204.230> <5bsj1f$llh@csugrad.cs.vt.edu> In article <5bsj1f$llh@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Because (you see this coming) the forked-file concept sucks and app > wrappers are better. :) I don't see how. It appears that when it comes to being able to be represented on multiple machines, Mach-o is indeed better. The fact that features made it into wrappers that didn't make it into Mach-o doesn't mean it should be that way. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 13:21:27 -0500 Organization: Atria Software Message-ID: <maury-2101971321270001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <32E4DF05.7E8F@exnext.com> In article <32E4DF05.7E8F@exnext.com>, jon@exnext.com wrote: > No, it's really not. Apple needs to increase marketshare. Thus, it needs > to sell to people who currently would run Solaris, NT, or linux. Apple already has a Unix to sell to these people. No one's buying it. Selling another Unix doesn't seem to help them any, unless you have an argument on why that I haven't seen. > And why is Unix's market share not growing? Because it doesn't > have the general-purpose apps or ease-of use of, say, Windows NT. > Rhapsody should provide both of these things. I agree, and again am left wondering how the hard to use Unix utilities figure into your argument. It would appear to me that a Unix with these replaced would do even better, no? > I also have to wonder what the Unix share would look like if > Linux was included. From what I've seen in InformationWeek (I think, I was in Ireland at the time), about 1% of the market is Linux. > > Oh yeah, and NeXT's superior technology will help a lot here. Just look > > at how successful it was when they sold machines running it. > > This isn't about NeXT. This is about Apple, and the fact that Apple > is losing marketshare. And it's about NeXT, because that's what Apple bought. NeXT was the better Unix, and it didn't sell. Why should hosting it on the PMac do any better? > Apple's current Unix offerings are AIX. Which suffers from the same > problems as other plain Unixes: no mass-market software, poor > ease-of-use. And yet those other Unixen outsell it considerably. Although I agree completely that the NeXT version is better than all of these put together my point remains: Apple will not increase market share _because_ they have a Unix. > Yeah. I know of two macs. They're sitting in a closet in Connecticut. > But are Mac owners replacing their old Macs with new Macs, or PCs? It > seems like the answer is PC's. Depends on who you read, but many (no, not most) people that are buying Macs are buying their first Mac. This is not true of the industry in general, where something to the effect of 90% (could be 80%) of Win purchases are replacing current machines. > The point is that it may seem like very few people want Unix. But > very few people want Macs. The Unix market may be small, but Apple > cannot afford to turn away anything that could increase their > marketshare. > When you've only got 6%, even a .5% increase is worthwhile. Well I would agree with that for sure, but it would appear to me the other 80% would be even better to go after. > And if Apple doesn't grab that market, Microsoft will. I think they already did. > Webservers: It'd be a lot easier to recompile a webserver and other > related tools if the Unix environment hasn't been mangled. I don't think this will mangle it at all. Quite the opposite in some cases. If you want the shell utilities, click Custom Install, click "Unix utilities". End of issue. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: Tue, 21 Jan 1997 10:47:10 -0500 Organization: Atria Software Message-ID: <maury-2101971047110001@199.166.204.230> References: <5bq73r$e18$1@solaris.cc.vt.edu> <antispam-2001971935190001@farrca.apple.com> In article <antispam-2001971935190001@farrca.apple.com>, antispam@apple.com (Cary Farrier (farrier@apple.com)) wrote: > Yep. We're looking into the technical aspects right now. > > -> Cary Not too sound too crazy or anything, but can you get a 68k version of InputSprocket out first? Maury
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 14 Jan 1997 20:57:00 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5bgrus$nkc$1@brachio.zrz.TU-Berlin.DE> References: <maury-1401971143490001@199.166.204.230> In article <maury-1401971143490001@199.166.204.230> maury@softarc.com (Maury Markowitz) writes: > In article <5b6dno$goj@news.next.com>, Eren_Kotan@next.com wrote: > > > id myArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", nil]; > > I'm curious, why the NSxxx class names? I know the historical context, > but is this important today? Seems somewhat unpleasing to the eye. Really just a convention so different class libraries can be intermixed without having to extend the language. Also an important reminder/warning: this is NeXT's idea of what an array behaves like, not the-ultimate-class-that-forever-defines-what- an-array-is.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:09:41 -0500 Organization: Atria Software Message-ID: <maury-2101971109420001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> In article <Qmt04oO00iV0M52u8d@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Apparently not, because you are arguing that we should not reuse the > preexisting code available in the form of the Unix utilities, and should > instead write APIs and an implementation in the C system library for all > of those utilities. That is the opposite of "code reuse"! Until you add in the words "OpenStep on NT". Once that's included it's clear that modern code indeed offers considerably better chances for code reuse than the current shell utilities. > The point is, regardless of what it's called or whether it's just one or > several libraries-- there is no point at all of creating tens of > thousands of system calls to replace the Unix command line utilities There are "tens of thousands" of command line utilities? And there's lots of reasons to do this. > unless that mammoth API is available on all of the hardware/operating This "mammoth" API is exactly as large as the current one. In fact, good design would allow it to be much smaller in fact (combine content and directory searching operations inside a single query object for instance). However, unlike the current API, it's language neutral, platform neutral, OOPS based and publishes its own interface. It also would allow for direct calls to the API using objects so you don't have to flatten your objects, and will pass back data or exceptions in the same way. Really now, the advantages are both obvious and huge. If they weren't, why did they create OpenStep in the first place? > system combinations that you're replacing the Unix CLI utilities, > otherwise programmers won't be able to depend on all of the API being > available, which would make it far less useful. The _current_ code is not available on all platforms, OpenStep for NT for instance. This not only makes this argument moot, but provides even more ammo for replacing it. > Besides which, why don't you try to estimate the number of > developer-years such a task would require? Two? Which utility in particular do you think is hard to recreate? > Sure it is. In fact, that's one of the reasons why OpenStep is pretty cool. > > > Code reuse: it's a good idea. > > Again, writing a new library which provides functionality already > implemented by Unix command-line tools is the precise opposite of code > reuse. Only if you consider the case when you're running on Unix. This is not the only case. Maury
From: Michael Taylor <mtaylor@aw.sgi.com> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 14:05:07 -0500 Organization: Alias|Wavefront Message-ID: <32E51363.2C67@aw.sgi.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <199701211742586676963@amtmtc.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > Macs have traditionally been touted as systems where you don't need a > system administrator. A lot of home users are not C.S. savvy and want > the new system to be as simple to install and administer as system 7 is, > with the advantages that a protected & pre-emptive system can give. > Sure, if you've got one Mac or half a dozen macs, then you don't need a system administrator. If you've got a network of a hundred macs, you will need a system administrator. Administrating 100 Macs and keeping them all up to date with recent software would be a difficult assignment. Unix is build to give a professional administrator the tools they need to efficiently maintain large networks. Apple has a chance to crack the enterprise computing market. Unix traditionally has done well in these markets despite having less software and worse user interface libraries. When Joe User calls you and tells you he can't run program X on his machine, it's a lot more efficient to log in remotely, retarget the display, and start testing than it is to pack up your manuals and start hunting for his desk. No to mention the advantage of not having to boot Joe off of his computer while you fix it. These are the sort of things that are taken for granted in the Unix community. I would assert the following: - one Mac is much easier to administrate than one Unix box - 100 Unix boxes are much easier to administrate than 100 Macs With better UI tools and more Unix hiding, the first statement should not necessarily hold for the next gen mac systems. /\/\ike -- /\/\ike Taylor | Mail: mtaylor@aw.sgi.com Alias|Wavefront Toronto | Voice: (416) 362-8558 x8740 Developer, API Team =D--' http://reality.sgi.com/mtaylor
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 21 Jan 1997 19:06:30 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c343m$1ko@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : raph@porter.as.utexas.edu (William Raphael Hix) wrote: : : Umm, Unix is important for people who want to run servers, you know. : There is a lot of server-related software out there for Unix. A lot of : it won't work if you throw out random utilities that are generally : assumed to exist on a Unix platform. Do you want to see Rhapsody have : an impact in the corporate environment? Not everyone is a home user. Is Unix important to people who want to run servers? Or is a protected memory, pre-emptively multitasking modern OS with a high performance file system what they want. Yes, until recently this meant Unix, but does it need to. I'd say the growth of Win NT indicates that not all people who run servers want Unix. There might be a better way. : (And remember, Unix is the only thing that currently competes with : Windows NT. Just being able to say that their operating system is Unix : gets Apple's foot in the door with the corporate types, most of whom : regard the Mac as a toy when it comes to high-end servers.) Getting into the high end server market against such established companies as Sun, HP, and DEC plus Win NT is even harder than shoring up Apple's strengths. Is another version of Unix the best way to go? Is servers the best place to get a foothold in the enterprise market? It is the part of enterprise furthest from Apple-NeXT's current strengths? I don't think that servers are the right entry for Apple. Content and application development build better on the existing strengths. But the important question is what Apple thinks? We'll see in a year, when the user releases of Rhapsody start. : > What about find? Should Apple leave the Unix find when we know they're : > going to include their new V-Twin search engine and Find File. Well, the : > V-Twin certainly replaces find if you are a GUI user, but what about CLI and : > scripts? Will Apple leave find for the 1% of users who might want to : > use their Mac like a Unix box? : : Why not? All these Unix utilities don't take up much space. Crippling : a Unix system isn't worth the effort. The _only_ consideration is : whether the existence of these utilities will hurt developers with : similar products, and I don't think that this is a serious problem. I : doubt 'find' is going to replace V-Twin for desktop use, but there are : plenty of sysadmins and shell scripts who use it. But the developer consideration is important to Apple. How important is unclear, but Apple has said that developer support will be critical to Rhapsody's success. What will they sacrifice in order to get developer support? If the question is supporting current Mac developers or Unix developers, the choice is clear. Hopefully they can find a compromise which satisfy both. Again, we'll know in a year. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:32:51 -0500 Organization: Atria Software Message-ID: <maury-2101971132510001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <maury-2001971526200001@199.166.204.230> <32E404D1.24FA@concentric.net> In article <32E404D1.24FA@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: > > > MailTool > > > sendMessage: 'This is the contents of the message.' > > > withSubject: 'My Subject' > > > to: '<cs4w@andrew.cmu.edu' > > > > One must assume the existence of an object storing much of this data > > even in the Unix case. Thus the line would become something to the effect > > of... > > > > myMessage.send; > > Your comment leaves me baffled. I fail to understand your point. Perhaps > you could elaborate? Certainly, but it's basically "what you said", although I used some pseudo-OOPS there. If you're writing a real application under OpenStep, you pretty much have to assume that you've created an object for storing up the components of the message you want to send. So instead of placing strings in the call as you did in your example, I assume that these had already been placed in fields in some object that inherited code from a Mail API in a shared library. MAPI is a good example of a non-OOPS version of what I'm referring too. This being the case, the call I illustrated would likely be closer to the truth, you'd build the object at various prior stages of the code, and once complete, simply call it's send method. Maury
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 11:38:58 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5c360i$gvq@crl.crl.com> References: <5ami95$ol3@news.tuwien.ac.at> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> In article <AF09658696681B35E3@travis.tfs.net>, Travis Butler <tbutler@tfs.net> wrote: >>If Apple wants the new OS to be a useful Unix platform >>(and they should) > >Here is the main point where you and I part company. I don't *want* the new >OS to be a 'useful Unix platform' if it comes at the expense of the Mac's >ease of use. I didn't buy a Unix box; I bought a Mac. If I'd wanted to buy >a Unix box, I could have plunked down less cash than I spent on my Mac and >bought a cheap Intel box running linux/X. I bought a Mac because I *wanted* >a Mac, not a Unix box. There are two mostly disjoint sets of people that can be addressed by Rhapsody: server people and friendly client people. Unix is very good at the server side of things--you can grab Apache or NCSA web servers, run mail gateways, serve up filesystems, and so on. The existing Openstep implementation is very good at being a friendly client that shields people from having to know anything about Unix. Because it's good at one doesn't mean it has to be bad at the other. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:46:00 -0500 Organization: Atria Software Message-ID: <maury-2101971146000001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> In article <AF09658696681B35E3@travis.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: > If you could make Unix functionality a part of the new OS without *forcing* > users to deal with these things, so they wouldn't need to see or use them > unless they really *wanted* to, then I wouldn't mind. But what I saw of > NeXTstep a few years ago didn't work that way, and the comments I've seen > here suggest that it hasn't changed in this respect. Worse, when you suggest that you don't want to run all these great shell utilities, they simply can't figure out why not. > Sorry, I'm starting to ramble here. My point is: Should you complicate or > burden the user experience of 95% of the user base to benefit the 5% that > actually make use of the Unix power features? I think that's a mighty poor > tradeoff for a general-purpose OS. Hear hear. > Let me turn the question around: Should Joe Average User have to wade > through Unix arcanum just to use the computer, when he doesn't know or care > what 1/4 of the things mean, let alone how to use them -- just so that the > small percentage of Unix gurus can easily run install scripts? Distributed costs... Distributed costs... Distributed costs... > I'll say it again... the vast majority of Rhapsody users will be *current > Mac users*, NOT Unix users. In fact, the vast majority won't even be NeXT users. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 11:55:54 -0500 Organization: Atria Software Message-ID: <maury-2101971155550001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> In article <Emt1MN_00iV0052vBl@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Because the two issues are unrelated? They are _identical_. > Well, if you want to scatter your applications around even though it > makes your computer less functional and harder for other people to use, > you can. Good, then let me. You are actually advocating that YOUR setup is better for me than MY setup? I would never say that to you, so why should I use an OS that enforces it? > I don't see why anyone would want to make their computer > harder to use, but then, that's just my preference for thinking > rationally showing through.... Oh, it's terribly rational for the computer to dictate where the user places files, rather than the other way around. You must use some other definition of "rational". > No, it's not, although I am unsurprised to discover that a Mac advocate > has not had exposure to large computer networks administered by an > organization. I've RUN large networks administered by an organization. > For example, CMU has hundreds of Macs in the clusters > with a very consistent filesystem layout. Bully for them. I believe you'll find that your experiences in university and the commercial world will be largely different. > Most Mac users here like the idea, so they generally arrange their > computers in similar ways to the cluster machines What cluster machines? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 12:05:46 -0500 Organization: Atria Software Message-ID: <maury-2101971205460001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <maury-2001971527440001@199.166.204.230> <5c17j7$1e44@ds2.acs.ucalgary.ca> In article <5c17j7$1e44@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca (Blake Stone) wrote: > Everybody agrees that a standard mail API would be nice. The > point is not that it wouldn't be useful the point is that THERE > ISN'T ONE. That's the problem, problems should be fixed. Complaining that there's no API doesn't help anyone. > Has anyone said it's impossible? The key points are: > > * They all EXIST in the form of CLI utilities > * It would be POSSIBLE to write them in API form I think we all agree on this? > Apple has 6 months to get a developer's release out. In that > time do you honestly believe they're going to design, write, > test, and document an API to replace all of UNIX's command line > functionality? Can you find a single post in which I advocated this? > I would love to see a brilliant OO API for every conceivable > need, but I'm not holding my breath waiting for it to happen. And as long as everyone shares this opinion, it will never get better. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 12:18:36 -0500 Organization: Atria Software Message-ID: <maury-2101971218370001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <SHESS.97Jan21090558@howard.one.net> In article <SHESS.97Jan21090558@howard.one.net>, shess@one.net (Scott Hess) wrote: > 2) The Unix tools are (quite frankly) not nearly well enough rounded > to be made into a generalized library. Thank you. > The first two points mean that a generalized, well-designed set of OOP > libraries implementing the same set of functionality as a particular > set of Unix command-line utilities will take 2-4 times the effort to > develop. My experience indicates that that is a _conservative_ > estimate. The effort required is likely to be open-ended. So for this reason we should live with the status quo and not even bother? Sorry, this doesn't strike me as a particularly strong argument. > The third point means that we only have a small subset of the possible > programmers who would have any incentive to work on the problem. > Since these OOP libraries won't as easily portable outside of MythOS, > anyone not on that platform won't have incentive to work on them. There's no reason why such libraries cannot be far more portable than you suggest here. Most modern library systems can not only support multiple languages, but multiple platforms and both OOPS and functional interfaces all at the same time. > So, we have perhaps 10% of the man-hours applied to a problem that 3x > harder than it needs to be. It's _very_ unlikely that this is going > to happen. I agree, but this again doesn't mean that it _shouldn't_ happen. > Each specific operation I've done in Unix probably would be slicker if > it had a GUI counterpart. On the other hand, any package which had > that many functions would be impossible to understand Ummm, you can wrap your head around the collection of Unix utilties but not the same collection re-implemented? Take the simple case, a 1:1 library. Now explain how this is any harder to understand than the current solution. > [In practice: A GUI grep-like program would be useful to many people. > A GUI program to find all *.h files which contain the phrase "Public > Interface" and then use their path relative to a given absolute as a > basis to create a symlink in another directory is probably _not_ going > to happen. Partially, this is because such a program would require so > much flexibility that it will probably require a scripting language, > at which point it might as well be a shell script, or even a "lambda" > version (a single command-line tied together with pipes).] I would recommend that you look at some of the OOPS database engines before stating this so strongly. I've seen quite a few generalized query objects, including one based in SOM for OpenDoc for instance. Not only is it possible, it's been done. And it's been done in a market that doesn't even really exist yet. Maury
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 21 Jan 1997 20:22:42 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c38ii$5ol@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> Jonathan W. Hendry (jon@exnext.com) wrote: : : Actually, Apple should let all those people who want Unix hang. Who : cares if they buy Solaris, or Windows NT, or run linux on a cheap : Pentium? Who needs em. Obviously Apple wants as many new customers as they can get, but that takes time. For Apple to survive they need to enhance their current strenghs and then reach out to new areas. Protected memory, pre-emptive multitasking, and a high performance file system are important to all high performance computing tasks, content and application development, data and image processing. Unix compatibility is much less important. Apple will need to consider the trade offs and make a decision based on where it wants to compete. : Apple doesn't need new markets, right? Their current markets are doing : *just fine*. They're doing just fine on their own. Selling to them home : users, schools, and artists. : : Oh, that's right. Apple's marketshare is dwindling. Apple's : traditional markets are moving to Windows. Schools, homes, graphics : professionals. Evidently, Apple must not be selling what people want : anymore. Apple isn't even holding on to their *current* customers. : I think Apple should spend some time to find out exactly what : users want. *Not* current Mac users. Former Mac users. Mac users : who have left the Mac for NT, Solaris, Linux, IRIX, whatever. : Obviously, Apple can't grow their marketshare selling to current : Mac owners. Apple has to design Rhapsody for former Mac owners. : Then they have to make it clear that Rhapsody is what they really : wanted, and that they should come back. An Intel port of Rhapsody : would make this easier. Most of Apple's losses are to Win95 and, to a lesser extent, Win NT, users who have demonstrated little interest in Unix compatibility. Even when Apple had a Unix, A-UX, it drew little support outside of academia. Apple needs to compete against Microsoft and this requires little Unix compatibility. As a workstation user, I'd love to see Rhapsody have as much Unix compatibility as possible. I'm not sure Apple will agree with me. : Let's see. Apple has about 6% marketshare. If Apple can successfully : sell to the 1% of users who want Unix, that would give Apple 7% : marketshare. A 16% increase in Mac marketshare. Furthermore, it's : an increase, which Apple hasn't seen in many moons. Exactly what percentage of users do you think want Unix compatibility? I don't mean the features of a modern OS, I mean make and rm and the contents of /usr? All told they probably make up 1-2% of the marketplace. What is the current marketshare of Sun, DEC and HP's Unix offerings. Admittedly this is the financial plum of the marketplace, but a small portion. Do you expect Apple to be able to quickly grab a majority share against Sun, HP, and DEC, not to mention Win NT? You sure have high expectations for Rhapsody. Hopefully Apple will meet them. : If Apple can grab back the graphics professionals who are using : NT, they could probably add another .5%. If Apple can grab : webserver marketshare from WinNT, that might account for another : .5%. (This would likely be easier if Apple shipped Rhapsody : on Intel). That'd increase Mac marketshare by another 1%. Apple's market share was once 10%, without the Unix or webserver folks. Why can't they be that now without them? The fastest growing part of the market is the home where Apple's much better represented than average. Do you really think that battling it out with Sun, HP and DEC is the way to keep Apple alive? Are we just going to concede the vast majority of the market to Microsoft? Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: Tue, 21 Jan 1997 12:21:53 -0500 Organization: Atria Software Message-ID: <maury-2101971221530001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> <4msyuOu00iV0M52s5o@andrew.cmu.edu> In article <4msyuOu00iV0M52s5o@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > I believe it is unfeasible to write sensible API's for every conceivable > Unix utility and to replace all of the expressive power of the shell. No one's talking about ridding ourselves of the shell as far as I can see. It would be that the shell is calling this libraries too. Before you say _that's_ infeasible, it's already running today in the form of MacPERL, which is OSA based and calls API directly out of the programs. So it's not only possible, but done for a shareware application no less. > There are roughly 1200 executables in my path; about 100 or so are > already available as functions via the BSD 4.3 system call API, which > leaves over a thousand left. Whereas the Mac OS probably already contains several thousand API calls. Again this is no argument as far as I can see. > I have no objection to people writing a good OO API to encapsulate the > functionality currently provided by popular tools like grep and find-- I > think it's a good idea. But people seem to think that simply providing > such an API means that the /bin/grep and /bin/find utilities aren't > needed anymore, and that claim makes no sense, for reasons that I've > explained in other articles. It doesn't mean they wouldn't be needed any more, the shell would simply call the new ones too. Maury
From: chafi@aol.com (Chafi) Newsgroups: comp.sys.next.programmer Subject: Immediate Openings for NextStep Programmer. Date: 21 Jan 1997 20:41:57 GMT Organization: AOL http://www.aol.com Message-ID: <19970121204101.PAA26927@ladder01.news.aol.com> Hello We are currently looking for programers (three positions available) with excellent Nextstep background for a major telecom corporation located in IOWA. Long term contract positions, Salary and benifits as per experience. Contact: Amar Vakil or Stan Menezes (312) 930 9000 Send resumes on (312) 930 0510 E-mail : apsi@ix.netcom.com 01/21/97
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 21 Jan 1997 21:17:24 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c3bp4$8s3@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0ptj$cvm@ds2.acs.ucalgary.ca> Blake Stone (bstone@acs3.acs.ucalgary.ca) wrote: : William Raphael Hix (raph@porter.as.utexas.edu) wrote: : Lastly, as you point out, these are both extreme cases and not : representative of the general case. Generalizing from extremes : does not tend to yield anything of value. For example, it would : be pointless to try to educate a person who already knows : everything, and equally pointless to try to educate a person who : cannot learn anything. Does this prove that education is : pointless? It is particularly difficult to argue from extremes when they aren't really opposites. A person who can not learn is not equivilent to a person who does not know anything. But this logical quibble aside, I did not intend to offer a concrete proof that Apple will ditch Unix compatibility. Instead I'm just trying to offer counter evidence to the assumption that Unix will be there. I hope it is, but Apple's vision for what Rhapsody will be and need to please third party software developers might result in disappointment to the Unix-friendly. : : > Well, how important is Unix compatibility? It's clear from : > this thread that to NeXT users it's essential. : : Only because a UNIX derivative is the underlying operating : system. If you get rid of it, you'll need to replace it with : another real operating system. Any suggestions? Windows NT? : Another UNIX? Or should Apple attempt to develop another : operating system from the ground up while ignoring their : dwindling share of the market? This I think is the compelling reason why much Unix compatibility will remain. It would take Apple time they don't have to rewrite the BSD middle layer which interfaces between OpenStep and the kernal in NeXTStep. But these arguments don't necessarily apply to a lot of Unix system utilities. : > But how much does this matter to the Mac community that Apple : > is pitching Rhapsody to? Would they rather have the system : > take up less space or have Unix compatibility 99% of them would : > never use. : : Replace that with "never knowingly use" and the answer becomes : obvious. 99% percent of the Mac users I know never invoke : NewHandle directly, so why not remove it from the API to save : disk space? If we're talking a few MB out of a system that adds up to 40-50, then you're right. But as the relative size creeps up over 10%, it gets harder to justify putting this in the system of all users. Perhaps they could have a "Unix Utilities" option in the OS installer for us workstation types. Or perhaps, some third party like Intercon will be able to sell us this add-on. : > The feelings of NeXT users (none of whom have compatible : > hardware) ... : > ... are secondary to the 10-100 times larger Mac community. : : Try to avoid making this an Us vs. Them thing. It would be : awfully nice to have a sense of community instead of a raging : war. Of course some NeXT users do not have hardware compatible : with the forthcoming Rhapsody. For that matter, a hell of a lot : of Mac users will not have compatible hardware, either. As much as I'd like for there to be harmony between Mac users (which I am at home) and current NeXT users (who I envy sitting at my Sun at work) the distinction is real because these 2 groups have different interests. How Apple will merge the interests of the techie NeXT users and the interests of the different pieces of its current user base is really what this whole thread is about. Hopefully, they can find a compromise which will make the Mac users happy without disillusioning the NeXT folks. However, at least in the near term, it is the Mac community which is the target of Rhapsody. Will any hardware which currently runs OpenStep run Rhapsody in its initial PPC version? I'm not talking the dream-like Intel compatible possibilities Apple hints at but does not promise, but PPC Rhapsody as it ships in 1998. It is the people who will be able to run Rhapsody in 98-99 for whom Apple will be tailoring the first version of Rhapsody. : The feelings of both are moot compared to the technical realities : of hosting the OPENSTEP API or a derivative thereof in a short : time frame. There is every reason in the world to believe that : the NeXT savvy are more likely to be in tune with these : realities than the Mac savvy, no matter how much larger the : latter group is. For someone who didn't want Us vs. Them, this sounds a little like platform bigotry to me. Markets matter when you want to sell things. As NeXT has shown, the set of NeXT savvy people can not support a major OS vendor, much less a producer of hardware. So Apple's target must be the larger group of users who want a modern OS with the Mac's ease of use and familiarity. Because of the time to market issue, I'd be very surprised if Apple completely removed the BSD middle layer. But the middle layer that Rhapsody ships with could be much more minimal than NeXT folks are accustomed to, without removing anything which will be missed by Apple's target audience. Hopefully it'd be easy to add the missing functionality back for those of us who want it. Of course that is my vision of Apple's target, which is different from most NeXT users, which is different from my mom's. Most importantly, it's probably different from Apple's but we won't know that for a year. : That being said, there sure are a lot of opinions being bandied : about as solid technical facts. Time will tell just exactly : where we're headed, and I'm eagerly awaiting the results. We're all trying to make our visions for the future come true by repeating them as loudly and often as possible. With the 6-12 months we have before there is something concrete to rail against, this is all we can do with our apprehension about the future of our platforms, both Mac and NeXT. Merging the 2 offers many wonderful possibilities, many of which will be disappointed, at least at first. But I think I'm going to like Rhapsody. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 13:24:19 -0500 Organization: Atria Software Message-ID: <maury-2101971324190001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> In article <5c2r53$3i3@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > Umm, this jars a little with the success of Linux... Linux seems to be used on about 1% of the machines in the world according to something I read once. Who knows if it's true, but it's running on one machine at work out of a couple hundred. Maury
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Date: 21 Jan 1997 21:15:58 GMT Organization: The University of Calgary Message-ID: <5c3bme$kbu@ds2.acs.ucalgary.ca> Andy Templeman (andy@amtmtc.demon.co.uk) wrote: > Macs have traditionally been touted as systems where you don't > need a system administrator. A lot of home users are not > C.S. savvy and want the new system to be as simple to install > and administer as system 7 is, with the advantages that a > protected & pre-emptive system can give. An out-of-the-box default installation of NeXTSTEP was fine for home use without needing weaking except when it cam to configuring it for Internet access. I expect that Apple will address the interface shortcomings in that area pronto and make it all as simple as it should be. What was REALLY cool, though, was that an out-of-the-box default installation was also fine for a corporate network. Just turn it on, watch it find the server and ... bingo! Automatically configured network connections, user accounts, shared printers, fax modems, the works. Take it to another location, plug it in, and watch it change personalities without any kind of local administration. Everything gets configured at the server level and is automatically picked up by workstations on the local net. You are going to love NetInfo (at least, when you don't hate it.) We had a zero-administration desktop environment running in our office years ago. A shame we had to rip it out and replace it with a Windows nightmare a year and a half later due to lack of supported office automation tools. I had DOS nightmares for weeks. Literally. I'd close my eyes to go to sleep and it would be waiting for me .... -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.oop.macapp3 Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Tue, 14 Jan 1997 21:59:22 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> In-Reply-To: <milkweed-0901970908220001@port5.chester.smallmedia.com> Excerpts from netnews.comp.sys.next.programmer: 9-Jan-97 Re: Mult. Inh. in Objective.. by Anders Pytte@plainfield. > But the point I wish to raise is that for many programmers (including > myself) choice of language is not as important as programming habits and > code design. My mental model includes ideal implementations of all these > features, and my programming habits act as a sort of "precompiler" into > whatever language I am using. > > In this case, wouldn't it be better if the language I used matched my > mental model exactly? Perhaps, but depends on the costs (they work both > ways). Objective C may require of a project fewer lines of code and no > days housekeeping memory, but then the code object is larger and slower, > which is a significant concern in our case. What it is that you wish to retain from your previously developed code and your familiarity/programming habits? If you want to reuse the portable aspects of C or C++ code that you have around, no problem-- you can use legacy C and C++ code with Obj-C just fine. You really should learn about OOP (things like encapsulation, polymorphism, and inheritance) to take full advantage of the benefits of OPENSTEP's API, etc, but nothing prevents you from writing non-OOP code if that's how you want to solve a problem. As for the size and performance of Obj-C based applications, I would suggest trying it before worrying about problems that most people don't encounter. C++ advocates always seem to imply there is a big tradeoff here, but I cannot recall ever seeing a NEXTSTEP developer (someone who has actually released commercial software) state that the size and performance of Obj-C was a significant problem. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Erik Doernenburg <erik@object-factory.com> Newsgroups: comp.sys.next.programmer Subject: Multiple threads and EOF2 Date: 21 Jan 1997 18:17:22 GMT Organization: Object Factory GmbH (Germany) Message-ID: <5c317i$bes@leonie.object-factory.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi! I am trying to convert a daemon that serves information merged from two databases to multiple clients. All DB access is read only, ie. the clients cannot alter the contents of the databases. This daemon instantiates a controller object for each client and runs each controller in a separate thread. This means, of course, that several database accesses can happen simultaneously. The daemon worked with EOF1x in such a way that new EODatabaseContext/Channel pairs were allocated in each thread and the fetch was performed via the channel's select/fetch methods. In EOF2 I obviously have to create more objects to perform a fetch (eg. an editing context) and I was wondering how much the threads can share. Do I need the whole set of EODatabaseContext, EODatabaseChannel, EOObjectStoreCoordinator and EOEditingContext for each thread, or is it possible that each thread has it's own editing context but these share one object store coordinator? And, if this peer configuration works, could it make use of multiple channels registered with the database context and perform fetches for different editing contexts in parallel? thanks in advance erik -- -------------------------------------------------------------------------- Erik Drnenburg OBJECT FACTORY Gesellschaft fr Informatik und Datenverarbeitung mbH http://www.object-factory.com
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 21 Jan 1997 21:49:29 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c3dl9$ag5@geraldo.cc.utexas.edu> References: <5ami95$ol3@news.tuwien.ac.at> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> <jinx6568-1601971352540001@news.sover.net> <5bsi7l$ecd@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : : The C compiler. Apple could very well leave that out.. wouldn't want : to give people a free alternative.. though I don't think that even the : GNU C compiler with Obj-C extensions will be able to link in CodeWarrior : object files or the OpenStep libraries, so I don't think they would gain : much by leaving it out; it's mostly useful for command-line stuff. And : leaving it out would be a big problem for Unix people, since most Unix : software is distributed in source form only (every Unix system comes : with a C compiler, except for some commercial implementations who have : discovered that they can charge extra for the compiler). And if Unix people were Apple's target for Rhapsody you'd be absolutely right, without cc it'd be almost useless. But Apple's current customer base, and the only people with machines capable of running Rhapsody when it is released, aren't Unix people. Mac users live in a world of shrink wrapped software, and will go to NT before they will compile applications themselves. If Rhapsody should ever need a C compiler as standard equipment, the game is over. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 16:02:01 -0600 Organization: mementech, inc. Message-ID: <32E53CD9.5B7FB1D8@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> <maury-2101971149510001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > c) I think the whole system would work better with shared > libraries rather than forked command line utilties Sure, but what difference does it make if you can't tell that there's a pea under the bottom mattress? This issue is not pressing at all. NeXTstep makes excellent use of shared libraries, and forked CLI utils are rare. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 16:36:30 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E536DE.3BBA@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <32E4DF05.7E8F@exnext.com> <maury-2101971321270001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32E4DF05.7E8F@exnext.com>, jon@exnext.com wrote: > > > No, it's really not. Apple needs to increase marketshare. Thus, it needs > > to sell to people who currently would run Solaris, NT, or linux. > > Apple already has a Unix to sell to these people. No one's buying it. > Selling another Unix doesn't seem to help them any, unless you have an > argument on why that I haven't seen. Apple has a crappy Unix, that doesn't have as nice an interface as NeXTSTEP, doesn't run Mac apps, and is aimed at servers. It's not user-friendly. You cannot compare AIX (or A/UX) to a Unix-based Rhapsody or even to NeXTSTEP. Apple's Unixen have *sucked*. > > And why is Unix's market share not growing? Because it doesn't > > have the general-purpose apps or ease-of use of, say, Windows NT. > > Rhapsody should provide both of these things. > > I agree, and again am left wondering how the hard to use Unix utilities > figure into your argument. It would appear to me that a Unix with these > replaced would do even better, no? No. Some people want these things. If Apple tries to sell some mangled Unix, nobody who wants *Unix* will buy it. A Unix site probably has lots of Unix scripts and utilities they've written and use every day. These would have to be rewritten or modified. Basically, using the new OS would be a giant pain in the ass for Unix users. Thus, the new OS would probably not be taken seriously, and few Unix sites would buy it. > > I also have to wonder what the Unix share would look like if > > Linux was included. > > From what I've seen in InformationWeek (I think, I was in Ireland at the > time), about 1% of the market is Linux. Not bad. About 16% of the Mac market. > > > > Oh yeah, and NeXT's superior technology will help a lot here. Just look > > > at how successful it was when they sold machines running it. > > > > This isn't about NeXT. This is about Apple, and the fact that Apple > > is losing marketshare. > > And it's about NeXT, because that's what Apple bought. NeXT was the > better Unix, and it didn't sell. Why should hosting it on the PMac do any > better? Because it'll run lots and lots of Mac applications that already exist. Because it's got the backing of a company with 1.8 billion in the bank to support it. Because it's no longer a freak OS, but instead has been 'blessed' by a major company in the industry. You might want to think about why NeXTSTEP didn't sell, before trying to apply those conditions to a NeXTSTEP-based MacOS. Most of the reasons NeXTSTEP didn't sell simply won't apply. > > > Apple's current Unix offerings are AIX. Which suffers from the same > > problems as other plain Unixes: no mass-market software, poor > > ease-of-use. > > And yet those other Unixen outsell it considerably. Although I agree > completely that the NeXT version is better than all of these put together > my point remains: Apple will not increase market share _because_ they have > a Unix. I disagree. Apple's Unixen have never been particularly stellar. Apple has never been a Unix company. Their Unix products have never been particularly well supported. Apple selling Unix has been like Yugo selling a luxury car. Radically different from their normal focus. I think Unix buyers knew this - Apple didn't appear to take Unix very seriously. Thus, they were less interested in buying Apple's unix. Why buy unix from someone when you *know* it's not going to be well supported? This has changed, since Unix-centric NeXT engineers are now developing the new OS. I think Unix shops may be more open to a Unix-based product if Apple can demonstrate that they are serious about it. > > Yeah. I know of two macs. They're sitting in a closet in Connecticut. > > But are Mac owners replacing their old Macs with new Macs, or PCs? It > > seems like the answer is PC's. > > Depends on who you read, but many (no, not most) people that are buying > Macs are buying their first Mac. This is not true of the industry in > general, where something to the effect of 90% (could be 80%) of Win > purchases are replacing current machines. > > > The point is that it may seem like very few people want Unix. But > > very few people want Macs. The Unix market may be small, but Apple > > cannot afford to turn away anything that could increase their > > marketshare. > > When you've only got 6%, even a .5% increase is worthwhile. > > Well I would agree with that for sure, but it would appear to me the > other 80% would be even better to go after. For the moment, Unix users are probably an easier target than Windows users. Especially if Apple gets in good with Sun - Sun shops would be able to deploy apps across Sun Solaris boxes and Apple Rhapsody boxes. This would be very nice, especially for shops that have secretaries using Solaris (they exist, I've seen one). The Unix market is probably an easier target because a) Unix vendors are already splintered and weak; b) Apple's chummy with Sun, and Sun would probably prefer to have its customers using Macs than Windows PC's on non-sparc desks. (lest those sparcs get replaced with Pentium Pros or Alphas running NT.) c) Apple could help Sun champion standard Java, which may aid Sun in their efforts against Microsoft's proprietary extensions. d) Microsoft can out-market Apple without breaking a sweat. Rhapsody could also become a nice alternative for small business types who want to run a webserver on Unix, but don't want to use Linux, and can't afford Sparcs. > > And if Apple doesn't grab that market, Microsoft will. > > I think they already did. True, to an extent. I'd bet the ex-Unix users wouldn't mind jumping back to a real Unix. Perhaps taking some other Windows users with them. (This would be much easier if Apple shipped Rhapsody on Intel.) -- Jonathan W. Hendry jon @ exnext . com
Date: Tue, 14 Jan 1997 20:41:04 -0600 From: mark@oaai.com Subject: Re: GX vs. DPS Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer Message-ID: <853295720.26750@dejanews.com> Organization: Deja News Usenet Posting Service References: <AF0120E2-172CB@198.95.246.165> In article <AF0120E2-172CB@198.95.246.165>, "Scott Thompson" <sthompson@macromedia.com> wrote: > If you wish to modify this example to make an argument in the GX vs. DPS > debate let's consider the following scenarios: > > 1. You want to draw the same shape in two different views that have > different magnifications. > > Using GX you have to create and set up the two view ports and establish a > link between the shape and the viewports. Then to do the actual drawing > takes one line of code (GXDrawShape) every time you want to draw the > figure. Drawing in the first view will tesselate the shape and cache off > the tesselated curve so that drawing in the second view is fast. > > To do it using DPS and the framework you have to create the two views and > set them up (just as in the GX space). Then to draw the shape you have to > execute the five lines of code you provided twice. Each time the code > sends values to the DPS interpreter which interprets them, re-tesselates > the curves and redraws them. Well actually if it was important to you to have it work just that extra bit quicker, you'd express the shape as a user path, and register that path with the server under a given name. Then to execute it within different views, you'd simply ask that the server stroke the server-cached path in each of the views. Please folks, if this were a gunfight then everyone would be shooting blanks. Just when you think you've pumped GX / DPS full of holes; lo - it still stands! We've all got a lot of learning to do in coming months. Regards, Mark --- M. Onyschuk and Associates Inc. Software Systems for the U.S. and Canadian Financial Industries. 15 La Rose Ave. Suite 702, Toronto Ontario M9P 1A7 (416)241-3076 -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Tue, 21 Jan 1997 16:10:06 -0600 Organization: mementech, inc. Message-ID: <32E53EBE.1DC04812@screaming.org> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> <maury-2101971146000001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > (Travis Butler) wrote: > > > If you could make Unix functionality a part of the new OS > > without *forcing* users to deal with these things, so they > > wouldn't need to see or use them unless they really *wanted* > > to, then I wouldn't mind. But what I saw of NeXTstep a few > > years ago didn't work that way, and the comments I've seen > > here suggest that it hasn't changed in this respect. > > Worse, when you suggest that you don't want to run all these > great shell utilities, they simply can't figure out why not. Even worse, when you suggest that you can keep UNIX without sacrificing useability, people suggest that the resulting system would still, somehow, be sullied by its presence -- regardless of how invisible it is. Of course, I know that you've never had such thoughts, Maury. I'm talking about other thick individuals. [followups trimmed back to advocacy groups] -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 17:13:01 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <EmtHxhi00iV0Q5bK5h@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c16dv$586@dismay.ucs.indiana.edu> <maury-2101971157140001@199.166.204.230> In-Reply-To: <maury-2101971157140001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> I don't understand this. How could it be more cross-platform by removing >> compatibility with one of two major platforms outside the MacOS? > > Because none of the other platforms have the same utilities installed by > default? Quick, where is find on my NT box? /usr/NextDeveloper/bin/find I believe is the standard location when you have NeXT's development tools installed. Besides, which other platforms are you talking about besides NT? Last time I checked, OpenStep on top of Unix was available for pretty much every hardware platform available nowadays. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: deniseh@nntp.best.com (Denise Howard) Newsgroups: comp.sys.next.programmer Subject: Re: Remote cvs and .nib wrappers Date: 21 Jan 1997 22:34:20 GMT Distribution: comp Message-ID: <5c3g9c$m2n@nntp1.best.com> References: <SHESS.97Jan21112355@slave.one.net> Scott Hess (shess@one.net) wrote: : I've been exploring the remote features of cvs. Unfortunately, it : seems that remote cvs doesn't work in combination with wrappers, so : cvs can't handle .nib files in the repository. Has anyone gotten that : working? Art Isbell (aisbell@cubicsol.com) wrote a couple of items that will help you. I don't have them myself anymore since I no longer use CVS at work, but what they'll do is tar and compress the nib, so that you can then check the result into CVS like any other file. There was a tweak he made to the Makefile.preamble and Makefile.postamble, too, I think. Alternatively, you could look into buying DevMan. We use it every day at Filoli; with >30 developers all chugging on files, it's an absolute necessity for change control! It handles nibs and rtf files without a second thought, too. Denise -- Denise Howard | PROGRAM, tr. v., An activity similar to Mountain View, CA | banging one's head against a wall, but deniseh@best.com | with fewer opportunities for reward. NeXTMail welcome! | http://www.best.com/~deniseh
From: Michael Taylor <mtaylor@aw.sgi.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 17:50:10 -0500 Organization: Alias|Wavefront Message-ID: <32E54822.4DAA@aw.sgi.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <32E4DF05.7E8F@exnext.com> <maury-2101971321270001@199.166.204.230> <32E536DE.3BBA@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > > For the moment, Unix users are probably an easier target than Windows > users. Especially if Apple gets in good with Sun - Sun shops would > be able to deploy apps across Sun Solaris boxes and Apple Rhapsody > boxes. This would be very nice, especially for shops that have > secretaries using Solaris (they exist, I've seen one). > I agree with your nice (or scathing:) summary. It's interesting to note that Sun already owns most of the commercial software that has been written for OpenStep (databases, spreadsheets, word processors, etc.) through their subsidiary Lighthouse Software. see http://www.lighthouse.com The early adopters of Rhapsody will be looking to Lighthouse and Sun for productivity software. Much of this software is pretty cool even if it will lack some of the features of monstrosities such as Microsoft office. Apple and NeXT are both driving hard on hard on Java, which should make Sun happy. /\/\ike -- /\/\ike Taylor | Mail: mtaylor@aw.sgi.com Alias|Wavefront Toronto | Voice: (416) 362-8558 x8740 Developer, API Team =D--' http://reality.sgi.com/mtaylor
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 17:33:21 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E54431.29AA@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <5c38ii$5ol@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > > Jonathan W. Hendry (jon@exnext.com) wrote: > : > : Actually, Apple should let all those people who want Unix hang. Who > : cares if they buy Solaris, or Windows NT, or run linux on a cheap > : Pentium? Who needs em. > Obviously Apple wants as many new customers as they can get, but that > takes time. For Apple to survive they need to enhance their current > strenghs and then reach out to new areas. Protected memory, pre-emptive > multitasking, and a high performance file system are important to > all high performance computing tasks, content and application development, > data and image processing. Unix compatibility is much less important. > Apple will need to consider the trade offs and make a decision based on > where it wants to compete. There are no trade offs. Only unjustified fears. > > : Apple doesn't need new markets, right? Their current markets are doing > : *just fine*. They're doing just fine on their own. Selling to them home > : users, schools, and artists. > : > : Oh, that's right. Apple's marketshare is dwindling. Apple's > : traditional markets are moving to Windows. Schools, homes, graphics > : professionals. Evidently, Apple must not be selling what people want > : anymore. Apple isn't even holding on to their *current* customers. > : I think Apple should spend some time to find out exactly what > : users want. *Not* current Mac users. Former Mac users. Mac users > : who have left the Mac for NT, Solaris, Linux, IRIX, whatever. > : Obviously, Apple can't grow their marketshare selling to current > : Mac owners. Apple has to design Rhapsody for former Mac owners. > : Then they have to make it clear that Rhapsody is what they really > : wanted, and that they should come back. An Intel port of Rhapsody > : would make this easier. > > Most of Apple's losses are to Win95 and, to a lesser extent, Win NT, > users who have demonstrated little interest in Unix compatibility. Even > when Apple had a Unix, A-UX, it drew little support outside of academia. > Apple needs to compete against Microsoft and this requires little > Unix compatibility. As a workstation user, I'd love to see Rhapsody > have as much Unix compatibility as possible. I'm not sure Apple will > agree with me. A/UX wasn't a serious Unix. It wasn't supported very well, and wasn't terribly well integrated. The question is this: If Unix is included in a user-friendly manner, does it open new markets for Macintoshes? The answer is yes. Does Apple need new MacOS customers? Yes. Is there any reason why Unix should taint MacOS into something unfriendly, complex, and hard-to-use for traditional Mac users? None whatsoever. What does Apple have to lose by including Unix? Nothing. > : Let's see. Apple has about 6% marketshare. If Apple can successfully > : sell to the 1% of users who want Unix, that would give Apple 7% > : marketshare. A 16% increase in Mac marketshare. Furthermore, it's > : an increase, which Apple hasn't seen in many moons. > > Exactly what percentage of users do you think want Unix compatibility? > I don't mean the features of a modern OS, I mean make and rm and the > contents of /usr? All told they probably make up 1-2% of the marketplace. > What is the current marketshare of Sun, DEC and HP's Unix offerings. > Admittedly this is the financial plum of the marketplace, but a small > portion. Do you expect Apple to be able to quickly grab a majority share > against Sun, HP, and DEC, not to mention Win NT? You sure have high > expectations for Rhapsody. Hopefully Apple will meet them. The Unix market is easier to crack than the Windows market. The Unix vendors are already fragmented, and Unix users are already drifting to Windows. It's also an enterprise market which is less prone to choosing a hardware platform according to how much software is available for it at Egghead. > : If Apple can grab back the graphics professionals who are using > : NT, they could probably add another .5%. If Apple can grab > : webserver marketshare from WinNT, that might account for another > : .5%. (This would likely be easier if Apple shipped Rhapsody > : on Intel). That'd increase Mac marketshare by another 1%. > > Apple's market share was once 10%, without the Unix or webserver folks. > Why can't they be that now without them? The fastest growing part of > the market is the home where Apple's much better represented than average. > Do you really think that battling it out with Sun, HP and DEC is the way > to keep Apple alive? Are we just going to concede the vast majority of > the market to Microsoft? Apple has an uphill battle ahead of them if they want to gain home marketshare. Microsoft has more mindshare. You can't freakin' swing a cat without hitting something with a Microsoft logo on it. For Apple to counteract this would require huge expenditures. They'd probably have to start paying CompUSA and others large amounts of money to give Macs a decent presence. Of course, CompUSA would probably just go to Microsoft, ask for more, and ignore Apple. Apple has to choose the battles they can win. I'm not convinced that Apple can win the home computer OS battle at this point. It would be better for Apple to pick up some wins on other battlefields (graphics, web, enterprise) first, then use those successes to gain home buyers. Get people to use it at work, and buy it for home because it's so much cooler. It's much easier to experience the advantages of a Mac in an 8-hour workday, than at a brief, half-hearted computer store demo. Apple should try to improve its visbility and marketing for home users. I don't think they should bet the farm on it, though. For the immediate future, Apple's marketing money would be better spent persuading developers to port their Windows-only children's applications to Macs. Co-marketing funds, developer subsidies, whatever. A big home computing marketing push would be a waste if there are significant applications that aren't available for the Mac. All it would take to blow a sale is one "Does it run <insert little Tommy's favorite app>?" "No.". -- Jonathan W. Hendry jon @ exnext . com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 18:05:01 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <smtIiRO00iV0M5bOIB@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> In-Reply-To: <maury-2101971203450001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. > Which portion do you not understand: > > a) it's easier to have API's than use streams? That is simply not true for every problem. > b) if you're in an OOPS paradigm you'd like to stay there? Again, OO programming is one paradigm out of many. It is not always the best solution to every possible problem, although it is very good for a lot of problems. > c) if you use system() you're not cross platform? I can use fork()/exec() (which is more controllable in terms of handling stdin, stdout, etc that system()) on every POSIX-compliant operating system and every Unix system around. Such code is portable to more operating system/hardware plaform combinations than any other system call API that is available today. How is this not cross-platform? > d) shared libs run in the application's space, thus requiring less demands > of the OS to be nicely MT? Unix systems aren't bothered by fork()ing and preemptively multitasking at the process level. In fact, they often do a better job of blocking I/O and asyncronous activities like networking than a single process which is multithreaded, and such designs are often more robust and offer higher performance. You do realize that the fastest and most efficient web servers are written by preforking child servers-- such a design beats a multithreaded web server in pretty much every regard. > I mean, what is so terribly difficult to grasp about any of these points? Nothing-- it's not terribly difficult at all. Why don't you understand that almost every single point you've made in several articles, including this one, have been wrong? >> Compared to everything else in Openstep/Mach, the unix things like /bin, >> etc, are rather small. Ripping them out wont get you much in the way of >> disk space nor anything else, and it will only cost you in functionality >> and flexability. > > No one has _ever_ advocated their complete removal. The other posts and > my own have suggested making OOPS based versions of the same thing. I > have mentioned this in every letter I've posted for the last three days, > how can everyone continue to miss this point? Because it conflicts with your own words: 'I don't think this will mangle it at all. Quite the opposite in some cases. If you want the shell utilities, click Custom Install, click "Unix utilities". End of issue.' If the Unix CLI utilities are not shipped as a core element of the operating system with _every_ copy of Rhapsody, then they will not available on _some_ Rhapsody systems. Software currently available for Unix, including essentials such as the system boot procedure (/etc/rc and friends) and networking and email (machd, netinfod, nfsd, sendmail, telnet, ftp, etc) depends on those CLI utilities. That in turn means that one would have to scrap going with a normal Unix boot and write some custom design for booting the system. This means that pretty much all of the current NeXT sysadmin software will no longer work, and neither will any of the current networking functionality. The means that Rhapsody will not be compatible with other Unix operating systems. Do you understand? If you make Unix optional, Rhapsody will no longer be Unix-compatible because you would have to replace the current Unix functionality with something else that is not optional-- this is the case with OpenStep on NT. Doing constitutes "ripping out Unix", since the operating system would no longer be a Unix operating system. And guess what? Apple bought NeXT because "Apple needed a truly modern operating system and NeXT had an exceptional operating system with modern services and API's." That operating system is based off of Mach, BSD 4.x Unix, GNU developer tools (with gcc at the top of the list as being the most sophisticated cross-platform compiler written to date), NEXTSTEP's GUI and tools, NEXTSTEP's networking and system administration functionality, the reference implementation of the OpenStep API, and related tools/APIs such as EOF and WebObjects. These components are highly integrated at the lower levels-- OpenStep is the only part that's truly OS-independent. Removing Unix means that you would have to re-write everything from the developer tools to the sysadmin tools to the networking software to the way the system boots. All of this to save $3 worth of disk space? -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Michel Coste <mic@micmac.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: Tue, 21 Jan 1997 23:18:28 GMT Organization: MiCMAC Message-ID: <E4Dsqs.6Cx@micmac.com> References: <5amli2$ol3@news.tuwien.ac.at> Cc: rft@cg.tuwien.ac.at In <5amli2$ol3@news.tuwien.ac.at> Robert F Tobler wrote: > > > PROPOSAL: > How to modify the Workspace manager to behave like the Finder I think this is a ridiculous idea. "Modify the Workspace manager to behave like the Finder" Ha ha ha! [I don't want to put you down Robert. I see perfectly your purpose and your analysis is quite good. But I think you didn't see how incidentally what you wrote could be sadly funny...] I remember when NeXT came out , ALL mac users were trying modify the Finder to mimic NeXT!!! What a WASTE you suggest! The Workspace is much more sophisticated than the Finder. To say the least what you suggest is a retrogradation... As a long time Macintosh user (Mac enthousiast and user since 1984) with maybe more than 10 000 hours and as a more recent convert to NeXT (enthousiast since 1988 and user since 1991!) I know perfectly the two environments and can compare them. > > Currently the Nextstep Workspace manager presents one or more windows called > "File Viewers" to the user, that consist of three parts: Right! > > * The shelf: This is a place to store commonly accessed files and > directories in a way similar to aliases on the Desktop of the > Macintosh. Yes it's like the desktop. But much better than aliases it deals with representations of the files... There is no need for a hidden "desktop folder" that contains these aliases (most finish to be orphaned sooner or later in my experience...) or worst real files! So the shelf does everything that the desktop does but it's a MUCH SUPERIOR metaphor! I thank everyday Jean-Marie Hullot for it's invention! > > * The icon path: This displays the location of the selected file by > showing the complete path from the root of the main disk to the > file, in the form of an icon sequence containing each directory. It's beautiful. When you clic once on every file/folder that you put on the shelf you see the icons of the complete path. The file could be on the other side of the world, it works the same. I thank everyday Jean-Marie Hullot for it's invention! > > * The browser: This part of the viewer can be used in three different > modes, one of them is the mode which shoes the contents of each > directory in the icon path as a column, the second one shows the > icon of each file in the current directory, and the third one shows > a list of all files in the current directory with all the additional > fields like owner, creation date, aso. Wrong! The third part is the View. One can choose between three Views: the more ancient style of the "Listing" (UNIX style of informations), the more recent style of the "Icons" (Macintosh style of information) and the actual style of the "Browser" (NeXT style of information, the more adapted to network navigation). In resume these three styles belong to the three more important periods of the computing history... I assume you talk from now on of the Browser View. > > Double-clicking a directory will show the directory in the current file > viewer without opening a new window. No need to double-clic... Select a directory in the Shelf (=desktop) or in the Browser will show it's content in the next column (and in the Path where you can make direct manipulation like on the Macintosh). > The Workspace manager supports the > functionality of opening a directory in a new file viewer window, if the user > wants it (using a Menu, a command shortcut Cmd-Shift-O, or Alt-Double-Click). > It also stores the mode of the browser in each directory that was opend with > its own file viewer window. It's very useful! Though I do most of my work in the main File Viewer, I sometimes open new ones this way to work on particular things. Since they are remembered it's very convenient (I have Files Viewers for my html work, for ftp, etc...) All in all I have much less windows on my NeXT than on my Mac! (On my Mac I have as many windows as there are windows = an infinity!) The File Viewer is a much sophisticated mecanism than the classic window. It's a weapon against the clutter made by these windows... > > In order to change the Workspace manager to behave like the finder, a small > number of changes are necessary: > > * Make it possible for a file viewer to contain only the shelf, or only > the browser. This should be user selectable. I don't see the advantage! If you want a bigger shelf/desktop you can open a File Viewer as large as the screen. BUT this is useless. I mean the desktop is not needed as much on the NeXT than on the Mac. On my Mac I'm perfectly happy with two or three File Viewer with big enough shelves. On my Mac I have a cluttered desktop! Why? Because the desktop on the Mac serves two main functions: - The useful one: put important files/folders and Drag & Drop Apps. I for one (like many I think!) put an alias of my System Folder at the bottom left of my screen. It makes installation of Control Panels and the like a breeze! On the NeXT there's no equivalent of the system Folder and Control Panels, so there's no use! Then I have an alias of ResEdit (a necessity for me since 1985!). On the NeXT there's no need of a ResEdit since you can open directly the equivalent of resources (text and tiff files). Then I have an alias to Save a Bundle since it's often needed... (On NeXT no equivalent is needed!). Then I have an alias to Shrinkwrap (On the NeXT it's a long time we don't manipulate diskettes anymore!). Then, Stuffit Expander alias. (On the NeXT decompression can be automatically and transparently made: I use Opener.app for that). And so on. You get the idea: under NeXTstep there is no need for drag & drop applications... I would like to say here that I think the concept of Services on the NeXT is superior since no waste of real estate is needed... I have then important folders like on my NeXT. - A rubbish dump: the desktop is often used to put the files we don't know where to put! Temporary files that we saved here because it's convenient to find them there later to trash them... New files waiting to be classified in the right place... > > * Add to the icon mode of the browser, Why not (optionally!)? That's a good idea. I only hope there's no penalisation when you open a directory with 1000 files! > the functionality to > (optionally) store the location of each icon in each directory. You mean by Icon View? No problem! It's really possible to add the possibility of a View by Icons with mess (no grid!)... > > * Add the option to always create a new "File Viewer" window for each > directory that is double-clicked. A very minor advantage. that could allow new users to make a clutter very quickly... so they could feel "at home"... Remember the File Viewer is not a "classic" window! > > * Add to the shelf the functionality of arbitrary icon placement; > currently icons can only be placed in a grid. Freedom Freedom!!!! I'm an anarchist myself (sort of...) but I don't see the advantages of putting the chaos there... But it's not a big deal. > > > Using these three features, the Next Finder can be implemented this way: > > * Make a shelf-only window that has the size of the screen and resides > below all other windows. This will be the Next Apple Desktop. Completely useless!!! The great thing with NeXTstep is that the files in the shelf are connected to a view! And remember there's no more need to drag & drop! Or maybe you presume that some Mac users are addicts to their drag & drop habits... > > * Set the defaults of the Next Finder to always create a new "Viewer" > at each double click, and to be in icon mode per default. You already said that! And the Icon View is already by default in the actual installation of NeXTstep. (I always thought it was a weakness from NeXT side!) > > Using these defaults there are some differences to the original Macintosh > Finder, e.g. the Desktop contains only "aliases", never real files. You see some advantages to aliases and real files in this case??????? I don't get it!!! > But I > think the overall user experience in such a customizable Next Finder, could > be made very close to the current Finder, so that Macintosh users will still > be able to efficiently use the Next Apple OS with only *very little* changes > to their accusomed habits. This proposal makes the user interface changes > from the current Finder to the Next Findersmall enough to be even less than > the changes made from system 6.x to system 7.0. > You said it: the only advantages to these changes would be to take care of Mac users habits, not for functionality... Now I think it's time for a more radical change! Remember there were some Apple II users that never accepted the Macintosh! Should have Steve Jobs managed them so the Mac interface would have been acceptable by them???? Sure not! Happily we had something completely different. The actual process is exactly the same... It happens that Steve Jobs is in charge of the supervision of the new system. So I'm confident he will not break the wonderful NeXT interface! (...) > Comments are welcome. I made some... > > ------------------------------------------------------------------------ > Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 > Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at > Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/ > > -- mc _________________________________________________________ Michel Coste <mailto:mic@micmac.com> MiCMAC - Online Publishing < http://www.micmac.com> _________________________________________________________
From: REMOVE.TO.REPLY.drg@biomath.mdacc.tmc.edu (David Gutierrez) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 14 Jan 1997 23:40:58 -0500 Organization: Univ. Texas M.D. Anderson Cancer Center Message-ID: <REMOVE.TO.REPLY.drg-ya02408000R1401972340580001@news.uth.tmc.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <ibhan-0801971336040001@infobhan.med.harvard.edu> <bononno-ya023680000801972235030001@news.nyu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <bononno-ya023680000801972235030001@news.nyu.edu>, bononno@acf2.nyu.edu (Robert Bononno) wrote: > In article <ibhan-0801971336040001@infobhan.med.harvard.edu>, > ibhan@student.med.harvard.edu (Ishir Bhan) wrote: > > >Rhapsody is supposed to be released at the same time as 7.8. That is, one > >year from now. The developer release will preceed it by several months > >(possibly as soon as 6). > > That's not what I read. It is, nevertheless, correct - according to presentations given at MacWorld last week. -- David Gutierrez drg@biomath.mdacc.tmc.edu "Only fools are positive." - Moe Howard
From: rex@mit.edu (Eric King) Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system Subject: Re: DPS Hit Detection Date: Wed, 15 Jan 1997 00:56:13 -0400 Organization: Netcom Message-ID: <rex-ya023080001501970056130001@nntp.ix.netcom.com> References: <5bg2e0$ar2@bignews.shef.ac.uk> <AF00F4DB-4F859@198.68.42.175> <32DBDD3C.1EBAB5AF@screaming.org> <5bh10q$c1s@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bh10q$c1s@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: )> infill and inneofill -- returns true if any portion of the point )> along the user path passed as an argument lies in the )> region painted by fill or eofill of the current path )> )> instroke -- returns true if any portion of the point or user )> path lies in the region painted by a stroke of the current )> path. )> )> The three following operators are similar except they use a )> user path instead of the current path: )> inufill, inueofill, inustroke )> Thanks for the info, unfortunately this is still requires quite a bit more work than the GXHitTest**** family of functions. Boolean hittesting is useful, but its nowhere near as useful as being able to hit test a graphic structure and then given the object or objects that were hit. It looks as if I'd have to implement several layers of abstraction on top of the PS code defining the appearance of my widget. Ultimately what I want and what GX provides are hierarchical container shapes that know which part of them has been hit (with adjustable tolerance and depth :)) and which object in my app that part is associated with. This is a true time saver. )In addition to the straight PostScript operators, the Purple book (which IMHO )will probably be a required read for many Mac developers, especially if )they're considering graphics-based apps: Not if I can help it. :) The more I learn, the more I *really* hope Apple keeps GX around. )I wanted to draw attention to an easily-missed paragraph on p140, which notes )that it is possible to do hit detection without using the DPS operators. In )general, assuming your mouse point and your drawn object are rectangles (or )you can consider a bounding box around the drawn object), you can do hit )detection using NXIntersectsRect (I presume there is an OpenStep )equivalent?!) to first find whether the mouse point lies within the bounding )box prior to doing any more "expensive" checks. GX does this automatically, i.e. if you hit test a shape, it'll scan the bounding rects of the subshapes until it hits an intersection, from there it'll scan the bounding rects of any subshapes in that shape, and continue on down through the hierarchy until it hits a primitive or until you reach a specified depth. Once it hits a primitive it'll hit test any parts of that primitive like starting or end caps, and then relay references to the shape that was hit and what part of the shape that was hit. (if applicable.) If its told to stop at a certain depth then it'll just return the picture or other container shape at that depth. The cool thing is that one can store actual objects in the shapes and just extract the appropriate tag from the returned shape and call say a 'DoClick' method. e.g. something like: theHitShape = GXHitTestPicture(myWidget, thePoint, &myHitTestInfo, 1 ,1); if (theHitShape != null) { tagsfound = GXGetShapeTags(theHitShape, myTagType, 1, 1, &myTagRef); if (tagsfound) { GXGetTag(myTagRef, myTagType, &myTag); myTag.doClick; } } Another handy feature is the ability to change the hit test parameters of each shape individually because that info's stored in a shape's transform object. By the same token since the parameters are in a transform *object*, they can be shared among shapes. So if you wanted to do something like disable hittesting for a bunch of shapes on the screen, you could just change one shared transform object and they'd all be affected. )I mentioned elsewhere an application I wrote which commonly had 4000+ items )in a window (View); if I remember rightly, checking which representations )intersected the mouse point saved a *lot* of time. Now what was it that us GX developers were saying about DPS performance... 8) Out of continuing curiosity do any of the DPS hit test operators offer adjustable tolerances, i.e. if I click within a few points of an object will it still register as a hit or will I have to compute the intersection of a bounding circle and the object I wish to test against? -Eric -- Excerpt from Marianne Moore's 'The Pangolin' This near artichoke with head and legs and grit-equipped gizzard, the night miniature artist engineer is, yes, Leonardo da Vinci's replica- impressive animal and toiler for whom we seldom hear.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 18:25:17 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> In-Reply-To: <maury-2101971109420001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> The point is, regardless of what it's called or whether it's just one or >> several libraries-- there is no point at all of creating tens of >> thousands of system calls to replace the Unix command line utilities > > There are "tens of thousands" of command line utilities? There are 1200 or so command line utilities in my path. Most of them have a much more complicated behavior than the basic commands like cp, mv, rm, and so forth-- those generally don't do much besides parse the command line and execute the appropriate system call. > And there's lots of reasons to do this. > > > unless that mammoth API is available on all of the hardware/operating > > This "mammoth" API is exactly as large as the current one. In fact, good > design would allow it to be much smaller in fact (combine content and > directory searching operations inside a single query object for > instance). However, unlike the current API, it's language neutral, > platform neutral, OOPS based and publishes its own interface. It also > would allow for direct calls to the API using objects so you don't have to > flatten your objects, and will pass back data or exceptions in the same > way. That API doesn't exist right now. Apple does not have the time to create such an API. I also question whether they can duplicate all of the functionality without having to undergo years of user feedback and debugging-- and Unix has undergone decades worth of testing. > Really now, the advantages are both obvious and huge. If they weren't, > why did they create OpenStep in the first place? OpenStep is another evolutionary step along the road towards the great Mecca in which good programs and reliable operating systems are available to all computer users. The existance of OpenStep does not mean that Rhapsody can dump the Unix CLI utilities without breaking far too many things (as I've explained in previous articles). Once again, the Unix utilities cannot be an optional part of Rhapsody without Apple having to replace that functionality with something else. >> system combinations that you're replacing the Unix CLI utilities, >> otherwise programmers won't be able to depend on all of the API being >> available, which would make it far less useful. > > The _current_ code is not available on all platforms, OpenStep for NT > for instance. This not only makes this argument moot, but provides even > more ammo for replacing it. NT provides a POSIX-compliant environment, does it not? POSIX, or S/VID, or one of those standards defines POSIX-compliant command-line utilities which are precisely the ones shipped with modern Unices (and are largely backwards-compatible with the BSD 4.3 utilities). >> Besides which, why don't you try to estimate the number of >> developer-years such a task would require? > > Two? Which utility in particular do you think is hard to recreate? make, sh, perl, diff, awk, sed, lex, yacc, grep, tar, cc, ld, as, emacs, gdb? Or what about system daemons like inetd, sendmail, netinfod, telnetd, ftpd? >>> Code reuse: it's a good idea. >> >> Again, writing a new library which provides functionality already >> implemented by Unix command-line tools is the precise opposite of code >> reuse. > > Only if you consider the case when you're running on Unix. This is not > the only case. Available evidence suggests that a lot of people implement popular Unix tools like make, sh, diff, and so forth for non-Unix operating systems since those tools are especially useful for developers and administrators because they provide a large amount of functionality. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 18:46:06 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <cmtJIyO00iV0A5bPI8@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <maury-2101971141510001@199.166.204.230> In-Reply-To: <maury-2101971141510001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> "Calls the OOPS libs" how? > > With a program. You know, those funky "API" things. What kind of program? A precompiled executable in the architechtures' machine language, or an interpreted program which requires an interpreter (ie, /bin/sh) and commands (ie, /bin/mount, /bin/find, /bin/grep, /etc/inetd, /usr/lib/sendmail, etc). >> Are you talking about having the system boot using a precompiled >> executable? > > No, I'm talking about having a OOPS shared library of some form on the > disk, rather than a CLI executable program that you fork off. That's it. What type of program calls the OOPS shared library? >> If so, remember that we already went through the reasoning >> why that's not as good as having the system boot be configurable via an >> interpreted shell. > > And it still could be. Is this really so strange? I am truly baffled > at the number of questions I'm getting about this that seem to be confused > about what I am suggesting. @Begin(Sarcasm) { Gee-- lots of people disagree with Maury, therefore they must all be confused and not understand what I mean. It couldn't possibly be the case that Maury is wrong.... } @End(Sarcasm) [ ... ] >> Who cares whether the current average Mac user would want them or not > > Riiiiight. In fact, let's install NT on their drives too. VMS while > we're at it. > > Have you heard of the term "distributed costs"? Yes. I suspect I understand them better than you do. What is the largest number of computers that you've had responsibility to administer? Furthermore, the difference in distributed costs would be the difference between the 15 MB or so for the Unix utilities if they are not optional, and however much space whatever your alternative is consumes. >> so long as the ability to run those applications has no negative >> implications to that Mac user besides $3 worth of disk space? > > Do you mean aside from the fact that code written to use them is thus > not portable by definition? No-- code written to use the Unix CLI utilities would be portable to all users of Rhapsody, assuming that Unix is not optional. That would not cause any portability problems for that Mac user, whereas the lack of the Unix CLI utilities would cause huge portability problems with Unix software because not every Rhapsody systems would be Unix-compatible. >> Rhapsody has the potential to sell to a large number of markets that >> Apple has never been successful in before-- such as corporate MCCA, >> Internet/Intranet usage, the server market, web technology, the >> important areas of higher education (ie, graduate CS/IS/Math programs >> :-), and so forth. Basicly, Rhapsody will cover all of the areas where >> Unix is popular, and hopefully will also make inroads into the normal >> business environment which is currently dominated by Microsoft Windows. > > Great, so have a check box in Custom Install that states "Install Unix > shell utilities" and you can do all of this? This is getting really > repetitive. Yes, it is. Rhapsody can either be Unix-compatible, or it can have Unix-compatibility as an optional add-on, which would mean that Rhapsody would have to have some non-optional replacement for the Unix utilities which would mean that some Rhapsody systems are guaranteed to not be Unix-compatible (because they didn't have the optional add-on installed). >> Assuming, of course, that Apple doesn't do anything _completely_ >> braindamaged-- which is the only description I have for the suggestion >> of ripping Unix out of Rhapsody. > > Who said anything about ripping Unix out of Rhapsody?!? READ THE THREAD! You did! Making Unix an optional part of Rhapsody means that Apple has to rip Unix out of Rhapsody and replace it with some non-optional alternative that provides similar functionality. Your operating system won't do anything if it can't boot, and Unix systems can't boot without the Unix CLI utilities. What part of that don't you understand? -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 21 Jan 1997 01:49:05 -0700 Organization: Primenet Services for the Internet Message-ID: <AF09D465-4C07A@198.68.42.144> References: <32E44F5F.6C31@exnext.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Jonathan W. Hendry <jon@exnext.com> said: >Lawson English wrote: >> >> Erik M. Buck >> >> <embuck@palmer.cca.rockwell.com> said: >> >> >A direct to screen API does exist for NeXTstep but it is not portable for >> >obvious reasons to other OpenStep/Hardware combinations. >> > >> >> That is very strange. The Mac has always allowed direct-drawing to the >> video buffer via an API that is consistent with all video hardware that >> works on the Mac, regardless of who makes it. > >"Regardless of who makes it"??? > >Pfft. As if the differences between Apple Macs and PowerComputing Macs >are even remotely as large as the differences between NeXT's, Intel >boxes with arbitrary video cards, HP workstations, and Sparcs. Not >friggin' likely. > >Or are you talking about monitors? Arbitrary video cards that work with Macs. As the man said in the article about Game Sprockets, Apple has a video API that supports direct-drawing, etc., for any Mac-compliant Plug-and-play video card, regardless of who makes it, regardless of VRAM size, shape, depth, acceleration, etc. Now, if the manufacturer doesn't provide a P'n'P driver for a specific video mode, the API doesn't work, but for P'n'P PCI cards and Mac NuBus cards, the old-style "raw" video API always works (allowing for bugs and non-compliance). The Game Sprocket API is supposed to be much (MUCH) easier to use, although I haven't had a need to delve into it (my last direct-to-screen stuff was done about 2 years ago for LC II-class machines using a PowerMac 7100/66 for the prototyping, and Game Sprockets wasn't even available back then, if memory serves). ------------------------------------------------------------------------- Windows: Tumor-causing, teeth-staining, smelly, puking habit. -------------------------------------------------------------------------
Date: Wed, 15 Jan 1997 00:42:26 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.oop.macapp3 Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Message-ID: <milkweed-1501970042260001@port5.chester.smallmedia.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> Organization: Milkweed Software In article <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: > Excerpts from netnews.comp.sys.next.programmer: 9-Jan-97 Re: Mult. Inh. > in Objective.. by Anders Pytte@plainfield. > > But the point I wish to raise is that for many programmers (including > > myself) choice of language is not as important as programming habits and > > code design. My mental model includes ideal implementations of all these > > features, and my programming habits act as a sort of "precompiler" into > > whatever language I am using. > > > > In this case, wouldn't it be better if the language I used matched my > > mental model exactly? Perhaps, but depends on the costs (they work both > > ways). Objective C may require of a project fewer lines of code and no > > days housekeeping memory, but then the code object is larger and slower, > > which is a significant concern in our case. > > What it is that you wish to retain from your previously developed code > and your familiarity/programming habits? If you want to reuse the > portable aspects of C or C++ code that you have around, no problem-- you > can use legacy C and C++ code with Obj-C just fine. > > You really should learn about OOP (things like encapsulation, > polymorphism, and inheritance) to take full advantage of the benefits of > OPENSTEP's API, etc, but nothing prevents you from writing non-OOP code > if that's how you want to solve a problem. > > As for the size and performance of Obj-C based applications, I would > suggest trying it before worrying about problems that most people don't > encounter. C++ advocates always seem to imply there is a big tradeoff > here, but I cannot recall ever seeing a NEXTSTEP developer (someone who > has actually released commercial software) state that the size and > performance of Obj-C was a significant problem. > Chuck, Thanks for the info - I admit I am unsure of the size and performance advantage of C++, since I have not done comparisons. But you have misunderstood my intent. I have nothing at all against Obj-C, in fact, I am excited by it. I did not mean that I feared giving up programming habits, rather that I am accustomed to compensating for shortcomings of languages through good design and good programming habits. I would need to do the same with Obj-C due to its lack of explicit multiple inheritance, operator overloading, etc. (am I correct here about Obj-C?). And I don't want to hear any more bullshit about my being better off without those features - when correctly used they enhance code design. My point is that choice of language is not as important as good programming habits and good code design. Each language has its die-hard advocates, ofcourse. But I expect that many like myself take the following pragmatic view: 1. I want my current (huge) code base supported (atleast for a while). 2. I will use whatever language has the best support and most promise for a given platform (or especially for multiple platforms). If Apple blesses Obj-C, and I can use it (efficiently) to advance our existing products and port them to other platforms, then i will bless Obj-C too. Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 19:09:20 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <omtJeke00iV0A5bQJe@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <gmt17KG00iV0A52nk5@andrew.cmu.edu> <maury-2101971151450001@199.166.204.230> In-Reply-To: <maury-2101971151450001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Removing functionality cannot _possibly_ make programming easier. > > And there is is again, a clear indication that you have either not read > the posts, or are incapable of understanding them. Are you claiming that removing functionality does make programming easier, or that you have not suggested removing functionality by making the Unix utilities optional? >> You can always decide to not use some API if you don't want to, but not >> having an API available at all means that you will have to do more work >> if/when you needed that functionality. > > Find a message in which I propose that the API's should be removed. If the Unix utilities are an optional component of Rhapsody, which is what you have repeatedly suggested, then these utilities will not be available on every system running Rhapsody. This means that the API provided by those Unix utilities will no longer be available on every system running Rhapsody. In effect, the Unix API has been removed since it would no longer be a mandatory part of all Rhapsody systems. > In fact, I've been constantly and unwaveringly suggesting that all of them > should indeed be API's, when in the current case they are not. An API stands for "application programming interface" and it refers to a convention by which a software component is used by other software. The Unix utilities have an API defined for their command line usage. [ ... ] -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 18:57:57 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <MmtJU5W00iV0A5bPoY@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> <maury-2101971149510001@199.166.204.230> In-Reply-To: <maury-2101971149510001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. > > If you were being sarcastic (I'll admit to not being sure, since your > > arguments to date don't make a whole lot of sense, IMHO): > > Right. If the posts here are any indication, it's because people simply > aren't reading them. I have stated for no less that TWO WEEKS the same > points over and over, and to date I've seen only ONE person figure it out. Alternative hypothesis: your arguments are wrong. This is what the majority of people are saying to you, with a single exception. [ ... ] > I have repeatedly, including the message you replied to that generated > this remark. I'm tired of being called a moron because... > > a) I don't need Unix shells on my machine > b) I don't want Unix shells on my machine > c) I think the whole system would work better with shared libraries rather > than forked command line utilties Unix operating systems need Unix shells and Unix utilities to function. Rhapsody needs to be a Unix operating system because Unix is a crucial component that provides the operating system functionality that was missing in MacOS which Apple believes people want. (And not just current Mac users, either but _new_ users....). It may well be true that most people don't ever want to use Unix directly. That's why Apple choose to buy NeXT, since NEXTSTEP does the best job of providing the functionality of Unix while still providing a very user-friendly environment that allows normal users to do their work without ever having to see or think about Unix _if_ they don't want to. But, if using Unix is so abhorrent to you, you have alternatives-- you could stick with MacOS 7.x, or switch to Windows NT. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: "Perry K. Lund" <lundp@wmpenn.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 13:36:25 -0600 Organization: William Penn College Message-ID: <32E51AB8.27D7@wmpenn.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <199701211742586676963@amtmtc.demon.co.uk> <32E51363.2C67@aw.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Taylor wrote: > > > Macs have traditionally been touted as systems where you don't need a > > system administrator. A lot of home users are not C.S. savvy and want > > the new system to be as simple to install and administer as system 7 is, > > with the advantages that a protected & pre-emptive system can give. > > > I would assert the following: > - one Mac is much easier to administrate than one Unix box > - 100 Unix boxes are much easier to administrate than 100 Macs > > With better UI tools and more Unix hiding, the first statement should > not necessarily hold for the next gen mac systems. The latest version of Network Assistant for Macs in conjunction with At Ease seems to be a move towards making life easier when managing 100s of Macs. With the choice of not using the goofy panels now available, At Ease is useable and not insulting to people. -- ------------------------------------------------------------------- Perry Lund Graduate Student CS Instructor Applied Computer Science UNI 1996 - 1997 William Penn College Cedar Falls, Iowa 50614 Oskaloosa, Iowa 52577 -------------------------------------------------------------------
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 00:10:39 GMT Organization: Cygnus Support Message-ID: <5c3ltv$ljg$1@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> Cc: maury@softarc.com In <maury-2101971203450001@199.166.204.230> Maury Markowitz wrote: > In article <5c1358$k5v$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > > Compared to everything else in > > Openstep/Mach, the unix things like /bin, etc, are rather small. Ripping > > them out wont get you much in the way of disk space nor anything else, and it > > will only cost you in functionality and flexability. > > No one has _ever_ advocated their complete removal. The other posts and > my own have suggested making OOPS based versions of the same thing. I > have mentioned this in every letter I've posted for the last three days, > how can everyone continue to miss this point? > I don't think that's the way you've been coming across, and while I don't have an article to quote, I do seem to remember you advocating specifically that things like access to the CLI and the Unix utilities be removed entirely. I don't think there's really a problem with a shared library that impliments the same functionality as the unix CLI tools. I don't think anyone has said "you shouldn't do that", I think they've been saying either: a) that's fine, but don't take away what I've already got, or b) why reinvent the wheel I presonally don't subscribe to the latter.. sometimes in order for your wheels to work with the next generation of carts/wagons/cars/etc, you need to reinvent them. Just don't take away/break what is already there. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Tue, 21 Jan 1997 19:37:49 -0600 Organization: mementech, inc. Message-ID: <32E56F6D.286A8712@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> <maury-2101971149510001@199.166.204.230> <MmtJU5W00iV0A5bPoY@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > Maury Markowitz: > > > > I have repeatedly, including the message you replied to that generated > > this remark. I'm tired of being called a moron because... > > > > a) I don't need Unix shells on my machine > > b) I don't want Unix shells on my machine > > c) I think the whole system would work better with shared libraries rather > > than forked command line utilties > > Unix operating systems need Unix shells and Unix utilities to function. > > Rhapsody needs to be a Unix operating system because Unix is a crucial > component that provides the operating system functionality that was > missing in MacOS which Apple believes people want. (And not just > current Mac users, either but _new_ users....). > > It may well be true that most people don't ever want to use Unix > directly. That's why Apple choose to buy NeXT, since NEXTSTEP does the > best job of providing the functionality of Unix while still providing a > very user-friendly environment that allows normal users to do their work > without ever having to see or think about Unix _if_ they don't want to. > > But, if using Unix is so abhorrent to you, you have alternatives-- you > could stick with MacOS 7.x, or switch to Windows NT. Well said. I think that about wraps up the issue. ;-) But I think that would have been a good time for a BeOS plug, young though it is. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 01:49:35 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5c3rnf$auu@bias.ipc.uni-tuebingen.de> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> Cc: nurban@csugrad.cs.vt.edu In <5c0fue$2e7@csugrad.cs.vt.edu> Nathan M. Urban wrote: > Why not? All these Unix utilities don't take up much space. Crippling > a Unix system isn't worth the effort. The _only_ consideration is > whether the existence of these utilities will hurt developers with > similar products, and I don't think that this is a serious problem. I > doubt 'find' is going to replace V-Twin for desktop use, but there are > plenty of sysadmins and shell scripts who use it. > <rampant> Any developer who sees in such tools a threat to his existence should better become a pig farmer fast! Evolution don't take prisoners. </rampant> -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy * No pig farmers were hurt in this posting
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Tue, 21 Jan 1997 17:54:30 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E4DDqv.10w@cam-ani.co.uk> References: <32E21849.265F@washdc.mindspring.com> In article <32E21849.265F@washdc.mindspring.com> Mike <indigo2@washdc.mindspring.com> writes: > But wait a second. If two people use the computer, can they map the same > hard drive to two different points in the file system? All users see the same filesystem. However you can make links (aliases), so the drive apears in two places. All users would see all the links. > If I had a 2Gb drive with two 1Gb partitions, would I be able to have > one partition mapped into the file system for user A's account and the > other partition mapped into the file system for user B's account? That'd > be nice: neither user could muck around with the other's documents. You could, but there would be little point. You need to forget about disks - they're an artifact of the hardware that (at least in the case of non-removeable media) you want to forget about as much as possible. You'd be far better off mounting a single 2Gb partition for all users (say /Users), and give each user a directory inside that (/Users/A and /Users/B). Each user can access the others data, as much as the other user wants them to, using access mechanisms - they can totally exclude each other if they want. The diference would be that if A needed 1.5Gb and B only used 300Mb there's no problem. You should also be able to use quotas (do they work this release?), so A and B can each use up to 1.2Gb (though not at the same time!), but for up to a few days let A use up to up to 1.5Gb (and then force hium to delete the stuff when it times out). > This leads me to think that in a networked environment, I would be able > to mount hard drives from other computers into my file system when I > start up, right? Sort of like automounting servers on a Macintosh > network. This is the normal way of mounting things - ordinary users CANT mount things! (with certain exceptions). The system does all the mounting, and users go find things in a what looks like a single big disk. > Ahhh. Logical volumes. That's what I want. Would it be difficult for the > guys at NeXT to get logical volumes supported? Are logical volumes a > fairly common part of other operating systems? What would happen if one > of the hard drives that makes up a logical volume takes a dive? Seems > like that would present some pretty sticky problems! Its not common, but its not unusual. However I've seen some people come unstuck when messing with these things - usually just by getting confused. Personally (unless I need a high speed raid array!), I'd be happier with one filesystem per disk. It is possible, if you'r eprepared to loose diskspace to have error recovery built in. I've used a system which hacd about 40 disks, each holding 1 bit of data, with some totally spare. Data was accessed as 32bits, with something like six of the drives used for error correction. you could unplug any drive, and the machine would pause for "a while", automatically swap in a spare drive, and rebuild the missing data from the redundancy built into the other drives! This isn't really needed for most purposes! $an
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Date: 21 Jan 1997 17:46:54 -0800 Organization: Cygnus Solutions Message-ID: <qdrajescq9.fsf@blues.cygnus.com> References: <petrichE3Ct2r.3AJ@netcom.com> <maury <maury-1401 <maury-1601971527030001@199.166.204.230> <5bsj1f$llh@csugrad.cs.vt.edu> <maury-2101971034290001@199.166.204.230> maury@softarc.com (Maury Markowitz) writes: > In article <5bsj1f$llh@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > Because (you see this coming) the forked-file concept sucks and > > app wrappers are better. :) > > I don't see how. It appears that when it comes to being able to be > represented on multiple machines, Mach-o is indeed better. The fact > that features made it into wrappers that didn't make it into Mach-o > doesn't mean it should be that way. As OpenStep so ably showed, Mach-o's segments worked great as long as they could port Mach to every hardware platform. As soon as that ability left their grasp with OpenStep/NT, the Mach-o format fell on its face. If they hadn't already pulled out a lot of the information into app wrappers, recompiling for a system that didn't have the ability to handle segments could have been a nightmare. App wrappers aren't that bad as long as the interface normally treats them as single entities. The wrapper makes it easier to pull out or add information to the application using the standard file system calls, and even if you localize your app for twelve different languages, you're not bogging down the load time with information the application is going to skip over anyway. -- Stephen L. Peters speters@cygnus.com PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "What, do you think soup is a biped?" -- Crow, MST3K
From: Joakim Johansson <no@more.spams> Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: 14 Jan 1997 08:42:25 GMT Organization: Research & Trade AB Distribution: world Message-ID: <5bfgth$jfo@baldwin.rat.se> References: <5be9qd$k2k@nntp1.apple.com> Michael D. Rossetti <rossetti@apple.com> writes > Our preliminary set of objectives for addressing the NeXT opportunity can > be stated as follows: > > 3. Enhancing AppKit through integration of key MacApp concepts. Would that mean a new OpenStep spec, or will AppKit be further changed wrt the OpenStep spec? (It might be a good idea to have an updated OS spec, but let's get the first one out and running first, please) Wouldn't it make more sense to make a "MacApp Framework" which includes that new functionality? (Actually, I though it'd make sense to implement much of the current Apple technologies as Frameworks (QT, OpenDoc, etc, etc).. It's the obvious solution to the integration at least..) Joakim -- Joakim Johansson Software Developer, Research & Trade jocke@rat.se <NeXTmail, MIME> http://www.rat.se/
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 18:00:59 -0500 Organization: Atria Software Message-ID: <maury-2101971800590001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <32E4DF05.7E8F@exnext.com> <maury-2101971321270001@199.166.204.230> <32E536DE.3BBA@exnext.com> In article <32E536DE.3BBA@exnext.com>, jon@exnext.com wrote: > Apple has a crappy Unix, that doesn't have as nice an interface > as NeXTSTEP, doesn't run Mac apps, and is aimed at servers. It's > not user-friendly. And a lot of other people have a crapy Unix too, and they get small sales too. Apple gets the sales it gets not by being Unix, but by being Apple. > No. Some people want these things. ^^^^ Good, then let those people install them. Some people (the vast majority) don't. > If Apple tries to sell some mangled > Unix, nobody who wants *Unix* will buy it. No one that _wants_ Unix buys what Apple has now. The market is tiny and Apple is way better off keeping current customers happy than attempting to go after markets that "allies" like Sun and SGI already do just fine in. > day. These would have to be rewritten or modified. Why do you think that Apple purchased OpenStep? Every application that runs on the Mac will have to be rewritten or modified. Apple is betting on the fact that development under OpenStep will be so easy that it will still be worthwhile. The same is just as true for any market. If new API's were available that offered more functionality and a better interface, why _not_ use them? Afraid of the work? > Basically, using the new OS would be a giant pain in the ass for > Unix users. And Apple doesn't have any, so this seems like a moot point. > Thus, the new OS would probably not be taken seriously, > and few Unix sites would buy it. And they didn't buy it in the past when it was a NeXT product either. Again, moot point. > Not bad. About 16% of the Mac market. That's of the PC market, so something more like 10%. On the Mac market itself, most likely the same number. Lots of growth there! > Because it'll run lots and lots of Mac applications that already exist. So can MAE on anyone else's Unix. > Because it's got the backing of a company with 1.8 billion in the bank > to support it. Because it's no longer a freak OS, but instead has been > 'blessed' by a major company in the industry. Considered a freak company by most these days. > You might want to think about why NeXTSTEP didn't sell, before trying > to apply those conditions to a NeXTSTEP-based MacOS. Most of the > reasons NeXTSTEP didn't sell simply won't apply. So you tell me then, why do _you_ think it didn't sell? You say people want Unix: people don't buy Unix Macs You say Apple's Unix sucks: people don't buy NeXTStep, which doesn't Seems like an empty argument to me. People who buy Unix want Unix. They can still buy it if they want. The market is small, not growing, and smaller than Apple's own. > I disagree. Apple's Unixen have never been particularly stellar. And NeXT's is, and yet it didn't sell either. You can't have it both ways! > > Well I would agree with that for sure, but it would appear to me the > > other 80% would be even better to go after. > > For the moment, Unix users are probably an easier target than Windows > users. I don't know about that, aside from OpenStep what can Apple offer that Sun or SGI or DEC or lots of other people can't? On the other hand all of these companies can offer all sorts of things that Apple can't. If the offering is OpenStep along, see the last sentance. > Especially if Apple gets in good with Sun - Sun shops would > be able to deploy apps across Sun Solaris boxes and Apple Rhapsody > boxes. This would be very nice, especially for shops that have > secretaries using Solaris (they exist, I've seen one). Wow. > True, to an extent. I'd bet the ex-Unix users wouldn't mind jumping back > to a real Unix. Maybe, we'll see. Maury
From: paul@computerActive.on.ca (Paul Nadon) Newsgroups: comp.sys.next.programmer Subject: Survey... just in case nobody knows... Date: 14 Jan 1997 20:41:48 GMT Organization: Carleton University, Ottawa, Canada Message-ID: <5bgr2c$7ur@bertrand.ccs.carleton.ca> Keywords: apple, buyout, survey Jan 14 -- Developer Survey Welcome to the second survey of platform choices for Macintosh developers. The first survey was conducted on January 2 and 3. Sponsorship. This survey is sponsored by _MacWEEK_, _Seybold Seminars_, and _DaveNet_. Goals. To learn more about the current direction of the Macintosh development community. A secondary goal is to understand how the direction changed during the week of January 6, when Apple communicated its direction to developers. Timing. The survey begins on 1/14/97; 12:00:00 AM. It completes on 1/14/97; 11:59:59 PM. You can monitor the survey in real-time on the _Survey Results_ page. When the survey is complete, come back to this page for the final results. Changes since the first survey. We welcome Next developers to participate in the second survey. The Java Virtual Machine is now available as a platform choice. This is distinct from Java the programming language, which can be used to create CGI applications or code that runs inside of a web browser. If you indicate that you plan to, or are currently developing for the Java VM, you are working on apps that are accessed thru the native operating system. Thanks! We send back a cookie, but not to limit voting. If you keep the cookie, we'll be able to track changes on an individual basis if we do a third survey. Mac or Next Developers only. Respond to this survey only if you are actively developing software for the Macintosh or Next platforms. We want to know how you feel right now, at this moment. Do you know what platforms you'll be developing software for in the future? Base your responses only on what you know right now. You may change your mind later as more facts become available. This isn't a corporate survey. If you work for a company that develops software for the Mac, or if you develop Mac software in your spare time, please fill out the form. The responses are accumulated into a summary, so you aren't making a public statement. You may include the URL of a web page that describes your products, but unless you state your future platform preferences on your site, no one will know how you voted. Please be honest about your true at-this-moment platform intentions. Survey: http://www.scripting.com/davenet/surveys/97/jan14/ -- Paul Nadon - computerActive inc. paul@computeractive.on.ca http://www.computeractive.on.ca
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 19:20:25 -0800 Organization: Modulation Message-ID: <32E58779.29E4@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <maury-2001971526200001@199.166.204.230> <32E404D1.24FA@concentric.net> <maury-2101971132510001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32E404D1.24FA@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > > > MailTool > > > > sendMessage: 'This is the contents of the message.' > > > > withSubject: 'My Subject' > > > > to: '<cs4w@andrew.cmu.edu' > > > > > > One must assume the existence of an object storing much of this data > > > even in the Unix case. Thus the line would become something to the effect > > > of... > > > > > > myMessage.send; > > > > Your comment leaves me baffled. I fail to understand your point. Perhaps > > you could elaborate? > > Certainly, but it's basically "what you said", although I used some > pseudo-OOPS there. If you're writing a real application under OpenStep, > you pretty much have to assume that you've created an object for storing > up the components of the message you want to send. > > So instead of placing strings in the call as you did in your example, I > assume that these had already been placed in fields in some object that > inherited code from a Mail API in a shared library. MAPI is a good > example of a non-OOPS version of what I'm referring too. > > This being the case, the call I illustrated would likely be closer to > the truth, you'd build the object at various prior stages of the code, and > once complete, simply call it's send method. Aha! Now I understand. Thanks. Actually, I would assume that the implementation of #sendMessage:withSubject:to: in MailTool class would be something like: MailTool class>sendMessage: messageString withSubject: subjectStruct to: adrString | message | message := MailMessage boundTo: self current. message text: messageString asText. message subject: subjectString asString. message address: (MailAddress fromString: adrString). message send. Whether one would actually use the "convenvience message" #sendMessage:withSubject:to:, or code using MailMessage directly, would depend on what one was doing and why. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 21 Jan 97 21:12:24 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan21211224@slave.one.net> References: <maury-0801971641590001@199.166.204.230> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> In-reply-to: nurban@csugrad.cs.vt.edu's message of 20 Jan 1997 14:35:44 -0500 In article <5c0heg$jud@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: I love Unix and the Unix command line. I just think it would more elegant if most of the Unix functionality were wrappered with objects. Then the utilities could slowly be rewritten into object libraries, so that instead of having programs with object wrappers, you have programs which are thin wrappers around the objects. (Like 'ls' messaging a FileList object or something.) The biggest problem with this is that of the Unix utilities in existence, very little of them would be useful if they were converted to be object libraries IN THEIR CURRENT FORM. Take, for instance, telnet. For the most part, it provides an input/output connection to a remote site. As an object library, you'd really want it to allow generalized access to the WILL/WONT/DO/DONT negotiations, and also to parse and otherwise manipulate the input/output. Command-line telnet really has no facilities for this. If you _had_ a general object library of this sort, it would certainly be useful in implementing a command-line telnet. But, having written something of the sort in the past, it's not an evolutionary thing. A telnet object library has a much greater set of requirements than the command-line telnet needs, and to service those requirements you generally have to make some compromises. [In the case of the telnet protocol, these compromises aren't that severe. But there certainly are cases where you would have to choose performance _or_ flexibility.] Beyond that, though, there simply isn't that much need. Most Unix utilities really wouldn't be useful to most programmers as an object library. Telnet, perhaps. Find, perhaps. sum? split? bc? Most Unix utilities were designed to live within a very specific "object" library which already exists. Better, a large portion of them are more useful within that framework than they would be if they were in a real object library. Keep in mind that part of the power of Unix is that it restricts how programs communicate, but generally provides a wide enough channel for _most_ stuff to get done. An object library widens the channel _tremendously_ over simple pipes and arguments - but brings with it a lot of overhead that you have to ignore to get common jobs done. You know how "everyone" thinks Unix is complicated compared to DOS? It's generally not because DOS is actually simpler. Rather, it's because DOS doesn't have as many options. ls has many more options than dir (though neither is an "intuitive" label), which in some sense makes ls less approachable. A "FileList" object would probably have _many_ more options than ls, which would make it even harder to use. My gut feeling is that a FileList class general enough to implement a modern ls command would be a pretty substantial class. Probably a goodly part of a framework, in fact. Nobody wants a FileList class which just returns exactly a list of filenames, after all ... Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 19:27:49 -0800 Organization: Modulation Message-ID: <32E58935.6F04@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> <maury-2101971149510001@199.166.204.230> <MmtJU5W00iV0A5bPoY@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld > Exclusive: App.. by Maury Markowitz@softarc. > > > If you were being sarcastic (I'll admit to not being sure, since your > > > arguments to date don't make a whole lot of sense, IMHO): > > > > Right. If the posts here are any indication, it's because people simply > > aren't reading them. I have stated for no less that TWO WEEKS the same > > points over and over, and to date I've seen only ONE person figure it out. > > Alternative hypothesis: your arguments are wrong. This is what the > majority of people are saying to you, with a single exception. > > [ ... ] > > I have repeatedly, including the message you replied to that generated > > this remark. I'm tired of being called a moron because... > > > > a) I don't need Unix shells on my machine > > b) I don't want Unix shells on my machine > > c) I think the whole system would work better with shared libraries rather > > than forked command line utilties > > Unix operating systems need Unix shells and Unix utilities to function. > > Rhapsody needs to be a Unix operating system because Unix is a crucial > component that provides the operating system functionality that was > missing in MacOS which Apple believes people want. (And not just > current Mac users, either but _new_ users....). > > It may well be true that most people don't ever want to use Unix > directly. That's why Apple choose to buy NeXT, since NEXTSTEP does the > best job of providing the functionality of Unix while still providing a > very user-friendly environment that allows normal users to do their work > without ever having to see or think about Unix _if_ they don't want to. > > But, if using Unix is so abhorrent to you, you have alternatives-- you > could stick with MacOS 7.x, or switch to Windows NT. Exactly so. I would like it if the Unix utilities exposed more of their inner goodies as shared library functions--but that will have to wait until the Unix community can find the time do so. It's a good goal. But so are many other things, and you can't have everything that's good--there's not enough time or money. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 97 21:33:27 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan21213327@slave.one.net> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <SHESS.97Jan21090558@howard.one.net> <maury-2101971218370001@199.166.204.230> In-reply-to: maury@softarc.com's message of Tue, 21 Jan 1997 12:18:36 -0500 In article <maury-2101971218370001@199.166.204.230>, maury@softarc.com (Maury Markowitz) writes: In article <SHESS.97Jan21090558@howard.one.net>, shess@one.net (Scott Hess) wrote: > The first two points mean that a generalized, well-designed set > of OOP libraries implementing the same set of functionality as a > particular set of Unix command-line utilities will take 2-4 times > the effort to develop. My experience indicates that that is a > _conservative_ estimate. The effort required is likely to be > open-ended. So for this reason we should live with the status quo and not even bother? Sorry, this doesn't strike me as a particularly strong argument. Sorry, perhaps I need to clarify - I'm not arguing about whether Unix utilities _should_ be converted to OOP libraries. I'm telling you why they _won't_ be so converted. > Each specific operation I've done in Unix probably would be > slicker if it had a GUI counterpart. On the other hand, any > package which had that many functions would be impossible to > understand Ummm, you can wrap your head around the collection of Unix utilties but not the same collection re-implemented? Take the simple case, a 1:1 library. Now explain how this is any harder to understand than the current solution. The secret, here, is that Unix has a very hard restriction on communications at a very low level. For the most part, communication is either via stream input, stream output, or command-line arguments. Any program, to be useful, has to come in under that bar. For that reason, I don't _have_ to understand the entire collection of Unix utilities, I only have to understand those I use. For a 1:1 library which provided a suitable stream abstraction, things would be just the same. On the other hand, a library which was that faithful to the source would be almost useless. For instance, take your directory-listing API. Under Unix, you essentially end up with a stream of bytes. Very simple. With an API, you'd want a stream of objects of some sort which would represent files. From there you'd query the file objects for various info you were interested in, probably using LISP mapcar style semantics. This is already quite a bit more complicated than a stream of bytes. Beyond that, though, you need to make certain that things work in entire frameworks. For instance, the directory-listing API should easily extend into the find(1) type API, and also into the file-manipulation API, and file-access API, etc, etc. An API thus has a significant amount of under-the-surface structure which makes everything work together. That structure _will_ make the framework harder to understand. Any specific operation is likely to be harder to understand, though once you get the "hang" of it, you can probably do pretty well. But the learning curve will necessarily be steeper than command-line Unix. [Keep in mind that we're talking an entire system of frameworks that have to work together. Millions of lines, at a minimum, and I'd expect the class count to be in the thousands - let alone the method count!] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 19:57:06 -0800 Organization: Modulation Message-ID: <32E59012.5DE7@concentric.net> References: <5ami95$ol3@news.tuwien.ac.at> <E3spt1.B9u@free.fdn.fr> <5b6dih$9bm@geraldo.cc.utexas.edu> <jinx6568-1601971352540001@news.sover.net> <5bsi7l$ecd@csugrad.cs.vt.edu> <5c3dl9$ag5@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : > : The C compiler. Apple could very well leave that out.. wouldn't want > : to give people a free alternative.. though I don't think that even the > : GNU C compiler with Obj-C extensions will be able to link in CodeWarrior > : object files or the OpenStep libraries, so I don't think they would gain > : much by leaving it out; it's mostly useful for command-line stuff. And > : leaving it out would be a big problem for Unix people, since most Unix > : software is distributed in source form only (every Unix system comes > : with a C compiler, except for some commercial implementations who have > : discovered that they can charge extra for the compiler). > > And if Unix people were Apple's target for Rhapsody you'd be absolutely > right, without cc it'd be almost useless. But Apple's current customer > base, and the only people with machines capable of running Rhapsody > when it is released, aren't Unix people. Mac users live in a world of > shrink wrapped software, and will go to NT before they will compile > applications themselves. If Rhapsody should ever need a C compiler > as standard equipment, the game is over. Define "need." If you mean "unuseable without it," I'd agree. If you mean "necessary in order to grab Unix source code off the net and compile it" (such source code will be available no matter what Apple does, or what OS they use), then I disagree. Especially if such sources are "self compiling" in the same way that Zip file can be "self extracting." Or if there's a nice user-friendly GUI tool for compiling source code. Users wouldn't even have to know what was really happening, any more than they have to understand the technoloyg behind compression. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 21 Jan 1997 15:25:03 -0800 Organization: Cygnus Solutions Message-ID: <qdwwt6sjao.fsf@blues.cygnus.com> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> tbutler@tfs.net (Travis Butler) writes: > The *reason* I want a Mac is so that I wouldn't have to deal with > the hassles of a CLI-based OS like Unix or DOS/Windows. So I > wouldn't *have* to deal with /bin, /usr and /etc, commands like > "ls", "mv", "chmod," and suchlike. I hate to put words in other > people's mouths, but I imagine that's the same reason a lot of the > Mac users in this debate bought Macs. > > If you could make Unix functionality a part of the new OS without > *forcing* users to deal with these things, so they wouldn't need to > see or use them unless they really *wanted* to, then I wouldn't > mind. But what I saw of NeXTstep a few years ago didn't work that > way, and the comments I've seen here suggest that it hasn't changed > in this respect. Actually, I'm seriously confused as to where in NeXTSTEP you felt you had to deal with /bin, `ls', `mv', `chmod' or any of the others. I know I've never felt a desperate need to drop to the command line for any of these things, and I don't think my wife has touched Terminal.app in years. Can you elaborate? As for the comments you're seeing here, I'd ignore them. Most of them seem to be arguing against a perception that Maury wants to dump all the Unix utilities completely and turn them into an object layer before Rhapsody goes gold. Whether that's true or not, I think it's more important to figure out where the existing GUI can be improved to make it work better for Joe Average User, not to play `what can we rip out this week'. > Let me turn the question around: Should Joe Average User have to > wade through Unix arcanum just to use the computer, when he doesn't > know or care what 1/4 of the things mean, let alone how to use them > -- just so that the small percentage of Unix gurus can easily run > install scripts? I agree completely, but I don't think this is an either-or thing. NeXTSTEP already does a good job of hiding the Unix-ness like /bin out of the box for normal users. Where is it falling down on the job? -- Stephen L. Peters speters@cygnus.com PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "What, do you think soup is a biped?" -- Crow, MST3K
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 04:55:34 GMT Organization: The University of Calgary Message-ID: <5c46k6$ma0@ds2.acs.ucalgary.ca> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: > Which portion do you not understand: Why you're wasting so much time advocating something that doesn't exist and isn't likely exist in the near future. You might as well advocate teleportation over automobiles for all the good it's likely to do. I would _love_ to see a complete OO paradigm used to completely reinvent a modern operating system API. I think that you are hopelessly underestimating the effort involved. Microsoft has just begun the chore and even though they've got money to burn they don't expect to be done any time soon. > No one has _ever_ advocated their complete removal. You mean aside from your stating that it would make life easier for developers and make the system more cross platform if they were removed? I hope you're not surprised people took that as advocacy for their removal. Yes, you've made it very clear since then that this wasn't what you meant, but it was what you said. -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
Newsgroups: comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Message-ID: <32DBCF8F.2BBF@running-start.com> From: Eric Hermanson <eric@running-start.com> Date: Tue, 14 Jan 1997 10:25:19 -0800 References: <5be9qd$k2k@nntp1.apple.com> <5bfgth$jfo@baldwin.rat.se> Organization: Running Start, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joakim Johansson wrote: > > Michael D. Rossetti <rossetti@apple.com> writes > > Our preliminary set of objectives for addressing the NeXT opportunity can > > be stated as follows: > > > > 3. Enhancing AppKit through integration of key MacApp concepts. > > Would that mean a new OpenStep spec, or will AppKit be > further changed wrt the OpenStep spec? > (It might be a good idea to have an updated OS spec, but > let's get the first one out and running first, please) I'd like to make something clear. Apple has no power to change the OpenStep spec itself (if it still wants to be compatible with everyone else, that is). The OpenStep spec can only be changed if it is approved by the open standards bodies (I think one of them is OMG in this case). Apple can certainly add proprietary frameworks on top of the OpenStep foundation (much like WebObjects and EOF are proprietary add-ons). Eric -- Running Start, Inc. * Ask About Our Software For: "The Enterprise Developer's Developer" * Workflow http://www.running-start.com * Web Commerce +1-520-760-4890 (4891 FAX) * Request Resolution eric@running-start.com * OPENSTEP/WebObjects/JAVA
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 04:59:38 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c46rq$84c@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1bm1$nhr@duke.squonk.net> Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : raph@porter.as.utexas.edu (William Raphael Hix) wrote: : > Then you are essentially arguing that tar is of little use? If : > this is so, then why bother including it on everyone's disk? : : It is of little use, to me, as a backup utility. : : It is of great use, to me, for downloading (or uploading) : distributions of various packages. I don't think it would : replace stuffit for Mac-ish things, but at the same time : Stuffit won't replace tar for unixy packages (not unless : Aladdin makes a version of stuffit for all unix platforms, : which I have actually asked them to do at times). Except that Stuffit does tar, create and extract. Stuffit and tar really do the same thing, file aggregating, though Stuffit compresses as well and has a nice interface. If I had stuffit on my Rhapsody machine, I wouldn't need tar. Your use of tar seems predicated on a Rhapsody software distribution system like most of Unix. Are you expecting lots of "here's the source code now compile it yourself" apps ported from Unix to Rhapsody? It's fundamental differences in expectations between the Mac and NeXT communities which fuel this thread. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 05:53:45 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c4a19$bja@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : : In any case, there are some (but not all) of those unix utilites : which are used during system bootup, or system shutdown, or other : system functions which *all* users will expect to have. : : I suppose they could separate out the ones they really *need*, and : have an optional installation package for the rest. To me this : seems like a lot of work, but maybe it isn't too bad. If they want : to do this, it won't bother me much -- assuming the system still : boots up of course. : : One thing that might help is to point out that some of this separate : already exists, There are a lot of unix utilities which are in the : developer package, and not the "NeXTSTEP user" package. So, maybe : the current NeXTSTEP situation isn't quite as bad as you think it : is, because some of the stuff is already separated into optional : packages. Such a scheme would allow Apple to maximize its appeal across the range of users. Imagine the following version of basic version of Rhapsody. 1) A Mach 3ish kernal (could be from NeXT, Apple, PPC Linux, Sun) 2) A stripped down version of the BSD emulated services, just the minimum necessary for OpenStep with boot handled by some means other than shell scripts. No CLI app or non-GUI access to BSD commands, to minimize the size of the distribution as well as Apple's potential problems supporting such things to the general Mac community. 3) OpenStep, with DPS, perhaps some QDGX enhancements as the Yellow Box. Sys 7.7 in the Blue Box, compatible with all productivity apps (except perhaps Word and Excel 8-)). This would be MacOS 8, selling for about $100. I think this would satisfy the Mac power users who just want more stability and performance from their Mac, and the home Mac users who just want their Macs to work, but neither of them wants learn anymore about computers than they know already. The price would need to be competitive with Win95 on the desktop. In addition there would be the optional Unix Application Environment (UAE) or perhaps the NeXT Application Environment (NAE) with a CLI app, full use of sed/grep/awk/... and shell scripts to your heart's content, except no ability to edit OS controls outside of the GUI. Perhaps it'd even have a OpenStep 4.2 mode for the appearence manager. This'd be full Unix compatibility (perhaps even with binary compatibility with AIX for PPC apps), except no cc, X11R6, perhaps no NFS. All of these would I'm sure be available from third parties. NAE would cost $100-200 perhaps, giving the current NeXT users a NeXT like system which also runs more commercial software, for I think less than NeXTstep user costs now? It'd also give Macs better connectivity in a Unix environment, and I guess given the work going into Unix-NT interactivity, better NT connectivity. Building on a strong Unix background, but having relatively low cost and great ease of use, this might be able to give NT a good fight. Would this satisfy everyone? Well, not the QD GX devotes or the folks who thinks Unix inside is as bad as Intel inside, even if they never see it. But I think it's still got a chance of satisfying a lot of people, from enterprise and content development to my mom, by being scalable. Hopefully it would avoid the dichotomy Microsoft has between their desktop and server OS. I put this "proposal" out as an attempt to constructively rationalize the hopes of the NeXT community with Apple's current loyal following, so I'd like to hear constructive comments. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 07:13:41 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c4en5$fpj@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <jinx6568-2101971048510001@news.sover.net> Chris Johnson (jinx6568@sover.net) wrote: : I agree with Nathan. Completely. Because we do have good installers, : and this is an ideal situation for a good installer. : Preloads would be a more interesting situation and I daresay if the : utilities are truly auxiliary they would not be included on mass-market : preloads. But you could probably download them as desired. As I said more completely in a previous post, I think such scalable installation is the way to keep everyone happy, though if it's too finally grained it becomes a support nightmare. Perhaps just a basic pure GUI OS for $100, and then an addon which gives CLI, scripts, and the rest, for $100-200 more. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: Drone <foxglove@globalserve.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 02:22:16 -0500 Organization: Envision This Message-ID: <32E5C028.146C@globalserve.net> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > > Oh, that's right. Apple's marketshare is dwindling. Apple's > traditional markets are moving to Windows. Schools, homes, graphics > professionals. Evidently, Apple must not be selling what people want > anymore. Apple isn't even holding on to their *current* customers. > I think Apple should spend some time to find out exactly what > users want. *Not* current Mac users. Former Mac users. Mac users > who have left the Mac for NT, Solaris, Linux, IRIX, whatever. > Obviously, Apple can't grow their marketshare selling to current > Mac owners. Apple has to design Rhapsody for former Mac owners. > Then they have to make it clear that Rhapsody is what they really > wanted, and that they should come back. An Intel port of Rhapsody > would make this easier. > > Let's see. Apple has about 6% marketshare. If Apple can successfully > sell to the 1% of users who want Unix, that would give Apple 7% > marketshare. A 16% increase in Mac marketshare. Furthermore, it's > an increase, which Apple hasn't seen in many moons. > I'm sick of this fallacy. Just because Apple's market share is decreasing, that doesn't mean that Mac users are abandoning the platform at greater rates. Since the majority of any computer market today is made up of those who already own outdated equipment, decreased market share simply means that Mac users are not replacing their systems as quickly as Wintel box users. Considering the massive tidal wave of hardware upgrades required by Windows 95 and Windows NT, at a time MacOS has not had major recent upgrades, this is not at all surprising. But it does not follow that fewer people are using Macintoshes, or that Windows is "winning". All it means is that there's going to be a new rash of dire predictions. Macintosh's problems right now rest in their sluggishness in bringing a new O/S to market. That's not good for their bottom line, since there are fewer upgrades forced by a higher O/S demands on the system. But does nobody see the positive side of this? How many of us have been forced to upgrade our CPUs in the last three years by an O/S revision? Apple is cash-rich so let them take some losses for a few more quarters, I like the mileage I'm getting on my PowerBook. In a year and a half or so, we'll all be buying again with the new O/S. Market share will increase. People will says Apple's back. And the real story (that market share is more closely tied to the timing of software releases than the size of the user base) will still be missing from the popular press. Personally, I hope that Microsoft's bloatware policy continues to the point where Wintel users are replacing their systems every six months. Thus, Mac's "market share" should shrink to about 1%, but with basically the same business and revenue. That will keep Apple healthy until the day Gates is drawn and quartered by the people buying 99% of the new computers each year for no good reason. Drone. -- "esse est percipi" foxglove@globalserve.net
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer Subject: Re: Event handling during tight loop Date: Wed, 22 Jan 1997 01:26:43 -0500 Organization: Demiurge Development Group Message-ID: <32E5B323.4C76@friday.com> References: <32e3b48a.0@192.33.12.30> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: jon klein <jklein@freon.artificial.com> Go look at the BackSpace source... basically, you want a modal event loop that doesn't lock one into modality. Backspace does this very well-- it avoids going all the way up to the main event loop unless some event occurs that it's internal event loop cannot handle. Caveats: Under OpenStep, be sure to maintain your own NSAutoreleasePool within the inner loop or else you will end up with a HUGE wad of unreleased objects when you leave the inner loop... they won't get leaked, but it will eat memory (by growing the processes swap size) and will cause the program to pause on the next pass through the MEL to clean up the accumalated objects. I don't know if it made it to OpenStep, but NeXTSTEP featured a single BOOL return function that would return YES if the user hit Command-. since the last call... it was intended to be used as a user-break signal from within tight loops-- ie; loops that couldn't afford even the overhead of what BackSpace does. b.bum
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: Thu, 23 Jan 1997 02:11:36 -0500 Organization: Demiurge Development Group Message-ID: <32E70F28.48B8@friday.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Scott Anguish <sanguish@digifix.com> Actually, tar really, really sucks as an archive tool... tar was designed for use as an archival tool for writing hierarchies of files to a linear piece of media. As such, it lacks certain conveniences such as 'random access', 'well organized directory information', or any of the other conveniences of, say, Stuffit. Don't get me wrong-- tar provides a certain set of functinality that is both convenient and highly functional... but to say it is superior to Stuffit is ridiculous. If anything, Aladdin should release a version of Stuffit that can be used from the command line... I'd certainly pay for a tool that give me random access to my archives, a full-featured GUI w/drag-n-drop, and a comparably featured command line utility. [Hey, Raymond, remember me? Probably not... I'm the person that fought so, so hard for Stuffit to become an accepted file type on Connect and CompuServe way back in the .7, .8 days... back when that stupid Huffman tool ruled the mac world.] The only real advantage the various Unix tools have over the various tools on other platforms is that they +work+ within an environment that can be scripted (note that easily is nowhere to be found). But-- the user interface is crap and it is quite easy for the user to mean one thing and end up fatally wounding themselves (instead of just piercing their foot). Combine the UI experience of the comparable tools under Mac w/the awesome functionality of the various unix tools and you have one hell of a powerful system that one may actually have a hope of using without hurting oneself. b.bum
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 06:08:09 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c4as9$4m2@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > > > Apparently not, because you are arguing that we should not > > reuse the preexisting code available in the form of the Unix > > utilities, and should instead write APIs and an implementation > > in the C system library for all of those utilities. That is > > the opposite of "code reuse"! > > Until you add in the words "OpenStep on NT". Once that's included > it's clear that modern code indeed offers considerably better > chances for code reuse than the current shell utilities. "OpenStep on WindowsNT" is a product that runs upon an already- existing operating system, which is to say, WindowsNT. OpenStep itself does not include (it the specification) anything about Unix utilities. WindowsNT, the operating system (or environment, whatever) includes many tools similiar to the tools in the land of Unix. Thus, OpenStep did not include Unix utilities. However, in the case of Rhapsody, there is no already-existing operating system. There are no tools which already exist. Thus, if you do not use the unix utilities from something like NeXTSTEP, you will have to get them from somewhere else. Where do you propose to get them? As near as I can tell, you are proposing that someone develops some libraries which reimplement all the same utilities. This might well produce a superior result, but it won't do that by the time WWDC rolls around. Note that I'm serious that I want the abilities which happen to be in the unix utilities, and I want Rhapsody released this year. If you have an alternate source for all these utilities, one which will not delay Rhapsody, that might well be fine with me (depending on how good the replacement is, I guess). However, I think your position would be much more crediable if you could point at a specific alternate source for all these utilities. Note that an answer of "we'll just start from scratch and write them all" would be a particularly foolish position. Unless you can point to the specific set of utilities you would use, we are left to assume you mean "rewrite it all from scratch". --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 06:20:47 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5c4bjv$4m2@duke.squonk.net> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <gmt17KG00iV0A52nk5@andrew.cmu.edu> <maury-2101971151450001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > > > [You] can always decide to not use some API if you don't want to, > > but not having an API available at all means that you will have > > to do more work if/when you needed that functionality. > > Find a message in which I propose that the API's should be removed. > In fact, I've been constantly and unwaveringly suggesting that > all of them should indeed be API's, when in the current case they > are not. The point is that you think unix commands are not an API. Those of us who have written shell scripts are quite certain that unix commands are an API. Crude, perhaps, but effective. An API does not have to be pretty in order to be an API. Thus, when you want to remove unix utilities, you are removing an API. It's an API that you don't care for, but it is still and API. Perhaps most importantly, it is an API which is currently used a lot to boot up the system, run tasks in the background (tasks that the user never types anything in for), and cleanly shutdown the system. If you remove this API, you will have to reimplement all those functions. No one here is saying that Mac users must learn this API, any more than they must learn Hypercard. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 03:38:02 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R2201970338030001@news.erols.com> References: <maury-0801971641590001@199.166.204.230> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5c04e3$gh9@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: >In article <32E30DB4.7126@concentric.net>, >Alan Lovejoy <alovejoy@concentric.net> wrote: > >>Yes, the system() function is a necessity in today's world. >> >>I think the goal of Rhapsody (and all Unixes) should be to continuously >>make it less so over time. Perhaps one day... > >Why? > Why not? -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 03:41:32 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R2201970341320001@news.erols.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <maury-2001971519140001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > That's right, it's all illogical. And the sky is indeed green on my >planet. Happy now? > Ah, you live in central New Jersey do you? ;-) Sorry, just trying to lighten the mood a bit. -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer.tools,comp.sys.next.programmer,comp.sys.sgi.apps,comp.sys.sgi.misc,comp.sys.sun.apps,comp.sys.sun.misc,comp.unix.aix,comp.unix.programmer,comp.unix.sco.programmer,comp.unix.solaris From: Alex Valentine <alexv@noblenet.com> Subject: PR: NobleNet Secure Message-ID: <E4EIzE.2ro@world.std.com> Followup-To: poster Keywords: NobleNet, Client/Server, Remote Procedure Call, RPC, ONC, XDR, TCP/IP, Middleware, Tool, Secure, API, EZ-RPC, Communications, Developer, Software, Windows, Unix, Macintosh, VxWorks, VMS, Internet, Intranet Sender: noblenet@world.std.com (NobleNet Inc.) Organization: NobleNet, Inc. Date: Wed, 22 Jan 1997 08:45:14 GMT PRESS RELEASE For Immediate Release For Further Information, Please Contact: Alex Valentine Director of Product Management NobleNet, Inc. Voice: (508) 460-8222 FAX: (508) 460-3456 e-mail: alexv@noblenet.com NobleNet Secure(TM) Provides Client/Server Application Security New Product Features Patented "Snap-in" Security Module Architecture Boston, January 21, 1997 -- NobleNet announces the availability of its initial entry into the market for securing applications that pass data over networks. Based on industry standards, NobleNet Secure is a highly flexible, modular approach to building secure client/server systems. Using a patented "snap-in" architecture, developers can implement pre-packaged security algorithms or integrate security modules of their choice, including custom algorithms for authentication, privacy, and integrity. Built with an open set of software interfaces, the domestic version of NobleNet Secure includes DES, RIVC4, XOR, MD5 and SHA modules. Application Programming Interfaces(APIs) allow for the integration of custom encryption algorithms, hardware-based smart cards, and both public and private key authentication. NobleNet Secure is a key element of the Optix(TM) document management system developed and marketed by Blueridge Technologies. "For our cross-platform, Internet architecture we needed a state-of-the-art security model and NobleNet Secure was the right solution," said Keith Ellis, Vice President of Sales and Marketing for Blueridge. A major design goal of NobleNet Secure is to provide a general purpose interface that accommodates any encryption method, and to do it in a way that minimizes the performance impact on the application. Higher levels of security typically impose application performance penalties. Solving performance problems with specialized hardware or higher powered computers can be an expensive solution. NobleNet's approach to security recognizes that not all application data requires encryption. Unlike most other implementations, NobleNet Secure allows security to be turned on or off on a per-call basis allowing developers to optimize the balance between security and performance. With NobleNet Secure, only those calls that require security are encrypted, leaving all other data to pass over the network without performance penalty. Being selective at the call coding level provides the developer an opportunity to construct secure applications that might not be possible with other approaches. "NobleNet Secure is ideal for programmers that want to get a quick immersion into secure client/server computing with software that requires very little effort to learn," said Mark Wedge, one of the principal programmers on Business Travel Solutions (BTS), SABRE Decision Technologies' (SM) new high performance on-line corporate travel booking and management project. The SABRE Group is now an independent company with its majority stock holder being AMR Corporation. "The software has a wealth of real-world capability that provides the developer with thorough control of just what is secured and what is passed without encryption. NobleNet Secure's flexibility saves development time and results in higher performing secure applications." NobleNet Secure works with any industry-standard Open Network Computing (ONC) implementation including NobleNet's recently announced RPC 3.0, the world's most advanced RPC environment. NobleNet Secure is currently available on Windows 3.1, 95, and NT, and on most popular UNIX platforms. Pricing is $2500 per platform which includes five end-user seats for application deployment. Additional deployment seats sell in 10, 100, and 1000 unit packages. For Independent Software Vendors (ISVs) desiring to integrate the software within their own product, NobleNet offers a percentage royalty pricing arrangement. NobleNet offers client/server middleware for procedural and object paradigms. Incorporated in 1991, NobleNet is the world leader in Remote Procedure Call (RPC) technology and has won numerous awards for its product family. The company headquarters in Southboro, Massachusetts can be reached by telephone at (508) 460-8222 or at http://www.noblenet.com/. Optix(TM) is a trademark of Blueridge Technologies, Flint Hill, VA http://www.blueridge.com. SABRE Decision Technologies(SM) is a service marks of SABRE Group Holding, Inc., Southlake, TX http://www.sabre.com.
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 05:07:41 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c47at$8o6@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <5c1c3e$nhr@duke.squonk.net> Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : It's not so much that I care about the unix underpinnings of the : current NeXTSTEP product, however I do think those underpinnings : provide many useful abilities. If Apple does not use Unix to do : those things, then they will have more work to do (one way or : another). I do think the abilities are important, and I do not : think it would be brilliant of Apple to start reinventing a lot : of wheels simply so they can say "Well, we kept Unix off our : hardware!". Too much work, for too little payback. : : I'm also of the opinion that if they *do* keep the unix underpinnings, : then they should pick a layout for Unix which already exists, : instead of dreaming up a new one. Note that they do not have to : stick with NeXT's BSD-style layer to do this, they could also use : a layout that mimics Solaris or AIX. The important point is that : the unix layer should look a lot like something which already : exists. : : The reason for this, to me, is that there are many packages with : nice little configure scripts which will break if Apple dreams up : some new layout for unix. I see this as creating work for everyone, : including Apple, and for no good reason. What you are saying makes perfect sense, if Rhapsody was the next generation of OS from a Unix workstation vendor or the true successor to NeXTStep. Apple has not really clearly defined what they want Rhapsody to be, or the future of OpenStep (except to say they will continue to support it). If Apple positions Rhapsody as a desktop OS, competing with Win 95 and NT workstation, leaving the server side to OpenStep then your arguments for Unix compatability are not as strong. Has anyone read any more details from Apple about the projected role of Rhapsody? Inofworld seems to think that the lack of details from Apple stems from exactly these kinds of debates, internally. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Date: 22 Jan 1997 07:21:25 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c4f5l$g5k@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury- mmalcolm crawford (m.crawford@shef.ac.uk) wrote: : On 01/21/97, Maury Markowitz wrote: : : > So which market do they go after? The PC market doesn't want Unix any : > more than the Mac market does. : > : Umm, this jars a little with the success of Linux... Linux is one of those things which USENET gives a better impression of than reality. Don't get me wrong, I like free Unix for common hardware and the grassroots communal development gestalt. It's just that Linux has much more USENET mindshare than real world "marketshare". Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 07:08:23 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c4ed7$fjt@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> Scott Anguish (sanguish@digifix.com) wrote: : On 01/20/97, William Raphael Hix wrote: : >Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: : >: raph@porter.as.utexas.edu (William Raphael Hix) wrote: : > : >Then you are essentially arguing that tar is of little use? : : Sounds to me that what he's saying is that its too clumsy for most : casual users to learn, and that there is a market for a front end to it. : : Tar is of a great use to many people out there, isn't that obvious : since almost everyone is adding its functionality and there are free : versions of it available? : Tar is of great use to Unix users. I use tar on my Unix box to aggregate files which I then compress and download to my Mac where Stuffit uncompresses and untars them. But most Mac users never encounter tar files since Mac software distribution is done by Stuffit/BinHex. But you expect Rhapsody software distribution to work like NeXTStep? Ports of apps from Unix to Rhapsody? This is another of those places there the NeXT and Mac community are talking about apples and oranges (I apologize for the pun). : >If this is then why bother including it on everyone's disk? : : Why? Well, lets see.. : : Its a universally available tool on ALL machines, without depending : on owning a third party product. This means that an Apple user who : downloads something from the Net has a tool to start from. But it doesn't do anything for a Mac user since Mac software in not in tar format. Perhaps for Rhapsody this will change, but I think that you are assuming things which aren't decide yet. : Same can be said for compress, ftp, telnet, etc... And there are software tools available for free or cheap which handle most of these in an GUI fashion familar to Mac users, so CLI version is of no use to Mac users. Will it be the Mac users or the NeXT users who must adapt. Both of course, we just don't know where who will give in. : >Even before the : >new OS, Apple's usurpation of functionality was one of the main complaints : >from developers. Apple is particularly beholden to their developers : >now since without developer support, Rhapsody is OpenStep/PPC. : >... There will be pressure on Apple to drop such functions. : : Then they need to "value add" to their products. : : Even if they drop it from the OS CD, anyone can compile it for it, : and still give it away. : : If they pressure Apple to drop basic functionality like this, then : Apple should tell them to take a leap. : What a NeXT user sees as basic functionality might seem like wasted disk space to a Mac user. Dropping them also reduces Apple's support load, perhaps lowering the cost. If it's a compiled freeware add-on it's not Apple's job to support it. Use it at your own risk. With tech savvy NeXT folks the risks of such are smaller than with typical desktop users. : : >Case #2, the Unix utility A is a "poor" substitute for Mac application B. : >In this case, what is the point of including this utility in the OS? : : Because its required by those who don't have the commercial product. : : Hell, better drop Edit.app from the release, its a RTF text editor, : and the word processor people are going to scream. So Apple is supposed to provide free versions of everything in case you can't afford (or don't want to spend the money on) the commercial version? The economics of a $100 dollar desktop OS are very different from those of a workstation OS. In the case of Edit.app, Apple does provide Simple Text. Should they provide both? : >Unix : >compatibility comes the reply. Well, how important is Unix compatibility? : : Very. To a NeXT user. Too much Unix compatibility might make some Mac users scared, or at least seem like a waste of disk space. : >It's clear from this thread that to NeXT users it's essential. But how : >much does this matter to the Mac community that Apple is pitching Rhapsody : >to? : : Oh, you mean like those piddly companies that have fortune 500 : status? You know, those Enterprise installations Apple HAS to get to get : back into the corporate market? Apple needs to appeal to their current users in order to survive long enough for enterprise to take notice. Besides NeXT demonstrated that even a solid reputation in the enterprise market is not enough to keep a large company or hardware manufacturer alive. : : > Would they rather have the system take up less space or have Unix : >compatibility 99% of them would never use. The feelings of NeXT users : >(none of whom have compatible hardware) are secondary to the 10-100 times : >larger Mac community. : : Well, scr*w you too. Apple has said today that OpenStep for other : platforms will continue to live, so suddenly alot more people become : relevant due to hardware compatibility. : : And again, what if an Enterprise application running on : OpenStep/Solaris or OpenStep/Intel require these tools? Someone needs a new : machine, Apple doesn't ship with the essential tools, so we better just buy : another Intel box with OpenStep/Intel on it. You are taking this too personally. I'm not trying to rain on you parade. Apple has said they will continue to support OpenStep on Intel and Solaris, but I haven't heard anything clear from them about future development, either as Rhapsody on other hardware or independently. Infoworld suggests that wrangling over these options is delaying fundamental choices like which kernal to bring to Rhapsody. But in any event, all such options are in the future. For now Apple has to sell Rhapsody to the current Mac power users if it's to ever get a chance to sell to enterprise or port it to Intel hardware. Apple did not buy NeXT to get the 50,000 yearly sales of OpenStep. It might want to use this as an entree into the enterprise market, but first it has to show that Rhapsody works and that it won't die off. This requires support from the Mac community. : > : >What about find? Should Apple leave the Unix find when we know they're : >going to include their new V-Twin search engine and Find File. Well, the : >V-Twin certainly replaces find if you are a GUI user, but what about CLI : and : >scripts? Will Apple leave find for the 1% of users who might want to : >use their Mac like a Unix box? : : Do you have ANY proof of your 1% number? Are you just grabbing at : air? OK.. Apple removes a whole boatload of unix tools.... which means that : those users who want to do things like run off-the-net stuff like Apache, : INN, sendmail, all those other great Unix server programs are going to have : to go through a hoop routine to install it? The 1% number is based on estimates of Linux installations on PCs. Perhaps it should be a few %. It sounds like you really want Rhapsody to be a cheap Unix, like a supported Linux. Mac users install Mac versions of servers. Some are free, some cost money but are supported. If you want Linux, get Linux. Don't ask millions of Mac users to accept Linux. : : Will Apple prohibit compiling and distribution of find then? Who : gets hurt by Apple including it? : : And what if someone writes a really cool freeware utility that uses : find... do they have to supply it? Of course Apple will not prohibit or inhibit distribution of any software. Apple just won't support it. I can just imagine calls to Apple which get answered, "Well you need to add -print to tell it to print the list of files it finds." Use at your own risk. : >Naturally, every real example is somewhere in between, but both of the : >extreme cases argue against strong Unix compatibility. : : Yeah, compatibility is bad. :-| Personally, I'd love Unix compatibility in my Mac, so all the Unix skills I have at work could be put to better use at home. But Apple isn't pushing Rhapsody for us tech-heads, it's got to appeal to a wider base that couldn't care less about Unix compatibility. : : CyberDog is bad. It hurts Eudora and other mail companies, better : kill it now. Apple did get pressure not to do Cyberdog, but evidently decided that the time had come for an least primitive systemwide Internet services. Perhaps for Rhapsody they'll add Unix compatibility to the list of things necessary to the OS. : sendmail, that might piss off a mail-gateway company : ppp - hell, someone might want to make a commercial version : ftp, sed, awk, perl, - all useful, but might tread on someone's : toes, gotta kill them. : : ftpd, httpd, Apache, INN - all server products that will compete : with other products. They're free here, gotta kill them too. Most of these would not be used by enough users to justify inclusion in the OS. Mac equivalents for most of the rest are available for free, some from Apple. If it wasn't and there was demand, someone would have ported it. Oh, but you want these exact versions. Get a Linux box then. Mac users are largely happy with what they have, if only it'd run stably, in protected memory with pre-emptive multitasking. : >It will be : >interesting to see how Apple resolves this. Perhaps some add-on Unix : >compatibility, even from a 3rd party. : : And lets not forget it will be free. Last time I heard OpenStep was far from free. It really sounds like you want Linux. I doubt you'll be happy with the outcome, because the OS is going to cost > $100 with or without complete BSD. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: mullere@in2p3.fr (Eric Muller) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 22 Jan 1997 10:52:28 GMT Organization: Laboratoire PHASE, Strasbourg, France Message-ID: <5c4rhc$o1k@ccpnws.in2p3.fr> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> Bill Bumgarner (bbum@friday.com) wrote: (some stuff deleted) : If anything, Aladdin should release a version of Stuffit that can be : used from the command line... I'd certainly pay for a tool that give me : random access to my archives, a full-featured GUI w/drag-n-drop, and a : comparably featured command line utility. If you use MPW you can have the Stuffit tools, they come with Stuffit Deluxe. So all you have to do is buying MPW (it come with CodeWarrior, MrC compiler and with the developper program from Apple) and Stuffit Deluxe. Personnaly I prefer to use Stuffit Expander with drag and drop than the MPW tools. -- Eric Muller, thesard au laboratoire PHASE, Strasbourg. Un Mac sinon rien! e-mail : mullere@in2p3.fr
Newsgroups: comp.sys.next.programmer From: Markus G <markusg@burrow.muc.de> Subject: Re: Emacs for OpenStep Content-Type: text/plain; charset=US-ASCII Message-ID: <7x4tgay96w.fsf@burrow.muc.de> To: Bill Bumgarner <bbum@friday.com> Sender: tm@burrow.muc.de (the mole) Organization: hardly any. . . References: <32E52CE3.1A0B@friday.com> Mime-Version: 1.0 (generated by tm-edit 7.92) Date: Tue, 21 Jan 1997 22:06:47 GMT >>>>> "BB" == Bill Bumgarner <bbum@friday.com> writes: BB> BTW: I installed the package from next-ftp.peak.org, but it BB> just gives a bus error upon launch. I also got a bus error when launching Emacs from the command line without supplying a file name (under 3.3, though). As far as I remember any of the following things fixed it for me (all out of my .emacs): (require 'ns-compat) ; settings for Emacs when run under the GUI: (cond ((eq window-system 'ns) ;;; NS specific instructions (setq gnus-display-type "grayscale") (global-font-lock-mode t) (setq ns-convert-font-trait-alist '(("Courier" "Courier-Bold" "Courier-Oblique" "Courier-BoldOblique"))) ) (t ;;; Instructions for dumb terminal or other window systems ;;; nothing here yet. )) While I'm at it. The following settings are also useful: (setq Man-switches "-M /usr/man:/usr/local/man:/usr/local/lib/perl5/man:/usr/gn\ u/man") (setq text-mode-hook '(lambda () (auto-fill-mode 1))) ; whenever using text-mode ; Enable auto-fill-mode Anyone with more suggestions? Hope this helps, Markus G
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 10:16:14 GMT Organization: University of Sheffield, UK Message-ID: <5c4pde$s64@bignews.shef.ac.uk> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> In-Reply-To: <maury-2101971324190001@199.166.204.230> On 01/21/97, Maury Markowitz wrote: > In article <5c2r53$3i3@bignews.shef.ac.uk>, mmalcolm crawford > <m.crawford@shef.ac.uk> wrote: > Linux seems to be used on about 1% of the machines in the world > according to something I read once. Who knows if it's true, but it's > running on one machine at work out of a couple hundred. > Fine. However your original message said: "The PC market doesn't want Unix any more than the Mac market does." I submit that Linux's success refutes this statement, and your subsequent post does not alter this. Clearly *some* people *do* want Unix. And in some cases are prepared to go to some lengths to get it too. Best wishes, mmalc. --
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Tue, 14 Jan 1997 16:01:47 -0800 Organization: Bridge Family Distribution: world Message-ID: <abridge-1401971601470001@dcn138.dcn.davis.ca.us> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> In article <toolz-1101972317210001@news>, toolz@homenet.ie (Neil O'Toole) wrote: > > > > I humbly suggest that Java provides much of the advantages of Objective-C > > plus provides automatic garbage collection, a big win. Some of the languages > > you list above support automatic GC also, but for programmers accustomed to > > C-based languages, automatic GC is very attractive. > > -- > > I don't know much about Objective-C but... the one question I have is, > does Obj-C support multiple inheritance? > > > I humbly suggest that Java provides much of the advantages > > Java the language, (as opposed to Java the technology) in it's current > incarnation is something of a joke. No multiple inheritance - therefore > it's very limitied and/or annoying. > > I know java has its interfaces "to protect ppl from the complexities of > multiple inheritance" (it said somewhere), but hell, let ppl who are > scared of "the complexities" use interfaces, and at least give me the > option of using multiple inheritance. > > Hope someone reads this before they finalise the java language spec. > > Neil. Issues related to multiple inheritence are religious in nature. As a Smalltalk sorta guy I never miss it. Does that make Smalltalk a joke as an object-oriented language? I don't think so. It doesn't make Java a joke either. It's a different way to design object-oriented systems. That Objective-C might not support multiple inheritance doesn't make it a bush-league language. Adam Bridge
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.mac.advocacy,comp.sys.next.advocacy Date: 22 Jan 1997 10:24:21 GMT Organization: University of Sheffield, UK Message-ID: <5c4psl$sdl@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> In-Reply-To: <maury-2101971155550001@199.166.204.230> On 01/21/97, Maury Markowitz wrote: > > For example, CMU has hundreds of Macs in the clusters > > with a very consistent filesystem layout. > > Bully for them. I believe you'll find that your experiences in > university and the commercial world will be largely different. > Why? Best wishes, mmalc. (Followups trimmed to advocacy groups) --
From: Steve Spicklemire <steve@spvi.com> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 06:07:54 -0500 Organization: Silicon Prairie Ventures Message-ID: <32E5F50A.2637@spvi.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu> <maury-2101971141510001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > > Great, so have a check box in Custom Install that states "Install Unix > shell utilities" and you can do all of this? This is getting really > repetitive. > in another article in this thread Charles William Swiger wrote: > > Okay, I'm willing to agree with that to an extent. However, your > Smalltalk IDE is not going to be able to provide the flexibility behind > the shell, such as emailing all files ending in '.gif' to somebody in > the way that: > > system("tar cf - *.gif | mail .... ) > > ...would do. > OK.. so what happens when I get my shiny new GUI app that expects 'system("tar cf - *.gif | mail .... )' to work and the user neglected to install 'tar'? Are all these unix utilities so enourmous that we really want to risk breaking so much code? I would think the whole spiel compares in size (more or less) to a complete installation of any modern office productivity suite. :-) -steve -- ---------------------------------------------------------------------- Steve Spicklemire Silicon Prairie Ventures, Inc. (and) University of Indianapolis steve@spvi.com steve@estel.uindy.edu
From: jack@radionics.com (Jack Miller) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 21 Jan 1997 10:54:20 -0500 Organization: RSA Message-ID: <jack-ya023480002101971054200001@news.tiac.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> <5c2n6k$1l8@bignews.shef.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5c2n6k$1l8@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > > If you could make Unix functionality a part of the new OS without *forcing* > > users to deal with these things, so they wouldn't need to see or use them > > unless they really *wanted* to, then I wouldn't mind. But what I saw of > > NeXTstep a few years ago didn't work that way, and the comments I've seen > > here suggest that it hasn't changed in this respect. > > > I know of many NEXTSTEP users who don't know anything about Unix, and never > will. They tend not to post here, though. What exactly was it about your > encounter that gave you the idea that you *needed* a CLI. When was this? In addition, Apple's been very clear about the fact that they will hide any unixy remnants in Rhapsody. Even if NextStep DID require any CLI use (which, I'm told, it doesn't), Rhapsody would not. (Personally, I wouldn't mind being able to access a unix CLI from Rhapsody... the one thing I would love to be able to do on my Macs but can't is manipulate files using wildcards. Yes, I know that Find File with the Finder Scripting Extension allows much of this functionality and more, but to me it's not as simple as 'mv hm4*gif ..') Cheers, xxx hj xxx
From: Rainer Frohnhfer Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: 15 Jan 1997 12:07:52 GMT Organization: University of Wuerzburg, Germany Message-ID: <5bihao$a0j@winx03.informatik.uni-wuerzburg.de> References: <maury-1401971143490001@199.166.204.230> <5bgrvs$pib@shelob.afs.com> Greg_Anderson@afs.com (Gregory H. Anderson) wrote: > Maury Markowitz writes > > I'm curious, why the NSxxx class names? I know the historical context, > > but is this important today? Seems somewhat unpleasing to the eye. > > To avoid namespace collisions, it is typical for each vendor of objects > to adopt a 2 or 3 letter prefix identifying the author in the class name. > Otherwise, two ISVs might both write a "Foo" class, which could never be > used together in the same project. "NS" is the prefix NeXT chose for its > own classes. And I wish they had not. In Germany, "NS" usually refers to the National Socialists (i.e. Nazis), when used in a term like "NS-regime". Now, what is a NSWindow? O.K., I guess it's clear that there won't be any mixup :) -- ------------------------------------- "Um Energie zu sparen, wird das Licht am Ende des Tunnels vorlaeufig abgeschaltet." rainer@mathematik.uni-wuerzburg.de (finger cip@mathematik for public key ...)
From: tbutler@tfs.net (Travis Butler) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 07:03:38 -0600 Organization: The Wandering Powerbook... Message-ID: <AF0B6C4A966812791F@node26.tfs.net> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> In article <5bsipf$l4g@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: >In article <jinx6568-1601971429460001@news.sover.net>, jinx6568@sover.net (Chris >Johnson) wrote: > >> > Mac users should note that the desktop on NEXTSTEP, when using an >> > extension like Fiend, is _not_ part of the filesystem. Every icon you >> > see on the desktop resides somewhere else, like aliases. I suppose this is no surprise by now, after the screeds I've made :), but I can't say I like this, just as I didn't like the equivalent setup in Win 3.1. As I understand it, part of the whole GUI/Desktop/OO paradigm that Apple used is that when you manipulate icons on the desktop, you're manipulating the actual files/items. Making desktop icons no more than pointers to the original files is confusing: in some places in the OS (i.e. the NeXT browser), icons *do* represent files, and manipulating them manipulates the files; in other places, they're only aliases, and they don't affect the original files. I think Apple did the right thing in making aliases explicit creations, and putting their names in italic to distinguish them from regular files; you *know* there's a difference between an alias and a file, and you have an obvious visual cue to distinguish them. >> Where are drive icons kept? > >There are no drive icons. Unix drives look like folders; they're >mounted directly into the filesystem wherever you want (and have >permission to put them). For example, you could have all your users' >directories stored on another drive and mount it as the /Users >folder. You literally can't tell what drive a folder is stored on >unless you open up an inspector. Hmmm. I can see both advantages and disadvantages. If you're running on a fairly static system, with little or no changes to the mounted disks, this can be a big advantage, since you don't have to worry about what file goes where; OTOH, dealing with removable media (or drives that are regularly switched between systems) would be a real nightmare. (That's also much the same way the Newton OS works with data, by the by; data objects (notes, for example, or contact records or appointments) stored on a PC card are inserted into the 'soup' of their respective applications when the card is inserted, and removed when the card is ejected. Again, a mechanism that could be convenient at times, and a real nuisance at others.) >There are some generic icons for removable media like floppy disks and >CD-ROMs that the File Viewer uses instead of a folder icon when you >insert one; those are probably stored in the Workspace's app wrapper. Hmmm. Does that mean items on removable media are *not* inserted into the regular directory tree when you insert a cartridge? Combining a reply to another message in the thread... In article <5bofh1$g3f@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: >In article <maury-1701971144500001@199.166.204.230>, maury@softarc.com (Maury >Markowitz) wrote: > >> If all the applications called the API's (notably if those API's were >> clean and OOPS based) there seems to be no use for the shell and utils >> except for scripting. > >Or for the people who prefer using a CLI to a GUI in order to perform >some tasks. Perhaps; but as I've been saying throughout, how many people is that? Is it worth keeping the underpinnings for a CLI for the small percentage of people who want it, if it clutters the system for the majority of people who don't? (More on this below.) As much as I dislike Windows, I'm tempted to use it as an example; you could interpret the explosion of Windows-based programs, with the corresponding withering of the DOS market, as an overwhelming user preference for GUI's. I admit I'm probably biased; I dislike CLI's, prefer GUI's... and the Mac was built from the ground up as a GUI system in exactly the way we're discussing. From the beginning, Mac programs have been calling shared interface and utility code through the Mac Toolbox API's. Scripting is the only area where CLI underpinnings might be an advantage, IMHO... and even there, there have been macro utilities to drive the GUI since... when were QuicKeys and Tempo introduced, 1988? And AppleScript and other Open Scripting Architecture-based languages like Frontier have given the MacOS high-level, object/event-based scripting since '92 or '93. >> Lots of code examples posted here to bolster the "we need grep >> because..." indeed do exactly this, stream their parameters to text >> and send them out to the shell. grep comes to mind, I'm sure you can > >You don't have to send them out to the shell, you can fork 'grep' >directly. grep isn't a bad example, actually. Um, I think you're missing or avoiding his point. I think he's right: most of the arguments in favor of the CLI utilities have been doing exactly what Maury is describing, citing the desirability of calling CLI utilities from programs as if they were being invoked from the shell. >> Then they claim this is a good thing, that you can do this. My point >> is, and has been, that thse utilties, like every other one, should be >> directly accessable via API's, preferably OOPS based ones. > >It is certainly cleaner that way. I would like to see more Unix >utilities have their core functionality folded out into separate >libraries, with the CLI utils being mostly wrappers to those APIs. >However, practically speaking, it is just plain a lot less work to put >OOP wrappers around existing CLI programs. Maybe we will eventually >see a bunch of Unix utils make the transition (for example, GNU has a >regular-expression library that a number of their programs share), in >reality wrappering CLI programs is often nearly as good and requires >less effort. Again, I'm probably biased, because the Mac was built from the ground up as you describe, with the functions provided as OS library API's called by applications. I also admit to an emotional dislike for GUI-driving-CLI, for several reasons. GUI-driving-CLI always felt like a Rube Goldberg contraption to me: it adds a layer of complexity to what could be direct library calls, it adds another link in the execution chain (and thus introduces another opportunity for things to go wrong), adds overhead from the extra steps of generating CLI commands and then having the shell execute them... and just feels less elegant on a gut level. You yourself note that it is only 'often nearly as good'... not 'always,' or 'just as good.' Also, every GUI-driving-CLI system I've seen has had 'holes' where the developers didn't provide a GUI shell for a CLI command... so that a user has to learn the CLI to get some things done. The Mac GUI lets you do *everything* - either directly or through GUI utilities. Travis Butler (The Professor, formerly of Myth and Magick!, Lawrence, KS; tbutler@tfs.net, now from the Wandering Powerbook; <http://www.tfs.net/personal/tbutler/>; Mac page <http://www.tfs.net/business/tbutler/>) ...Cats are the proof of a higher purpose to the universe.
From: tomstiller@macconnect.com (Tom Stiller) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: Wed, 22 Jan 1997 07:55:01 -0500 Organization: David Sarnoff Research Center Message-ID: <tomstiller-2201970755020001@quixote.sarnoff.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> <5c4rhc$o1k@ccpnws.in2p3.fr> In article <5c4rhc$o1k@ccpnws.in2p3.fr>, mullere@in2p3.fr (Eric Muller) wrote: >Bill Bumgarner (bbum@friday.com) wrote: >(some stuff deleted) >: If anything, Aladdin should release a version of Stuffit that can be >: used from the command line... I'd certainly pay for a tool that give me >: random access to my archives, a full-featured GUI w/drag-n-drop, and a >: comparably featured command line utility. > >If you use MPW you can have the Stuffit tools, they come with Stuffit Deluxe. >So all you have to do is buying MPW (it come with CodeWarrior, MrC compiler >and with the developper program from Apple) and Stuffit Deluxe. >Personnaly I prefer to use Stuffit Expander with drag and drop than the >MPW tools. StuffIt Deluxe includes a Control Panel called True Finder Integration (tm) which allows any (finder recognized) StuffIt archive to be manipulated like a folder. When it is enabled, you can double-click the archive to open it and navigate the subdirectories contained within it. If you drag a folder or file to another location, it will be unstuffed as it is moved. It seems like everything the original poster wanted. Tom Stiller -- Everyone is entitled to my opinion
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer Subject: Re: ObjC Vs C++ (NextStep & Mac Frameworks) Date: Tue, 14 Jan 1997 11:43:49 -0500 Organization: Atria Software Distribution: inet Message-ID: <maury-1401971143490001@199.166.204.230> References: <E3nHrL.1tB@cam-ani.co.uk> <5b6dno$goj@news.next.com> In article <5b6dno$goj@news.next.com>, Eren_Kotan@next.com wrote: > id myArray = [NSArray arrayWithObjects:@"One", @"Two", @"Three", nil]; I'm curious, why the NSxxx class names? I know the historical context, but is this important today? Seems somewhat unpleasing to the eye. Maury
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: 22 Jan 1997 15:05:36 GMT Organization: University of Sheffield, UK Message-ID: <5c5ac0$66a@bignews.shef.ac.uk> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> <maury-2001971514370001@199.166.204.230> <32E403A3.788@concentric.net> <maury-2101971129150001@199.166.204.230> In-Reply-To: <maury-2101971129150001@199.166.204.230> On 01/21/97, Maury Markowitz wrote: > Not in my case, my _only_ interest is the utilities. The kernel is fine > the way it is, and there are lots and lots of direct calls to other Unix > API's that seem just fine the way they are too. > > This thread is specifically about those utilities, they should be better. > I'm completely lost now... What utilities? And how should they be better? You've said you *don't* want to rip out the CLI either, so could you please explain again exactly what it is that you do want to rip out? Just all those annoying little files in /bin? Best wishes, mmalc. (Followups trimmed) --
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 15:09:23 GMT Organization: University of Sheffield, UK Message-ID: <5c5aj3$66n@bignews.shef.ac.uk> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <scottm-ya02408000R2201970341320001@news.erols.com> In-Reply-To: <scottm-ya02408000R2201970341320001@news.erols.com> On 01/22/97, Scott Maxwell wrote: > In article <maury-2001971519140001@199.166.204.230>, maury@softarc.com > (Maury Markowitz) wrote: > > That's right, it's all illogical. And the sky is indeed green on my > >planet. Happy now? > > > Ah, you live in central New Jersey do you? ;-) > No, I think he's just standing on his head... Best wishes, mmalc. --
From: Stefano Pagiola <spagiola@worldbank.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 09:22:40 -0500 Organization: World Bank Message-ID: <32E622B0.4136@worldbank.org> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> <5c2n6k$1l8@bignews.shef.ac.uk> <jack-ya023480002101971054200001@news.tiac.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jack Miller wrote: > > In article <5c2n6k$1l8@bignews.shef.ac.uk>, mmalcolm crawford > > > If you could make Unix functionality a part of the new OS without *forcing* > > > users to deal with these things, so they wouldn't need to see or use them > > > unless they really *wanted* to, then I wouldn't mind. But what I saw of > > > NeXTstep a few years ago didn't work that way, and the comments I've seen > > > here suggest that it hasn't changed in this respect. > > > > > I know of many NEXTSTEP users who don't know anything about Unix, and never > > will. They tend not to post here, though. What exactly was it about your > > encounter that gave you the idea that you *needed* a CLI. When was this? Here's one long-time NeXT user (since 1991) that knows just the bare minimum about Unix. Enough to use some of those Unix utilities which do not have a GUI equivalent, in the rare cases that I need to. (Example: after my hard disk crashed, I lost my backup software along with a lot of other things. I downloaded a new version from the net, but of course it was compressed. How do I uncompress the app whose purpose in life it is to help me uncompress files? I spent 2 minutes learning the bare minimum I needed to know about tar (with some help from friendly netizens), uncompressed the app, and promptly started using it rather than tar for all my future uncompressing needs.) -- Stefano Pagiola 850 N Randolph Str No.817, Arlington VA 22203, USA All opinions are my own and do not necessarily reflect those of my employer
Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer From: hans@vuur (Hans Mulder) Subject: Re: Librarian replacement Message-ID: <E4F1x0.FBp@icgned.nl> Followup-To: comp.sys.next.advocacy,comp.sys.next.programmer Sender: news@icgned.nl Organization: IC Group References: <5b5j42$bh7@bignews.shef.ac.uk> <32D6864C.5DE6@steeldriving.com> Date: Wed, 22 Jan 1997 15:34:12 GMT In <32D6864C.5DE6@steeldriving.com> Jonathan W. Hendry (jon@steeldriving.com) wrote: >Doesn't the new 4.0 Project Builder perform some sort of indexing? >Does that use parts of the Indexing Kit? Yes, the 4.0 Project Builder performs some sort of indexing, and it uses the Indexing Kit. Unfortunately, the Indexing Kit has not been ported to NT or Solaris, so those options in Project Builder's "Find" panel that use it are disabled in the NT and Solaris versions. -- HansM
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 16:23:29 GMT Organization: Airwindows Message-ID: <jinx6568-2201971125520001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <maury-2001971529140001@199.166.204.230> <5c1cb7$nhr@duke.squonk.net> <maury-2101971209420001@199.166.204.230> In article <maury-2101971209420001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > Asside from the fact that it would say "InputSproket shared library" > rather than "grep"? Or that programs could call them directly rather than > forking? Or that they would have OOPS interfaces? Isn't forking preferable when you consider a multiprocessing system that could toss the forked process off to another processor? I really doubt Apple and the NeXT wizards are going to overlook _that_ one, particularly since two and four processor Macs are already out there. Jinx_tigr (aka Chris Johnson)
From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: Wed, 15 Jan 1997 13:28:49 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <kmrG7VK00iV945mAVH@andrew.cmu.edu> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <milkweed-1501970042260001@port5.chester.smallmedia.com> In-Reply-To: <milkweed-1501970042260001@port5.chester.smallmedia.com> Excerpts from netnews.comp.sys.next.programmer: 15-Jan-97 Re: Mult. Inh. in Objective.. by Anders Pytte@plainfield. > Thanks for the info - I admit I am unsure of the size and performance > advantage of C++, since I have not done comparisons. Until you encounter a problem or do your own testing, may I suggest that you not worry about these issues? The general consensus around here is that Obj-C developers don't run into problems with the size or speed of Obj-C executables. > But you have misunderstood my intent. I have nothing at all against Obj-C, > in fact, I am excited by it. I did not mean that I feared giving up > programming habits, rather that I am accustomed to compensating for > shortcomings of languages through good design and good programming habits. Okay, so far, so good. I think you'll find that you don't need to compensate for the language nearly as much using Obj-C as you have to do in C++. We can also hope that the combination of Apple's and NeXT's resources will be able to improve the development environment even further. I hope they learn some things from Java and Delphi, although I'd rather have significant changes appear after the first release or two. > I would need to do the same with Obj-C due to its lack of explicit > multiple inheritance, operator overloading, etc. (am I correct here about > Obj-C?). And I don't want to hear any more bullshit about my being better > off without those features - when correctly used they enhance code design. Sure. Obj-C itself does not support MI or operator-overloading, but Obj-C++ does. People using pure Obj-C generally seem to use forwarding and delegation mechanisms, and/or protocols and categories in places where C++ programmers would use MI. I think Obj-C programs are much more understandable and much more maintainable than the comparible C++ versions. As for operator overloading, I regard that as potentially one of the greatest causes of problems in C++, for the reason that it creates a heavyweight context or dependancy on the aggregated program environment which makes code difficult to reuse in a simple fashion. This is one of the reasons that large C++ frameworks are hard to understand, debug, and never seem to be delivered on time. Primary example: Taligent. But if you want to write code which uses operator-overloading, you can. > My point is that choice of language is not as important as good > programming habits and good code design. Each language has its die-hard > advocates, ofcourse. But I expect that many like myself take the following > pragmatic view: > > 1. I want my current (huge) code base supported (atleast for a while). While it's up to Apple now, I would certainly hope that they will give you this. I believe they can, since NEXTSTEP already had the ability to integrate ObjC and C++ code for a while, now. > 2. I will use whatever language has the best support and most promise for > a given platform (or especially for multiple platforms). There are some nice aspects to Java (especially the package hierarchy for multiple namespaces), but it is not nearly as mature as Obj-C and the object libraries available for Obj-C. > If Apple blesses Obj-C, and I can use it (efficiently) to advance our > existing products and port them to other platforms, then i will bless > Obj-C too. Et Domine dixit: fiat absolvo, fili. :-) [ And my apologies to any Latin purists, since it's been _way_ too long to remember how to spell the declensions perfectly. ] -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: bstone@acs3.acs.ucalgary.ca (Blake Stone) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Date: 22 Jan 1997 15:57:02 GMT Organization: The University of Calgary Message-ID: <5c5dce$f0q@ds2.acs.ucalgary.ca> Maury Markowitz (maury@softarc.com) wrote: > In article <5c17j7$1e44@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca > (Blake Stone) wrote: > > Apple has 6 months to get a developer's release out. In that > > time do you honestly believe they're going to design, write, > > test, and document an API to replace all of UNIX's command line > > functionality? > Can you find a single post in which I advocated this? Why else would you post, in an advocacy form, in the midst of a discussion on Apple's future OS plans: "In fact, I've been constantly and unwaveringly suggesting that all of them should indeed be API's, when in the current case they are not." > > I would love to see a brilliant OO API for every conceivable > > need, but I'm not holding my breath waiting for it to happen. > And as long as everyone shares this opinion, it will never get > better. You start holding your breath, and we'll see just how fast it gets better :-) I'm not sitting around waiting for it to happen. Instead, I wrote the ThreadKit for OOing the threading APIs in Mach. I wrote a standard object interface for card games, which became the definitive NeXTSTEP Solitaire. I wrote object interfaces to hide the differences between CGI and ISAPI. I've translated the object interfaces to DirectX to Delphi. I've written wrappers to hide MAPI behind an object interface. I'm making it better as fast as I can. I just don't expect to be done any time soon. What have you been doing? -- ------------------------------------------------------------------------- Blake W. Stone bstone@dkw.com Technical Director - DKW Systems "Art may imitate life, but life http://www.dkw.com/bstone imitates TV" - Ani Difranco
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 17:02:50 GMT Organization: Airwindows Message-ID: <jinx6568-2201971205130001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> In article <maury-2001971522480001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5bshs8$e5n@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > I don't know anyone who does this. Even the Mac > > people tend to put everything in the Applications folder or a > > subdirectory of it. > Balogna, I can't think of a single Mac I've every had the pleasure of > using that had all of it's programs arranged such, and that's a large > number of Macs (in the hundreds). That's just _wrong_. Actually it beats putting everything in the desktop folder ;) I said once and I'll say again, I could deal with having to put everything in the applications folder if I decided to treat it like it was a hard disk. It's very simple. Instead of having the hard disk icon on my screen, I'd have the application folder icon on my screen. Open it and it would look like a hard disk, with apps, documents, organized as I wanted them to be. Interestingly, if multiple people had separate applications folders and had them set up differently (perhaps with aliases/symbolic links for shared things so you could have the same thing in two different positions) then you'd have entirely separate customizable environments for each user, with the other user's files hidden from the first user (or revealed as 'another folder'). I could usually hide .bin and .etc etc etc, but in this paradigm if I showed them they would appear as other 'hard disks/folders/whatever' on the desktop. That would work, I do not require that my system files be visually contained in a folder that represents my hard disk. In fact some of the disk techniques like logical volumes etc. tend to break down the concept of 'hard disk icon' anyhow. It's _all_ a visual metaphor, an illusion, it's just in how you present it. Jinx_tigr (aka Chris Johnson)
From: Michael Hudson <sorry.no.email@nowhere.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Wed, 22 Jan 1997 17:31:35 +0000 Organization: University of Leicester, UK Message-ID: <32E64EF7.3D6A@nowhere.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Greg Titus wrote: > > Michael Hudson <sorry.no.email@nowhere.com> writes: > > >I have just read in excess of twenty posts about "Multiple Inheritance > >(Re: NextStep & Mac Frameworks)" that discussed the relative merits of > >Objective-C and C++. > > >Does Objective-C have templates? > > Nope. Don't need 'em. Templates are a hack to get around the > limitations in C++'s strong binding. When you want to manipulate > objects in a generic way in Objective-C you just declare your > arguments as "id" (any object), and the same method works for > everything instead of the compiler making multiple copies of the code > for every type of object you might use. [snip] > >The STL > > No, a lot of equivalent functionality is in NeXT's Foundation > framework. > OK. Can you write me a short bit of code that would sort an array of any type in Objective-C? (I don't really want a complete quicksort algorithm, but somethnig that shows it would be possible) -- Regards, Michael Hudson Please don't email this address - it's not mine.
Date: Wed, 15 Jan 1997 13:31:12 -0600 From: marko@wgatg.com Subject: Re: DPS Hit Detection Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.misc Message-ID: <853351061.18559@dejanews.com> Organization: Deja News Usenet Posting Service References: <5bg2e0$ar2@bignews.shef.ac.uk> <AF00F4DB-4F859@198.68.42.175> <32DBDD3C.1EBAB5AF@screaming.org> <5bh10q$c1s@bignews.shef.ac.uk> <rex-ya023080001501970056130001@nntp.ix.netcom.com> In article <rex-ya023080001501970056130001@nntp.ix.netcom.com>, rex@mit.edu (Eric King) wrote: > Thanks for the info, unfortunately this is still requires quite a bit > more work than the GXHitTest**** family of functions. Boolean hittesting is > useful, but its nowhere near as useful as being able to hit test a graphic > structure and then given the object or objects that were hit. It looks as > if I'd have to implement several layers of abstraction on top of the PS > code defining the appearance of my widget. Ultimately what I want and what > GX provides are hierarchical container shapes that know which part of them > has been hit (with adjustable tolerance and depth :)) and which object in > my app that part is associated with. This is a true time saver. Eric: Now I see the misunderstanding here - we NeXT folks are perplexed about what's lacking in the hit testing, and you all are surprised that that's all there is to DPS. The missing piece of information though is that with NEXTSTEP/OpenStep, we use nested NSView subclasses for drawing, and "hit detection" is already provided for these - a view that is clicked receives a mouseDown: message if it wants. Furthermore, through a mechanism called the "responder chain," if a nested View fails to acknowledge a hit, then its superview is given the opportunity to acknowledge it. There is no real work involved here - you just implement the method and you'll receive notification of a hit within your bounds. If you need to specialize the hit test however, you just override the mouseDown: method and perform a geometric test, or as a fallback for complex shapes, use the DPS hit test routines (which for us serve to complete the business of hit detection, they aren't the sole source of hit detection mechanism). Mark -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 15:42:14 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R1501971542140001@news.erols.com> References: <5ami95$ol3@news.tuwien.ac.at> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.ee.uwa.edu.au <scottm-ya02408000R1401972248330001@news.erols.com> <5bj39f$lco@crl.crl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5bj39f$lco@crl.crl.com>, mcgredo@crl.com (Donald R. McGregor) wrote: >But really, the existing system works pretty well. Put shared apps >in /LocalApps, personal apps in ~/Apps. Fixing this should be >a pretty low priority, maybe deffered until there's some sort of >object store. > True. Personally, I hope they spend some time integrating file/creator types into the system so extensions aren't necessary. That's more annoying to me (personally) than much else. -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 13:00:13 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E655AD.55D3@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Travis Butler wrote: > Also, every GUI-driving-CLI system I've seen has had 'holes' where the > developers didn't provide a GUI shell for a CLI command... so that a user > has to learn the CLI to get some things done. The Mac GUI lets you do > *everything* - either directly or through GUI utilities. No, the Mac GUI does not let you do *everything*. If there is something that is not in the GUI, you *cannot* do it. Unless, of course, some nice programmer comes along and writes a program that lets it happen. -- Jonathan W. Hendry jon @ exnext . com
From: Pascal Chesnais <pascal@mit.edu> Newsgroups: comp.sys.next.programmer Subject: mktime() Date: Wed, 22 Jan 1997 13:32:20 -0500 Organization: MIT Media Laboratory Message-ID: <32E65D33.446B@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are having problems here with mktime under nextstep 3.3 has anyone else run into this? Putting today's time gets us a wrong return value (on the order of 3 year!!!) pasc
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 13:20:18 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <UmtZdWi00iV_Q6I_8Z@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c4a19$bja@geraldo.cc.utexas.edu> In-Reply-To: <5c4a19$bja@geraldo.cc.utexas.edu> Excerpts from netnews.comp.sys.next.programmer: 22-Jan-97 Re: MacWorld Exclusive: App.. by William Raphael Hix@port > 2) A stripped down version of the BSD emulated services, just the minimum > necessary for OpenStep with boot handled by some means other than shell > scripts. No CLI app or non-GUI access to BSD commands, to minimize the > size of the distribution as well as Apple's potential problems > supporting such things to the general Mac community. There are some problems I see with that suggestion. Let me present just the ones that would affect Mac users and not discuss any of the problems that would affect Unix users. 1) Apple has to re-write the system boot procedure they are getting from NeXT. This takes time, and has a reasonable chance of being buggy for a release or two. 2) Apple has to re-write most of the tools they get from NeXT, including the developer tools (the compiler, ProjectBuilder.app, InterfaceBuilder.app, etc), the system administration tools (NetInfoManager, NFSManager, UserManager, PrintManager, etc), and the networking and system functionality currently provided by Unix daemons (sendmail, nfsd, inetd, telnetd, named, etc). This will take lots of time, and, with 100% certainty will have bugs that will take quite some time to exterminate. 3) Remember Copland? Apple already tried and _failed_ to write their own replacement operating system for MacOS 7.x. While the brain-trust they've gained by acquiring NeXT's engineers would undoubtedly be of assistance in creating a new operating system, NeXT's engineers have already created their own operating system to do preemptive multitasking, good virtual memory, and so forth-- NEXTSTEP, which is based off of a reasonably sophisticated Mach kernel and BSD 4.x Unix and GNU utilities. 4) It removes functionality that some current Mac users have said that they would like. There are some Mac users who have stated that a CLI interface with Unix utilities would be nice to have every once in a while. Although no doubt that admission infuriates those Mac advocates who are anti-Unix and/or anti-CLI. And, yes, I am familiar with AU/X. One of the reason that AU/X was not popular with either normal Mac users or with normal Unix users was not because it was a Unix OS-- it's because AU/X was one of the worst Unix implementations ever made kludged on top of the Mac interface. NEXTSTEP is everything AU/X should have been, and much, much more. If one of the reasons we're having to argue about Rhapsody including Unix is due to Mac users remembering AU/X-- _please_ _PLEASE_ go use NEXTSTEP. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 12:38:15 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0mtZ27a00iV_86I8Yp@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <32E5F50A.2637@spvi.com> In-Reply-To: <32E5F50A.2637@spvi.com> Excerpts from netnews.comp.sys.next.advocacy: 22-Jan-97 Re: MacWorld Exclusive: App.. by Steve Spicklemire@spvi.c > OK.. so what happens when I get my shiny new GUI app that expects > 'system("tar cf - *.gif | mail .... )' to work and the user neglected to > install 'tar'? Are all these unix utilities so enourmous that we really > want to risk breaking so much code? They are 15 MB on my machine running NEXTSTEP 3.3. However, removing them does not mean that you would save 15 MB from every installation of Rhapsody, since Rhapsody would have to ship with some sort of replacement in order to provide the (now missing) functionality that lets the machine boot and do things like networking. > I would think the whole spiel compares in size (more or less) to a complete > installation of any modern office productivity suite. :-) Less. MS-Office '97 is what? 80 MB? -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: paul@pth.com (Paul Haddad) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 22 Jan 1997 19:24:42 GMT Organization: InternetMCI Message-ID: <5c5phq$8kr@news.internetmci.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> <32E64EF7.3D6A@nowhere.com> In <32E64EF7.3D6A@nowhere.com> Michael Hudson wrote: > > OK. Can you write me a short bit of code that would sort an array of any > type in Objective-C? > (I don't really want a complete quicksort algorithm, but somethnig that > shows it would be possible) > > Easy. Assuming you have an array of objects called arrayToBeSorted. sortedArray = [arrayToBeSorted sortedArrayUsingSelector:@selector(compare:)]; Just make sure that the objects in the array respond to the compare: method (NSString, NSValue, NSDate all do). Writting the compare: method basically boils down to comparing two objects and returning <1 , 0, or >1. Here's a couple possible implementation @interface ObjectToBeSorted // Assuming internalValue returns an int - compare:anotherObject { if ([self internalValue] < [anotherObject internalValue]) return NSOrderedDescending; if ([self internalValue] > [anotherObject internalValue]) return NSOrderedAscending; return NSOrderedSame; } @end @interface ObjectToBeSorted // Assuming internalValue returns an NSString - compare:anotherObject { return [[self internalValue] compare:[anotherObject internalValue]]; } @end That's all you need, the standard NSArray takes care of sorting. If you want a quick sort or some other kind of sort you can always subclass NSArray... See ya, -- Paul Haddad
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer Subject: Re: Emacs for OpenStep Date: Thu, 23 Jan 1997 09:46:55 -0500 Organization: Demiurge Development Group Message-ID: <32E779DF.2A65@friday.com> References: <32E52CE3.1A0B@friday.com> <7x4tgay96w.fsf@burrow.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Markus G <markusg@burrow.muc.de> Thank you for the suggestions, I will apply them to my monstrous initialization environment (that works under Xemacs, emacs .28 or .34; under NeXTSTEP, NT, or X windows). Unfortunately, it doesn't fix the problem at hand. Is anyone working on a port of the emacs-for-nextstep to OpenStep? b.bum
From: kpompei@xmission.com (Kevin Pompei) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 12:35:13 -0700 Organization: XMission Internet (801 539 0900) Message-ID: <MPG.d5019de869ba646989683@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <32E5F50A.2637@spvi.com> <0mtZ27a00iV_86I8Yp@andrew.cmu.edu> In article <0mtZ27a00iV_86I8Yp@andrew.cmu.edu>, cs4w+@andrew.cmu.edu spouts forth... > Less. MS-Office '97 is what? 80 MB? > Try 200MB! Kevin Pompei
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 14:37:58 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <gmtamKS00iV_I6IBY8@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> In-Reply-To: <maury-2101971155550001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> I don't see why anyone would want to make their computer >> harder to use, but then, that's just my preference for thinking >> rationally showing through.... > > Oh, it's terribly rational for the computer to dictate where the user > places files, rather than the other way around. Correct. A multiuser computer system has conventions for where you should place common files (like applications, fonts, and other such resources) which are supposedly intended for use by all users. Such a system _prevents_ users from interfering with the files of other users or the OS itself unless that user has special permissions. This is also the primary reason why Unix systems are largely immune to viruses. However, nothing prevents a user from placing their files in whatever fashion they choose within their home directory (and whereever else they have the appropriate permissions for). For that matter, single-user computer systems have some of those conventions too-- what else did you think the special nature of the "System folder" represents under MacOS? > You must use some other definition of "rational". Obviously. Are you willing to accept empirical evidence from the real world as to which of our respective definitions is more valid, or does that not interest you? >> No, it's not, although I am unsurprised to discover that a Mac advocate >> has not had exposure to large computer networks administered by an >> organization. > > I've RUN large networks administered by an organization. You're kidding, right? If this is actually true, (a) provide some details, and (b) why aren't you making any sense? How can you possibly have "administered" a large network of computers (presumably Macs) if you did not have some conventions for what was on each computer and where such common functionality was to be located? How did you figure out how many licenses of various software packages were needed? >> For example, CMU has hundreds of Macs in the clusters >> with a very consistent filesystem layout. > > Bully for them. I believe you'll find that your experiences in > university and the commercial world will be largely different. Some are, some aren't. So far, I've never encountered a company when I was doing consulting which did not have conventions for the way a multiuser machine's filesystem(s) should be arranged. The point was, I was showing a real-world example of roughly as many Macs that did have a convention for filesystem layout as you stated that you were familiar with which did not have such a convention. And this refutes your attempt to claim that Macs in general do not have such conventions. >> Most Mac users here like the idea, so they generally arrange their >> computers in similar ways to the cluster machines > > What cluster machines? The computer systems in public areas at CMU are known as 'computer clusters'. Hence, the term 'cluster machines', which are the machines described above with "CMU has hundreds of Macs..." -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 13:53:03 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Amta8De00iV_M6IB5S@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> In-Reply-To: <5c4ed7$fjt@geraldo.cc.utexas.edu> Excerpts from netnews.comp.sys.next.advocacy: 22-Jan-97 Re: MacWorld Exclusive: App.. by William Raphael Hix@port >: Tar is of a great use to many people out there, isn't that obvious >: since almost everyone is adding its functionality and there are free >: versions of it available? > > Tar is of great use to Unix users. I use tar on my Unix box to aggregate > files which I then compress and download to my Mac where Stuffit > uncompresses and untars them. But most Mac users never encounter tar > files since Mac software distribution is done by Stuffit/BinHex. > But you expect Rhapsody software distribution to work like NeXTStep? I hope that Rhapsody uses NeXT's packages and Installer.app, yes. Normal NEXTSTEP users never invoke tar themselves-- they use GUI tools like Installer.app and Opener.app which use tar internally. If you look back a few weeks, I described exactly how easy Installer.app and Opener.app are to use, and the fact that you get functionality like receipts (for uninstalling software and for showing what software has been installed on a system), multilanguage support, and FAT binary support. Heck, even Maury seemed to like Installer's functionality, although I deliberately never mentioned that .pkg were wrappers around a tar'ed and compress'ed file along with some small text files and an icon. :-) > Ports of apps from Unix to Rhapsody? Sure hope so. Doesn't any Mac user see some advantages to being able to run your own personal web server on your own machine, or to be able to send and receive electronic mail quickly and efficiently? [ ... ] >: >If this is then why bother including it on everyone's disk? >: >: Why? Well, lets see.. >: >: Its a universally available tool on ALL machines, without depending >: on owning a third party product. This means that an Apple user who >: downloads something from the Net has a tool to start from. > > But it doesn't do anything for a Mac user since Mac software in not in > tar format. Perhaps for Rhapsody this will change, but I think that > you are assuming things which aren't decide yet. In that sense, this is what everyone on these newsgroups are doing! No doubt Apple and NeXT have a lot of decisions to make which have not been made yet. Possibly, although it's _far_ less likely-- some of the debate that goes on here in Usenet will have some influence on the decisions they make. It would be to our collective advantage in the long term if we can make discussions about Rhapsody as useful as we can, since it might make Rhapsody a better operating system. Prosletizing the "one true Mac way" to the point where someone at Apple gets disgusted enough to publicly disagree with your slander of DPS, or arguing that we have to rip Unix out of Rhapsody in order to save three dollars in disk space but screw up almost every aspect of NeXT's technologies, are, in my opinion, some of the most pointless and idiotic arguments I've ever seen on Usenet. _Why_ be so brain-damaged? [ ... ] >: If they pressure Apple to drop basic functionality like this, then >: Apple should tell them to take a leap. > > What a NeXT user sees as basic functionality might seem like wasted disk > space to a Mac user. Dropping them also reduces Apple's support load, > perhaps lowering the cost. [ ... ] Hold on a second. At the end of this article I'm responding to, you said: > Mac users are largely happy with what they have, if only it'd run stably, > in protected memory with pre-emptive multitasking. The combination of the Mach kernel and Unix utilities provides the functionality that you say Mac users would want. You can't rip the Unix layer out from between Mach and NeXT's software tools without seriously impacting that functionality, because Apple would have to write an as-yet-imaginary middle layer to replace that functionality. Do you think something like that is simply appear out of thin air? Nope-- it would take lots of time and development effort to get 1.0 version done, and would take even more time and effort to get stable and reliable. [ ... ] -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 20:40:25 GMT Organization: Indiana University, Bloomington Message-ID: <5c5tvp$jfu@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <scottm-ya02408000R2201970338030001@news.erols.com> NNTP-Posting-User: 1073745024 In article <scottm-ya02408000R2201970338030001@news.erols.com>, Scott Maxwell <scottm@nic.com> wrote: >In article <5c04e3$gh9@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >>In article <32E30DB4.7126@concentric.net>, >>Alan Lovejoy <alovejoy@concentric.net> wrote: >> >>>Yes, the system() function is a necessity in today's world. >>> >>>I think the goal of Rhapsody (and all Unixes) should be to continuously >>>make it less so over time. Perhaps one day... >> >>Why? >> >Why not? Because it's so easy to use, and because a lot of existing code uses it. What would you gain by removing it? -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 20:58:20 GMT Organization: Global Objects Inc. Message-ID: <5c5v1c$6t4@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> Alan Lovejoy <alovejoy@concentric.net> wrote: > Charles William Swiger wrote: > > My point was that an API for the majority of external commands is not > > available. Nor would creating such API for every command be practical > > or even desirable. > > I agree is't not available. And until it is, the CLI is necessary. > And a CLI would still be a good idea after such a library was > available, because it's a programming language (and the typical GUI > is not). > > However, I think such a library of useful utility classes/methods > is very desirable. Code reuse: it's a good idea. That's where the MiscKit comes in...in being particularly germane to the current example, there is even a MiscMail object! (It is usually used to open up a window in the Mail app of the user's choice and programmatically compose a message for the user, filling in the subject: and to: lines for "suggenstion box" features and such.) I guess that's a case of hooking up to an existing API, but the MiscKit's object (a Facade pattern) makes the access a lot cleaner, and if the underlying API ever changes, apps using the MiscKit will just need to link against a new kit. I'm currently working with someone to create a framework of Message objects to simplify posting mail, news, or other types of messages. Hopefully it will be available in a month or two. :-) But, the point is this: the MiscKit is a case in point--APIs that we've felt are generally useful, but lacking in NEXTSTEP/OPENSTEP, are what we have created. We haven't recreated every API, but we have done a *lot*. A quick look at the kit manifest or docs on http://www.misckit.com/ will convince anyone of that. I don't think that Apple should necessarily be expected to create all these APIs, and in the time frame they have right now, they can't do it anyway. That's why community support like the MiscKit is such a good thing! One interesting thing to note: a lot of these APIs, when turned into objects, are very tricky to do well. Getting a good API seems to take several iterations. I've noticed that NeXT has added to OPENSTEP improved versions of many of the APIs that have been in the NEXTSTEP version of the MiscKit. I don't know that they actually borrowed our ideas or code--in fact, I suspect not--but the NeXT versions do tend to be better than our first generation tries, so they probably at least learned a little from our mistakes. (I do know that several of the AppKit and Foundation engineers are cognizant of what we're doing, though I don't know what degree, if any, of cross pollination occurs.) Of note is that eventually these APIs _are_ finding their way back into the NeXT API... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: More on Power Management! Date: 22 Jan 1997 21:19:07 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5c608b$40qc@news.doit.wisc.edu> I've done more research since my last message and found a set of routines in the library libDriver.a. A few of these are used by the AMD scsi driver example. If anyone has any clue about how to use these (parameters, return values, etc), I'd love to know. I wish NeXT would just give me the damn header file or some documentation on them. I don't know why they're keeping it so secret. Here are the routines: PMGetPowerEvent PMGetPowerStatus PMRestoreDefaults PMSetPowerManagement PMSetPowerState Thanks! -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: Can one inherit from a class cluster? How? Date: 22 Jan 1997 21:22:59 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5c60fj$40qc@news.doit.wisc.edu> I was trying to implement a subclass of NSData that had an extra instance variable in it designating the endian-ness of the machine it originated on (so I could convert it appropriately when using Distributed Objects across different architectures). The problem is, I can't seem to create a subclass of NSData because it isn't really a class - it's a class cluster (it doesn't give an error until I try to create an instance of the subclass at runtime, then it fails). Has anyone run into this problem? A solution? The kluge I am using right now is just having another container object that holds an NSData object. But there are a number of inconveniences in this approach. Advice appreciated. Thanks -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
From: Eric_Smalling@amrcorp.com (Eric Smalling) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 97 21:08:42 GMT Organization: SABRE Decision Technologies http://www.amrcorp.com Message-ID: <5c5vmp$ab1@aadt.sdt.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <0mtZ27a00iV_86I8Yp@andrew.cmu.edu> In article <0mtZ27a00iV_86I8Yp@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> <32E5F50A.2637@spvi.com> wrote: >Less. MS-Office '97 is what? 80 MB? HA! My MS-Office '97 Directory Proporty window reports over 135MB!! (Not including whatever it may have installed in my WINNT directory) ____________________________________________________________________ Eric A. Smalling SABRE Decision Technologies - Ft Worth, Texas USA --=== ------=== The Any views expressed are mine alone and are in no ----------- SABRE way the views of AMR or any of it's subsidiaries. ------=== Group --=== email:Eric_Smalling@amrcorp.com Corp Web Site: http://www.amrcorp.com/sabr_grp/sdt/sdt.htm ____________________________________________________________________
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 16:40:50 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E68962.52E@exnext.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <32E5F50A.2637@spvi.com> <0mtZ27a00iV_86I8Yp@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 22-Jan-97 Re: MacWorld > Exclusive: App.. by Steve Spicklemire@spvi.c > > I would think the whole spiel compares in size (more or less) to a complete > > installation of any modern office productivity suite. :-) > > Less. MS-Office '97 is what? 80 MB? 130 or so, I think. -- Jonathan W. Hendry jon @ exnext . com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 15:39:56 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <gmtbgQW00iV_E6ID5J@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <32E420C6.17B7@concentric.net> In-Reply-To: <32E420C6.17B7@concentric.net> Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld Exclusive: App.. by Alan Lovejoy@concentric. >> Code reuse is a principle which states that it is usually easier and >> better to use preexisiting code rather than reinvent the wheel by >> re-writing functionality that is already available. >> >> I understand what code reuse means. Do you? >> >> Apparently not, because you are arguing that we should not reuse the >> preexisting code available in the form of the Unix utilities, and should >> instead write APIs and an implementation in the C system library for all >> of those utilities. That is the opposite of "code reuse"! > > Ahem. Now whose being offensive? > > Here's the most offensive part: you're wrongly attributing to me a position > I have never stated, and in fact disagree with: namely, that the CLI utility > commands should not be used, or should be eliminated. Hmm. I'd have to look through a few hundred articles to see precisely what you said. You do agree that (1) you made the suggestion that the API for the Unix CLI utilities should be abstracted into a library, and (2) that you make that comment apparently in support of Maury's suggestion without ever mentioning that you did not agree with the rest of his suggestion to make those utilities optional? Regardless of what you think about the second part, your suggestion to recode the functionality of the Unix CLI utiltities into a library is still the "opposite of 'code reuse'", since that functionality already exists. > If the code in the UNIX shell commands were refactored and abstracted into > utility functions with a standard API, the universe of reusable code would > be increased. Agreed. > (And of course, the original shell commands would still be available with > the same functionality and external interfaces). I hope this is clear, and > does not need any further proof. It's clear. So far, so good-- [ ... ] >> >> The point is, regardless of what it's called or whether it's just one or >> several libraries-- there is no point at all of creating tens of >> thousands of system calls to replace the Unix command line utilities >> unless that mammoth API is available on all of the hardware/operating >> system combinations that you're replacing the Unix CLI utilities, >> otherwise programmers won't be able to depend on all of the API being >> available, which would make it far less useful. > > So no OS should ever provide a library that has any function not also > available on any other OS? Or just not available on any other Unix? Not at all. But I expect the process to be an evolutionary one that will take a great deal of time. In the meantime, the Unix utility API is pretty darn useful because it provides some important functionality. > And a technical point: a function in a library is not a system call. It's > only a system call if the function actually runs as part of the kernel, in > the kernel address space, with kernel permissions. That's the standard definition of the term 'system call' under Unix; other operating systems use that term more generally to refer to functionality provided by the standard system library. Since I've been talking to a Mac audience a lot, I've been trying to avoid using purely Unix terminology. [ ... ] -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Michael Taylor <mtaylor@aw.sgi.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 16:52:02 -0500 Organization: Alias|Wavefront Message-ID: <32E68C02.7D55@aw.sgi.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > > You are taking this too personally. I'm not trying to rain on you parade. > Apple has said they will continue to support OpenStep on Intel and > Solaris, but I haven't heard anything clear from them about future > development, either as Rhapsody on other hardware or independently. For those interested, Apple has thrown out another small tidbit of information for our consumption. Draw what conclusions you will. The following is taken from a letter from Gil Amelio posted to the comp.sys.next.announce news group on Jan 21st. It promises future development of cross platform tools. It seems to indicate that Apple technologies will be ported to other OpenStep platforms. ------ Excerpt ---------- OpenStep Enterprise. We are also committed to continue the development of OpenStep Enterprise and OpenStep Developer, and to enhance them over time. One example is the developer API documentation, which we plan to update and improve. We plan to continue selling OpenStep Enterprise to current and future customers in markets where it is being sold now, with the same sales and support resources. Finally, the OpenStep API and development tools will be a core component of Rhapsody the code name for Apple's next generation operating system. This will increase the installed base of OpenStep many times over, helping ensure its acceptance as a viable and popular development environment. Cross Platform Support. Apple will maintain NeXT's commitment to cross-platform and cross-processor support, and will continue to develop, sell, and support products currently available, including those for Windows NT, Solaris, HP-UX, and NEXTSTEP. In addition, we plan to add support with Rhapsody on PowerPC processors. Cross platform support for WebObjects and OpenStep aligns perfectly with Apple's overall strategy of moving core software technologies such as QuickTime cross platform. We firmly believe that Apple's acquisition of NeXT will increase the market acceptance for the NeXT technology in which you've invested time, resources, and money. Apple is firmly committed to enhancing, selling, and supporting this technology in the future, and to providing NeXT customers with innovative technology for cross-platform development of mission-critical, enterprise solutions. -- /\/\ike Taylor | Mail: mtaylor@aw.sgi.com Alias|Wavefront Toronto | Voice: (416) 362-8558 x8740 Developer, API Team =D--' http://reality.sgi.com/mtaylor
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 13:35:30 -0800 Organization: Bridge Family Message-ID: <abridge-2201971335300001@dcn132.dcn.davis.ca.us> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> UNIX is a strange beastie to those of us looking in at from the Mac side. Years ago in another incarnation I remember OS's that were refered to as "User Friendly". The Mac was just invented and, in my household, it was better than "User Friendly." It was "User Chummy". UNIX has always appeared to me as "User Hostile" with a command-line interface that was at once cryptic, terse to the point of rudeness, and documented for geeks not real users. The shell programs struck me as quite useful -- if you could get over the price of admission -- which was quite steep. And then there was moving from one system to another in which the system administrator had hacked the kernel in some way, or forgotten one of the 10,000 security loop holes or . . . You get the drift -- my early UNIX experience was not positive. So imagining my Mac taken over by a version of this system is somewhat alarming. BUT....only somewhat. UNIX is an adult operating system. I imagine that I'd start my system once a day if I chose not to leave it on all the time. The file system would be safe as houses. File system performance, I hope, will be good. But I don't want to turn on my Mac and find a totally different look and feel than what I'm used to. I want Dantz Retrospect to back up my hard disk. I want new products to install swiftly and cleanly and where I want them to go (it's my computer not the software company -- I'll take responsibiliity for screwups). That being the case I don't care what's under the hood: UNIX, Mach, Be, or squirrels in a cage -- as long as it works. Now, if you can add well designed command-line environment, I'll take the time to re-learn how to use it. That's fine. If UNIX utilties have to be there to get the system on its feet in the morning (I use coffee but if shell scripts are needed: be my guest just don't TELL me about it unless something terrible happens that I need to worry about -- then tell me something that makes sense instead of cryptic commands or Error 51 or something [that's a dig at Apple too]). And please, above everything else, make sure my system is secure so while I'm on the net some hacker in Cleveland doesn't actuate some obscure UNIX bug and thrash the hell out of my system. That hasn't happened to my Mac (I don't rate a Ping of Death I guess -- no complaints). But I'm DYING for the OpenStep development environment. Objective-C just makes so much sense. We're talking major league lust here. I'd steal and old black cube just to play with it. So, with that and SmalltalkAgents and maybe Prograph CPX I'll be a happy guy. And then Apple can chose to add different appearances so NeXT folks think they're on OpenStep or something and my wife will think her Mac is a little neater and a whole LOT more stable while she runs FreeHand and PageMaker and Photoshop. And I can play with Bryce. And it'll just work and I won't EVER know what's lurking inside the box unless I have this dying need to pull up a terminal window and write a script to devise a histogram of how many files of each file-name-length I have. (a straight-forward shell script I'm sure) Regards, Adam Bridge
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 01:37:59 GMT Organization: Indiana University, Bloomington Message-ID: <5bk0pn$f3i@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971753450001@199.166.204.230> NNTP-Posting-User: glhansen In article <maury-1501971753450001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> In any event, your entire argument here is weak and irrelevant. > > You're right of course, who would want something like standardization? > >> issue was whether Rhapsody should include Unix utilities. I argued >> that it should, because many developers of GUI applications could use >> them to save time. Your response is to assert that Unix utilities are >> "nonstandard". > > No, my argument is, and was sidestepped, that these functions are better >off provided vias modern interfaces rather than command line tools. > >> Rhapsody! Whatever Rhapsody includes is a de facto standard Rhapsody >> utility, and may be used in Rhapsody GUI apps. > > So they should get rid of the command line stuff then. If nothing else, you need the command line stuff to run scripts. That's reason enough for me to keep it in. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 14:09:14 -0800 Organization: Modulation Message-ID: <32E6900A.2A90@concentric.net> References: <maury-0801971641590001@199.166.204.230> <32E30DB4.7126@concentric.net> <5c04e3$gh9@dismay.ucs.indiana.edu> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gregory Loren Hansen wrote: > > In article <scottm-ya02408000R2201970338030001@news.erols.com>, > Scott Maxwell <scottm@nic.com> wrote: > >In article <5c04e3$gh9@dismay.ucs.indiana.edu>, > >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > >>In article <32E30DB4.7126@concentric.net>, > >>Alan Lovejoy <alovejoy@concentric.net> wrote: > >> > >>>Yes, the system() function is a necessity in today's world. > >>> > >>>I think the goal of Rhapsody (and all Unixes) should be to continuously > >>>make it less so over time. Perhaps one day... > >> > >>Why? > >> > >Why not? > > Because it's so easy to use, and because a lot of existing code uses it. > > What would you gain by removing it? Removing it? I don't advocate that at all. Reimplementing the Unix shell utilities so that their implementations are less monolithic and are based on reuseable sub-functions is all I am recommending. And even then, only as time and resources permit (which may mean never...sigh). -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 15 Jan 1997 17:53:29 -0500 Organization: Atria Software Message-ID: <maury-1501971753450001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > In any event, your entire argument here is weak and irrelevant. You're right of course, who would want something like standardization? > issue was whether Rhapsody should include Unix utilities. I argued > that it should, because many developers of GUI applications could use > them to save time. Your response is to assert that Unix utilities are > "nonstandard". No, my argument is, and was sidestepped, that these functions are better off provided vias modern interfaces rather than command line tools. > Rhapsody! Whatever Rhapsody includes is a de facto standard Rhapsody > utility, and may be used in Rhapsody GUI apps. So they should get rid of the command line stuff then. Maury
From: ga@ed4u.com (G. Gordon Apple, PhD) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer, Subject: LAMG Dev. SIG, Jan. 28 Date: 22 Jan 1997 21:58:38 GMT Organization: Advanced Communications Engineering, Inc. Message-ID: <ga-2201971359570001@cust34.max55.los-angeles.ca.ms.uu.net> LAMG Developer SIG (LAMG, formerly Los Angeles Macintosh Group. Looks like we officially changed the name just in time. :-) Meeting: Tuesday, Jan 28, 7:00 PM NeXT color machine demo and developer features presentation. Review of CodeWarrior 11. Discussion of Apple Computer system software directions. The new CodeWarrior 11 was mailed out (bulk mail) on Wed. Jan. 15. Just to make sure we have it in time, MW is mailing me another one via Priority Mail. One way or another we will have it for the meeting. After I made some phone calls to BANG (Bay Area NeXT Group), Earnest Prabhakar called me from LA. We eventually scared up a Color NeXT machine which he has agreed to bring to our meeting and demo features, developer tools, etc. This should be a great, (now) useful and informative demo relating to our future. We will get a peek through the veil of our shotgun bride and we won't have to endure the indignity of demoing it on a PC like I thought we were going to. We're not sure it will work with the Proxima, so real developers to the front, lookie-loos to the rear, please. The agenda will be: 1. Quick review of CW-11. 2. NeXT Demo, OpenStep, Interface Builder, etc. 3. Polite Q&A and discussion about NeXT technologies. 4. Raucous discussion of everything known, unknown, rumored, inferred, insinuated, surmised, and hoped for in the future AppleOS. (Bring Kevlar vests, brass knuckles, or whatever you think appropriate :-) We made one attempt to gather questions and concerns from developers to submit to Marco Landi since he promised me personally he would respond to these. Probably due to the holidays, there were only a few responses and insufficient time to get it together and have an impact, so it was not submitted. I still think we should try to compile such a list and send it while it might still be effective. Please give me any such questions in writing and I will try to get it together. Of course, if any of you would like to volunteer for this task, please let me know. I'll think about if for at least 5 sec. before handing it over to you. MEETING LOCATION, TIME, DIRECTIONS: LAMG Developer SIG meetings are at 7:00 PM on the last Tuesday of each month (except December). The LAMG Resource Center is at 1640 5th St., #220, Santa Monica, CA. From 405, take SM Freeway (10) west past Lincoln to 4th & 5th St. exit. On exiting, immediately take the 5th St. right turn. The building will be on your immediate left. Park on frontage road or at Mall on 4th St. (3 hr. free). For additional info, you can contact me directly. -- G. Gordon Apple, PhD The Ed4U Project Advanced Communications Engineering, Inc. Redondo Beach, CA ga@ed4u.com www.ed4u.com
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 22 Jan 1997 22:26:34 GMT Organization: Global Objects Inc. Message-ID: <5c646q$6t4@news.xmission.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> <32E64EF7.3D6A@nowhere.com> Michael Hudson <sorry.no.email@nowhere.com> wrote: > OK. Can you write me a short bit of code that would sort an > array of any type in Objective-C? > (I don't really want a complete quicksort algorithm, but > somethnig that shows it would be possible) Absolutely! However, the one I'm going to point you at is a little bit more complex than what you are expecting, because it does more than you ask for. :-) This example is found in the freely available MiscKit, by the way. Look at the MiscListSorting category... Add this in a category on NeXT's List object and suddenly all list objects have the ability to sort--on any key you specify: /* * This is O((n)(n)) which isn't great but it was easy to code. * it would be better to use a quicker sort routine instead * which is O(nlog(n)) [For future implementations, right? :-)] */ - sortUsing:(SEL)aSelector ascending:(BOOL)aBool { unsigned int c,d; BOOL found; int compareValue; compareValue = (aBool ? -1 : 1); for (c = 1; c < [self count]; c++){ found = NO; d = c-1; while (!found) { /* move to left until find right place */ if ([self compareUsing:aSelector objectAt:d+1 :d] == compareValue) { [self swap:d+1 with:d]; d--; } else { found = YES; } } } return self; } Note that you need to write these two methods: - (int)compareUsing:(SEL)aSelector objectAt:(unsigned int)pos1 :(unsigned int)pos2 - swap:(unsigned int)pos1 with:(unsigned int)pos2 The latter is easy: - swap:(unsigned int)pos1 with:(unsigned int)pos2 { if ([self objectAt:pos1] && [self objectAt:pos2]){ id temp = [self objectAt:pos1]; dataPtr[pos1] = [self objectAt:pos2]; dataPtr[pos2] = temp; } return self; } But the compare method is the tricky one. Since it is long, I've appended it to this message. Why is it long? Let's look at what it does... The compare method is cool because you get to choose *how* the objects are compared. Pick a method that all the objects implement such as -compare: and then pass that method name to the compare routine and it will perform the appropriate comparisons. Since we don't know the return type of the method, we query the runtime system and then use a case statement to handle the comparison for any return type that a method can send back. This means that well do the right thing when comparing objects whether they return ints, floats, or char strings when queried. This flexibility means I can: (a) stick any object I like into a List object (that ability was already there in NeXT's object) (b) I can sort on _any_ key: -age, -length -- _whatever_ I want (c) The sort key doesn't have to exist at compile time Let me explain (c). Objective C is flexible enough I can write an app and allow it to load in bundles (ie, a plug-in). Let's say that the plug in defines a new type of object. I can take the existing List object, fill it with the new object, and sort on a key defined by the new object--which probably didn't exist when this was compiled. In fact, I could have a textfield in my app where I can type in the method to query when sorting and the app could pass that on to the above sorting routine! (Usually, you wouldn't do it quite that way, of course...) I'm not claiming that this is the best code, and it certainly is a more complex example than most would hand you. The complexity is due to the fact that this is about as general a solution as can be imagined, and that generality bloats the code a bit. :-) As an example of how you could make this whole thing a *lot* simpler, for the case where all the objects in your list respond to the -compareTo:caseSensitive: method, like a MiscString does, you can use this code (also from the MiscKit): // Two C wrappers so that the qsort() library function is happy static int stringValueCompare(const void *arg1, const void *arg2) { MiscString *str1 = *(id *)arg1; MiscString *str2 = *(id *)arg2; return [str1 compareTo:str2 caseSensitive:YES]; } static int noCaseStringValueCompare(const void *arg1, const void *arg2) { MiscString *str1 = *(id *)arg1; MiscString *str2 = *(id *)arg2; return [str1 compareTo:str2 caseSensitive:NO]; } // The sorting method - miscStringSortCaseSensitive:(BOOL)aFlag // added by DAY { // Danger: we don't first check to assure that all objects can // respond to -compareTo:caseSensitive: and we'll crash and burn // if they don't, so beware! if (aFlag) qsort(NX_ADDRESS(self), [self count], sizeof(id), stringValueCompare); else qsort(NX_ADDRESS(self), [self count], sizeof(id), noCaseStringValueCompare); return self; } That can also be attached to any container via a category. Note that we're making assumptions about the layout of the List object's memory and configuring the qsort() call appropriately, so this should be treated as a method making access to private variables. It works because we know what we're doing, but it is dangerous practice since we don't control the implementation of the List object. Still, any object that responds to the method, be it a MiscString or other object, will work for this one. The trick here is that you can't chane the comparison key. Note that a clever programmer could fix up the C wrapper functions above and the qsort call in such a way that the method can be altered--using the code appended below to handle the different comparison types...so that you don't have to use the slow sort routine given at the first. (Lack of time has kept me from doing it; I've bigger fish to fry right now.) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a> #define COMPARE_RESULT(A,B) ( ((A) < (B)) ? -1 : ( ((A) == (B)) ? 0 : 1) ) - (int)compareUsing:(SEL)aSelector objectAt:(unsigned int)pos1 :(unsigned int)pos2 { Method methodStruct; if ([self objectAt:pos1] && [self objectAt:pos2]){ methodStruct = class_getInstanceMethod([[self objectAt:pos1] class],(SEL)aSelector); if (!aSelector || !methodStruct){ NXLogError("[%s:%s]: no get selector for object at %d", [[self class] name],sel_getName(_cmd),pos1); return 0; } /* Here i am checking the return type of the the method (Well I hope that I am checking) * (the Return type of the method) */ switch(methodStruct->method_types[0]){ case _C_ID: { id val1 = ((id(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); id val2 = ((id(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); if ([val1 respondsTo:@selector(compare:)]){ return (int)[val1 perform:@selector(compare:) with:val2]; }else{ NXLogError("[%s:%s]: can't compare object values of \"%s\":%u and \"%s\":%u", [[self class] name],sel_getName(_cmd),[[val1 class] name],pos1,[[val2 class] name],pos2); } } break; case _C_SHT: { short int val1 = ((short int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); short int val2 = ((short int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_USHT: { unsigned short int val1 = ((unsigned short int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); unsigned short int val2 = ((unsigned short int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_INT: { int val1 = ((int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); int val2 = ((int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_UINT: { unsigned int val1 = ((unsigned int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); unsigned int val2 = ((unsigned int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_LNG: { long int val1 = ((long int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); long int val2 = ((long int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_ULNG: { unsigned long int val1 = ((unsigned long int(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); unsigned long int val2 = ((unsigned long int(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_FLT: { float val1 = ((float(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); float val2 = ((float(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_DBL: { double val1 = ((double(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); double val2 = ((double(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); return COMPARE_RESULT(val1,val2); break; } case _C_CHARPTR: { const char *val1 = ((const char *(*)(id,SEL))[[self objectAt:pos1] methodFor:aSelector]) ([self objectAt:pos1],aSelector); const char *val2 = ((const char *(*)(id,SEL))[[self objectAt:pos2] methodFor:aSelector]) ([self objectAt:pos2],aSelector); if (val1 && val2){ return NXOrderStrings(val1,val2,YES,-1,NULL); }else{ if (val1){ return 1; }else{ return -1; } } break; } default: break; } }else{ #ifdef DEBUG NXLogError("[%s:%s]: no object at %d or %d",[[self class] name],sel_getName(_cmd),pos1,pos2); #endif } return 0; }
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: Cost of a NeXT Web Site? Date: 16 Jan 1997 03:57:51 GMT Organization: Digital Fix Development Message-ID: <5bk8vv$3im@news.digifix.com> References: <5bjnet$b79@news.asu.edu> In-Reply-To: <5bjnet$b79@news.asu.edu> On 01/15/97, sugee@imap2.asu.edu wrote: > >I doubt that many advocates and customers like Chylser, CyberSlice, >Nissan, and etc. as the list goes on, will argue about the merits of >using NeXT's Web technologies for deploying their Web sites. We have all >heard plenty and are proud of what is being accomplished. > >However, what I haven't heard anything about, something which curiously >dawned on me recently and after reviewing what some of these folks are >doing, is the cost of implementing and deploying these Web Sites. Can >anybody provide approximate costs or actual figures of sites like these? >I do respect people's anonymity. > Thats likely not something that you're going to have much luck finding out, the spectrum is pretty wide there. There are some WebObjects projects like Stepwise (a NEXTSTEP/OpenStep product registry) that are based on EOF and WOF and it took perhaps 20-40 hours to implement. (The back end OpenStep UI has probably taken about as long). Of course I've re-written it a number of times now so thats a rather poor example. I've written sample catalog applications in WebObjects in a matter of a weekend. However I know of _much_ larger scale projects that have been in development for 6-8 months with a pretty good team of people on it (4-6).. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 22 Jan 1997 18:53:52 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c69ag$ecf@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> <5c12es$3ej@dismay.ucs.indiana.edu> In article <5c12es$3ej@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > In article <5c0heg$jud@csugrad.cs.vt.edu>, > Nathan M. Urban <nurban@vt.edu> wrote: > >Which is better? Accessing system services via distributed message > >passing, and dynamically loading and unloading object bundles into a > >running process's context? Or forking and exec'ing a shell to execute > >a new process, with all its associated overhead, and communicating with > >stream-based I/O that needs to be parsed into data structures? I like > >the former approach a lot better. > I couldn't care less. Unless there were some obvious benefits to show for > it. But the message I've been getting from an admittedly lukewarm > following of the thread is that the people who want to change this mostly > want to change it for aesthetics, or "just because". Will it make a > noticeable difference in performance or flexibility? I am of the opinion that you _would_ gain a noticeable improvement in flexibility and, in some cases, performance. Otherwise I wouldn't be advocating it. I do think it would be much more flexible, a lot easier to access program functionality from other programs, more convenient to distribute functionality over a network, and other advantages. > >Not that I'm advocating ripping Unix utilities out, or even saying that > >you shouldn't write apps which call utilities via a system() call. > >(Unlike some other people on this group...) Far from it. I love Unix > >and the Unix command line. I just think it would more elegant if most > >of the Unix functionality were wrappered with objects. Then the > >utilities could slowly be rewritten into object libraries, so that > >instead of having programs with object wrappers, you have programs > Oh, I'd have no problem with that. Just as long as I can keep my system() > call, I don't care how it's implemented (as long as performance doesn't > suffer). system() is the easiest way I've ever seen to pass messages to > the shell. Compare that with, say, writing a MacOS program that passes > messages via AppleScript. Does NeXT do it any better? What's "it"? Passing messages to the shell? To Unix command-line utilities? To applications? Something else? > One thing I'm reasonably certain of is system() and the shells won't > change much in any way, shape, or form until there's a universal and > backwards-compatible way to pass objects around. Likely. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 18:55:31 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c69dj$ej7@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2001971738220001@199.166.204.230> <5c1d0j$nhr@duke.squonk.net> <maury-2101971212030001@199.166.204.230> In article <maury-2101971212030001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > > throw out the Unix layer > Why would they do that? Who's asking them too? You are, apparently. I just ran across another article from you: > > [from somebody] > > Really, there's no point in ripping out Unix. > [from you] > Yes there _is_: ^^^^^^^^^^^^^^ -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 1997 01:29:03 GMT Organization: Indiana University, Bloomington Message-ID: <5c6esv$ses@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> <32E6900A.2A90@concentric.net> NNTP-Posting-User: 1073745024 In article <32E6900A.2A90@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: >Gregory Loren Hansen wrote: >> >> In article <scottm-ya02408000R2201970338030001@news.erols.com>, >> Scott Maxwell <scottm@nic.com> wrote: >> >In article <5c04e3$gh9@dismay.ucs.indiana.edu>, >> >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: >> > >> >>In article <32E30DB4.7126@concentric.net>, >> >>Alan Lovejoy <alovejoy@concentric.net> wrote: >> >> >> >>>Yes, the system() function is a necessity in today's world. >> >>> >> >>>I think the goal of Rhapsody (and all Unixes) should be to continuously >> >>>make it less so over time. Perhaps one day... >> >> >> >>Why? >> >> >> >Why not? >> >> Because it's so easy to use, and because a lot of existing code uses it. >> >> What would you gain by removing it? > >Removing it? I don't advocate that at all. > >Reimplementing the Unix shell utilities so that their implementations are less >monolithic and are based on reuseable sub-functions is all I am recommending. >And even then, only as time and resources permit (which may mean never...sigh). Oh! I thought you thought there was something wrong with system(). But sure, improving what's there is a great idea. And if you can call them through system(), that would sure be a lot easier than, say, programming with AppleScript. BTW, what's monolithic and unreuseable about Unix shell utilities? Each of them do one and only one thing and you often have to string many of them together to get something done. That's not monolithic. And they're all sitting in standard libraries that any user or any program can call at any time. That's pretty reuseable. Maury had a good idea. Make a set of object-oriented libraries, and directories like /bin would be filled with CLI-style wrappers. All your old programs will continue to work, but you get to use the spiffy new API. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Eric_Smalling@amrcorp.com (Eric Smalling) Newsgroups: comp.sys.next.programmer Subject: The Competition? Date: Wed, 22 Jan 97 22:48:26 GMT Organization: SABRE Decision Technologies http://www.amrcorp.com Message-ID: <5c65ho$bfm@aadt.sdt.com> Keywords: OpenStep WebObjects Portable Distributed Objects I am trying to do a _NON-BIASED_ review of OpenStep EOF (for NT mainly) and WebObjects Enterprise. I have seen both products and am VERY impressed, however, what products are there out there to compete with these? The only thing I've found to compete with WebObjects is "BackStage II" from MacroMedia and I'm not even sure if it does even a tenth of what WO 3.0 does. As for OpenStep EOF - it's the PDO piece that I amd intrigued with. I can find NO OTHER product that comes close to this. Anyone out there wanna help me here? ____________________________________________________________________ Eric A. Smalling SABRE Decision Technologies - Ft Worth, Texas USA --=== ------=== The Any views expressed are mine alone and are in no ----------- SABRE way the views of AMR or any of it's subsidiaries. ------=== Group --=== email:Eric_Smalling@amrcorp.com Corp Web Site: http://www.amrcorp.com/sabr_grp/sdt/sdt.htm ____________________________________________________________________
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 18:43:14 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c68mi$cqk@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2001971506200001@199.166.204.230> <5c0nkk$r0l@csugrad.cs.vt.edu> <maury-2001971752260001@199.166.204.230> In article <maury-2001971752260001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5c0nkk$r0l@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > I'm just saying that when you're doing a bunch of streams > > processing, there isn't as much of a need to have a pure object library. > But people aren't doing a lot of streams processing except in very > specific areas. And even in these areas I don't think using an OOPS > library is any worse, notably if it's got all the extras like published > interfaces and such. > > You can convert from objects to streams and back again without much > > difficulty. > Yeah, but WHY? The point I was trying to make is that replacing stream-processing apps with pure object replacements is not a very high priority, and wrappering them is probably the way to go. Things like, say, mail transfer agents would be better candidates for OOP libraries. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 22 Jan 1997 18:48:33 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c690h$djc@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5c04e3$gh9@dismay.ucs.indiana.edu> <5c0heg$jud@csugrad.cs.vt.edu> <4msyuOu00iV0M52s5o@andrew.cmu.edu> In article <4msyuOu00iV0M52s5o@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 CLI utils vs. > objects (was .. by Nathan M. Urban@csugrad. > > In practice, the way I think this would happen is Unix utilities being > > rewritten one-by-one so that they depend on little libraries instead of > > integrated code, and then making those libraries object-oriented. (It > > might be better to put object wrappers around C libraries so that you > > can still access their APIs from C or some non-OOP language if you > > want.) During the long conversion process, there would still be no > > problem with writing apps which call programs via object wrappers using > > the system() call. > > Comments? Do other Unix hackers think this is the way Unix should > > evolve? > I believe it is unfeasible to write sensible API's for every conceivable > Unix utility and to replace all of the expressive power of the shell. Not every conceivable one, no. Just the main ones.. besides, the transition could be made over a long period of time -- assuming that new Unix programs begin to use the new philosophy so they don't have to be modified later too. As to replacing all of the expressive power of the shell, I'm not suggesting that you can do that with OOP alone. I want the Unix utilities to stay just the way they are; I'd just like it if they worked by calling external libraries (preferably OOP) to make it cleaner and easier to programatically access their functionality. > I have no objection to people writing a good OO API to encapsulate the > functionality currently provided by popular tools like grep and find-- I > think it's a good idea. But people seem to think that simply providing > such an API means that the /bin/grep and /bin/find utilities aren't > needed anymore, and that claim makes no sense, for reasons that I've > explained in other articles. I'm not of the latter opinion either. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 22 Jan 1997 18:46:01 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c68rp$d6l@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> In article <maury-2101971109420001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <Qmt04oO00iV0M52u8d@andrew.cmu.edu>, Charles William Swiger > <cs4w+@andrew.cmu.edu> wrote: > > Apparently not, because you are arguing that we should not reuse the > > preexisting code available in the form of the Unix utilities, and should > > instead write APIs and an implementation in the C system library for all > > of those utilities. That is the opposite of "code reuse"! > Until you add in the words "OpenStep on NT". Once that's included it's > clear that modern code indeed offers considerably better chances for code > reuse than the current shell utilities. Note that a lot of Unix utilities use pretty much straight ANSI C, and not too many direct Unix system calls, so there _are_ portable to NT. Many of those that aren't directly portable are portable without too many changes. I have seen a number of them available for NT. I am of the opinion that there are many cases in which a developer would find it much more productive to base his code around a Unix utility and port that utility to NT than rewrite all the code from scratch. You seem to be under the assumption that all Unix utilities are tiny little things that a programmer could bang out in a few weeks or something. This is not the case. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: sschaper@inlink.com Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 22:21:05 GMT Organization: InLink Message-ID: <32e6928e.106264041@news.inlink.com> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> <5c1gni$nhr@duke.squonk.net> On 21 Jan 1997 04:29:38 GMT, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: >b) certainly NeXTSTEP users do not want Unix at the expense > of ease-of-use. In some of the early interviews with Ellen > Hancock, she said something like "NeXTSTEP has done a good > job of hiding Unix from the user. However, there are still > some rough spots, and we intend to complete the job". I, > for one, think that's a very good approach. > Exactly, use IB to design Apple Human Interface Guideline compliant GUI shells for the various UNIX tools and so forth that haven't already been so dressed up. This is doable, right?
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Date: Wed, 22 Jan 1997 11:40:26 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E4Er3F.5H9@cam-ani.co.uk> References: <5bu1uq$hrc@darla.visi.com> In article <5bu1uq$hrc@darla.visi.com> dwy@ace.net (David Young) writes: > You can't mount multiple drives to the some mount point. Using standard > UNIX filesystem conventions, one drive = one mount point. Just to throw a spanner in - BSD4.4 (at least the netBSD1.1 version I've played with) CAN do this. The problem is that new files created always go to the same disk (when writing to directories which are on more than one disk), but its ideal for setting up bin's and home directories. Just mount allMachines:/LocalUsers on /Users on all machines. If NeXT go with their "new" kernel then this should be included! $an
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 23 Jan 1997 01:34:29 GMT Organization: Indiana University, Bloomington Message-ID: <5c6f75$spl@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <5c0heg$jud@csugrad.cs.vt.edu> <5c12es$3ej@dismay.ucs.indiana.edu> <5c69ag$ecf@csugrad.cs.vt.edu> NNTP-Posting-User: 1073745024 In article <5c69ag$ecf@csugrad.cs.vt.edu>, Nathan M. Urban <nurban@vt.edu> wrote: >In article <5c12es$3ej@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: >> Oh, I'd have no problem with that. Just as long as I can keep my system() >> call, I don't care how it's implemented (as long as performance doesn't >> suffer). system() is the easiest way I've ever seen to pass messages to >> the shell. Compare that with, say, writing a MacOS program that passes >> messages via AppleScript. Does NeXT do it any better? > >What's "it"? Passing messages to the shell? To Unix command-line >utilities? To applications? Something else? Oh, any and all of them. The command-line is just a specific type of shell, the shell is just another application, so it's all the same. The only message passing and scripting I know about is AppleScript and Unix streams. I don't know how NeXT compares to either one. But I do know one thing for sure, it's a lot easier to pass a command to the shell with system() than with AppleEvents. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Thu, 23 Jan 1997 10:21:37 +1100 Organization: Unisys Message-ID: <32E6A101.7010@acm.org> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders Pytte wrote: > I have read (and greatly enjoyed) Joyner's 3rd edition of "A Critique of > C++", and did not find a single inaccurate statement in it. If I were > starting a new project on a platform that had very strong support for > Eiffel, that would be my choice of language. I would love to get rid of > header files, have assertion and other runtime debugging integrated into > my language. I really aprreciate all of Eiffel's qualitues. But Obj-C and > Java (so far) have far too many limitations for the sort of development I > do. Glad you enjoyed the critique. I am certainly neither criticising Bjarne Stroustrup, nor the users of the language. I'm just bringing to people's attention that C++ is now old and flawed. And I appreciate that you would also prefer to use a better language. > Joyner's critique suffers certain flaws in assumption, however. No weight > is assigned to the practical likelyhood of individual flaws actually > impacting on a software development project. I don't consider this an error of omission. My effort is to write about the flaws. These lead to many traps that are commonly enough fallen into. To do what you suggest would require full time funded research to get those kinds of statistics. And then how would you get such numbers? By a survey probably, and people are not very good at reporting on their mistakes. The critique evaluates the flaws in C++. So where are the flaws in assumption? > 5. All other factors mentioned in Joyner's critique. > > We had no problem avoiding the sorts of ambiguities Joyner complains > about. We didn't even have to discuss them. It took us all of a few > minutes to implement tools for assertion, and MacApp provided other tools > for runtime error detection. Some of the critiques have been made obsolete > by new compilers and linkers. Maintaining header files was boring but not > very time consuming. Etc., etc. Perhaps you didn't, but people seem to have no problems overlooking mistakes that are made. The problems in C++ are there, and they do cause people headaches. The point of the critique is that we should encourage better languages. The ambiguities in C++ also cause problems to those who are extending and standardising the language. Most of the things I point out are easily fixed in a language design. They do tend to be the things easily avoided. Other factors are harder to fix in a language. However, the critique is not only to find flaws, but to point out where C++ makes the programmer take care of low level details (bookkeeping tasks), which could much better be taken care of by a compiler. Another factor in C++ is the maintenance problem. So the critique actually points out more faults than just ambiguities. > Conclusion. > > So here is my point. Most the "linguistic" advantages of other languages > over C++ are _small_ compared to other factors active in the business of > software development. With the one exception of garbage collection, I > think Joyner's (and other's) critiques, though correct, are alarmist and > exagerated in importance; I agree with Stroustrup, that the flaws of C++ > are acceptable. No the critique is not alarmist. Perhaps you are alarmed by the number of problems in C++ that I find in the critique. The best C++ people that I know in fact think I have only scratched the surface, and I have been too kind. I have certainly not sensationalised of overblown importance, just reported on the facts. Yes, I and many others are alarmed about the increasing use of C++, when we should be moving to more modern languages. Eiffel is a step on the way. Myself and many others disagree with you and Stroustrup that the flaws of C++ are acceptable. You just can't cover them up that easily any more. I think that in the next few years you will see a steady decline in the use of C++ as people find languages that are better suited to their purposes. And for those who are wondering what Anders and I are talking about, you can find the critique at: http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html Thank you Anders for the opportunity to respond to your thoughts. ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:22:53 GMT Organization: ace dot net internet technologies Message-ID: <5bkhft$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971753450001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : No, my argument is, and was sidestepped, that these functions are better : off provided vias modern interfaces rather than command line tools. You're wrong. It'd be better as both. Else, you could argue that providing System 7 compatibilty is a waste, which is something I'm sure I'd be more likely to accept than you. The breadth of functionality that is covered in the UNIX utility suite is pretty big. Re-implementing perfectly clean interfaces like popen ("/usr/lib/sendmail -f maury@softarc.com dwy@ace.net") is time better spent on pushing forward. It's not like we're dealing with DOS here. : So they should get rid of the command line stuff then. Didn't you just suggest the exact opposite in the last post I replied to? -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:18:35 GMT Organization: ace dot net internet technologies Message-ID: <5bkh7r$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : Dave, I'm not asking for people to get rid of the *&(#&^*%$ utilties. : I'm saying that they should be OOPS libs on the disk with published : interfaces that you can call from within your programs regardless of : version and do so without having to flatten your code to a byte stream! Originally you were. When I had posted my reply, you were being utterly clueless and going on about the evils of cp, ls and rm and how horrible rm was because it didn't ask for confirmation (which, it does with the -i switch). Byte streams work well for some things. Objects work well for some things. You're not required to do system("mv foo bar"), you can use system calls, file system objects, whatever. Programmer's choice, which is really the important issue. : Since CLI's run on all computer's, it's obvious that we should get rid : of libraries of code altogether and make absolutely everything a shell : command. It's obvious isn't it? Are you trying to match my sarcastic wit? :) : There, now we don't need those silly library things and we can just ask : cshell to display our windows for us! Better yet, let's get rid of all : those imcompatible and confusing programming languages, let's do : EVERYTHING in the shell! Yeah, addition and division and everything! : It'll work! You're not following what I'm saying. There's nothing wrong with objects (in fact, I love objects. I live and die for objects.), but in many cases it makes more sense to use the shell. mv, rm, ls are bad examples. awk, sed, cut, sort, and uniq are better examples. They're designed for bytestream manipulation, which is something that is pretty common in most programs. Certain things don't always model well as objects; very complex pattern matching comes to mind. : Oh, then would you like to point out this paradigm of superb programming : you refer to but don't name? sendmail? ls? BTW, I don't know what paradigm you're inferring from my earlier posts. Do you think I'm somehow against OOP? What's wrong with ls? You prefer, say, dir /w? I doubt that a program would ever invoke ls and parse the output; it'd be more work than opendir(). Sendmail, despite its flaws, is incredibly powerful, btw. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 16 Jan 1997 06:29:19 GMT Organization: ace dot net internet technologies Message-ID: <5bkhrv$big@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971810510001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : > : Yes, but the quality of these applications varies, some is passable, : > : lots os terrible. rm doesn't even ask you to confirm, let alone allow you : > : to rescue the items. It's not lazy coders that's the problem, it's the : > : code that exists from years ago that is. Take note, you are faulting "rm" itself, which I will respond to below. : Ummm, so you're saying that rm's default behaviour is to ask you to : confirm? Or that all of this stuff is standardized? Or is ad hominem : attacks just something you do for fun? There are more issues at work than just rm, and if you had an understanding of UNIX, you'd know that. The site's administrator might choose to put 'alias rm "rm -i"' in /etc/tcshrc, in which case prompting would be the "default" behavior for that site. Or, maybe he thought he was clever and put 'alias rm "mv $* ~/.Trash"' and added "rm -rf ~/.Trash" in /etc/logout. Woo woo, there's all the functionality you were just whining about in two lines of shell aliases that'll work across the board on all unices with tcsh. There are really three levels of "default" behavior here: the factory rm, without aliases; the site-wide shell alias (if any) for rm, and the per-user alias (if any) for rm. The idea of "default" kind of loses its meaning in this context, wouldn't you say? rm does one thing, and one thing only: delete stuff. Anything else gets added someplace else, in the shell, or where ever. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 16 Jan 1997 06:58:46 GMT Organization: ace dot net internet technologies Distribution: world Message-ID: <5bkjj6$big@darla.visi.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> G. Gordon Apple, PhD (ga@ed4u.com) wrote: : MI is extremely useful as both a design tool and a modification tool if : used properly. Like any other tool you can also misuse it in ways that : get you into deep yogurt. In the design case, it allows you to partition : and encapsulate various independently-useful orthogonal functionalities so : that they can be combined at will (mixins) without each feature tripping : over the others. Hmm. Doens't sound much better than Object Composition to me, other than you get neat triangle trees instead of dotted rectangles around circles.. : In the case of modifications, it allows addition of features without : messing up the original classes. For example, you buy (or obtain by hook : or by crook) a library of objects that you really don't want to modify, : but now you want to subclass and implement streams or something that was : not included in that object library. It's easy to do with MI. Without : it, you're hosed, or you at least have a lot more work than you had : planned. Aha! No you're *not*! Objective-C to the rescue again, with "categories", a totally powerful way to extend any class with new methods, regardless of whether or not you have source. I find myself wishing for it all the time in other lanaguages. Basically, you define a category of a class with: @interface NSString (DavesExtendedNSString) and add methods you please, and every intance of NSString across the applicaiton gets the new methods, which, when combined with anonymous messaging, is very useful indeed... -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: "Eric A. Dubiel" <eadubie@rs6000.cmp.ilstu.edu> Newsgroups: isu.talk,isu.isunix,comp.sys.next.programmer,comp.sys.mac.programmer.misc Subject: NEWS: Objective-C and Ada95 from Tenon Date: Wed, 22 Jan 1997 21:57:19 -0600 Organization: Instructional Technology Services-Illinois State University Message-ID: <32E6E19C.692A@rs6000.cmp.ilstu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: isunet-l@thor.cmp.ilstu.edu FYI: Useful for future OPENSTEP, Windows, UNIX, and Mac OS projects... This press release is from: <anita@tenon.com (Anita Holmgren)> Phone: 805-963-6983 FAX: 805-962-8202 Contact: Anita Holmgren Internet: anita@tenon.com <http://www.tenon.com> Objective-C and Ada95 Now Available for Power Mac MachTen CodeBuilder - An affordable software development tool for the next generation MacOS Santa Barbara, CA, January 7, 1997. Tenon Intersystems has extended MachTen - its highly-regarded UNIX system for Apple computers - to include the Objective-C and the GNAT-Ada 95 tool suite. MachTen CodeBuilder, a new offering from Tenon being demonstrated this week at Macworld in San Francisco, includes C, C++, Objective-C, Java, Ada95 and Fortran77. CodeBuilder can be used in combination with standard Macintosh editors and compilers to develop Macintosh applications, X applications, and UNIX applications. MachTen CodeBuilder extends MacOS with a family of dynamically-linked, shared libraries that, like a Java virtual machine, create a UNIX virtual machine-based execution environment with pre-emptive multi-tasking. Tenon's MachTen UNIX is based on the same Carnegie Mellon Mach and BSD UNIX foundation as Steve Jobs' NeXT OS, making CodeBuilder a good platform for porting and building next-generation MacOS applications. The native PowerPC (PPC) package contains a complete UNIX software development environment with a source-level debugger and C, C++, Objective-C, Ada95 and Fortran77 compilers all generating native PPC code. Because CodeBuilder creates binary PowerPC Executable Format (PEF) files that can integrate directly with other Macintosh development tools, software developers can combine Macintosh debuggers and compilers with the CodeBuilder tool suite to get the best of both the Macintosh and UNIX worlds. CodeBuilder is a powerful tool for porting existing UNIX applications or developing new, advanced applications on Power Macs and Power Mac clones. This unique toolset gives developers the ability to create an application with a single source base not only for Power Macs under a native Apple operating system, but also for Silicon Graphics, SUN, NeXT, or HP environments. CodeBuilder gives Apple developers the freedom to take advantage of time-tested UNIX development tools without giving up the features of their favorite Macintosh editors or compilers. Tenon's new development tool suite includes a native UNIX fast file system. CodeBuilder has two file systems - a UNIX file system which extends the Macintosh file system with file name case sensitivity, and this new native fast file system which removes the Macintosh file name length limitations and sizing restrictions. Tenon's fast file system can be contained within a single Macintosh file, making disk partitioning unnecessary. Depending upon the application, Tenon's new file system can result in a two- to ten-fold performance improvement. This performance advantage, coupled with the latest high-performance Power Macs, creates a new standard in desktop computing. CodeBuilder supports a complete GNU software development environment. The GNU Ada95 and Objective-C compiler were brought to Power Macs by leveraging Tenon's existing gcc development tool suite. The Ada95 environment includes up-to-date tools for object-oriented programming and the core Ada essential tools suite from the Free Software Foundation. The Ada compiler includes a tasking run-time environment, an interface to the MacOS threads library, and Ada language bindings to the Macintosh Toolbox (API). Objective-C, an object-oriented extension to the C language, is the NeXTStep development language. The GNUStep OpenStep base class library is included on the CodeBuilder CD as a source code compilation example. GNUStep is a widely-available implementation of OpenStep, the NeXT distributed application run time environment. The fact that CodeBuilder's Objective-C is able to build and execute large sections of the GNUStep library demonstrates the strength of CodeBuilder's Objective-C implementation. A future release of CodeBuilder will include the complete GNUStep environment. CodeBuilder's Kaffe (a development & execution environment for Java bytecode), scripting tools (such as Perl, MacPerl, tck/tk and expect) and popular Macintosh and UNIX text editors (such as BBEdit Lite, Alpha, and emacs) make CodeBuilder an ideal internet programming and Web developer tool. CodeBuilder includes a high-performance X11R6 24-bit color X server as well as an X client application development environment. The current release supports AfterStep, a NeXT-style X desktop. Options for OpenGL and Motif 2.0 will be offered by the end of the first quarter of '97, further strengthening CodeBuilder's X development capabilities. The software comes on CD with BSD UNIX source code, on-line documentation in both HTML and Adobe Acrobat PDF formats, and an introductory price of $99. Tenon has been shipping UNIX, X , and networking software for the Macintosh since 1991. In 1994 MachTen was selected by UNIX World's Open Computing magazine as "A Best Product of the Year". Eric A. Dubiel; http://www.ilstu.edu/~eadubie mailto:eadubie@rs6000.cmp.ilstu.edu ytalk eadubie@138.87.201.11 MIME, SUN, NeXT, PGP Mail ok R&D---Instructional Technology Services----Illinois State University Intelligence is the ultimate aphrodisiac- Timothy Leary ALL VIEWS EXPRESSED REPRESENT MYSELF ONLY
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Date: 23 Jan 1997 04:07:01 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c6o55$ojc@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> Charles William Swiger (cs4w+@andrew.cmu.edu) wrote: : Excerpts from netnews.comp.sys.next.programmer: 22-Jan-97 Re: MacWorld : Exclusive: App.. by William Raphael Hix@port : > 2) A stripped down version of the BSD emulated services, just the minimum : > necessary for OpenStep with boot handled by some means other than shell : > scripts. No CLI app or non-GUI access to BSD commands, to minimize the : > size of the distribution as well as Apple's potential problems : > supporting such things to the general Mac community. : : There are some problems I see with that suggestion. Let me present just : the ones that would affect Mac users and not discuss any of the problems : that would affect Unix users. : : 3) Remember Copland? Apple already tried and _failed_ to write their : own replacement operating system for MacOS 7.x. : : While the brain-trust they've gained by acquiring NeXT's engineers would : undoubtedly be of assistance in creating a new operating system, NeXT's : engineers have already created their own operating system to do : preemptive multitasking, good virtual memory, and so forth-- NEXTSTEP, : which is based off of a reasonably sophisticated Mach kernel and BSD 4.x : Unix and GNU utilities. The problem with Copland was reportedly making the old Mac Toolbox work on a modern kernal. OpenStep is to solve that problem, not necessarily the rest of NeXTStep. They seem to be planning to replace the kernal. I think for time reasons they need to keep the BSD 4.3 middle layer to provide the basic OS functions, but not all of BSD provides features required for OpenStep compatibility. NeXT sold their OS for $800, a price comparable with other workstation vendors. Apple will not be able to sell a desktop OS for this, or compete with Win NT workstation ($250). I'm trying to predict where the compromise will come. : 4) It removes functionality that some current Mac users have said that : they would like. There are some Mac users who have stated that a CLI : interface with Unix utilities would be nice to have every once in a : while. Although no doubt that admission infuriates those Mac advocates : who are anti-Unix and/or anti-CLI. The point is not removal of functionality, but spliting it into pieces. The basic OS is to satisfy the ordinary Mac user, at the $100 price point they're comfortable with. The NAE provides all the OpenStep functionality you'd want, as a cost of a few hundred dollars more. Even then, it's less than half the cost NeXT now charges. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 07:21:01 GMT Organization: Global Objects Inc. Message-ID: <5bkkst$sab@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5bbtbb$b14@news.xmission.com> <maury-1501971815580001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5bbtbb$b14@news.xmission.com>, don@globalobjects.com wrote: > Now do you see my point? All of these things in the "perfect" OS would > be object libs on the drive. Your programs would send them messages with > objects as parameters. Your CLI would do the opposite of what you have to > do now, it would take flat bytes and turn them into objects to pass to > these libs. > > Look, ignore Unix, just look at that last paragraph and tell me what > exactly is so wrong for asking for the entire OS to work the same way, > rather than some one way and others others? I understand what you want. In general, I like the idea too. I don't see it feasible to do given what Apple has to work with and where they need to get to, given the time frame they are forced to deal with. Maybe in the distant future this would become a reality. To a certain degree, it already is a reality in that, for exmaple, the "rm" command is just a cover to the unlink() function in the system library. And so on for the simple UNIX commands. It will take a long time to make the more complex commands work well in this scenario; the UNIX filter paradigm, while not great for everything, does work very well for a lot of data processing applications, and some are really complicated, and imposing the structure of objects over them may be more of a hindrance than a help. (It's back to the right tool for the job argument, though admittedly, UNIX tools are older and are slowly being replaced by better paradigms. I have no problem moving to something better when it is better and more stable than what I have, but I'm not going to move before then without kicking and screaming. What you want isn't going to happen within the next two years, and may take longer than that. Also, don't ignore that for a lot of batch type jobs, the CLI is still a lot more efficient an interface than a GUI. So you can't just get rid of it. Again, right tool for the job... > No, I _don't_ expect this to happen any time soon. Is that a > reason to think it's a bad idea to try? No, I suppose not. Problem is that once people depend on this stuff (and it may be the best that there is, and reality may constrain them to use these things out of practical need) you then have a backward compatability problem. So you have a catch-22. If you wait to "do it right" you lose a market opportunity, but if you use what you have, you get locked in... > > which this reliance perhaps needs some reexamination. But I'll be > > damned if I'm going to try to rewrite awk or sed--or sendmail--so that > > my apps can use them. Those already work, and I'd like to save some > > time to get to the core of what I wish to produce. > > Yeah, but do you really like flattening out your objects so you can > stream them? Doesn't bother me. The cases I "outsource" to a UNIX command I am typically dealing with passing a text string or a glob of binary data through a filter. The string and data objects have methods for doing this painlessly. One method call, that's it. Outsourcing is still easier than trying to write all that code and fold it into a project, following up with extra testing, etc. I'm sure that as software development evolves, everything we know today will eventually change. But it will be a slow process. Just look at how long UNIX has lasted and you know that there's a lot of inertia out there. The fact that the year 2000 problem exists is due to underestimating that inertia. Let's hope we've learned out lesson. There's nothing wrong with dreaming, but it is often more useful to be practical and deal with reality, assuming you can figure out what it is. :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: pjb@imaginet.fr (Pascal Bourguignon) Newsgroups: comp.sys.next.programmer Subject: Re: Doesn't anyone know about power management? Date: 23 Jan 1997 02:27:12 GMT Organization: ImagiNET Message-ID: <5c6ia0$go7@belzebul.imaginet.fr> References: <5c1vrs$ktg@uni2f.unige.ch> In article <5c1vrs$ktg@uni2f.unige.ch> dami@cui.unige.ch (Laurent Dami) writes: > > For info: I'm using NS on a NEC Versa P laptop, and APM works just fine. > I just suspend/resume very often, and never met any problem. But I know > nothing about the kernel internals, sorry. One more data point: I'm using a DELL Lattitude XPi 90 ST, and I have to disable APM for the hardisk would not resume when it's asleep. Then I would have to power off and on, and then the file system is no more usable, and I have to reinstall it. __Pascal Bourguignon__
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 21:46:54 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E6D11E.7EA7@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> <5c1gni$nhr@duke.squonk.net> <32e6928e.106264041@news.inlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit sschaper@inlink.com wrote: > > On 21 Jan 1997 04:29:38 GMT, Garance A Drosehn > <gad@eclipse.its.rpi.edu> wrote: > > >b) certainly NeXTSTEP users do not want Unix at the expense > > of ease-of-use. In some of the early interviews with Ellen > > Hancock, she said something like "NeXTSTEP has done a good > > job of hiding Unix from the user. However, there are still > > some rough spots, and we intend to complete the job". I, > > for one, think that's a very good approach. > > > > Exactly, use IB to design Apple Human Interface Guideline compliant > GUI shells for the various UNIX tools and so forth that haven't > already been so dressed up. > > This is doable, right? That appears to be Apple's intention, to some point. I think there are plenty of Unix tools that won't get a GUI, simply because they are obscure enough that only a CLI-friendly person would care to use them. Nature of the beast, I suppose. -- Jonathan W. Hendry jon @ exnext . com
Date: Wed, 22 Jan 1997 23:01:44 -0500 From: milkweed@plainfield.bypass.com (Anders Pytte) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Message-ID: <milkweed-2201972301440001@port10.chester.smallmedia.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> Organization: Milkweed Software In article <32E6A101.7010@acm.org>, i.joyner@acm.org wrote: > Anders Pytte wrote: > > > Joyner's critique suffers certain flaws in assumption, however. No weight > > is assigned to the practical likelyhood of individual flaws actually > > impacting on a software development project. > > I don't consider this an error of omission. My effort is to write about > the > flaws. These lead to many traps that are commonly enough fallen into. To > do > what you suggest would require full time funded research to get those > kinds > of statistics. And then how would you get such numbers? By a survey > probably, > and people are not very good at reporting on their mistakes. The > critique > evaluates the flaws in C++. So where are the flaws in assumption? ... > > Conclusion. > > > > So here is my point. Most the "linguistic" advantages of other languages > > over C++ are _small_ compared to other factors active in the business of > > software development. With the one exception of garbage collection, I > > think Joyner's (and other's) critiques, though correct, are alarmist and > > exagerated in importance; I agree with Stroustrup, that the flaws of C++ > > are acceptable. > > No the critique is not alarmist. Perhaps you are alarmed by the number > of problems in C++ that I find in the critique. The best C++ people > that I know in fact think I have only scratched the surface, and I > have been too kind. I have certainly not sensationalised of overblown > importance, just reported on the facts. Yes, I and many others are > alarmed about the increasing use of C++, when we should be moving > to more modern languages. Eiffel is a step on the way. Myself and many > others disagree with you and Stroustrup that the flaws of C++ are > acceptable. You just can't cover them up that easily any more. I think > that in the next few years you will see a steady decline in the use of > C++ as people find languages that are better suited to their purposes. > > And for those who are wondering what Anders and I are talking about, > you can find the critique at: > > http://www.progsoc.uts.edu.au/~geldridg/cpp/cppcv3.html Ian, I was hoping someone would do the job of slaying me, and rather painlessly at that. I repent: there was no error of assumption on your part; by the same reasoning, nor was your critique alarmest. However, the main part of my conclusion, I believe, stands: it is still possible to create excellent products at competitive cost using C++, because the cost of this language's flaws, when prudently managed, is small compared to its benefits (excellent support, wide availability of tools and environments and skilled programmers, etc.). This is what i meant when i agreed with Stroustrup. In the meantime, I meant it when I said I would consider switching to Eiffel for my next project. But when will an _industrial_ version be available for the Mac? Anders. -- Anders Pytte Milkweed Software RR 1, Box 227 Voice: (802) 472-5142 Cabot VT 05647 Internet: milkweed@plainfield.bypass.com
From: "Kenneth R. Fleming" <ken@suite.com> Newsgroups: comp.sys.next.programmer Subject: Job Offer Date: 15 Jan 1997 16:17:26 GMT Organization: SuiteSoftware Message-ID: <01bc0300$99b090a0$b4ac3895@ken.suite.com> We are developing graphical tools to manage large scale distributed object systems. We are looking for some with extensive background in Objective-C and OpenStep/NeXTStep. Skills in C++ and JAVA as well as knowledge Message Oriented Middleware, CORBA and other graphics systems would be a plus (i.e. more $$$). email or fax resume. FAX 714-978-1840
From: scottm@nic.com (Scott Maxwell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 02:49:58 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R1601970249580001@news.erols.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.e <scottm-ya02408000R1401972248330001@news.erols.com> <AmrGwKS00iV9E5mDUv@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <AmrGwKS00iV9E5mDUv@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.advocacy: 14-Jan-97 Re: MacWorld >Exclusive: App.. by Scott Maxwell@nic.com >> Well how about this. Perhaps a method could be devised so that when you >> move an application the database of locations is updated when the move >> occurs? I know nothing of the internal operation of OpenStep but it seems >> like an easy thing to implement. > >What would that gain you? > >Right now, NEXTSTEP has conventions for the filesystem locations for >applications and other components which are supposed to be available to >everyone on the system. These conventions exist for a number of good >reasons-- they simplify system administration and fileserver >configuration, and they make it much easier for users to use a new >machine without having to waste time trying to figure out where >important applications were installed. > This is true. I'm not debating that. But, there are quite a few single users (not multi-user) who might find it strange not to be able to put things where they want them. I didn't say it was a good or bad thing. It's just the way a lot of people are used to doing things. >Nothing prevents you from installing applications whereever you want and >making links (aka aliases) into the standard locations, or from making >links from the standard locations whereever else you like. > >-Chuck > > > Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer > ----------------+---------------------+--------------------- > I know you're an optimist if you think I'm a pessimist. -- -------------------------------- Scott Maxwell - scottm@nic.com "We are a fact-gathering organization only... the minute the FBI begins making recommendations on what should be done with its information, it becomes a Gestapo." -- J. Edgar Hoover
From: rmcassid@uci.edu (Robert Cassidy) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Encryption Date: Thu, 16 Jan 1997 01:14:58 -0700 Organization: UC Irvine Message-ID: <rmcassid-1601970114580001@dialin9234.slip.uci.edu> References: <5b37rh$ss5@lastactionhero.rs.itd.umich.edu> <E3tB8n.IL@shinto.nbg.sub.org> In article <E3tB8n.IL@shinto.nbg.sub.org>, tomi@shinto.nbg.sub.org (Thomas Engel) wrote: > I am not sure if NeXT owns the patent or NeXTs mathematics guru...Richard > Crandall (hey..maybe he's one of the reasons why Mathematica has always > remained available for NeXTSTEP). > > Side Note: Elliptic Encryption can provide more unique keys with shorter key > length the public key systems based on primes. Richard found a way to remove > all divisions in the EE encryption and could replace the with simple plus and > mius operations. Thuse it is called FEE. > FEE is more secure then PGP since it can take a 40bit key and will cause the > same amount of "cracking" headache as a 120bit PGP (ok..these numbers are > wrong I would have to look them up...but you get the idea) FYI, there is an article written by Crandall in the Feb97 Scientific American concerning large number mathematics that makes mention of FEE. It's not very specific or technical regarding FEE but according to the article he estimates it would take the worlds combined computing power more than 10^10,000 years to decipher a FEE encrypted SciAmerican. Sounds pretty damn secure to me...
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 20:29:24 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E6BEF4.7D1A@exnext.com> References: <maury-0801971641590001@199.166.204.230> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <5c68rp$d6l@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan M. Urban wrote: > Note that a lot of Unix utilities use pretty much straight ANSI C, and > not too many direct Unix system calls, so there _are_ portable to NT. > Many of those that aren't directly portable are portable without too > many changes. I have seen a number of them available for NT. > > I am of the opinion that there are many cases in which a developer > would find it much more productive to base his code around a Unix > utility and port that utility to NT than rewrite all the code from > scratch. You seem to be under the assumption that all Unix utilities > are tiny little things that a programmer could bang out in a few weeks > or something. This is not the case. I'd also add that many of the Unix tools are available, free, from Cygnus in the CygWin32 package. I've got it on my Win95 box. Quite nice, though the integration with the Win95 filesystem could be nicer. Then again, it's been a while since I installed it, so maybe it's improved since then. Some are a bit screwy since the underlying functionality isn't there (whoami on a single-user system?) _~1 EXE 15,360 04-13-96 7:35p [.exe AR EXE 139,776 04-13-96 7:34p ar.exe AS EXE 249,344 04-13-96 7:34p as.exe AWK EXE 157,184 04-13-96 7:35p awk.exe BASENAME EXE 6,144 04-13-96 7:35p basename.exe BASH EXE 256,512 04-13-96 7:34p bash.exe BASHBUG 2,081 04-13-96 7:34p bashbug BISON EXE 64,000 04-13-96 7:34p bison.exe BYACC EXE 56,832 04-13-96 7:34p byacc.exe C__~1 EXE 5,120 04-13-96 7:35p c++.exe C__FIL~2 EXE 20,992 04-13-96 7:34p c++filt.exe CAPTOI~1 EXE 87,552 04-13-96 7:35p captoinfo.exe CAT EXE 9,728 04-13-96 7:35p cat.exe CC EXE 45,056 04-13-96 7:35p cc.exe CHGRP EXE 8,704 04-13-96 7:35p chgrp.exe CHMOD EXE 10,752 04-13-96 7:35p chmod.exe CHOWN EXE 9,728 04-13-96 7:35p chown.exe CKSUM EXE 8,192 04-13-96 7:35p cksum.exe CLEAR EXE 63,488 04-13-96 7:35p clear.exe CMP EXE 10,240 04-13-96 7:35p cmp.exe COMM EXE 8,192 04-13-96 7:35p comm.exe CP EXE 19,456 04-13-96 7:35p cp.exe CSPLIT EXE 37,888 04-13-96 7:35p csplit.exe CUT EXE 11,264 04-13-96 7:35p cut.exe CVTRES EXE 9,728 04-13-96 7:35p cvtres.exe CYGWIN DLL 3,264,906 04-13-96 7:35p cygwin.dll D EXE 25,088 04-13-96 7:35p d.exe DATE EXE 25,600 04-13-96 7:35p date.exe DD EXE 13,312 04-13-96 7:35p dd.exe DIFF EXE 64,512 04-13-96 7:35p diff.exe DIFF3 EXE 15,872 04-13-96 7:35p diff3.exe DIR EXE 25,088 04-13-96 7:35p dir.exe DIRNAME EXE 6,144 04-13-96 7:35p dirname.exe DLLTOOL EXE 164,864 04-13-96 7:34p dlltool.exe DU EXE 10,752 04-13-96 7:35p du.exe ECHO EXE 7,168 04-13-96 7:35p echo.exe EGREP EXE 55,296 04-13-96 7:35p egrep.exe ENV EXE 7,680 04-13-96 7:35p env.exe EXPAND EXE 8,704 04-13-96 7:35p expand.exe EXPR EXE 35,840 04-13-96 7:35p expr.exe FALSE 331 04-13-96 7:35p false FGREP EXE 55,296 04-13-96 7:35p fgrep.exe FIND EXE 51,712 04-13-96 7:35p find.exe FINGER EXE 16,896 04-13-96 7:35p finger.exe FLEX__~1 EXE 131,584 04-13-96 7:34p flex++.exe FLEX EXE 130,560 04-13-96 7:35p flex.exe FMT EXE 11,776 04-13-96 7:35p fmt.exe FOLD EXE 8,704 04-13-96 7:35p fold.exe FTP EXE 51,200 04-13-96 7:35p ftp.exe G__~1 EXE 5,120 04-13-96 7:35p g++.exe GASP EXE 37,888 04-13-96 7:34p gasp.exe GAWK EXE 157,184 04-13-96 7:35p gawk.exe GCC EXE 45,056 04-13-96 7:35p gcc.exe GCOV EXE 11,776 04-13-96 7:35p gcov.exe GDB EXE 765,952 04-13-96 7:35p gdb.exe GREP EXE 55,296 04-13-96 7:35p grep.exe GROUPS 1,440 04-13-96 7:35p groups GUNZIP EXE 44,544 04-13-96 7:35p gunzip.exe GZEXE 3,842 04-13-96 7:35p gzexe GZIP EXE 44,544 04-13-96 7:35p gzip.exe HEAD EXE 9,216 04-13-96 7:35p head.exe HOSTNAME EXE 6,144 04-13-96 7:35p hostname.exe I386-C~1 EXE 45,056 04-13-96 7:35p i386-cygwin32-gcc.exe ID EXE 8,192 04-13-96 7:35p id.exe IGAWK 2,998 04-13-96 7:35p igawk INDENT EXE 40,448 04-13-96 7:35p indent.exe INFOCMP EXE 93,696 04-13-96 7:35p infocmp.exe INSTALL EXE 12,288 04-13-96 7:35p install.exe JOIN EXE 12,800 04-13-96 7:35p join.exe LD EXE 242,176 04-13-96 7:35p ld.exe LESS EXE 134,656 04-13-96 7:35p less.exe LESSKEY EXE 6,656 04-13-96 7:35p lesskey.exe LN EXE 11,776 04-13-96 7:35p ln.exe LOCATE EXE 10,752 04-13-96 7:35p locate.exe LOGNAME EXE 5,632 04-13-96 7:35p logname.exe LS EXE 25,088 04-13-96 7:35p ls.exe M4 EXE 74,240 04-13-96 7:35p m4.exe MAKE EXE 92,672 04-13-96 7:35p make.exe MD5SUM EXE 13,824 04-13-96 7:35p md5sum.exe MKDIR EXE 9,216 04-13-96 7:35p mkdir.exe MKFIFO EXE 7,168 04-13-96 7:35p mkfifo.exe MKNOD EXE 8,704 04-13-96 7:35p mknod.exe MOUNT EXE 2,560 04-13-96 7:35p mount.exe MV EXE 12,800 04-13-96 7:35p mv.exe NICE EXE 7,680 04-13-96 7:35p nice.exe NL EXE 35,328 04-13-96 7:35p nl.exe NM EXE 145,408 04-13-96 7:35p nm.exe NOHUP 2,055 04-13-96 7:35p nohup OBJCOPY EXE 238,592 04-13-96 7:35p objcopy.exe OBJDUMP EXE 267,264 04-13-96 7:35p objdump.exe OD EXE 20,480 04-13-96 7:35p od.exe PASTE EXE 10,240 04-13-96 7:35p paste.exe PATCH EXE 35,840 04-13-96 7:35p patch.exe PATHCHK EXE 8,192 04-13-96 7:35p pathchk.exe PR EXE 15,872 04-13-96 7:35p pr.exe PRINTENV EXE 6,656 04-13-96 7:35p printenv.exe PRINTF EXE 10,752 04-13-96 7:35p printf.exe PROTO EXE 83,456 04-13-96 7:35p proto.exe PROTOIZE EXE 26,624 04-13-96 7:35p protoize.exe PWD EXE 7,168 04-13-96 7:35p pwd.exe RANLIB EXE 139,776 04-13-96 7:35p ranlib.exe RCL EXE 64,512 04-13-96 7:35p rcl.exe RESET EXE 107,520 04-13-96 7:35p reset.exe RM EXE 10,752 04-13-96 7:35p rm.exe RMDIR EXE 6,656 04-13-96 7:35p rmdir.exe SDIFF EXE 14,336 04-13-96 7:35p sdiff.exe SED EXE 52,224 04-13-96 7:35p sed.exe SHAR EXE 26,112 04-13-96 7:35p shar.exe SIZE EXE 126,976 04-13-96 7:35p size.exe SLEEP EXE 6,144 04-13-96 7:35p sleep.exe SORT EXE 20,480 04-13-96 7:35p sort.exe SPLIT EXE 9,728 04-13-96 7:35p split.exe STRINGS EXE 126,976 04-13-96 7:35p strings.exe STRIP EXE 238,592 04-13-96 7:35p strip.exe STTY EXE 22,528 04-13-96 7:35p stty.exe SUM EXE 8,192 04-13-96 7:35p sum.exe SYNC EXE 6,144 04-13-96 7:35p sync.exe TAC EXE 33,792 04-13-96 7:35p tac.exe TAIL EXE 13,824 04-13-96 7:35p tail.exe TAR EXE 109,568 04-13-96 7:35p tar.exe TEE EXE 7,680 04-13-96 7:35p tee.exe TELNET EXE 55,296 04-13-96 7:35p telnet.exe TEST EXE 15,360 04-13-96 7:35p test.exe TIC EXE 87,552 04-13-96 7:35p tic.exe TIME EXE 11,776 04-13-96 7:35p time.exe TOE EXE 87,552 04-13-96 7:35p toe.exe TOUCH EXE 23,040 04-13-96 7:35p touch.exe TPUT EXE 87,552 04-13-96 7:35p tput.exe TR EXE 16,384 04-13-96 7:35p tr.exe TRUE 332 04-13-96 7:35p true TSET EXE 107,520 04-13-96 7:35p tset.exe TTY EXE 6,656 04-13-96 7:35p tty.exe UMOUNT EXE 2,048 04-13-96 7:35p umount.exe UNAME EXE 6,656 04-13-96 7:35p uname.exe UNEXPAND EXE 9,216 04-13-96 7:35p unexpand.exe UNIQ EXE 9,216 04-13-96 7:35p uniq.exe UNPROT~1 EXE 22,528 04-13-96 7:35p unprotoize.exe UNSHAR EXE 9,728 04-13-96 7:35p unshar.exe UPDATEDB 4,376 04-13-96 7:35p updatedb USERS EXE 7,168 04-13-96 7:35p users.exe UUDECODE EXE 8,192 04-13-96 7:35p uudecode.exe UUENCODE EXE 7,680 04-13-96 7:35p uuencode.exe V EXE 25,088 04-13-96 7:35p v.exe V1 EXE 113,664 04-13-96 7:35p v1.exe VDIR EXE 25,088 04-13-96 7:35p vdir.exe WC EXE 8,704 04-13-96 7:35p wc.exe WHO EXE 9,216 04-13-96 7:35p who.exe WHOAMI EXE 5,632 04-13-96 7:35p whoami.exe XARGS EXE 11,776 04-13-96 7:35p xargs.exe YES EXE 6,144 04-13-96 7:35p yes.exe ZCAT EXE 44,544 04-13-96 7:35p zcat.exe ZCMP 2,002 04-13-96 7:35p zcmp ZDIFF 2,002 04-13-96 7:35p zdiff ZFORCE 1,006 04-13-96 7:35p zforce ZGREP 1,335 04-13-96 7:35p zgrep ZMORE 1,070 04-13-96 7:35p zmore ZNEW 3,504 04-13-96 7:35p znew SH EXE 256,512 07-04-96 11:14p sh.exe -- Jonathan W. Hendry jon @ exnext . com
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Problems with EOF 2.0 application Date: 16 Jan 1997 08:55:05 GMT Organization: Digital Fix Development Message-ID: <5bkqd9$5b7@news.digifix.com> I'm still having some problems with the application I use to update Stepwise. I think the only remaining problem is something that I've not yet got a good handle on, although I'm not sure if thats the only problem left. I've written some HTML pages that describe the App, including screen dumps, and the EOModel dump from my EOModelViewer.app. If you are interested in a copy of it, visit my pages for more information. Basically it allows you to dump EOF 2 .eomodeld's to a detailed HTML table format for documentation and or printing. The pages are at http://www.digifix.com/StepwiseEOF _any help_ would be appreciated! -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 23:13:19 -0800 Organization: Modulation Message-ID: <32E70F8F.17C2@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <32E420C6.17B7@concentric.net> <gmtbgQW00iV_E6ID5J@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld > Exclusive: App.. by Alan Lovejoy@concentric. > >> Code reuse is a principle which states that it is usually easier and > >> better to use preexisiting code rather than reinvent the wheel by > >> re-writing functionality that is already available. > >> > >> I understand what code reuse means. Do you? > >> > >> Apparently not, because you are arguing that we should not reuse the > >> preexisting code available in the form of the Unix utilities, and should > >> instead write APIs and an implementation in the C system library for all > >> of those utilities. That is the opposite of "code reuse"! > > > > Ahem. Now whose being offensive? > > > > Here's the most offensive part: you're wrongly attributing to me a position > > I have never stated, and in fact disagree with: namely, that the CLI utility > > commands should not be used, or should be eliminated. > > Hmm. I'd have to look through a few hundred articles to see precisely > what you said. You do agree that (1) you made the suggestion that the > API for the Unix CLI utilities should be abstracted into a library, and > (2) that you make that comment apparently in support of Maury's > suggestion without ever mentioning that you did not agree with the rest > of his suggestion to make those utilities optional? In reference to: (1) Yes. (2) Debatable, at best. Firstly, my first post in the thread is a response to you, not to Maury. And in the post to which I initially responded, there was no mention made of getting rid of the Unix shell. However, I can understand how you might have gotten confused, since from your point of view both things would have seemed to be the theme of the thread. In hindsight, it would have been better had I made my position on the subject of getting rid of the CLI explicit from the beginning. > Regardless of what you think about the second part, your suggestion to > recode the functionality of the Unix CLI utiltities into a library is > still the "opposite of 'code reuse'", since that functionality already > exists. Hmmm... I might agree that rewriting something is not in itself reuse, and is in fact a failure to reuse. However, I think such a failure in reuse actually occurs when the original code is written such that rewriting it is required in order to achieve better reuse. And of course, rewriting code should be done only for good reason. The question is, is rewriting code solely to make it (and its subfunctions) more reuseable sufficient justification? I think so--or rather, I think it can be, but it depends on other factors--such as time, money, the likelyhood that the code that is rewritten for greater reusability will actually get reused, and so forth. So in the **ideal** situation, I'm all for it. In practice, it depends. I don't think Apple can afford to spend any time doing this sort of thing during the next two years. After that, maybe. But they'll need help from the whole Unix community. > > If the code in the UNIX shell commands were refactored and abstracted into > > utility functions with a standard API, the universe of reusable code would > > be increased. > > Agreed. If so, then I think we essentially agree on the whole topic. > > (And of course, the original shell commands would still be available with > > the same functionality and external interfaces). I hope this is clear, and > > does not need any further proof. > > It's clear. So far, so good-- > > [ ... ] > >> > >> The point is, regardless of what it's called or whether it's just one or > >> several libraries-- there is no point at all of creating tens of > >> thousands of system calls to replace the Unix command line utilities > >> unless that mammoth API is available on all of the hardware/operating > >> system combinations that you're replacing the Unix CLI utilities, > >> otherwise programmers won't be able to depend on all of the API being > >> available, which would make it far less useful. > > > > So no OS should ever provide a library that has any function not also > > available on any other OS? Or just not available on any other Unix? > > Not at all. But I expect the process to be an evolutionary one that > will take a great deal of time. In the meantime, the Unix utility API > is pretty darn useful because it provides some important functionality. Yep. > > And a technical point: a function in a library is not a system call. It's > > only a system call if the function actually runs as part of the kernel, in > > the kernel address space, with kernel permissions. > > That's the standard definition of the term 'system call' under Unix; > other operating systems use that term more generally to refer to > functionality provided by the standard system library. Since I've been > talking to a Mac audience a lot, I've been trying to avoid using purely > Unix terminology. Ah! Understood. Terminology differences are so often the cause of needless misunderstandings. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: CLI utils vs. objects (was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!) Date: 23 Jan 1997 02:01:57 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c72d5$i1j@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5c12es$3ej@dismay.ucs.indiana.edu> <5c69ag$ecf@csugrad.cs.vt.edu> <5c6f75$spl@dismay.ucs.indiana.edu> In article <5c6f75$spl@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > In article <5c69ag$ecf@csugrad.cs.vt.edu>, > Nathan M. Urban <nurban@vt.edu> wrote: > >In article <5c12es$3ej@dismay.ucs.indiana.edu>, > >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> Oh, I'd have no problem with that. Just as long as I can keep my system() > >> call, I don't care how it's implemented (as long as performance doesn't > >> suffer). system() is the easiest way I've ever seen to pass messages to > >> the shell. Compare that with, say, writing a MacOS program that passes > >> messages via AppleScript. Does NeXT do it any better? > >What's "it"? Passing messages to the shell? To Unix command-line > >utilities? To applications? Something else? > Oh, any and all of them. The command-line is just a specific type of > shell, the shell is just another application, so it's all the same. The > only message passing and scripting I know about is AppleScript and > Unix streams. I don't know how NeXT compares to either one. NEXTSTEP tends to use two things for message passing: Portable Distributed Objects (PDO) for direct object-to-object communication, and Services for user-invoked actions that either take no parameters or operate on the current selection. Both of them are pretty slick and rather easy to use programatically. I don't know of anyone who has written a command-line interface to applications via PDO, though, since applications tend not to document their interface. There is a nice app out called TickleServices that lets you write TCL scripts as services. As to passing things to the shell, there are nice object wrappers around that, basically equivalent to a system() call except they use objects instead of a C call. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 1997 02:22:15 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c73j7$inp@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> In article <maury-2001971748370001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > If you want the Unix command-line utilities, install them. If you > don't, don't. Why has this possibility whipped the Unix people into such > a frenzy? It's not the > Arguments include... > a) Unix utils make it easier to develop > But not as easy as OOPS libs with the same functionality Yes, nonexistent OOPS libs that Apple will NOT have time to write. I agree with you that they're nicer, but plain and simple, Apple is not going to make them. > b) Unix utils make it easier to port the applications > But only to other Unixen, to NT it certainly hurts Wrong. I already mentioned that most of the main Unix utilities have been ported to NT. (And OS/2, and some other OSes.) > c) Unix utils make it easier to administer > Only because it depends on them no, it doesn't under NT Again, Apple is not going to throw out all of the Unix admin tools. You see, NT is an operating system. It has admin tools. Rhapsody is a Unix system. If you take out the Unix tools, you have nothing left! Apple does not have the time to replace all of them, nor should it. > d) It allows you do run all this great Unix software > Which the VAST majority of it's users don't want anyway Rule #1: Do not throw out a competitive advantage. Most home users do not want Unix software. Many corporate, technical, and scientific users do. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 1997 02:26:18 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c73qq$j63@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <5c343m$1ko@geraldo.cc.utexas.edu> In article <5c343m$1ko@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : raph@porter.as.utexas.edu (William Raphael Hix) wrote: > : Umm, Unix is important for people who want to run servers, you know. > : There is a lot of server-related software out there for Unix. A lot of > : it won't work if you throw out random utilities that are generally > : assumed to exist on a Unix platform. Do you want to see Rhapsody have > : an impact in the corporate environment? Not everyone is a home user. > Is Unix important to people who want to run servers? Or is a protected > memory, pre-emptively multitasking modern OS with a high performance > file system what they want. Many of them want Unix. There are an awful lot of experienced Unix admins out there. More importantly, there is an enormous amount of server software available for Unix. It's what runs the Internet. > Yes, until recently this meant Unix, but > does it need to. I'd say the growth of Win NT indicates that not all > people who run servers want Unix. There might be a better way. Maybe, but Apple isn't about to go write the new killer server OS when they had to go out and buy one just to stay alive. > : Why not? All these Unix utilities don't take up much space. Crippling > : a Unix system isn't worth the effort. The _only_ consideration is > : whether the existence of these utilities will hurt developers with > : similar products, and I don't think that this is a serious problem. I > : doubt 'find' is going to replace V-Twin for desktop use, but there are > : plenty of sysadmins and shell scripts who use it. > But the developer consideration is important to Apple. How important is > unclear, but Apple has said that developer support will be critical to > Rhapsody's success. What will they sacrifice in order to get developer > support? Did you just ignore what I said, or what? I think it's ludicrous to even imagine that 'find' is going to replace V-Twin, or that 'tar' will be competition for StuffIt. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 23:24:13 -0800 Organization: Modulation Message-ID: <32E7121D.5341@concentric.net> References: <maury-0801971641590001@199.166.204.230> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> <32E6900A.2A90@concentric.net> <5c6esv$ses@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gregory Loren Hansen wrote: > > In article <32E6900A.2A90@concentric.net>, > Alan Lovejoy <alovejoy@concentric.net> wrote: > >Gregory Loren Hansen wrote: > >> > >> In article <scottm-ya02408000R2201970338030001@news.erols.com>, > >> Scott Maxwell <scottm@nic.com> wrote: > >> >In article <5c04e3$gh9@dismay.ucs.indiana.edu>, > >> >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> > > >> >>In article <32E30DB4.7126@concentric.net>, > >> >>Alan Lovejoy <alovejoy@concentric.net> wrote: > >> >> > >> >>>Yes, the system() function is a necessity in today's world. > >> >>> > >> >>>I think the goal of Rhapsody (and all Unixes) should be to continuously > >> >>>make it less so over time. Perhaps one day... > >> >> > >> >>Why? > >> >> > >> >Why not? > >> > >> Because it's so easy to use, and because a lot of existing code uses it. > >> > >> What would you gain by removing it? > > > >Removing it? I don't advocate that at all. > > > >Reimplementing the Unix shell utilities so that their implementations are less > >monolithic and are based on reuseable sub-functions is all I am recommending. > >And even then, only as time and resources permit (which may mean never...sigh). > > Oh! I thought you thought there was something wrong with system(). But > sure, improving what's there is a great idea. And if you can call them > through system(), that would sure be a lot easier than, say, programming > with AppleScript. > > BTW, what's monolithic and unreuseable about Unix shell utilities? Each > of them do one and only one thing and you often have to string many of > them together to get something done. That's not monolithic. And they're > all sitting in standard libraries that any user or any program can call at > any time. That's pretty reuseable. Well, some are much more "monolithic" than others. "rm" is hardly more than a wrapper for the unlink() function, so it's fine just as it is. But some are rather large and complex. I find it hard to believe that none of them have any harvestable subfunctions that could be effectively reused if only they were published in a documented library (although it may be true that many don't). > Maury had a good idea. Make a set of object-oriented libraries, and > directories like /bin would be filled with CLI-style wrappers. All your > old programs will continue to work, but you get to use the spiffy new API. Exactly. It's the promised land. Now, when will it be economically justified to get there? Perhaps never, but I sure hope we can do better than that. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: leigh@cs.uwa.edu.au (Leigh Smith) Newsgroups: comp.sys.next.programmer Subject: Experience with DriverKit and MiG ? Date: 23 Jan 1997 09:04:30 GMT Organization: The University of Western Australia Distribution: world Message-ID: <5c79iu$3a3$1@enyo.uwa.edu.au> Hi All, I'm working on a device driver for a 6DOF motion tracker. I've got most of the code done, including MiG generated asynchronous reply messages to stream the coordinates to separate threads in the user task. I'm still a bit unsure about the most appropriate means of streaming coordinates from the Kernel IO task to the MiG RPC message. In the MIDI driver a FIFO buffer is filled in the Kernel IO task, with a separate thread reading from the FIFO to call the MiG reply messages. Is it possible to simply call the MiG reply messages from the Kernel IO task itself? I can't seem to get it to work and IOConvertPort steadfastly refuses to convert the port. Trawling on the rare chance someone with device development experience can provide experiences and suggestions. Many thanks. -- Leigh Smith Computer Science, University of Western Australia +61-9-380-1945 leigh@cs.uwa.edu.au (NeXTMail/MIME) "In a world where success means gaining time, thinking has a single but irredeemable fault: it's a waste of time" - J-F. Lyotard
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: 23 Jan 1997 09:51:46 GMT Organization: University of Sheffield, UK Message-ID: <5c7cbi$3bm@bignews.shef.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> <abridge-2201971335300001@dcn132.dcn.davis.ca.us> In-Reply-To: <abridge-2201971335300001@dcn132.dcn.davis.ca.us> On 01/22/97, Adam Bridge wrote: > UNIX is a strange beastie to those of us looking in at from the Mac side. > Years ago in another incarnation I remember OS's that were refered to as > "User Friendly". The Mac was just invented and, in my household, it was > better than "User Friendly." It was "User Chummy". UNIX has always > appeared to me as "User Hostile" with a command-line interface that was at > once cryptic, terse to the point of rudeness, and documented for geeks not > real users. [...] > You get the drift -- my early UNIX experience was not positive. So > imagining my Mac taken over by a version of this system is somewhat > alarming. BUT....only somewhat. UNIX is an adult operating system. I > imagine that I'd start my system once a day if I chose not to leave it on > all the time. The file system would be safe as houses. File system > performance, I hope, will be good. > I really can't believe that after the thousands of messages that have been posted on this subject that you still have not noticed that anyone who has ever used NEXTSTEP for more than a day has said that, unless you want to find out, you'll never know it's Unix. With the NeXT, Steve Jobs set out to produce a better Mac than the Mac, and in the opinion of most of us who use NeXT's s/w, he, in collaboration with some outstandingly talented engineers and designers, succeeded. If you believe in AppLE, do you really think they would sacrifice everything the company stands for and the main competitive advantage they have (IMHO) just to put a commandline interface and a few terminal windows in front of their users? No. Please, read the press releases, read the web sites, particularly the unofficial ones that NeXT-users have created to tell people more about the new OS, and then if you have any well-founded concerns, come back and ask them in an informed manner. Best wishes, mmalc. (Followups trimmed) --
From: Constantin Szallies <szallies@energotec.de> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 23 Jan 1997 10:34:41 GMT Organization: Tech Net GmbH Message-ID: <5c7es1$7bc2@ddfservb.technet.net> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> <32E64EF7.3D6A@nowhere.com> Michael Hudson <sorry.no.email@nowhere.com> wrote: >Greg Titus wrote: >> Michael Hudson <sorry.no.email@nowhere.com> writes: >> >Does Objective-C have templates? >> >> Nope. Don't need 'em. Templates are a hack to get around the >> limitations in C++'s strong binding. When you want to manipulate >> objects in a generic way in Objective-C you just declare your >> arguments as "id" (any object), and the same method works for >> everything instead of the compiler making multiple copies of the code >> for every type of object you might use. >[snip] >> >The STL >> >> No, a lot of equivalent functionality is in NeXT's Foundation >> framework. >> > >OK. Can you write me a short bit of code that would sort an array of any >type in Objective-C? >(I don't really want a complete quicksort algorithm, but somethnig that >shows it would be possible) This is only possible (nicely) with templates. Objective-C doesn't have templates, so it's not possible in Objective-C. The other replies to your question show code to sort a set of objects of any type. You can't add non-object types into these containers. Note that Smalltalk doesn't have this problem -- in the Smalltalk world everything is an object! In my experience, you don't have to hold primitive types like int, float etc. too often in containers, so the lack of templates in Objective-C is not really servere. For small sets of primitive types, one can use wrapper objects for each type without major performance impact. Have a nice day, -- Constantin Szallies, Energotec GmbH szallies@energotec.de 49211-9144018
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: kilgallen@eisner.decus.org (Larry Kilgallen) Subject: Re: NextStep & Mac Frameworks Organization: LJK Software Message-ID: <1997Jan16.103207.1@eisner> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> Date: Thu, 16 Jan 1997 15:32:07 GMT In article <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) writes: > MI is extremely useful as both a design tool and a modification tool if > used properly. Like any other tool you can also misuse it in ways that > get you into deep yogurt. In the design case, it allows you to partition > and encapsulate various independently-useful orthogonal functionalities so > that they can be combined at will (mixins) without each feature tripping > over the others. > > In the case of modifications, it allows addition of features without > messing up the original classes. For example, you buy (or obtain by hook > or by crook) a library of objects that you really don't want to modify, > but now you want to subclass and implement streams or something that was > not included in that object library. It's easy to do with MI. Without > it, you're hosed, or you at least have a lot more work than you had > planned. That ending seems to be a rather broad claim: > It's easy to do with MI. Without > it, you're hosed, or you at least have a lot more work than you had > planned. If one wants to add "mixins" in Ada95 one uses generics, and I have not seem any claim that generics are in any way more difficult for mixins. They certainly remove a lot of the risk associated with multiple inheritance, since there is ambiguity regarding common ancestors differently overridden, etc. Larry Kilgallen
From: abridge@wheel.dcn.davis.ca.us (Adam Bridge) Newsgroups: comp.sys.next.programmer Subject: How to get started Date: Thu, 16 Jan 1997 08:14:56 -0800 Organization: Bridge Family Message-ID: <abridge-1601970814560001@dcn134.dcn.davis.ca.us> I'm looking at what it will take to get started writing NeXT software. The price of admission, I have to admit, seems awfully high. Am I missing something? And are there recommendations as to platform (since I'm going to have to build a machine to run it). Thanks, Adam Bridge
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 16:29:09 GMT Organization: Netcom Distribution: world Message-ID: <5bll0l$me7@dfw-ixnews2.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > It's time someone started making open OS's that > DIDN'T use command lines and shell scripts to accomplish things. We've > had GUI's for ten years now, isn't it time to stop calling utils with > them? Why? Various scripting languages are all the rage now. JavaScript, WebScript, VBScript, etc. plus what proponents sell as advanced 4th-generation languages (4GLs) which are usually interpreted. The Unix Bourne shell language is similar. Scripting languages are a powerful alternative to GUI interfaces which can be very cumbersome in many cases. Providing both just creates a richer environment as long as users aren't *required* to use a CLI. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 23 Jan 1997 12:01:30 GMT Organization: Vienna University of Technology, Austria Message-ID: <5c7juq$7n5@news.tuwien.ac.at> References: <5amli2$ol3@news.tuwien.ac.at> <E4Dsqs.6Cx@micmac.com> Michel Coste <mic@micmac.com> wrote: > I remember when NeXT came out , ALL mac users were trying modify the > Finder to mimic NeXT!!! > What a WASTE you suggest! The Workspace is much more sophisticated > than the Finder. > To say the least what you suggest is a retrogradation... > > [ point by point comments ommited ] > The opinion of Next users (and I am also a Next user!) is utterly irrelevant to what Apple has to do to cater to their current user base. You showed point by point, that you think the Next way is better, and I agree with you in most of the cases (not all), but Apple couldn't care less about what we Next users think if they can retain their Marketshare (and Next users are negligible for that matter). The things I sugested show that it is possible to cater to all Mac users, while making all changes optional, so that *NO* functionality is lost to current Next users, so that the change is no retrogradation. I posted this to show that it is easily possible to modify the *default* behaviour of the next Workspace *WITHOUT* loosing the possibility to change everything back to the way it works now. I hope Apple/Next does something along these lines, and doesn't make a real retrogradation. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
From: Mark_Bessey@next.com (Mark Bessey) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 16 Jan 1997 16:27:01 GMT Organization: NeXT Software, Inc. Distribution: world Message-ID: <5blksl$ruc@news.next.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> G. Gordon Apple, PhD writes > MI is extremely useful as both a design tool and a modification > tool if used properly. Like any other tool you can also misuse it in > ways that get you into deep yogurt. In the design case, it allows you > to partition and encapsulate various independently-useful orthogonal > functionalities so that they can be combined at will (mixins) without > each feature tripping over the others. The mix-in model of OOP isn't supported very well by Objective-C. You can often achieve much the same results by using delegation and forwarding to create "composite" objects. > In the case of modifications, it allows addition of features > without messing up the original classes. For example, you buy (or > obtain by hook or by crook) a library of objects that you really don't > want to modify, but now you want to subclass and implement streams or > something that was not included in that object library. It's easy to > do with MI. Without it, you're hosed, or you at least have a lot more > work than you had planned. This is exactly what Objective-C protocols are for. They allow you to add methods to any existing class. This can even be done for classes that you don't have the source code to - can C++ do that? There are surely some features of C++ that would be nice to have in Objective-C (stack-allocated objects and operator overloading, for instance), but Multiple Inheritance a feature I often wish I had. -Mark -- Mark Bessey NeXT Software, Inc Software Quality Assurance -->I DON'T SPEAK FOR NeXT <--
From: Stefano Pagiola <spagiola@worldbank.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 09:15:51 -0500 Organization: World Bank Message-ID: <32E62117.583E@worldbank.org> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > >: > Example: does the existence of tar, a reasonably able backup > >: > utility with a really unfriendly UI, make companies like Alladin > >: > or Dantz who make backup software more or less eager to port to > >: > Rhapsody? I think less likely, because the number of potential > >: > buyers for Stuffit is reduced by the existence of tar and freeware > >: > extensions. Speaking as a long-time NeXT user, I can testify that over the years a large variety of backup apps, ranging from freeware through shareware to commercial software, have been written for NeXTSTEP. Yes, tar is in there, but most users want either more functionality or more ease of use, so there's been a ready market for these utilities. -- Stefano Pagiola 850 N Randolph Str No.817, Arlington VA 22203, USA All opinions are my own and do not necessarily reflect those of my employer
From: rdogra@mailserv.metro.mci.com (Rajnish Dogra) Newsgroups: comp.sys.next.programmer Subject: Re: mktime() Date: 23 Jan 1997 13:24:05 GMT Organization: InternetMCI Message-ID: <5c7opl$34e@news.internetmci.com> References: <32E65D33.446B@mit.edu> Pascal Chesnais <pascal@mit.edu> wrote: >We are having problems here with mktime under nextstep 3.3 >has anyone else run into this? Putting today's time gets >us a wrong return value (on the order of 3 year!!!) > >pasc The following code works in my NeXTStep 3.3 for Intel #include <stdio.h> #include <time.h> // // struct tm { // int tm_sec; /* seconds after the minute (0-59) */ // int tm_min; /* minutes after the hour (0-59) */ // int tm_hour; /* hours since midnight (0-23) */ // int tm_mday; /* day of the month (1-31) */ // int tm_mon; /* months since January (0-11) */ // int tm_year; /* years since 1900 */ // int tm_wday; /* days since Sunday (0-6) */ // int tm_yday; /* days since Jan. 1 (0-365) */ // int tm_isdst; /* flag; daylight savings time in effect */ // long tm_gmtoff; /* offset from GMT in seconds */ // char *tm_zone; /* abbreviation of timezone name */ // }; void main (void) { struct tm t, * t3; time_t tt, t2; t.tm_sec = 0; t.tm_min = 30; t.tm_hour = 9; t.tm_mday = 23; t.tm_mon = 0; t.tm_year = 97; tt = mktime(&t); fprintf (stderr, "sec = [%d]\n", t.tm_sec); fprintf (stderr, "min = [%d]\n", t.tm_min); fprintf (stderr, "hour = [%d]\n", t.tm_hour); fprintf (stderr, "mday = [%d]\n", t.tm_mday); fprintf (stderr, "mon = [%d]\n", t.tm_mon); fprintf (stderr, "year = [%d]\n", t.tm_year); fprintf (stderr, "wday = [%d]\n", t.tm_wday); fprintf (stderr, "yday = [%d]\n", t.tm_yday); fprintf (stderr, "\n\n"); t2 = time(&t2); t3 = localtime (&t2); fprintf (stderr, "sec = [%d]\n", t3->tm_sec); fprintf (stderr, "min = [%d]\n", t3->tm_min); fprintf (stderr, "hour = [%d]\n", t3->tm_hour); fprintf (stderr, "mday = [%d]\n", t3->tm_mday); fprintf (stderr, "mon = [%d]\n", t3->tm_mon); fprintf (stderr, "year = [%d]\n", t3->tm_year); fprintf (stderr, "wday = [%d]\n", t3->tm_wday); } Rajnish Dogra NeXTStep Developer
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 09:29:56 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5bloik$aqu@crl.crl.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> In article <maury-1501971811400001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <5b9d73$p3u@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >> Oooh, I bet the _Unix Hater's Handbook_ told you to say that. > > No actually, it's post right here in this conference that show >examples. For instance... > >I've been tearing my hair out the last couple days dealing with >HP-UX, Hewlett-Packard's version of Unix. They made a raft of >gratitious filesystem changes that added NOTHING to the value >Unix environment. 1. I said that. 2. It was said in the context of someone's proposal to make Apple's proposed Unix system "better" by renaming things like /usr. 3. I think all the unix utilities oughta be in there, in their full glory and grime. 4. Unix may suck--all OSes do--but making a bunch of gratitous changes that would make Apple's Unix layer different from every other Unix would suck even more. Casual, everyday users should never see Unix. Power users and developers are perfectly capable of dealing with the quirks of Unix, and removing or bastardizing Unix would be a tragedy of the first order, as well as a dumb business move. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.oop.macapp3 Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 16 Jan 97 10:48:07 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan16104807@howard.one.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> In-reply-to: Charles W Swiger's message of Tue, 14 Jan 1997 21:59:22 -0500 In article <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> writes: As for the size and performance of Obj-C based applications, I would suggest trying it before worrying about problems that most people don't encounter. C++ advocates always seem to imply there is a big tradeoff here, but I cannot recall ever seeing a NEXTSTEP developer (someone who has actually released commercial software) state that the size and performance of Obj-C was a significant problem. Fact of the matter is, most NeXTSTEP apps which are slow are slow because the developer didn't spend enough time looking at what the app is doing. If your app is drawing the same scene multiple times without changing it, then even if your language gives you 100% of the hardware's capability, it could be slower than an interpretted language which only draws the scene _once_. A long-term project I'm involved with is essentially a word processor with the capability of substantially rewriting the text based on answers users give to questions. The engine is written entirely in Objective-C. Every six to nine months, we manage to double or triple the speed of certain paths through the engine, without disrupting the UI (or application model) much at all, all while we continue to add new features to it. There's no reason we couldn't translate the engine into C++, gaining a "free" 10% in performance. OTOH, that would probably expand our six to nine month performance improvement schedule out to 12 to 16 months. That's an expensive price to pay for a 10% performance gain! As with anything else, algorithmic optimizations pay off much better than micro optimizations. If I thought we _really_ had anything to gain by going to C++ for our engine, we'd be there already. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <I plan to become so famous that people buy tapes of me reading source code>
From: rdieter@math.unl.edu (Rex Dieter) Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: brk and sbrk Date: 23 Jan 1997 13:41:51 GMT Organization: University of Nebraska--Lincoln Distribution: world Message-ID: <5c7pr0$4e6@crcnis3.unl.edu> Keywords: brk, sbrk I'm involved in a software porting venture... the software at hand uses the functions brk and sbrk. The NEXTSTEP man pages say these functions are not supported. Are there any other functions available to provide similar functionality? ____ Rex A. Dieter rdieter@math.unl.edu (NeXT/MIME OK) Computer System Manager http://www.math.unl.edu/~rdieter/ Mathematics and Statistics University of Nebraska-Lincoln
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 18:01:27 GMT Organization: Airwindows Message-ID: <jinx6568-1601971303370001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> In article <mckinnon-1001970053450001@mckinnon.tezcat.com>, mckinnon@tezcat.com (Chuck McKinnon) wrote: > Well if .apps all have to go into a certian location for the OS to work, > why not make the "Applications" folder act like the System folder. > Currently, the Applications folder is a normal folder with a special > icon, and the system will recognize it as such; also the Finder allows > for protection of this folder. What folder? This is something that came with my Mac I suppose, like the short-lived Documents folder? > Just go the next step (pun intended) and make the Applications folder > the required place for .apps and make the system treat it as such. This > would make even more sense for new/consumer user: it makes sense. > All apps go in the Applications folder, [duh!] and the new system will > get what it need. > Or is this too simple? Way too simple for me, I'm afraid, I would find that disgustingly restrictive. The notion of an 'Applications', 'Documents' etc folder, is horribly Win-like, not something I could deal with. My root folders are along the lines of 'video', 'writing' etc, not categories that are frankly only useful to the computer itself. "Applications"? What good does that do me? Useless. Jinx_tigr (aka Chris Johnson)
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: 23 Jan 97 09:27:33 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan23092733@slave.one.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> <5c6qsj$2lv@news.digifix.com> In-reply-to: sanguish@digifix.com's message of 23 Jan 1997 04:53:39 GMT In article <5c6qsj$2lv@news.digifix.com>, sanguish@digifix.com (Scott Anguish) writes: A universally available format with the features of Stuffit (random access wise) and the free/clear compression algorithms of gzip would be a huge winner provided that the archive format and algorithms were made public so that it could become an 'all platform' solution. Sounds like InfoZip to me. Or perhaps zoo, though InfoZip has better compression. [In case you live in a DOS box, InfoZip is a portable version of PKZip. Source code included.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: jinx6568@sover.net (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 16 Jan 1997 18:28:40 GMT Organization: Airwindows Message-ID: <jinx6568-1601971330530001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <32D2BCF1.41C6@cineon.kodak.com> <maury-0901971043380001@199.166.204.230> <5b39ha$2cn@bignews.shef.ac.uk> <maury-0901971623200001@199.166.204.230> <5b44cf$s7g@bignews.shef.ac.uk> <jbf-ya023580001001970120370001@news.tiac.net> In article <jbf-ya023580001001970120370001@news.tiac.net>, jbf@frazer.com (James B. Frazer) wrote: > > The whole of NEXTSTEP, absolute minimum installation, takes up less than > > 100MB I believe. I don't know just how much MacOS uses, but if you added > > enough extras to give you the same functionality (i.e. you'd have to add > > internet connectivity, a number of applications for system administration > > etc), I wonder if you'd be in the same ballpark? > My system partition, with the 7.5.5 OS and a minimal set of Unixy utilities, > runs to 90MB. Now that's somewhat inflated by my PowerPC architecture; perhaps > the equivalent would be 60-70 MB on a 680x0. That's close enough so that Mac > fans shouldn't fret. And, believe me, those Unix utilities replace a great > many small Mac applications. 40.1 MB here on 68K 7.5.5. This is not including GX, no speech extensions, no Applescript or Apple Guide extensions (I do trim my system to be more compact). But it does include CD-Rom, open transport, PPP etc etc etc, the Netscape 3.01 Java libraries and cache (currently at 5M and full) as well as Kaleidoscope and support files, and a limited amount of Clarisworks support files, and of course the Eudora support folder *think* what else? Anyway, that's 40.1 megs in total. In a lot of ways I'd like to see the end of the extensions and system folders. One reason is that if I am going to use something like Kaleidoscope I want to _replace_ the relevant code and discard the previous code, rather than patching it in. I also don't particularly like needing to have app stuff in my system folder. Though it's sobering that even with Netscape and Eudora and Clarisworks I'm at 40M. How is it that it can require 100M? Jinx_tigr (aka Chris Johnson)
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 97 09:22:07 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan23092207@slave.one.net> References: <maury-0801971641590001@199.166.204.230> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> <32E6900A.2A90@concentric.net> <5c6esv$ses@dismay.ucs.indiana.edu> In-reply-to: glhansen@copper.ucs.indiana.edu's message of 23 Jan 1997 01:29:03 GMT In article <5c6esv$ses@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) writes: Maury had a good idea. Make a set of object-oriented libraries, and directories like /bin would be filled with CLI-style wrappers. All your old programs will continue to work, but you get to use the spiffy new API. Then you could call the API "Perl" ... [sorry, I just couldn't resist,] -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software Subject: Re: killer apps for Apple/NeXT Date: 16 Jan 1997 01:31:25 GMT Organization: Rockwell Avionics - Collins Message-ID: <5bk0dd$jnq@castor.cca.rockwell.com> References: <32DD473F.334E@worldnet.att.net> Cc: ziziz@worldnet.att.net In <32DD473F.334E@worldnet.att.net> zizi zhao wrote: > Dean Hall is looking for killer apps for Apple/NeXT OS. He says: > "So far > most of the stories have been about > Apple , I would really like to know > about how the deal affects NeXT > developers. Does anyone have a > killer app in the works? What about > game developers? " > in his webpage http://members.tripod.com/~dehall/nextstep.html One of the companies I contract for may just have the "killer app". Imagine building first class OpenStep objects (especially highly graphical animating ones) with no code at all. This thing could put Visual Basic out of the picture and or be a great way to build Visual Basic component ware. My company is in fact working on a high end game using all of the latest greatest NeXT technology. Sorry I can not give details. P.S. Renderman was already available for Mac
From: Charles W Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Installing software, was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 16 Jan 1997 13:20:15 -0500 Organization: Carnegie Mellon, Pittsburgh, PA Message-ID: <Qmrb5T600iWp05gzo0@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <bononno-ya023680000801972236310001@news.nyu.edu> <maury-0901971047250001@199.166.204.230> <5b39sm$2u9@bignews.shef.ac.uk> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <32D60909.42EC@surf.net.au> <5b647r$s70@news.xmission.com> <ting-1201971325500001@hera.e <scottm-ya02408000R1401972248330001@news.erols.com> <AmrGwKS00iV9E5mDUv@andrew.cmu.edu> <scottm-ya02408000R1601970249580001@news.erols.com> In-Reply-To: <scottm-ya02408000R1601970249580001@news.erols.com> Excerpts from netnews.comp.sys.next.advocacy: 16-Jan-97 Re: MacWorld Exclusive: App.. by Scott Maxwell@nic.com >> Right now, NEXTSTEP has conventions for the filesystem locations for >> applications and other components which are supposed to be available to >> everyone on the system. [ ... ] > > This is true. I'm not debating that. But, there are quite a few single > users (not multi-user) who might find it strange not to be able to put > things where they want them. I didn't say it was a good or bad thing. It's > just the way a lot of people are used to doing things. What you've said is clearly true. I suspect that for many people it simply won't be a problem. So let's consider an example of how a typical software installation works under NS, and see whether there is anything that you feel might be a problem. Let's say you're browsing some NS sites on the web, and see some software that you want to get-- a new demo, or an updated version, or whatever. You click on the URL, and your web browser happily goes and downloads the file. Let's say this was some shrinkwrapped software which was built into an Installer.app package [.pkg], and is archived to the FTP or web site probably in .compressed or .tar.gz format (1). When the download is done, your web browser will automatically invoke Opener.app to extract the package, and Opener.app will in turn automatically invoke Installer.app. Installer.app has a really nice and simple interface; all you have to do is click the "Install" button, and Installer may ask you where the files should go if you don't choose to accept the default location that the authors of the package recommend. You can also do such things as select which languages and which architectures (if you've got a FAT binary). But unless you tell it differently, software installed via this mechanism will be put in a sensible place. That's all, folks-- one click in the web browser, one click for Installer.app. Oh, in some cases you might have to hit return once or twice to confirm where to put the software and which languages/architectures to install. If you have a reason to install the software somewhere else than the default, no problem. If you do that and still want to have the system recognize the document types associated with that software, you can make a link. So I am of the opinion that the conventions in use for where things 'should' go will be something that most Mac people will like if they ever think about it at all. [ This is assuming that Apple doesn't change any of this, which they presumably would if Apple thinks that their user base is going to have problems. ] One more thing-- uninstalling software is just as easy. Whenever you install a package, Installer saves a record of the files installed and how to uninstall them in /NextLibrary/Receipts/. Just double-click on the .pkg file for whatever it is to run Installer, and then click "Uninstall". -Chuck ----------------- (1) NeXT's .compressed is another name for .tar.Z, and is used by the WorkSpace which lets you compress, decompress, and inspect .compressed files. Opener.app is an awesome utility that understands pretty much every major archive format used: *.Z,tar,shar,lzh,lha unix compressed files *.z,gz GNU gzipped files *.taz,tgz msdos .tar.Z, .tar.gz *.uu uuencoded file *.hqx,bin,sit,cpt macintosh archives *.arc,zip,zoo msdos arc archives *.PS (Preview misses cap .PS) *.arj msdos arj archives (extraction only) *.compressed NeXT compressed files Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Drone <foxglove@globalserve.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 11:15:21 -0500 Organization: Envision This Message-ID: <32E78E99.1289@globalserve.net> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> <32E655AD.55D3@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > > No, the Mac GUI does not let you do *everything*. If there is something > that is not in the GUI, you *cannot* do it. Unless, of course, some > nice programmer comes along and writes a program that lets it happen. > Well, DUH! Drone. -- "esse est percipi" foxglove@globalserve.net
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 23 Jan 1997 10:26:08 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c7vug$4s4@csugrad.cs.vt.edu> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> In article <32E64EF7.3D6A@nowhere.com>, none wrote: > OK. Can you write me a short bit of code that would sort an array of any > type in Objective-C? Well, that's a built-in method of NSArray.. their documentation example is (modified for a mutable array): NSMutableArray *sortedArray = [anArray sortUsingSelector:@selector(compare:)]; The compare: message is sent to each object in the array, no matter what they are -- you can have a mixed array of objects, of course -- and returns NSOrderedAscending, NSOrderedDescending, or NSOrderedSame. (Those three return values are C enumerated types, by the way.) > (I don't really want a complete quicksort algorithm, but somethnig that > shows it would be possible) Internally, it's doing something like: id obj1 = [anArray objectAtIndex:i]; id obj2 = [anArray objectAtIndex:j]; if([obj1 compare:obj2] == NSOrderedDescending) { // swap elements [obj1 retain]; // keep the array from freeing obj1 when it is replaced at 'i' // don't have to worry about obj2, it gets retained by the first replace // and released by the second [anArray replaceObjectAtIndex:i withObject:obj2]; [anArray replaceObjectAtIndex:j withObject:obj1]; [obj1 release]; // decrement the reference count } I hope this works, it's just off the top of my head. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.mac.advocacy,comp.sys.next.advocacy Date: Thu, 23 Jan 1997 10:57:41 -0600 Organization: mementech, inc. Message-ID: <32E79885.7DBD37EB@screaming.org> References: <maury-0801971641590001@199.166.204.230> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> <32E6900A.2A90@concentric.net> <5c6esv$ses@dismay.ucs.indiana.edu> <SHESS.97Jan23092207@slave.one.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott Hess wrote: > > (Gregory Loren Hansen) writes: > > Maury had a good idea. Make a set of object-oriented libraries, > > and directories like /bin would be filled with CLI-style wrappers. > > All your old programs will continue to work, but you get to use the > > spiffy new API. > > Then you could call the API "Perl" ... > > [sorry, I just couldn't resist,] No problem; I couldn't stop thinking about perl during this entire thread. I like Maury's idea in the abstract, and I trust that we'll keep slowly approaching that object-nirvana. Today AppLE has too many higher priorities that need to be addressed before they go yanking-out all the calls to system() and replacing the functionality of what was being called with an ObjC/OpenDoc frameworks. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 13:04:41 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E7A839.564E@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c73j7$inp@csugrad.cs.vt.edu> <32E7A213.77BB@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > > Nathan M. Urban wrote: > > > > In article <maury-2001971748370001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > > > > a) Unix utils make it easier to develop > > > But not as easy as OOPS libs with the same functionality > > > > Yes, nonexistent OOPS libs that Apple will NOT have time to write. I > > agree with you that they're nicer, but plain and simple, Apple is not > > going to make them. > > > > I'm starting to think that what Maury really wants is Perl. ;) Doh! &^*&^%()! Scott beat me to it. Drat. -- Jonathan W. Hendry jon @ exnext . com
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 22:08:34 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E6D632.7A82@exnext.com> References: <maury-0801971641590001@199.166.204.230> <scottm-ya02408000R2201970338030001@news.erols.com> <5c5tvp$jfu@dismay.ucs.indiana.edu> <32E6900A.2A90@concentric.net> <5c6esv$ses@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gregory Loren Hansen wrote: > Maury had a good idea. Make a set of object-oriented libraries, and > directories like /bin would be filled with CLI-style wrappers. All your > old programs will continue to work, but you get to use the spiffy new API. Kind of like ixsearch, ixbuild, etc. (I think, anyway. I suspect they wouldn't work if you nuked the indexing kit shlibs.) -- Jonathan W. Hendry jon @ exnext . com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Date: Thu, 16 Jan 1997 15:27:03 -0500 Organization: Atria Software Message-ID: <maury-1601971527030001@199.166.204.230> References: <petrichE3Ct2r.3AJ@netcom.com> <marke-0201970007270001@port55.annex5.nwlink.com> <AEF16B02-AD9E5@198.68.42.189> <5ahf5n$pq2@bignews.shef.ac.uk> <5ajg47$soi@bignews.shef.ac.uk> <1997010514570823842@p026.gor.euronet.nl> <5ap7db$mnu@nyheter.chalmers.se> <5argj1$84s@majipoor.cygnus.com> <5auv1t$h2c@nyheter.chalmers.se> <5b0vqa$k9@majipoor.cygnus.com> <maury-0801971738540001@199.166.204.230> <5b1bq7$48e@news.xmission.com> <maury-0901971304410001@199.166.204.230> <5b5vme$s70@news.xmission.com> <maury <maury-1401971527570001@199.166.204.230> <0mrHfT600iV945m0Ei@andrew.cmu.edu> In article <0mrHfT600iV945m0Ei@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: > multiple sections supported by Mach-O are a straightforward extension of > the venerable a.out format, which had precisely three sections: TEXT, > DATA, and BSS. Ahhhhhhh. So (you see this coming), why did it stop there? Maury
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 12:38:27 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E7A213.77BB@exnext.com> References: <maury-0801971641590001@199.166.204.230> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c73j7$inp@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan M. Urban wrote: > > In article <maury-2001971748370001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > > a) Unix utils make it easier to develop > > But not as easy as OOPS libs with the same functionality > > Yes, nonexistent OOPS libs that Apple will NOT have time to write. I > agree with you that they're nicer, but plain and simple, Apple is not > going to make them. > I'm starting to think that what Maury really wants is Perl. ;) -- Jonathan W. Hendry jon @ exnext . com
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: 23 Jan 1997 20:17:20 GMT Organization: Digital Fix Development Message-ID: <5c8h0g$9sf@news.digifix.com> References: <maury-0801971641590001@199.166.204.230> <SHESS.97Jan23092733@slave.one.net> In-Reply-To: <SHESS.97Jan23092733@slave.one.net> On 01/22/97, Scott Hess wrote: >In article <5c6qsj$2lv@news.digifix.com>, > sanguish@digifix.com (Scott Anguish) writes: > A universally available format with the features of Stuffit (random > access wise) and the free/clear compression algorithms of gzip > would be a huge winner provided that the archive format and > algorithms were made public so that it could become an 'all > platform' solution. > >Sounds like InfoZip to me. Or perhaps zoo, though InfoZip has better >compression. > >[In case you live in a DOS box, InfoZip is a portable version of >PKZip. Source code included.] > Yep, it does doesn't it. Of course they'd have to store the multi-forked Apple files in some special manner in the archive, but that shouldn't be a big deal. There must be a good multi-forked Apple file 'flatten' format available right? Other than BinHex that is.. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: How to get started Date: 16 Jan 1997 20:52:11 GMT Organization: Digital Fix Development Message-ID: <5bm4dr$a3s@news.digifix.com> References: <abridge-1601970814560001@dcn134.dcn.davis.ca.us> In-Reply-To: <abridge-1601970814560001@dcn134.dcn.davis.ca.us> On 01/16/97, Adam Bridge wrote: >I'm looking at what it will take to get started writing NeXT software. >The price of admission, I have to admit, seems awfully high. Am I missing >something? And are there recommendations as to platform (since I'm going >to have to build a machine to run it). > The price of OpenStep developer is likely to come down soon. Originally it was thought that it would happen at Expo, but I doubt it will until the FTC approves the merger and the deal is done. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 23 Jan 1997 20:55:39 GMT Organization: The University of Iowa Message-ID: <5c8j8b$10sg@flood.weeg.uiowa.edu> References: <32E78DAF.433F@srsys.com> From article <32E78DAF.433F@srsys.com>, by Bill Vareka <billv@srsys.com>: > Matthew Clay wrote: I didn't seem to say anything... >> >> From article <5c0ivv$7e4@gaea.titan.org>, by toon@gaea.titan.org (Greg Titus): >> > Michael Hudson <sorry.no.email@nowhere.com> writes: >> >>Function overloading >> >>User defined type conversions >> > >> > Nope. These lose a lot of their utility when type isn't so important, as in >> > C++. I wrote that this was not the case, as any Prolog programmer would agree. > Is this true? Objective-C has no *function* overloading. I can > understand both sides to the arguments about *operator* overloading but > function overloading is > one of those features that, once you see it, > it seems so natural. instead of defining.. > > Draw(); > Draw(color *bkgrd); > Draw(float scaled); > now I'll need to regress back to: > Draw(); > DrawWithNewBckgrdColor(color *bkgrnd); > DrawScaledVersion(float scaled); That's correct. As Objective-C and Java mature and become mainstream, however they will face the same compelling arguments for new features as C++ did/does. The choices seem limited to following the same feature-rich path as C++ and being criticized as monstrosities, or striving for the minimality of C and being criticized as primitive. -mc
From: acurylo@inmediapresents.com (Alex Curylo) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: NextStep & Mac Frameworks Date: Thu, 16 Jan 1997 11:09:40 -0800 Organization: InMedia Presentations Distribution: world Message-ID: <acurylo-1601971109400001@van0217.tvs.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> In article <5bkjj6$big@darla.visi.com>, dwy@ace.net (David Young) wrote: > Aha! No you're *not*! Objective-C to the rescue again, with "categories", > a totally powerful way to extend any class with new methods, regardless > of whether or not you have source. I find myself wishing for it all the > time in other lanaguages. Basically, you define a category of a class > with: > > @interface NSString (DavesExtendedNSString) > > and add methods you please, and every intance of NSString across the > applicaiton gets the new methods, which, when combined with anonymous > messaging, is very useful indeed... What gets me is how, if all these super-neat features like this that the Obj-C guys keep casually throwing out really do exist as described, why on earth did the universe at large adopt C++ instead? ---- Alex Curylo -- alex@witty.com
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 23 Jan 97 15:16:27 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan23151627@slave.one.net> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> In-reply-to: nurban@csugrad.cs.vt.edu's message of 23 Jan 1997 10:26:08 -0500 In article <5c7vug$4s4@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: In article <32E64EF7.3D6A@nowhere.com>, none wrote: > (I don't really want a complete quicksort algorithm, but > somethnig that shows it would be possible) Internally, it's doing something like: id obj1 = [anArray objectAtIndex:i]; id obj2 = [anArray objectAtIndex:j]; if([obj1 compare:obj2] == NSOrderedDescending) { // swap elements [obj1 retain]; // keep the array from freeing obj1 when it is replaced at 'i' // don't have to worry about obj2, it gets retained by the first replace // and released by the second [anArray replaceObjectAtIndex:i withObject:obj2]; [anArray replaceObjectAtIndex:j withObject:obj1]; [obj1 release]; // decrement the reference count } I hope this works, it's just off the top of my head. Aighh! I would expect that NSArray is implemented internally as a pointer to a block of memory, and that they could just use qsort() with wrappers around -compare:. Something like: @implementation NSArray . static compare_wrapper( id obj1, id obj2) { return [obj1:compare:obj2]; } -(void)sortInPlace { qsort( [self getBaseOfArray], [self count], sizeof( id), compare_wrapper); } . @end Of course, that all has to be wrapped up in various sugar. For instance, you can sort an NSMutableArray in-place, but an NSArray can't be sorted in place ... from code using the API. _Internally_ it can be sorted in place easily enough :-). Also, the generic -sortUsingSelector: would have to store away the appropriate selector somewhere to be used by -performSelector:withObject:. In any case, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer From: allan@ali.bc.ca (Allan Noordvyk) Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Message-ID: <E4HCz4.5y3@gateway.ali.bc.ca> Sender: nobody@gateway.ali.bc.ca Cc: billv@srsys.com Organization: A.L.I. Technologies, Inc. Date: Thu, 23 Jan 1997 21:28:16 GMT References: <5c0ivv$7e4@gaea.titan.org> <5c2pmq$fec@flood.weeg.uiowa.edu> <32E78DAF.433F@srsys.com> In comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Bill Vareka wrote: > Is this true? Objective-C has no *function* overloading. I can understand both > sides to the arguments about *operator* overloading but function overloading is > one of those features that, once you see it, it seems so natural. > > instead of defining.. > > Draw(); > Draw(color *bkgrd); > Draw(float scaled); > > now I'll need to regress back to: > > Draw(); > DrawWithNewBckgrdColor(color *bkgrnd); > DrawScaledVersion(float scaled); > > Tell me it isn't so.... :-( Actually the syntax would be something like: - draw; - drawWithBackgroundColor:(Color *)aColor; - drawWithScale:(float)aScale; Which isn't really any more work to define than the overloaded C++ functions (except for longer names) and has the advantage that the calling code is more readable (ie. I don't have to figure out the type of the argument to tell which method is being called. If you really wanted to "overload" a method, note that you can define something like: - (void)drawWithObject:anObject { // This method does the appropriate drawing activity // for the provided argument object. if ([anObject isKindOfClass:[Color class]]) { // Treat the argument as the background // color to be used. .... return; } if ([anObject isKindOfClass:[NSNumber class]]) { // Treat the argument as the scale // factor to be used. ... return; } ... } But all this achieves in most situations is difficult to read and slightly less efficient code. For the most part, overloading is not something I care about. If the type of the argument is important, I probably have a purpose for the argument which should be reflected in the method name. If the type isn't important, then I am going to treat all of the objects essentially the same and I will just have one method (eg. addObject: ). Example: If I want to add a method to draw with a particular *foreground* color to your C++-ish example, I can't just define something like: Draw(color *foregrd); because there is already a Draw method with color argument. Instead, I'd have to have to define DrawWithForegroundColor(color *foregrd) Which is inconsistant with the other draw methods and leads to a confusing API. -- Allan Noordvyk, Software Artisan e-mail: allan@ali.bc.ca ALI Technologies Voice: 604.279.5422 x 317 Richmond, Canada Fax: 604.279.5468 * NeXT and MIME mail welcome * "I have never seen anything fill up a vacuum so fast and still suck." -- Rob Pike, commenting on The X Window System
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: Re: brk and sbrk Date: 23 Jan 97 15:09:37 Organization: Is a sign of weakness Distribution: world Message-ID: <SHESS.97Jan23150937@slave.one.net> References: <5c7pr0$4e6@crcnis3.unl.edu> In-reply-to: rdieter@math.unl.edu's message of 23 Jan 1997 13:41:51 GMT In article <5c7pr0$4e6@crcnis3.unl.edu>, rdieter@math.unl.edu (Rex Dieter) writes: I'm involved in a software porting venture... the software at hand uses the functions brk and sbrk. The NEXTSTEP man pages say these functions are not supported. Are there any other functions available to provide similar functionality? sbrk()/brk() are indeed there, though. Just not supported. I'd try them, first. Unfortunately, I don't know what the interface is, perhaps it'll be fine to snarf prototypes from another platform. [Aha, just a second ... int brk( void *end); void *sbrk( int incr);] If that's distasteful, you could probably emulate them to a great degree. I've never used brk()/sbrk(), but here goes (this code has never been compiled - don't look at me!): // 40M good enough? This isn't the value _actually_ allocated, // it's the amount of zerofill memory desired. You can run it // right off the scale if you want. It will wreak havoc with // your VSIZE in ps(1), of course. #define MaxSize (40*1024*1024) static void *__endCode=NULL; /* The "end" of code space. */ static void *__endData; /* The "end" of data space. */ // Allocate a MaxSize area "between" the end of code and the // stack. It's not really there, it just sounds like it is. // Returns the "end of code" pointer, which I think most // brk()/sbrk() users need. void *init_sbrk( void) { if( __endCode!=NULL) { return __endCode; } if( vm_allocate( task_self(), &__endCode, MaxSize, TRUE)!=KERN_SUCCESS) { errno=ENOMEM; return NULL; } // Mark the pages protected so you can't go in and screw // with them. vm_protect( task_self(), __endCode, MaxSize, FALSE, VM_PROT_NONE); vm_inherit( task_self(), __endCode, MaxSize, VM_INHERIT_COPY); __endData=__endCode; return __endCode; } // If newEnd is in range, let it go through. Everything between // __endCode and __endData is marked read/write, everything // paste __endData is marked free. int emu_brk( void *newEnd) { if( __endCode<newEnd && newEnd<__endCode+MaxSize) { void *align; __endData=newEnd; align=__endData; align=(((unsigned)align+vm_page_size-1)/vm_page_size)*vm_page_size; vm_protect( task_self(), __endCode, align-__endCode, FALSE, VM_PROT_WRITE); // The following three lines probably need error // handling, but I'm not going to do it. The theory, // here, is that you deallocate the pages (throwing // them back into the system's pool), reallocate them // as zerofill pages, and set the protection to allow // no access. The problem is, what if it can't allocate // the pages in the same place? It _should_ work, so // long as another thread in this process didn't come // in meanwhile and allocate something in there. // vm_deactivate() would be alright, except that it // doesn't actually free the pages, so it's not very // close to the intent of brk(). vm_deallocate( task_self(), align, MaxSize-(align-__endCode)); vm_allocate( task_self(), align, MaxSize-(align-__endCode), FALSE); vm_protect( task_self(), align, MaxSize-(align-__endCode), FALSE, VM_PROT_NONE); vm_inherit( task_self(), align, MaxSize-(align-__endCode), VM_INHERIT_COPY); return 0; } errno=ENOMEM; return -1; } void *emu_sbrk( int increment) { void *prevEnd=__endData; if( emu_brk( prevEnd+increment)==-1) { return NULL; } return prevEnd; } Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Bill Vareka <billv@srsys.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Thu, 23 Jan 1997 08:11:27 -0800 Organization: Stanford Research Systems Message-ID: <32E78DAF.433F@srsys.com> References: <5c0ivv$7e4@gaea.titan.org> <5c2pmq$fec@flood.weeg.uiowa.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Clay wrote: > > From article <5c0ivv$7e4@gaea.titan.org>, by toon@gaea.titan.org (Greg Titus): > > Michael Hudson <sorry.no.email@nowhere.com> writes: > > > >>Function overloading > >>User defined type conversions > > > > Nope. These lose a lot of their utility when type isn't so important, as in > > C++. > Is this true? Objective-C has no *function* overloading. I can understand both sides to the arguments about *operator* overloading but function overloading is one of those features that, once you see it, it seems so natural. instead of defining.. Draw(); Draw(color *bkgrd); Draw(float scaled); now I'll need to regress back to: Draw(); DrawWithNewBckgrdColor(color *bkgrnd); DrawScaledVersion(float scaled); Tell me it isn't so.... :-( bill vareka
Newsgroups: comp.sys.next.programmer Subject: Re: Event handling during tight loop Message-ID: <32E80C7B.8DD@running-start.com> From: Ralph Zazula <zazula@running-start.com> Date: Thu, 23 Jan 1997 17:12:27 -0800 References: <32e3b48a.0@192.33.12.30> Organization: Running Start, Inc. MIME-Version: 1.0 To: jon klein <jklein@freon.artificial.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jon klein wrote: > > Hey, > I've got a tight loop in a program, and I'd like for it to be > interuptable by hitting a button. Without using threads, can somebody > help me with this procedure? Do I use [NXApp getNextEvent], and then > find an NX_MOUSEDOWN and manually check the coordinates to see if they > hit the button? > > -- > -jon klein > jklein@freon.artificial.com > > Caper will do it for me. I'm assuming this is a NEXTSTEP application (since you refer to NXApp). Yes, using getNextEvent:waitFor:threshold: will allow you to process events in your tight loop. If you see an event, you can dispatch it manually using sendEvent:. It probably wouldn't hurt to send all events since the user could then manipulate the menu (e.g., to hide or quit the app). The code might look something like this: - runLoop { NXEvent *event; while(![self done]) { /* run part of the long-running process */ [self computeALittle]; /* process events that have queued up */ while(event = [NXApp getNextEvent:NX_ALLEVENTS waitFor:0.0 threshold:NX_MODALRESPTHRESHOLD]) { /* send events -- possibly button clicks and stuff */ [NXApp sendEvent:event]; } } } Ralph -- Ralph Zazula Running Start, Inc. zazula@running-start.com 520/760-4890 (voice/fax) http://www.running-start.com
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 24 Jan 1997 03:13:26 GMT Organization: Netcom Distribution: world Message-ID: <5c99cm$n3l@sjx-ixn5.ix.netcom.com> References: <5c0ivv$7e4@gaea.titan.org> <5c2pmq$fec@flood.weeg.uiowa.edu> <32E78DAF.433F@srsys.com> Bill Vareka <billv@srsys.com> wrote: > Is this true? Objective-C has no *function* overloading. I can understand both > sides to the arguments about *operator* overloading but function overloading is > one of those features that, once you see it, it seems so natural. > > instead of defining.. > > Draw(); > Draw(color *bkgrd); > Draw(float scaled); > > now I'll need to regress back to: > > Draw(); > DrawWithNewBckgrdColor(color *bkgrnd); > DrawScaledVersion(float scaled); Some of us don't view this as regression, but progress :-) Objective-C method names are very expressive and somewhat self-documenting *by convention*, so I wouldn't as happy trying to recall which of the following to use: - draw - draw:(NSColor *)aColor // How does draw: use aColor? - draw:(float)aFactor // How does draw: use aFactor? compared with - draw - drawWithBackgroundColor:(NSColor *)aColor - drawWithScalingFactor:(float)aFactor However, draw and draw: are 2 different Objective-C selectors, so the draw method is distinguishable from draw:. But the Objective-C runtime doesn't use return or argument types to distinguish among selectors. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: Thu, 23 Jan 1997 20:35:27 -0600 Organization: mementech, inc. Message-ID: <32E81FEF.156B70AF@screaming.org> References: <5amli2$ol3@news.tuwien.ac.at> <E4Dsqs.6Cx@micmac.com> <5c7juq$7n5@news.tuwien.ac.at> <5c93k6$l5c@news3.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Kheit wrote: > But you are right...in and of ourselves...we don't amount to a hill > of beans (the NeXT community...)...well, on the other hand...we > are the biggest pool of Rhapsody developers out there :) ...suddenly panic-stricken Mac advocates worldwide develop an insatiable appetite for the OpenStep documentation on next.com... -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 20:45:33 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E8143D.1586@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> <32E655AD.55D3@exnext.com> <tbrown-ya023580002301971942020001@news.netset.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ted Brown wrote: > > In article <32E655AD.55D3@exnext.com>, jon@exnext.com wrote: > > >Travis Butler wrote: > > > >> Also, every GUI-driving-CLI system I've seen has had 'holes' where the > >> developers didn't provide a GUI shell for a CLI command... so that a user > >> has to learn the CLI to get some things done. The Mac GUI lets you do > >> *everything* - either directly or through GUI utilities. > > > >No, the Mac GUI does not let you do *everything*. If there is something > >that is not in the GUI, you *cannot* do it. Unless, of course, some > >nice programmer comes along and writes a program that lets it happen. > > And this differs from any other OS how? The CLI on NeXTSTEP (and others) allows access to functionality that hasn't been developed with a GUI. The Mac GUI has no 'holes' because there's less functionality there to begin with. -- Jonathan W. Hendry jon @ exnext . com
From: andylee@ucla.edu (Andy Lee) Newsgroups: comp.sys.next.programmer Subject: Problem using MiscInspectorKit (MiscKit 1.9.0) Date: Fri, 24 Jan 1997 04:23:22 GMT Organization: University of California, Los Angeles Message-ID: <32e83488.154926334@news.ucla.edu> Hello, I am puzzled by a problem encountered with MiscInspectorKit and would appreciate any help or suggestion, i.e. what else could I use to implement inspectors? (NeXTstep FIP 3.3 User / 3.2 Dev) Following the SwapKit Tutorial in MiscKit, I created in my main project a master inspector manager with several inspector wrappers to load their respective .nib files. Inside each .nib file, the file owner is a wrapper, and there are several MiscInspectors to swap their views into the Inspector Panel. The prototype works great. Each wrapper loads and registers their MiscInspectors and swap their views into the Inspector Window. But when I subclass the MiscInspector to implement revert: in each, the program mysteriously cause a "memory access exception" error (in _class_lookupMethodAndLoadCache) during wrapper's [NXApp loadNibSection: owner:] call. (This is preceeded by error messages: "unrecognized -initialize message sent to instance of Window class", also to View, ScrollView, ClipView, DiagramView, LabelRep class in that order.) This is most puzzling because my subclasses of MiscInspector currently has NOTHING in it: no new instance variable, no revert:, no ok:, no methods, just empty skeleton of a subclass to MiscInspector. When I set in IB these subclasses back as MiscInspector, everything works. Any suggestion would be appreciated. Andy Lee andylee@ucla.edu andylee@netcom.com
From: Rich Gillam <richard_gillam@taligent.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Thu, 23 Jan 1997 16:27:42 -0800 Organization: Taligent, Inc. Message-ID: <32E801FB.4475@taligent.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> <32E64EF7.3D6A@nowhere.com> <5c7es1$7bc2@ddfservb.technet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >This is only possible (nicely) with templates. Objective-C doesn't >have templates, so it's not possible in Objective-C. The other >replies to your question show code to sort a set of objects of any >type. You can't add non-object types into these containers. Good point. Personally, I find the distinction between "objects" and "primitive types" one of the big flaws of C++, and I'm sorry that's it's also in Objective-C and Java. Another point is that while the examples will work with collections of any type, they won't (necessarily) work with collections where the elements are of DIFFERENT types. Unless the element types define comparison operations which compare them to not only other instances of the same type, but to instances of any other types that are represented in the collection (amd which are commutative), you'll either get bogus results or a runtime exception. There is no way (I think) to define a collection such that it is guaranteed to hold only instances of a certain type. You'll also get a runtime error if you stick objects into the collection that don't recognize the "compare" operation. Of course, in C++ you'll get a compile-time error for doing this, but it won't be particularly helpful a lot of the time. I may be wrong about all this because I've never coded in Objective-C. I'm just going on the comments others have made thus far in this thread. Feel free to set me straight. --Rich Gillam Text geek Taligent
From: brubeck@wport.com (Matt Brubeck) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: Thu, 23 Jan 1997 18:31:17 -0800 Organization: Zip News Message-ID: <brubeck-ya02408000R2301971831170001@snews.zippo.com> References: <maury-0801971641590001@199.166.204.230> <SHESS.97Jan23092733@slave.one.net> <5c8h0g$9sf@news.digifix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5c8h0g$9sf@news.digifix.com>, sanguish@digifix.com (Scott Anguish) wrote: >> A universally available format with the features of Stuffit (random >> access wise) and the free/clear compression algorithms of gzip >> would be a huge winner > > Of course they'd have to store the multi-forked Apple files in some >special manner in the archive, but that shouldn't be a big deal. There must >be a good multi-forked Apple file 'flatten' format available right? Other >than BinHex that is.. It's called MacBinary. ,--------------.-------------------. | Matt Brubeck I brubeck@wport.com | `--------------^-------------------'
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer Subject: mmap/munmap under mach Date: Fri, 24 Jan 1997 23:29:21 -0500 Organization: Demiurge Development Group Message-ID: <32E98C21.2568@friday.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: next-prog@omnigroup.com Does anyone have mmap() and munmap() equivalents for mach [under OS4.1]? I ask because I'm in the midst of porting msql-- if someone either has source to emulations of both functions, or has already done the port, please let me know. BTW: It appears that mmap exists within the OS-- even madvise is present. But compilation reveals that the munmap() function is undefined. As I do not have the implementation details of mmap(), I cannot undo whatever it does (maybe just a vm_dealloc() would work? Likely...?). thank you, b.bum
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 02:46:50 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E7176A.7732@exnext.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c6qhu$r1v@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > Mostly we're trying to assuage our anxiety about our prefered platform. > I wrote to this thread hoping to see where the compromise of Mac and > NeXT users would lead. I just don't see Apple shipping for $100 the > same OS which NeXT sold for $800. Perhaps the ecomomy of scale will pay > off this well. The academic price for OPENSTEP/Mach (including development tools) is around $295. The $800 price is probably so high so that NeXT could continue to exist despite few OS sales. There's no particular reason for the new OS to cost $800. Materials certainly don't cost $800. The development of the OS is essentially paid for. Apple is probably more concerned with survival than with recouping the $400 million, and they'll never recoup all the money they blew on Copland. The only real issues are license payments, profit margin, and market pressures. Apple knows they can't charge too much for the OS. I'd guess that, at most, it'll cost as much as NT Workstation. Probably less, since Apple desperately needs widespread adoption of the new OS. I wouldn't be surprised to see a special introductory price. Then again, I could be completely wrong. -- Jonathan W. Hendry jon @ exnext . com
From: colnet@loria.fr (Dominique Colnet) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.lang.eiffel Subject: Re: NextStep & Mac Frameworks Date: 24 Jan 1997 09:22:48 GMT Organization: CRIN & INRIA-Lorraine - Nancy - FRANCE Message-ID: <5c9v18$95r@muller.loria.fr> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> <milkweed-2201972301440001@port10.chester.smallmedia.com> <32E85082.37DE@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In article <32E85082.37DE@acm.org>, Ian Joyner <i.joyner@acm.org> writes: |> > In the meantime, I meant it when I said I would consider switching to |> > Eiffel for my next project. But when will an _industrial_ version be |> > available for the Mac? |> |> I think there is only SmallEiffel, which is a university freebee, Before buying an industrial version for the Macintosh do not forget to try SmallEiffel first. I think that our results are quite impressive. Precompiled version for 68000 and PPC are available. |> and SIG computers version. Apple is probably doing a good job of |> scaring off prospective compiler developers right now. Let's hope |> they get sorted out (I would love to do MacApp again). In fact it |> was after a MacApp project that I saw Eiffel and thought it a |> worthy successor to Object Pascal. It's a shame Apple didn't pick |> up on the idea. SIG is probably more industrial strength. |> |> Perhaps someone should encourage Metrowerks to get together with |> an Eiffel compiler vendor or someone willing to write an Eiffel |> compiler for CW. It sounds like they would be a really good match. |> Having already written an Eiffel compiler in Pascal, I'm willing |> to volunteer. Yes, but it is now time to use Eiffel to write Eiffel compilers :-) -- ------------------------------------------------------------ Dominique COLNET -- Talk Eiffel with SmallEiffel Talk Eiffel C.R.I.N. (Centre de Recherche en Informatique de Nancy) POST: CRIN,BP 239,54506 Vandoeuvre les Nancy Cedex,FRANCE EMAIL: colnet@loria.fr VOICE:+33 0383593079 FAX:+33 0383413079
From: dlehn@crib.bevc.blacksburg.va.us (David I. Lehn) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 24 Jan 1997 04:09:42 GMT Organization: Virginia Tech Message-ID: <5c9cm6$otb$1@solaris.cc.vt.edu> References: <5bq73r$e18$1@solaris.cc.vt.edu> <antispam-2001971935190001@farrca.apple.com> Cary Farrier (farrier@apple.com) (antispam@apple.com) wrote: > In article <5bq73r$e18$1@solaris.cc.vt.edu>, dlehn@vt.edu wrote: > > > Is Apple going to push Sprockets for Rhapsody? > > Yep. We're looking into the technical aspects right now. > Perhaps a better question: Will a game framework become part of the OpenStep spec? After GNUstep matures games would be very portable! Having a well thought out standard API for sound, input, speech, 3D, quicktime, buffering, etc would be great. -NSDave --- David I. Lehn <dlehn@vt.edu> | http://www.vt.edu:10021/D/dlehn/ Computer Engineering Student @ Virginia Tech in sunny Blacksburg, VA
From: Tim Weilkiens <twe@informatik.uni-kiel.de> Newsgroups: comp.sys.next.programmer Subject: Re: mmap/munmap under mach Date: Fri, 24 Jan 1997 11:34:30 +0100 Organization: Institute of Computer Science, University of Kiel, Germany Message-ID: <32E89036.75E2@informatik.uni-kiel.de> References: <32E98C21.2568@friday.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------33FC6A391CE2" To: bbum@friday.com This is a multi-part message in MIME format. --------------33FC6A391CE2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bill Bumgarner wrote: > > Does anyone have mmap() and munmap() equivalents for mach [under OS4.1]? > > I ask because I'm in the midst of porting msql-- if someone either has > source to emulations of both functions, or has already done the port, > please let me know. > > BTW: It appears that mmap exists within the OS-- even madvise is > present. But compilation reveals that the munmap() function is > undefined. As I do not have the implementation details of mmap(), I > cannot undo whatever it does (maybe just a vm_dealloc() would work? > Likely...?). > I attached a patch which was posted on the msql Mailinglist. For me its works fine. Tim -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ( o ) "Paddington on the Rocks" ()~*~() (_)-(_) Tim Weilkiens, Kiel, Germany /\ / \/\ Tim.Weilkiens@kiel.netsurf.de /\ / \ tim-w@pz-oekosys.uni-kiel.d400.de --------------33FC6A391CE2 Content-Type: text/plain; charset=us-ascii; name="mmap.next.path" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="mmap.next.path" From owner-msql-list@bunyip.com Fri Jan 10 04:21:27 1997 Received: from services.Bunyip.Com by skadi.informatik.uni-kiel.de with SMTP id AA10949 (5.65a/IDA-1.4.2 for twe); Fri, 10 Jan 97 04:21:14 GMT Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA22625 for msql-list-out; Thu, 9 Jan 1997 11:32:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA22620 for <msql-list@services.bunyip.com>; Thu, 9 Jan 1997 11:32:03 -0500 Received: from lca.u-nancy.fr by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03177 (mail destined for msql-list@services.bunyip.com); Thu, 9 Jan 97 11:31:49 -0500 Received: from labserver by lca.lca.u-nancy.fr (NX5.67e/NX3.0M) id AA01340; Thu, 9 Jan 97 17:34:24 +0100 Message-Id: <9701091634.AA01340@lca.lca.u-nancy.fr> Received: by labserver.lca.u-nancy.fr (NX5.67f2/NX3.0X) id AA09936; Thu, 9 Jan 97 17:33:29 +0100 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) In-Reply-To: <32D4D194.4945@ahand.unicamp.br> X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0) Received: by NeXT.Mailer (1.118.2) From: Etienne Klein <etienne@lca.u-nancy.fr> Date: Thu, 9 Jan 97 17:33:27 +0100 To: msql-list@bunyip.com Subject: [mSQL] Solve: mmap patch for NeXTSTEP References: <32D4D194.4945@ahand.unicamp.br> Sender: owner-msql-list@bunyip.com Precedence: bulk Reply-To: msql-list@bunyip.com Errors-To: owner-msql-list@bunyip.com Status: RO Hi, I just want to share this little patch wich solve the mmap problem for NeXTSTEP. It apparently works (meaning all msql tests are OK) for: NSFIP 3.3 p1 NS Motorola 3.3 p1. It does NOT work for HP 3.2 All other configurations are untested ! Thanks to the authors Fabien Roy and Robert Ehrlich for this patch ! Etienne Klein Laboratoire de Chimie Analytique Faculte de Pharmacie de Nancy France /* * @(#)map.c 1.0 of 20 December 1996 * * Copyright (c) 1996 by Fabien Roy. * Written by Fabien Roy and Robert Ehrlich. * Fabien_Roy@free.fdn.fr Robert.Ehrlich@inria.fr * Not derived from licensed software. * * Permission is granted to anyone to use this software for any * purpose on any computer system, and to redistribute it freely, * subject to the following restrictions: * * 1. The author is not responsible for the consequences of use of * this software, no matter how awful, even if they arise * from defects in it. * * 2. The origin of this software must not be misrepresented, either * by explicit claim or by omission. * * 3. Altered versions must be plainly marked as such, and must not * be misrepresented as being the original software. * */ #include <sys/types.h> #include <sys/mman.h> #include <stdlib.h> #include <syscall.h> caddr_t mmap(caddr_t addr, size_t len, int prot, int flags, int fd, off_t off) { int pagelessone = getpagesize() -1; int size; caddr_t pageaddress; /* round to next page size */ size = (len + pagelessone) & ~pagelessone; /* allocate aligned pages */ if (!(pageaddress = (caddr_t) valloc(size))) return (caddr_t) -1; /* map it */ if (syscall(SYS_mmap, pageaddress, size, prot, flags, fd, off)){ free(pageaddress); return (caddr_t) -1; } return pageaddress; } void munmap(caddr_t addr, size_t len) { syscall(SYS_munmap,addr,len); free(addr); } -------------------------------------------------------------------------- To remove yourself from the Mini SQL mailing list send a message containing "unsubscribe" to msql-list-request@bunyip.com. Send a message containing "info msql-list" to majordomo@bunyip.com for info on monthly archives of the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list! --------------33FC6A391CE2--
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.lang.eiffel Subject: Re: NextStep & Mac Frameworks Date: Fri, 24 Jan 1997 17:02:42 +1100 Organization: Unisys Message-ID: <32E85082.37DE@acm.org> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> <milkweed-2201972301440001@port10.chester.smallmedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anders, Anders Pytte wrote: > > Ian, > > I was hoping someone would do the job of slaying me, and rather painlessly > at that. I repent: there was no error of assumption on your part; by the > same reasoning, nor was your critique alarmest. > > However, the main part of my conclusion, I believe, stands: it is still > possible to create excellent products at competitive cost using C++, > because the cost of this language's flaws, when prudently managed, is > small compared to its benefits (excellent support, wide availability of > tools and environments and skilled programmers, etc.). This is what i > meant when i agreed with Stroustrup. OK, you can use a careful subset of C++ to make your program more disciplined, and as long as your developers play ball, more cost efficient. However, I think such programming wisdom should be designed into a language to start with, so that you don't have arguments over style, or have to break in new programmers who have come from different environments. I think Eiffel is a language that is well designed from that perspective. However, you still have to use some of the uglier features of C++ such as its implementation of multiple inheritance, associated scope resolution and templates. These are good things to add to the language, but I would rather daily deal with cleaner implementations of them. And I would rather the compiler did more of the tedious manual work for me, which would result in being able to change things easier, and thus a much better maintenance cycle. > In the meantime, I meant it when I said I would consider switching to > Eiffel for my next project. But when will an _industrial_ version be > available for the Mac? I think there is only SmallEiffel, which is a university freebee, and SIG computers version. Apple is probably doing a good job of scaring off prospective compiler developers right now. Let's hope they get sorted out (I would love to do MacApp again). In fact it was after a MacApp project that I saw Eiffel and thought it a worthy successor to Object Pascal. It's a shame Apple didn't pick up on the idea. SIG is probably more industrial strength. Perhaps someone should encourage Metrowerks to get together with an Eiffel compiler vendor or someone willing to write an Eiffel compiler for CW. It sounds like they would be a really good match. Having already written an Eiffel compiler in Pascal, I'm willing to volunteer. ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------
From: moellney@simtec.imr.mb.uni-siegen.de (Michael Möllney) Newsgroups: comp.sys.next.programmer Subject: EOModeler OS4.1/NT Date: 24 Jan 1997 12:07:15 GMT Organization: Uni Siegen Message-ID: <5ca8lj$4cn@si-nic.hrz.uni-siegen.de> Hi I just wanted to start to learn sth about EOModeler and the EOF Concept. First step: get a database with ODBC option a) got DB2/NT Server 2.1.2 (IBM try & buy 60 days) which hse an ODBC adaptor option b) got postgres95/OS4.0/MACH with postodbc (po020-32.tgz) for the nt-side both installed well. Both databases work fine with MS-Access connected over ODBC. Whenever I start EOModeler saying NEW and choose ODBC, set the ODBC-name there's a lot working on the machine and then a protected memory -error comes up and say i have to quit EOModeler. Oh yes, I downloaded and installed the ODBC-NT Patch from next-answers has anybody had such experiences, how did you work around them, what is it what I#m doing wrong? bye, Michael -- Michael Möllney Paul-Bonatz-Strae 9-11, Raum 426/2 57068 Siegen Tel: +49-271-740-4724 moellney@simtec.imr.mb.uni-siegen.de
From: jq@papoose.quick.com (James E. Quick) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 1997 06:59:48 -0500 Organization: PHCS Message-ID: <5ca87k$cu3@papoose.quick.com> References: <maury-0801971641590001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu> <maury-210 <32E5F50A.2637@spvi.com> In article <32E5F50A.2637@spvi.com>, Steve Spicklemire <steve@spvi.com> wrote: >OK.. so what happens when I get my shiny new GUI app that expects >'system("tar cf - *.gif | mail .... )' to work and the user neglected to >install 'tar'? Are all these unix utilities so enourmous that we really >want to risk breaking so much code? I would think the whole spiel >compares in size (more or less) to a complete installation of any modern >office productivity suite. :-) An office utility suite weighs in at several hundred MB. Standard Unix executables are a small fraction of this. The combined disk space for the standard Unix executables is between 15 and 20 MB. Chump change. Considering that SCSI devices less than 1GB aren't even being made anymore and 2GB is now the entry level standard, this space is not an issue. -- ___ ___ | James E. Quick jq@quick.com / / / | Private HealthCare Systems NeXTMail O.K. \_/ (_\/ | Systems Integration Group (617) 895-3343 ) | "I don't think so," said Rene Descartes. Just then, he vanished.
From: amando@gcomm.com Newsgroups: comp.sys.next.programmer Subject: Hashtable usage Date: Fri, 24 Jan 1997 09:53:11 +0200 Organization: CompuServe Incorporated Message-ID: <32E86A67.652C@gcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am very new in the Next world and I have a question that I think can be easily answered by you, the next guru's. I need a function to make different serial numbers from an order number. For example, make a different serial number for each sale I made. I have read that a hash table is the method for doing this, but I am not very sure. For example, if the order number is 1, can I have a serial number of 8 digits that will not be used in the following orders numbers?, or I am wrong. Please, tell me information and excuses for the English. Thanks in Advance! Amando Blasco
From: amando@gcomm.com Newsgroups: comp.sys.next.programmer Subject: Hashtable usage Date: Fri, 24 Jan 1997 09:58:06 +0200 Organization: CompuServe Incorporated Message-ID: <32E86B8E.73A4@gcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am very new in the Next world and I have a question that I think can be easily answered by you, the next guru's. I need a function to make different serial numbers from an order number. For example, make a different serial number for each sale I made. I have read that a hash table is the method for doing this, but I am not very sure. For example, if the order number is 1, can I have a serial number of 8 digits that will not be used in the following orders numbers?, or I am wrong. Please, tell me information and excuses for the English. Thanks in Advance! Amando Blasco
From: "David Every" <dke@adnc.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 97 08:09:41 +0000 Organization: adnc.com Message-ID: <AF0E1ECF-469D3@207.158.13.24> References: <32E3D1EA.7F8F@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable nntp://news.adnc.com/comp.sys.next.advocacy, nntp://news.adnc.com/comp.sys.mac.advocacy, nntp://news.adnc.com/comp.sys.mac.system Jonathan W. Hendry <jon@exnext.com> > Oh, that's right. Apple's marketshare is dwindling. Apple's > traditional markets are moving to Windows. Schools, homes, graphics > professionals. You are incorrect... Macs marketshare was flat last quarter. Since marketshare is a measurement of sales at a given time - and the computer market is growing - then Macs units are growing as well - just at the same rate as the rest of the industry (no faster or slower). I beleive sales of Macs (and compatibles) was at 5.1 million last year (96) as opposed to 4.5 million for '95. That is not exactly losing ground. Apple has given a little ground to its compatibles - but Macs are selling more units than ever. > Evidently, Apple must not be selling what people want > anymore. Apple isn't even holding on to their *current* customers. Funny.... 5.1 million machines last year.... that seems like pretty good sales volume to me. > Let's see. Apple has about 6% marketshare. If Apple can successfully > sell to the 1% of users who want Unix, that would give Apple 7% > marketshare. A 16% increase in Mac marketshare. Furthermore, it's > an increase, which Apple hasn't seen in many moons. Sure... Apple should focus on 1% of the marketplace instead of say 50%?!? Apple needs to make a good OS. The best that they can - then let the marketplace sort itself out. -- David K. Every MacKiDo Warrior - The Power of the Macintosh Way! -- =A91997 DKE. Non-exclusive, royalty free license to distribute is granted to any service provider except Microsoft. By distributing this, Microsoft agrees to pay $1,000 per posting.
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: Remote cvs and .nib wrappers Date: 24 Jan 97 12:16:09 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Jan24121609@howard.one.net> References: <SHESS.97Jan21112355@slave.one.net> <5c3g9c$m2n@nntp1.best.com> In-reply-to: deniseh@nntp.best.com's message of 21 Jan 1997 22:34:20 GMT In article <5c3g9c$m2n@nntp1.best.com>, deniseh@nntp.best.com (Denise Howard) writes: Scott Hess (shess@one.net) wrote: : I've been exploring the remote features of cvs. Unfortunately, : it seems that remote cvs doesn't work in combination with : wrappers, so cvs can't handle .nib files in the repository. Has : anyone gotten that working? Art Isbell (aisbell@cubicsol.com) wrote a couple of items that will help you. I don't have them myself anymore since I no longer use CVS at work, but what they'll do is tar and compress the nib, so that you can then check the result into CVS like any other file. There was a tweak he made to the Makefile.preamble and Makefile.postamble, too, I think. I snarfed CVS.NIHS.bs.tar.gz from ftp.peak.org. This is a package with an InterfaceBuilder palette which intercepts .nib saves. It then copies the CVS directory from the .nib~ file back to the .nib file itself. Unfortunately, it's for NeXTSTEP. Fortunately, with very little effort, I ported it to OpenStep/Mach. Most of the code's gone, but most of the ideas are the same. That wasn't much help, though, because I could already use wrappers fine on OpenStep/Mach. With substantially more effort, I managed to port it to OpenStep/NT. So now I can potentially do without wrappers for .nib files (.rtfd I didn't care one way or the other) on NeXTSTEP, OpenStep/Mach, and OpenStep/NT. Now all I need is CVS for NT (speak up, someone, before I port it myself!). See my homepage for OSCVS.tar.gz, which is the source to the palette for OpenStep. Sorry, no binaries, worse yet, NO SUPPORT. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Rainer Frohnhfer Newsgroups: comp.sys.next.programmer Subject: Once again --- pthreads for NeXTSTEP? Date: 24 Jan 1997 14:43:07 GMT Organization: University of Wuerzburg, Germany Message-ID: <5cahpr$tk2@winx03.informatik.uni-wuerzburg.de> Hi, this has been asked several times before: Where can I get a pthreads package for NeXTSTEP? ftp.hasc.ca doesn't exist anymore (apparently), and I couldn't find this anywhere else. And, yes, I know about cthreads. Any pointers welcome, Rainer -- ------------------------------------- "Um Energie zu sparen, wird das Licht am Ende des Tunnels vorlaeufig abgeschaltet." rainer@mathematik.uni-wuerzburg.de (finger cip@mathematik for public key ...)
From: stefan.boehringer@rz.ruhr-uni-bochum.de (Stefan Boehringer) Newsgroups: comp.sys.next.programmer Subject: Re: mktime() Date: 24 Jan 1997 20:47:32 GMT Organization: Ruhr-Universitaet Bochum, Rechenzentrum Message-ID: <5cb754$ruo$1@sun579.rz.ruhr-uni-bochum.de> References: <32E65D33.446B@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Pascal Chesnais <pascal@mit.edu> wrote: > We are having problems here with mktime under nextstep 3.3 > has anyone else run into this? Putting today's time gets > us a wrong return value (on the order of 3 year!!!) I had similar problems. Just look into the misckit. One of the more recent releases contains mktime replacements in the MiscTime class. Just copy them over. - Stefan Bhringer
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.oop.macapp3 Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 24 Jan 97 15:37:35 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan24153735@howard.one.net> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan8.171354.1@eisner> <5b1bka$sdo@bias.ipc.uni-tuebingen.de> <5b1inf$996@bignews.shef.ac.uk> <5b1ovj$tm6@nntp1.apple.com> <5b23sa$48e@news.xmission.com> <milkweed-0901970908220001@port5.chester.smallmedia.com> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <SHESS.97Jan16104807@howard.one.net> In-reply-to: shess@one.net's message of 16 Jan 97 10:48:07 In article <SHESS.97Jan16104807@howard.one.net>, shess@one.net (Scott Hess) writes: In article <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu>, Charles W Swiger <cs4w+@andrew.cmu.edu> writes: As for the size and performance of Obj-C based applications, I would suggest trying it before worrying about problems that most people don't encounter. C++ advocates always seem to imply there is a big tradeoff here, but I cannot recall ever seeing a NEXTSTEP developer (someone who has actually released commercial software) state that the size and performance of Obj-C was a significant problem. Fact of the matter is, most NeXTSTEP apps which are slow are slow because the developer didn't spend enough time looking at what the app is doing. If your app is drawing the same scene multiple times without changing it, then even if your language gives you 100% of the hardware's capability, it could be slower than an interpretted language which only draws the scene _once_. I've recently been reading some literature that indicates that even C++'s dispatch advantage is somewhat under pressure. It appears that VTBLs, which fairly efficient under 80's era processors, are less so under 90's processors. The instructions are such that they can't be easily pipelined because they each depend on the previous instruction to a great degree. Dynamic dispatch mechanisms have more instructions, yes, but the overall execution time is no longer related entirely to instruction count, and dynamic dispatch is getting _relatively_ better. OTOH, it's pretty easy to understand that code bloat from templates and such will not improve performance, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 1997 17:24:07 GMT Organization: Airwindows Message-ID: <jinx6568-2401971226320001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> In article <5c9g5b$nrl@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > In article <jinx6568-2201971205130001@news.sover.net>, jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) wrote: > > I said once and I'll say again, I could deal with having to put > > everything in the applications folder if I decided to treat it like it was > > a hard disk. It's very simple. Instead of having the hard disk icon on my > > screen, I'd have the application folder icon on my screen. Open it and it > > would look like a hard disk, with apps, documents, organized as I wanted > > them to be. > Of course, NEXTSTEP users would freak out if they saw you putting > documents in the applications folder. :) (Not that you couldn't do > that if you wanted, of course.. it's just really weird..) Not really :) Suppose I have a bunch of animated gifs, that are only used to put on web pages and can only be worked on by a few programs. I can drag and drop them on whichever one I please- why should they not be in a folder which contains each app? However, mostly I'll have folders like 'writing' or a 'notes' folder in a context such as 'HTML' or 'Marathon'- having the Notes in a centralized loaction would require extra information in each title, and I would have to navigate to it rather than have the informationn right there when I'm working in that context :) Jinx_tigr (aka Chris Johnson)
From: no_spam@Glue.umd.edu (David T. Wang) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 24 Jan 1997 18:43:33 GMT Organization: University of Maryland, College Park, MD Message-ID: <5cavsl$8lg@dailyplanet.wam.umd.edu> David Every (dke@adnc.com) wrote: : Since marketshare is a measurement of sales at a given time - and the : computer market is growing - then Macs units are growing as well - : just at the same rate as the rest of the industry (no faster or : slower). I beleive sales of Macs (and compatibles) was at 5.1 million : last year (96) as opposed to 4.5 million for '95. That is not exactly : losing ground. Apple has given a little ground to its compatibles - : but Macs are selling more units than ever. : Funny.... 5.1 million machines last year.... that seems like pretty : good sales volume to me. Apple itself shipped About 4 Million Units in Fiscal 1996. Could you tell me where you saw the 5.1 Million units number?
From: andylee@ucla.edu (Andy Lee) Newsgroups: comp.sys.next.programmer Subject: Re: Problem using MiscInspectorKit (MiscKit 1.9.0) Date: Fri, 24 Jan 1997 22:06:25 GMT Organization: University of California, Los Angeles Message-ID: <32e93164.219667948@news.ucla.edu> References: <32e83488.154926334@news.ucla.edu> I solved the problem by naming the subclass of MiscInspector as MiscInspector<Something>. Hm... that's just strange. :-) Andy Lee On Fri, 24 Jan 1997 04:23:22 GMT, andylee@ucla.edu (Andy Lee) wrote: >Hello, > >I am puzzled by a problem encountered with MiscInspectorKit and would >appreciate any help or suggestion, i.e. what else could I use to >implement inspectors? (NeXTstep FIP 3.3 User / 3.2 Dev) > > Following the SwapKit Tutorial in MiscKit, I created in my main >project a master inspector manager with several inspector wrappers to >load their respective .nib files. Inside each .nib file, the file >owner is a wrapper, and there are several MiscInspectors to swap their >views into the Inspector Panel. > >The prototype works great. Each wrapper loads and registers their >MiscInspectors and swap their views into the Inspector Window. But >when I subclass the MiscInspector to implement revert: in each, the >program mysteriously cause a "memory access exception" error (in >_class_lookupMethodAndLoadCache) during wrapper's [NXApp >loadNibSection: owner:] call. (This is preceeded by error messages: >"unrecognized -initialize message sent to instance of Window class", >also to View, ScrollView, ClipView, DiagramView, LabelRep class in >that order.) > >This is most puzzling because my subclasses of MiscInspector currently >has NOTHING in it: no new instance variable, no revert:, no ok:, no >methods, just empty skeleton of a subclass to MiscInspector. When I >set in IB these subclasses back as MiscInspector, everything works. > >Any suggestion would be appreciated. > >Andy Lee >andylee@ucla.edu >andylee@netcom.com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 24 Jan 1997 15:03:06 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <omuFJuW00iV243UoxE@andrew.cmu.edu> References: <32E3D1EA.7F8F@exnext.com> <AF0E1ECF-469D3@207.158.13.24> In-Reply-To: <AF0E1ECF-469D3@207.158.13.24> Followups redirected out of c.s.n.programmer and c.s.m.system. Let's try to move non-relevent threads out of those two newsgroups.... Excerpts from netnews.comp.sys.next.advocacy: 24-Jan-97 Re: MacWorld Exclusive: App.. by "David Every"@adnc.com >> Let's see. Apple has about 6% marketshare. If Apple can successfully >> sell to the 1% of users who want Unix, that would give Apple 7% >> marketshare. A 16% increase in Mac marketshare. Furthermore, it's >> an increase, which Apple hasn't seen in many moons. > > Sure... Apple should focus on 1% of the marketplace instead of say > 50%?!? Possibly-- the current size of a marketplace is only one factor. The needs and pocketbooks of a smaller market can sometimes make it a more attactive choice. For example, the license fees for some of the higher-end Unix software packages (for things like an WebObjects/EOF/DO server on the Internet, or an Oracle DB server, or specialized software for things like hospitals & medical usage) are often in the range of $25,000, and consulting rates for those specialized markets are generally lucrative, too. I am not saying that Apple should be strictly motivated by money, but the possible financial value of a market is far more important than raw marketshare in terms of numbers of users. Marketshare _times_ the per-seat profit (or net worth, or invested capital, or whatever similar measure you want to use) is a better estimate of the importance of a market. For all that Apple sells far more Macs per year than Sun sells SPARCstations, Sun is a bigger company because the Unix server market is worth a lot more per seat. Both Sun and NeXT made more money from doing consulting, training, and software sales then they ever have from selling hardware. Ellen Hancock's comments suggest that Apple is becoming more aware of this, and my opinion is that it's a more sensible way of deciding what your company should do than a blind drive towards getting more marketshare than Microsoft does. > Apple needs to make a good OS. The best that they can - then let the > marketplace sort itself out. I completely agree with you. But I think it would serve Apple well to capture a strong position selling their new OS to the customers that NeXT has sold to-- things like large banks and financial houses, Wall Street, Internet service providers, and other vertical-market customers. This in combination with a large percentage of the current Mac userbase would be a much healthier market.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Followup-To: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Date: 24 Jan 1997 22:37:08 GMT Organization: ace dot net internet technologies Message-ID: <5cbdik$r4d@darla.visi.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E801FB.4475@taligent.com> <5c9gjf$qtb@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : > you'll either get bogus results or a runtime exception. : > There is no way (I think) to define a : > collection such that it is guaranteed to hold only instances of a : > certain type. : : There's nothing preventing you from writing or subclassing a collection : class that will refuse to hold more than one type of object. Yeah. It would've been a little inflexible of NeXT to limit NSArray to one type. Having a different class for every type would lead to class overload, like a certain framework from... um, nevermind. Alternately, you could extend NSArray with a category to sort using a "smart" sorter (preferably in some other class) which could determine the classes of the objects to be compared at runtime and dynamically load the required comparison class.. :) [trim] -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: Tim Desjardins <timd@solect.com> Newsgroups: comp.sys.next.programmer Subject: XDR on NeXTStep Developer 3.2? Date: Fri, 24 Jan 1997 18:23:25 -0500 Organization: Solect Technology Group Message-ID: <32E9446C.3C8B@solect.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Where can I find the library for the xdr routines on Developer 3.2? Thanks,
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 24 Jan 1997 15:34:06 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E91CBE.56EF@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> <jinx6568-2401971226320001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chris Johnson wrote: > Not really :) > Suppose I have a bunch of animated gifs, that are only used to put on > web pages and can only be worked on by a few programs. I can drag and drop > them on whichever one I please- why should they not be in a folder which > contains each app? However, mostly I'll have folders like 'writing' or a > 'notes' folder in a context such as 'HTML' or 'Marathon'- having the Notes > in a centralized loaction would require extra information in each title, > and I would have to navigate to it rather than have the informationn right > there when I'm working in that context :) I guess that NeXT users would find this weird since we're used to having applications that we don't 'own', and since it's a multiuser network OS. For instance, Edit.app is found in /NextApps. It's local to each machine. If you saved your documents with it, you'd lose access to them if you move to another machine. For some apps, this wouldn't be a problem, of course, if they're on a Net-mounted directory. Sysadmins often prefer to leave the Apps directories (other than the one in your home directory) read-only, so that users aren't installing weird or pirated software. When you get into a 1,000 users on a global WAN, storing documents with the applications definitely becomes problematic. ;) I generally put my documents in ~/Library, with appropriate subfolders. You might have ~/Library/notes, ~/Library/HTML, ~/Library/Marathon, etc. I put my programming stuff in ~/Develop. OTOH, my home directory often contains a bunch of cruft I've forgotten to throw out. ;) It works out rather well. I tend to organize other OS's the same way. Cruft included. ;) NeXTSTEP's Open and Save panels default to your home directory, IIRC. So storing Edit documents in /NextApps would be more work than putting them in ~/Library, since you'd have to do more browsing to get there. -- Jonathan W. Hendry jon @ exnext . com
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: Fri, 24 Jan 1997 15:54:15 -0800 Organization: Esperance Communications Message-ID: <jk-2401971554150001@ip-salem2-22.teleport.com> References: <maury-0801971641590001@199.166.204.230> <SHESS.97Jan23092733@slave.one.net> <5c8h0g$9sf@news.digifix.com> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1"; URL=<http://www.esperance.com/pgp-key.asc> In article <5c8h0g$9sf@news.digifix.com>, sanguish@digifix.com (Scott Anguish) wrote: > Of course they'd have to store the multi-forked Apple files in some >special manner in the archive, but that shouldn't be a big deal. ZipIt already does this, it can MacBinarize a file before adding it to the archive although according to its documentation, there are some problems with this. -- Joel Klecker <URL:mailto:jk@esperance.com> <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. "I was gratified to be able to answer promptly. I said I don't know." -- Mark Twain
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 24 Jan 1997 16:23:01 -0600 Organization: mementech, inc. Message-ID: <32E93645.21D43FE@screaming.org> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> <jinx6568-2401971226320001@news.sover.net> <32E91CBE.56EF@exnext.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > Chris Johnson wrote: > > > > Suppose I have a bunch of animated gifs, that are only used to put on > > web pages and can only be worked on by a few programs. I can drag and drop > > them on whichever one I please- why should they not be in a folder which > > contains each app? However, mostly I'll have folders like 'writing' or a > > 'notes' folder in a context such as 'HTML' or 'Marathon'- having the Notes > > in a centralized loaction would require extra information in each title, > > and I would have to navigate to it rather than have the informationn right > > there when I'm working in that context :) > > I guess that NeXT users would find this weird since we're used to > having applications that we don't 'own', and since it's a multiuser > network OS. > > For instance, Edit.app is found in /NextApps. It's local to each > machine. If you saved your documents with it, you'd lose access > to them if you move to another machine. A traditional multi-machine environment would have the user's home directory on an NFS server, with the user authentication done by a NetInfo or NIS server. The mountpoint for the home directories would be the same on all the machines so that any person could walk up to any NeXTstep machine and still get their own environment and data. A setup where a user could not access their data when they logged onto another machine is poorly administered. ----- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
Newsgroups: comp.sys.next.programmer From: thomas@gamelan.shnet.org._NO_SPAM (Thomas Funke) Subject: Re: mmap/munmap under mach Message-ID: <1997Jan24.113948.592@gamelan.shnet.org> Sender: thomas@gamelan.shnet.org (thomas) Cc: bbum@friday.com Organization: Disorganization References: <32E98C21.2568@friday.com> Date: Fri, 24 Jan 1997 11:39:48 GMT In <32E98C21.2568@friday.com> Bill Bumgarner wrote: > Does anyone have mmap() and munmap() equivalents for mach [under OS4.1]? > > I ask because I'm in the midst of porting msql-- if someone either has > source to emulations of both functions, or has already done the port, > please let me know. > > BTW: It appears that mmap exists within the OS-- even madvise is > present. But compilation reveals that the munmap() function is > undefined. As I do not have the implementation details of mmap(), I > cannot undo whatever it does (maybe just a vm_dealloc() would work? > Likely...?). > > This was posted a while ago in the net: From: tagoldth@camtwh.eric.on.ca Newsgroups: comp.sys.next.software Subject: NeXT mmap() summary Date: 3 Mar 1995 19:52:07 GMT Organization: The Eye Research Institute of Canada Lines: 61 Distribution: world Message-ID: <3j7s17$a9q@sator.eric.on.ca> NNTP-Posting-Host: camtwh.eric.on.ca Summary: it does work, but not as a normal mmap Keywords: tied to NeXT Mach vm_ functions Hi All, After receiving *many* requests asking if I got the answer of how NeXT implemented mmap(), I am posting a simple summary (please don't ask for more details, I need my sleep :-) ). mmap() on the NeXT Mach OS works, but the semantics of allocation are changed, here are the details: - Under normal OS (whatever that is :-) ) - mmap first argument can specify - pointer value 0 (which means os finds suitable location for the map) - pointer value as suggestion on where to do the map - mmap will do the actual page allocations for you. - Under NeXT OS - first argument is pointer to region user has allocated using vm_allocate(). Here's a simple example: #include or import whats appropriate, such as mman.h etc ... vm_allocate((vm_task_t)task_self(), (vm_address_t*)&addr, 8192,TRUE); mmap((caddr_t)addr,(size_t)256,PROT_READ|PROT_WRITE, MAP_SHARED,fd,(off_t)0); .... - In the above, addr is a character pointer and fd the open file descriptor of what I want to mmap(). - I have tested it for sharing pages among processes (as I use it on other os'es) and it appears to work properly, see Big_Disclaimer below. - You can create wrapper functions, #ifdefs, etc, to merge the NeXT OS style mmap() code with code for other machines. - I didn't see a munmap() in the symbols of the libraries, so I just used vm_deallocate(). I assume here that the mmap goes away automagically when I deallocate the region. See Big_Disclaimer below.... Disclaimer: The above is written late at night, just to test it, and is not written to handle every case. Please look at the NeXT vm_* routine descriptions in the Librarian, and in the man pages on a SunOS machine (or other suitable machine with mmap implemented) for a description of how mmap() normally should work). Big_Disclaimer: NeXT supplies no man page for mmap(), so even though it works above, this could suggest that it is unsupported, and the semantics of what it does may be a variation, or have exceptions, to what I am describing. USE AT YOUR OWN RISK. At some point I may exhaustively test it to be sure it all works right, if I find something odd, I'll post it. If we are lucky, 3.3 Dev may have it in the docs... My thanks to an anonymous person who suggested that the user must allocate the region of memory to map into. IT WORKED! :-)
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 24 Jan 1997 16:55:34 GMT Organization: The University of Iowa Message-ID: <5capi6$mqk@flood.weeg.uiowa.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> From article <5c9h5n$rju@csugrad.cs.vt.edu>, by nurban@csugrad.cs.vt.edu (Nathan M. Urban): > In article <ga-2301971701310001@cust27.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) wrote: > >> In article <32E78DAF.433F@srsys.com>, Bill Vareka <billv@srsys.com> wrote: > >> There are no two sides to operator overloading. If you want to be able >> to write expressions that look anything like mathematics, using complex >> numbers, Galois fields, vectors, matrices, etc. you need operator >> overloading, > > Writing expressions that look like mathematics in arbitrary mathematical > structures is hardly a requirement for a general-purpose programming > language; the convenience of operator overloading is not necessarily > worth its drawbacks for most programmers. Indeed. I often prefer writing :-) (sqrt (plus (sqr (minus x y)) (sqr (minus x y)))) > >> which BTW means having function overloading because operators >> by definition are functions. > > No. Operator overloading is NOT a subset of function overloading. > Operators on objects are methods, which are not functions, at least in > Objective-C. (Note that "function overloading" refers to C functions, > not mathematical ones.) Overloading applies to anything you can name. In C++, you can overload functions, member functions (methods), and operators. You also have your choice of _implementing_ most operators as either a function or a method. The typical dichotomy is that a binary, non-assignment operator is implemented as a function, all others as methods. They are some very good reasons for doing it this way (see the FAQ). Because you can't define an operator in Objective-C, it need not be a function or a method. -mc
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 1997 17:11:04 GMT Organization: Airwindows Message-ID: <jinx6568-2401971213230001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <maury-0901971623200001@199.166.204.230> <5b3vkl$ebp@news.xmission.com> <maury-1001971418120001@199.166.204.230> <5bbe59$8fh@crl.crl.com> <jinx6568-1601971439000001@news.sover.net> <32DEDEC1.490C@exnext.com> <AF09658696681B35E3@travis.tfs.net> In article <AF09658696681B35E3@travis.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: > If you could make Unix functionality a part of the new OS without *forcing* > users to deal with these things, so they wouldn't need to see or use them > unless they really *wanted* to, then I wouldn't mind. But what I saw of > NeXTstep a few years ago didn't work that way, and the comments I've seen > here suggest that it hasn't changed in this respect. I certainly haven't gotten that impression, and I've been in the thick of these arguments since I started. Not only that, one of the few things we _do_ know is that Apple has every intention of insulating home users from the sparks and machinery, and has said so quite clearly. Apple already insulates users from TextEdit calls and drawing rects with Quickdraw for putting up windows. Apple insulates users from window management and handles determination of the foreground windows in an intuitive way. Why should they not be able to deal with this newer, easier task? Apple does _not_ insulate users from some memory management, as we know from the Get Info dialog box and manual setting of app memory spaces. Now this can change. ;) > Let me turn the question around: Should Joe Average User have to wade > through Unix arcanum just to use the computer, when he doesn't know or care > what 1/4 of the things mean, let alone how to use them -- just so that the > small percentage of Unix gurus can easily run install scripts? No. Instead Joe Average gets to totally ignore the Unix arcanum just as he gets to ignore FSpOpenResFile, InitApplZone, LAPRmvATQ, PBMakeFSSpec, XorRgn (do you know how hard it is to find toolbox routines with cryptic names? Wow. Mostly it's CloseWindow, DisposePalette, DrawString, GetFontInfo, GetSpecificHighLevelEvent, GetProcessSerialNumberFromPortName... really! These are from 'Routines that should not be called from within an interrupt', Inside Mac original edition) But just as Mac programmers get to use GoToPublisherSection and GetFontName and GetLastEditionContainerUsed and FSpRstFLock, Unix sysadmins get to use the Unix routines. Don't even _think_ of them as Stuffit Expander, think of them as Toolbox routines, okay? They are going to be there if Rhapsody is going to work. There isn't time to invent everything over again, basically. And is anyone demanding that FSpRstFLock be removed because it is cryptic? > ...Cats are the proof of a higher purpose to the universe. On the bright side, this is one of my favorite sigs I've ever seen :) Jinx_tigr (aka Chris Johnson)
Newsgroups: comp.sys.next.programmer From: Matthew Hocker <hocker@interactive.net> Subject: window class method question Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Organization: IBS Interactive, Inc. Message-ID: <E4IsBw.JsM@news.interactive.net> Mime-Version: 1.0 Date: Fri, 24 Jan 1997 15:57:32 GMT Quick, hopefully simple question. Under NS3.3, 3.2 dev, I am trying to keep a window initially hidden then open it programmatically. I have the window connected to an instance of my controller class so that it is recognized (supposedly) in the code as slipWindow (type id). I then try and open the window by using: [slipWindow display]; which causes a memory fault. I've tried slipWindow=[Window alloc]; then [slipWindow init]; then [slipWindow display]; but I still get the same error (in gdb). What am I doing wrong? Theoretically, the window should already be allocated, since I drew it in IB, but maybe I need to allocate it somehow? Any help is welcome! Thanks Matt -- __ Matthew Hocker, B.Eng (McGill) | Voice your concern about /\_\ "Believer in all things well-engineered" | Internet censorship! Write \/_/ hocker@onyx.interactive.net | to Senator-Gorton@ NeXTSTEP! NeXTmail and MIME welcomed here! | gorton.senate.gov !
From: kent@voicenet.com Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 97 20:02:07 -0500 Organization: Voicenet - Internet Access - (215)674-9290 Message-ID: <AF0EC5C3-4D5E0@207.103.11.102> References: <5cavsl$8lg@dailyplanet.wam.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit nntp://netnews.voicenet.com/comp.sys.next.advocacy, nntp://netnews.voicenet.com/comp.sys.mac.advocacy, nntp://netnews.voicenet.com/comp.sys.mac.system >: Since marketshare is a measurement of sales at a given time - and the >: computer market is growing - then Macs units are growing as well - >: just at the same rate as the rest of the industry (no faster or >: slower). I beleive sales of Macs (and compatibles) was at 5.1 million >: last year (96) as opposed to 4.5 million for '95. That is not exactly >: losing ground. Apple has given a little ground to its compatibles - >: but Macs are selling more units than ever. > >: Funny.... 5.1 million machines last year.... that seems like pretty >: good sales volume to me. > >Apple itself shipped About 4 Million Units in Fiscal 1996. Could you >tell me where you saw the 5.1 Million units number? > Duder look at what the guy above you wrote. He said 5.1 million Mac/clones in 1996. That is quite possible since you yerself just said Apple alone sold 4 million of em. Mellow out duder and READ THE POST !!!!!!!!! I think 1.1 million between Motorola, ah Power Computing, Umax, and them Genesis dudes, APS is quite possible. You mean between 5 clone makers they only sold 1.1 million ?? That actually sounds lame. I thought it would be more 8( Oh weeeeeeell theres always 1997 8)
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 24 Jan 1997 16:37:52 GMT Organization: The University of Iowa Message-ID: <5caoh0$dpu@flood.weeg.uiowa.edu> References: <5c93h6$3ur@darla.visi.com> From article <5c93h6$3ur@darla.visi.com>, by dwy@ace.net (David Young): > Matthew Clay (clay@herky.cs.uiowa.edu) wrote: > : That's correct. As Objective-C and Java mature and become mainstream, > : however they will face the same compelling arguments for new features as > : C++ did/does. The choices seem limited to following the same feature-rich > : path as C++ and being criticized as monstrosities, or striving for the > : minimality of C and being criticized as primitive. > > As far as function overloading goes, what's the point with a runtime > typing system? The same as in more static world -- freedom from all having to deal with all details at every step. For example, in the Prolog world, we might overload a predicate add/2 as add(int(N), int(M)) :- integer_add(N, M). % low-level integer add add(float(N), float(M)) :- float_add(N, M). % " floating add So that a programmer who only wanted to write a doubling routine, but did not care what kind of numbers are being doubled, could write double(N) :- add(N, N). Overloading is orthogonal to compile-time/run-time typing, though overload resolution is not. Overloading is just using the same name for the same logical concept, where the concept may have different implementations, and this is not much different than overriding methods in a subclass. > There's also the issue of method syntax (and some tradition) making it > irrelevant. Consider: > > - drawImage:anImage withFloatingPointScaleFactor:(float)f; > - drawImage:anImage withScalingObject:o; > vs. > drawImage (f); > drawImage (o); > > I tend to prefer the former, as it leads to more self-documenting > code, and less of that "hmm, what paramters does this take?" kind > of thing. I think it depends greatly on your viewpoint. An important aspect of an any high-level language is abstraction, and OO languages tend to support it greatly. For example, the above could be re-written as class Image { void ScaleBy(float simpleFactor); // optimized version void ScaleBy(ScalingObject complexFactor); // general version ... }; Image anImage; ... anImage.ScaleBy(x); // what is x? I think it's pretty clear that we want to scale the image, and that 'x' is directly involved. Just as in method overriding, we often don't care how things get done, for example, the direct role of 'x'. No, we assume that the author and the compiler do the right things for each case. If we want to know the details, for example to verify correctness, we have to look harder. Perhaps we have to look at the declaration of 'x', or look at the definition of ScaleBy(), or even trace through the call itself. But again, just as in a method override, this is the "price" we pay for abstraction. Is this too much? I don't think so -- we specifically wanted details! -mc
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 1997 15:27:36 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5cakd8$829@netty.york.ac.uk> References: <maury-0801971641590001@199.166.204.230> <maury-1701971144500001@199.166.204.230> <maury-2001971752260001@199.166.204.230> On Mon, 20 Jan 1997 17:52:26 -0500, Maury Markowitz <maury@softarc.com> wrote: > > By "this" do you mean OOP wrappers around CLI programs? > > No, _replacing_ the code with OOP shared libs. don't be silly. the whole point of object orientation is to obtain better modularity within the system. the unix shell and its associated programs have better modularity than objective C or C++ will ever have. have you ever seen an OO library that allows objects to be interconnected as freely as the unix shell allows ? why reinvent the wheel (badly) ? rog.
Newsgroups: comp.sys.next.programmer,comp.sys.mac.misc,comp.sys.mac.system From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Real-time video effects Was: DPS Hit Detection Message-ID: <E4Iv3H.qA@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <5biv18$h7p@castor.cca.rockwell.com> <AF028AED-9B7E4@198.68.42.195> <5bjlj4$sab@news.xmission.com> <rex-ya023080001501972214240001@nntp.ix.netcom.com> Date: Fri, 24 Jan 1997 16:57:16 GMT rex@mit.edu (Eric King) wrote: > It certainly sounds intriguing :) Me, I'm looking forward to MovieClips > Pro, the non-pro version right now gives you a very tantalizing taste of > what kinds of real-time video effects are possible with GX's graphics > engine. Has anyone tried making something that can transform and blend > NextTime movies together in real-time? (That is on a Pentium or Pentium > Pro, not on an ND board.) While real-time is a problematic phrase (how fast is your real-time ? 30fps, 20fps ?...how big are your movies..full NTSC/PAL resolution at 24 bit ? ) this issues has little to do with a NeXTdimension board. The dimension would currently be the slowest NeXTIME platform around. But then...NeXTIME does basically not care about DPS. NeXTIME bypasses the DPS and directly writes to the framebuffer. If your effects can perform on bitmap data...combine the two samples of your two source movies (each frame is probvided as an NTSampleBuffer object) and deliver the transformed endresult to the imaging pipeline. Now if you are talking about translating a NTSampleBuffer into a native AppKit NSImage...then manipulating it (with DPS) add alpha channels and then putting things back together. Well, thats another issue and I would not comment on that until I have tested it. Still it has nothing to do with the way NeXTIME works...its how complex your manipulations are. Aloha Tomi
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 24 Jan 1997 19:21:22 GMT Organization: Global Objects Inc. Message-ID: <5cb23i$ofj@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <199701211742586676963@amtmtc.demon.co.uk> andy@amtmtc.demon.co.uk (Andy Templeman) wrote: > Charles W Swiger <cs4w+@andrew.cmu.edu> wrote: > > Because you need the shell and the utils in order for the operating > > system to boot in a flexible way that can be maintained by a system > > administrator. > > Macs have traditionally been touted as systems where you don't need a > system administrator. A lot of home users are not C.S. savvy and want > the new system to be as simple to install and administer as system 7 is, > with the advantages that a protected & pre-emptive system can give. You don't have to be a sysadmin to run a NeXT box, either. In fact, I've known several folks who use a NeXT at home and probably know less about CS than the average Mac user. However, if you want to hook a bunch of NeXT boxes together, the sysadmin facilities are in place and work well. Seems this is the best of both worlds, since you can sell to home users or to corporations, and either type will find the system quite usable. So why rip out something that could potentially increase the markets you can successfully sell into if it doesn't damage the current markets you are targeting? By the way, IMHO, Apple still needs to make a few improvements in the GUI to hide UNIX a little better--but there isn't really that much more to do. When I bought my NeXT in 1991, one phrase that was common is "if you have to use the command line, it is a bug." In other words, they were trying to make the system such that you would never need the CLI--but they'd leave it in there for those who want and/or like it, such as sysadmins. Frankly, all I ever use the CLI for is sysadmin tasks; everything else is handled quite nicely by the GUI and I prefer that interface for most things. Most of the things Mac users fear about NeXT's UNIX underpinnings are really quite groundless--but until they've actually _used_ a system, it is impossible to "prove" it. So, if you don't know NeXT, find someone who will show you just how nice it is. I think that most Mac users are in for a pleasant surprise. It really is not as scary as you think and some things are positively amazing... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: pkoren@ti.com (Peter A. Koren) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: 24 Jan 1997 19:25:53 GMT Organization: Texas Instruments Message-ID: <5cb2c1$382@sf18.dseg.ti.com> References: <5amli2$ol3@news.tuwien.ac.at> <E4Dsqs.6Cx@micmac.com> <5c7juq$7n5@news.tuwien.ac.at> <5c93k6$l5c@news3.digex.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII In article <5c93k6$l5c@news3.digex.net>, jkheit@cnj.digex.net says... > >snip > >Yes, but ms dos, unix, and other system users are much bigger than >apple's market of say around 5million users with hardware capable >of running the upcoming OS. Furthermore, and arguably, apple has >been loosing customers to those other platforms. Apple has to do >what is BEST, not what is most wanted by current mac users. Apple >has to do what is is BEST to be compelling enough for users of >other systems to switch over or come back to apple. A superior UI >to both the current mac, and next UI wouldn't hurt. > I jumped ship from the Mac when I went back to school full time to get another degree (CS). I had to get a PC to do the course work, but then I discovered NeXTStep on Intel and I finally had what I really wanted; an easy to use and powerful system. It beat both the Mac and Windows. But I couldn't stay with NeXTStep after graduating because of the money. I also needed the Unix apps and X stuff, so I went to Linux. The Apple-Next merger is for me a Godsend. My NeXT machine (bad pun) will be a Rhapsody running Mac or Mac clone. This deal brings me back to Apple. Pete Koren
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: mmap/munmap under mach Date: 24 Jan 97 09:40:16 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan24094016@howard.one.net> References: <32E98C21.2568@friday.com> In-reply-to: Bill Bumgarner's message of Fri, 24 Jan 1997 23:29:21 -0500 In article <32E98C21.2568@friday.com>, Bill Bumgarner <bbum@friday.com> writes: BTW: It appears that mmap exists within the OS-- even madvise is present. But compilation reveals that the munmap() function is undefined. As I do not have the implementation details of mmap(), I cannot undo whatever it does (maybe just a vm_dealloc() would work? Likely...?). Question: Have you tried copying the prototype from an older system, and compiling away? In the past NeXT has removed prototypes from the header files, but the implementations are often still in the libraries. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 24 Jan 1997 12:08:01 -0700 Organization: Primenet Services for the Internet Message-ID: <AF0E59FF-BE0C2@198.68.42.129> References: <5c9cm6$otb$1@solaris.cc.vt.edu> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >Perhaps a better question: >Will a game framework become part of the OpenStep spec? > >After GNUstep matures games would be very portable! > >Having a well thought out standard API for sound, input, >speech, 3D, quicktime, buffering, etc would be great. Games Sprockets is supposed to encourage developers to develope for Macintosh-FIRST by providing a cross-platform solution that works with both MacOS and WIndows. Having a cross-platform solution that works with a free OS doesn't seem like a viable rationale for porting Games Sprockets to OpenStep/GnuStep. Also, one would need QuickDraw 3D and RAVE to make it work well, and I guarantee that Apple won't be porting those to GnuStep. --------------------------------------------------- What's so cool about Cyberdog? Parts is parts, right? ---------------------------------------------------
From: "Jonathan W. Hendry" <jon@exnext.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 24 Jan 1997 19:46:39 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32E957EF.65C0@exnext.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <199701240608351834902@amtmtc.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andy Templeman wrote: > > Jonathan W. Hendry <jon@exnext.com> wrote: > > [snip - why should apple support 1% of users who want unix] > > > > Actually, Apple should let all those people who want Unix hang. Who > > cares if they buy Solaris, or Windows NT, or run linux on a cheap > > Pentium? Who needs em. > > > > [...] > > > > If Apple can grab back the graphics professionals who are using > > NT, they could probably add another .5%. If Apple can grab > > webserver marketshare from WinNT, that might account for another > > .5%. (This would likely be easier if Apple shipped Rhapsody > > on Intel). That'd increase Mac marketshare by another 1%. > > Apple already sell Unix boxes for people who want to run Unix servers. > You can buy today a Network server 700 which runs AIX. How will Apple be > exposing themselves to a new market by offering a second unix operating > system? What about people who want Unix, but not a server? There are lots of people running Unix as a workstation OS. They'd love to have lots of polished productivity apps. Right now, if they want them, they've got to go to NT. There's a huge difference between offering Yet Another Unix (AIX, or A/UX) and offering a robust, user-friendly Unix which runs lots of useful, polished applications. -- Jonathan W. Hendry jon @ exnext . com
From: Michael Hudson <sorry.no.email@nowhere.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Fri, 24 Jan 1997 17:48:25 +0000 Organization: University of Leicester, UK Message-ID: <32E8F5E9.2620@nowhere.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan M. Urban wrote: > id obj1 = [anArray objectAtIndex:i]; > id obj2 = [anArray objectAtIndex:j]; > > if([obj1 compare:obj2] == NSOrderedDescending) { // swap elements > [obj1 retain]; // keep the array from freeing obj1 when it is replaced at 'i' > // don't have to worry about obj2, it gets retained by the first replace > // and released by the second > [anArray replaceObjectAtIndex:i withObject:obj2]; > [anArray replaceObjectAtIndex:j withObject:obj1]; > [obj1 release]; // decrement the reference count > } I can think of another reason why C++ took off, rather than Objective-C: That looks nothing like C. C++ code (unless it's very templatey) looks much like C. I have never coded in pure C, but I'd say that the fact that C++ can look like C must have made the transition less scary for many people. -- Regards, Michael Hudson Please don't email this address - it's not mine.
From: glen_stewart@associate.com (Glen Stewart) Newsgroups: comp.sys.next.programmer Subject: BASIC on NeXT? Date: Fri, 24 Jan 1997 23:19:59 -0500 Organization: The Association at http://associate.com Message-ID: <glen_stewart-2401972320070001@stewart-3.pnet.msen.com> Kinda in preparation of Mac-NeXT, I'm planning to install the Mac 68k port of NetBSD or OpenBSD on my IIci to begin getting some UNIX administration experience. I've spoken with about 6 people currently running NetBSD 1.2 on their IIci's, and they claim great stability - though it's a bit slow (-; Anyway, I'd love to be able to do BASIC programming in UNIX. Does anyone here know if there is such a compiler available? GCC seems to be just about everywhere (even on the Mac68k port), but BASIC is what I really prefer. Thanks for your reply if you know of such a tool. Glen -- The Scottish Stewart Clan Home - Genealogy Database, Symbols, Tartans, Septs http://associate.com/stewart.html The Association BBS - Gigs of *fully described* Macintosh files from '94-'97 http://associate.com/bbs_mug.html CyberChurch - A Massive Gathering of the Saints via dozens of Mailing Lists! http://associate.com/CyberChurch_news/ ListServ@associate.com - Mailing Lists like: Associated_MUG, DragonRaid, FutureBASIC, Soon, ChristianUnity, Christian_Music, MissionNet, and AOG
From: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Concerning Function Overloading in Obj-C.(Re: Multiple Inheritance) Date: Fri, 24 Jan 1997 22:55:27 -0500 Organization: TofuSoft Message-ID: <jchan-ya023580002401972255270001@news.apk.net> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <SHESS.97Jan23151627@slave.one.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Can't we just pass the parameter as an id object and then do a switch based on the object type? --- The Evil Tofu (Only Human)
From: GWILLEM@alpha.ntu.ac.sg (Van Schaik Willem Anthon Johan ) Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Followup-To: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Date: 25 Jan 1997 04:47:59 GMT Organization: Nanyang Technological University Message-ID: <5cc39v$51e@ntuix.ntu.ac.sg> References: <5amli2$ol3@news.tuwien.ac.at> <E4Dsqs.6Cx@micmac.com> <5c7juq$7n5@news.tuwien.ac.at> Robert F Tobler (rft@cg.tuwien.ac.at) wrote: : what we Next users think if they can retain their Marketshare (and Next users Isn't that . . . . . . . . . . . . . . . . . . . . MarKETshare :-) Willem
From: no_spam@Glue.umd.edu (David T. Wang) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 25 Jan 1997 05:18:27 GMT Organization: University of Maryland, College Park, MD Message-ID: <5cc533$drv@dailyplanet.wam.umd.edu> kent@voicenet.com wrote: : >: Since marketshare is a measurement of sales at a given time - and the : >: computer market is growing - then Macs units are growing as well - : >: just at the same rate as the rest of the industry (no faster or : >: slower). I beleive sales of Macs (and compatibles) was at 5.1 million : >: last year (96) as opposed to 4.5 million for '95. That is not exactly : >: losing ground. Apple has given a little ground to its compatibles - : >: but Macs are selling more units than ever. : > : >: Funny.... 5.1 million machines last year.... that seems like pretty : >: good sales volume to me. : > : >Apple itself shipped About 4 Million Units in Fiscal 1996. Could you : >tell me where you saw the 5.1 Million units number? : > : Duder look at what the guy above you wrote. He said 5.1 million Mac/clones : in 1996. That is quite possible since you yerself just said Apple alone : sold 4 million of em. Mellow out duder and READ THE POST !!!!!!!!! I think : 1.1 million between Motorola, ah Power Computing, Umax, and them Genesis : dudes, APS is quite possible. You mean between 5 clone makers they only : sold 1.1 million ?? That actually sounds lame. I thought it would be more : 8( Oh weeeeeeell theres always 1997 8) Clone sales were estimated at between 350,000 to 500,000 units. Power Computing is rumored to have sold a bulk of that number. Motorola only started shipping machines in late 1996, Daystar sold about 5000 boxes (mostly high end multi-cpu configs) APS and Umax? haven't heard much about them at all. Do you have any idea where a 5.1 Million number could be reached?
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 25 Jan 1997 01:52:09 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ccaip$nm3@csugrad.cs.vt.edu> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <SHESS.97Jan23151627@slave.one.net> In article <SHESS.97Jan23151627@slave.one.net>, shess@one.net (Scott Hess) wrote: > In article <5c7vug$4s4@csugrad.cs.vt.edu>, > nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: > Internally, it's doing something like: > [a bunch of messaging] > Aighh! I would expect that NSArray is implemented internally as a > pointer to a block of memory, and that they could just use qsort() > with wrappers around -compare:. Well, yes. I didn't mean that "internally" too literally.. I just wanted to show an example of how you'd manipulate arrays using message passing. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Concerning Function Overloading in Obj-C.(Re: Multiple Inheritance) Date: 25 Jan 1997 01:52:58 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ccaka$n27@csugrad.cs.vt.edu> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5c7vug$4s4@csugrad.cs.vt.edu> <SHESS.97Jan23151627@slave.one.net> <jchan-ya023580002401972255270001@news.apk.net> In article <jchan-ya023580002401972255270001@news.apk.net>, jchan@apk.net (Jerome Chan) wrote: > Can't we just pass the parameter as an id object and then do a switch based > on the object type? No, the object type isn't an ordinal. You can't switch on it, just like you can't switch on strings. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: john_zollinger@arkona.com (John Zollinger) Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: So what do I need to catch the Apple/Next wave?? Date: Sat, 25 Jan 1997 08:04:25 GMT Organization: Arkona, LLC Message-ID: <32e9bad9.14819349@news.xmission.com> References: <5brihp$1hti@yuma.ACNS.ColoState.EDU> warnerr@beethoven.cs.colostate.edu ( richard warner) wrote: > I have the NEXTSTEP 3.3 Developer system. A proud owner of a >Color NEXTSTATION - until just recently prepping to buy high-end >laptop (six solid years from the NEXT, not bad). Had pretty well given >up on NEXT *gasp* until the big news. WOOHOO!! LIFE. Way to go Stevey. > So now I'm wondering, can I load NS on the laptop and then load >Win/95 under it to access my office productivity stuff - or should I get >the SoftPC emulator? What do I need to do/can I get both NS and Win/95 >on the same box, preferably Win/95 running in a window under NS. Well, softpc runs only Win3.1 stuff last I heard. The best way to do it is to have two partitions on your hard drive. One for OPENSTEP for Mach, one for Win95 or NT. When you boot you can choose to go into either. Under NEXTSTEP you will be able to access the FILES on your Win95 partition, but you won't be able to access your NEXTSTEP stuff under Win95. I have Win95, NT, and OPENSTEP for Mach on my machine. > Another line of questions has to do with development. NEXTSTEP >native vs OPENSTEP. Is there an OPENSTEP developer product for Intel boxes >and do I want it instead of NS native? Is it the product that has a >future?? Yes. You can get either OPENSTEP for Mach (much like what you have on your black box). Or you can get OPENSTEP for Windows NT. Which is basically the OPENSTEP development tools, but in the NT OS. The good part about the OPENSTEP NT is that you can still get at your MS Office apps since they run fine in NT, the downside is that you don't have the nice mach OS, and you can't do any nifty unix things, you don't have all the great NeXT apps like mail, librarian, and, well, it's NT. If you are used to NEXTSTEP, moving to NT is quite annoying. > Another line of questioning - is NS 3.3 Developer the latest/greatest >still for Intel boxes (if OPENSTEP is the way to go - which version?). The latest is 4.1, and I think 4.2 is coming out shortly? > Lastly, a RFO (Request For Opinions) as to which is better as of today: >Buy a new Intel box and put NS/OPENSTEP on it - or wait to purchase until >some hot Apple/NEXT combo hits the market. Of particular interest to >me is in the realm of laptops, but also interested in opinions generally. Good question. I have no idea. I'm holding off on getting an Apple box until I see what horror's they do to the NeXT UI. If Apple keeps their current UI, I'll stick with OPENSTEP for Mach on Intel. :-) If they see-the-light and keep the majority of the current UI, then I will consider getting one. Ciao,
From: crobato@kuentos.guam.net Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 1997 09:33:50 GMT Organization: Kuentos Communications Inc. Message-ID: <5cck1u$g07@lehi.kuentos.guam.net> References: <5cc533$drv@dailyplanet.wam.umd.edu> In <5cc533$drv@dailyplanet.wam.umd.edu>, no_spam@Glue.umd.edu (David T. Wang) writes: >kent@voicenet.com wrote: >: >: Since marketshare is a measurement of sales at a given time - and the >: >: computer market is growing - then Macs units are growing as well - >: >: just at the same rate as the rest of the industry (no faster or >: >: slower). I beleive sales of Macs (and compatibles) was at 5.1 million >: >: last year (96) as opposed to 4.5 million for '95. That is not exactly >: >: losing ground. Apple has given a little ground to its compatibles - >: >: but Macs are selling more units than ever. >: > >: >: Funny.... 5.1 million machines last year.... that seems like pretty >: >: good sales volume to me. >: > >: >Apple itself shipped About 4 Million Units in Fiscal 1996. Could you >: >tell me where you saw the 5.1 Million units number? >: > > >: Duder look at what the guy above you wrote. He said 5.1 million Mac/clones >: in 1996. That is quite possible since you yerself just said Apple alone >: sold 4 million of em. Mellow out duder and READ THE POST !!!!!!!!! I think >: 1.1 million between Motorola, ah Power Computing, Umax, and them Genesis >: dudes, APS is quite possible. You mean between 5 clone makers they only >: sold 1.1 million ?? That actually sounds lame. I thought it would be more >: 8( Oh weeeeeeell theres always 1997 8) > >Clone sales were estimated at between 350,000 to 500,000 units. Power >Computing is rumored to have sold a bulk of that number. Motorola >only started shipping machines in late 1996, Daystar sold about 5000 >boxes (mostly high end multi-cpu configs) APS and Umax? haven't heard >much about them at all. Do you have any idea where a 5.1 Million number >could be reached? > > Umax did 100,000 for the year. Half a year actually since they started shipping six months ago. Motorola did 40-50,000. In eight weeks. Rgds, Chris ************************************** *"Defend your OS choice, or you will lose it."* *---Steve Kahng, CEO, Power Computing. * *>> crobato@kuentos.guam.net << * **************************************
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 22 Jan 1997 10:47:52 -0600 Organization: mementech, inc. Message-ID: <32E644B8.29CAF0F5@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury- <5c4f5l$g5k@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > mmalcolm crawford (m.crawford@shef.ac.uk) wrote: > : On 01/21/97, Maury Markowitz wrote: > : > : > So which market do they go after? The PC market doesn't want > : > Unix any more than the Mac market does. > : > > : Umm, this jars a little with the success of Linux... > > Linux is one of those things which USENET gives a better impression of > than reality. Don't get me wrong, I like free Unix for common hardware > and the grassroots communal development gestalt. It's just that Linux > has much more USENET mindshare than real world "marketshare". Here's a better way to phrase that idea: Linux users are more effectively internetworked. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Michel Coste <mic@micmac.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 25 Jan 1997 08:16:24 GMT Organization: MiCMAC Sender: news@micmac.com Message-ID: <E4K1nC.5I1@micmac.com> References: <5ami95$ol3@news.tuwien.ac.at> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> <5c9g1e$ng5@csugrad.cs.vt.edu> Cc: nurban@csugrad.cs.vt.edu This was written in comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system (<5c9g1e$ng5@csugrad.cs.vt.edu>) by Nathan M. Urban: > In article <AF0B6C4A966812791F@node26.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: > > > >There are no drive icons. Unix drives look like folders; they're > > >mounted directly into the filesystem wherever you want (and have > > >permission to put them). > > > Hmmm. I can see both advantages and disadvantages. If you're running on a > > fairly static system, with little or no changes to the mounted disks, this > > can be a big advantage, since you don't have to worry about what file goes > > where; OTOH, dealing with removable media (or drives that are regularly > > switched between systems) would be a real nightmare. > > How so?? I deal with removable media all the time. I don't see any > problems with it. > Well... He doesn't know ho NeXTSTEP deals with the problem! In the Workspace, when inserting a removable media, the user has these choices: - Place the icon on shelf - Open a new File Viewer - Select the Disk - Do nothing (what he thinks!) I personally make the second choice. But for people only doing backups to optical the fourth choice makes sense... So the NeXT way is always a big advantage! > > >There are some generic icons for removable media like floppy disks and > > >CD-ROMs that the File Viewer uses instead of a folder icon when you > > >insert one; those are probably stored in the Workspace's app wrapper. > > > Hmmm. Does that mean items on removable media are *not* inserted into the > > regular directory tree when you insert a cartridge? > > No, they _are_ inserted into the regular directory tree. What makes you > think otherwise? Well I think it's difficult to imagine how NeXT work if you've never touched a system, never seen a screen shot, never read something serious about it! From now on there are two sort of people. The ones who wait and try to learn these things before making noise on the Net (this is not intended for you Travis: obviously you _want_ to learn!) and the ones who made their idea without ever going to the clue market... (probably because they were born with ideas on everything). > > > >In article <maury-1701971144500001@199.166.204.230>, maury@softarc.com (Maury > > >Markowitz) wrote: > > Yes. There is utterly no advantage to ripping out the CLI stuff. > What's this "clutters the system" stuff, anyway? You don't even have > to know it exists. I can't see any reason to rip out enormous amounts > of functionality to have a "less cluttered" system. Besides, Unix > requires many of these utilities to work! I guess he don't want to understand that. Out of reach! > Apple is going to provide GUI shells for more of the NEXTSTEP CLI > commands (you can already do anything from the NEXTSTEP GUI you want > w/o resorting to a CLI, except for some sysadmin commands, which is > what Apple is targeting), so you'd better learn to live with it. Well said Nathan! It should be the moral of the story... mc
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Date: 23 Jan 1997 04:47:58 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5c6qhu$r1v@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> Charles William Swiger (cs4w+@andrew.cmu.edu) wrote: : Excerpts from netnews.comp.sys.next.advocacy: 22-Jan-97 Re: MacWorld : Exclusive: App.. by William Raphael Hix@port : > Tar is of great use to Unix users. I use tar on my Unix box to aggregate : > files which I then compress and download to my Mac where Stuffit : > uncompresses and untars them. But most Mac users never encounter tar : > files since Mac software distribution is done by Stuffit/BinHex. : > But you expect Rhapsody software distribution to work like NeXTStep? : : I hope that Rhapsody uses NeXT's packages and Installer.app, yes. : Normal NEXTSTEP users never invoke tar themselves-- they use GUI tools : like Installer.app and Opener.app which use tar internally. : : If you look back a few weeks, I described exactly how easy Installer.app : and Opener.app are to use, and the fact that you get functionality like : receipts (for uninstalling software and for showing what software has : been installed on a system), multilanguage support, and FAT binary : support. This is the way any good installer works, it need only use tar if the software is coming from a Unix base. This is natural for NeXT with little shrinkwrapped software and hence heavy dependence on Unix's legacy. We'll have to see how true this remains with Rhapsody's mix of NeXT and Mac veterans. : : > Ports of apps from Unix to Rhapsody? : : Sure hope so. Doesn't any Mac user see some advantages to being able to : run your own personal web server on your own machine, or to be able to : send and receive electronic mail quickly and efficiently? Umm, there are Mac web servers you know. In fact more WWW severs run on Macs than on NeXT. It is no longer true that internetable means Unix. [snipped out tar's usefulness to NeXT users] : > But it doesn't do anything for a Mac user since Mac software in not in : > tar format. Perhaps for Rhapsody this will change, but I think that : > you are assuming things which aren't decide yet. : : In that sense, this is what everyone on these newsgroups are doing! No : doubt Apple and NeXT have a lot of decisions to make which have not been : made yet. : : Possibly, although it's _far_ less likely-- some of the debate that goes : on here in Usenet will have some influence on the decisions they make. : It would be to our collective advantage in the long term if we can make : discussions about Rhapsody as useful as we can, since it might make : Rhapsody a better operating system. : Mostly we're trying to assuage our anxiety about our prefered platform. I wrote to this thread hoping to see where the compromise of Mac and NeXT users would lead. I just don't see Apple shipping for $100 the same OS which NeXT sold for $800. Perhaps the ecomomy of scale will pay off this well. I'd love to have complete BSD 4.3 available on the same machine which runs Quicken at home. : Prosletizing the "one true Mac way" to the point where someone at Apple : gets disgusted enough to publicly disagree with your slander of DPS, or : arguing that we have to rip Unix out of Rhapsody in order to save three : dollars in disk space but screw up almost every aspect of NeXT's : technologies, are, in my opinion, some of the most pointless and idiotic : arguments I've ever seen on Usenet. Was it me specifically who slandered DPS? or am I a generic Mac user to lay your frustration on. Again, as a long time Unix user (Hell, I'm a FORTRAN programer on a bad day), I'm not advocating removing Unix from Rhapsody. I am however trying to figure out what Apple will do to NeXTStep to ease its acceptance with current Mac users. From the flip side, many NeXT users who have contributed to this thread see life under Rhapsody as no different from their current NeXTStep experience. With a short term projected audience of millions of Mac users, followed by current OpenStep users when Rhapsody makes it to their platform, I don't see this as a reasonable expectation. : _Why_ be so brain-damaged? I take that back, we all participate in USENET in order to insulted. I'm sorry you don't like my opinion, I find your's malformed as well. : >: If they pressure Apple to drop basic functionality like this, then : >: Apple should tell them to take a leap. : > : > What a NeXT user sees as basic functionality might seem like wasted disk : > space to a Mac user. Dropping them also reduces Apple's support load, : > perhaps lowering the cost. [ ... ] : : Hold on a second. At the end of this article I'm responding to, you said: : : > Mac users are largely happy with what they have, if only it'd run stably, : > in protected memory with pre-emptive multitasking. : : The combination of the Mach kernel and Unix utilities provides the : functionality that you say Mac users would want. : : You can't rip the Unix layer out from between Mach and NeXT's software : tools without seriously impacting that functionality, because Apple : would have to write an as-yet-imaginary middle layer to replace that : functionality. : : Do you think something like that is simply appear out of thin air? : Nope-- it would take lots of time and development effort to get 1.0 : version done, and would take even more time and effort to get stable and : reliable. : I don't want to remove BSD from Rhapsody, I'm wondering if Apple will minimize the size of the base installation and make the add-ons cost additional. If the Openstep API calls every single BSD command directly, then division is not possible if one is to maintain OpenStep compatibility. My impression from conversations with NeXTStep users is that there are parts of BSD not needed for OpenStep compatability. For example, the pieces of BSD which are part of OpenStep developer are optional for the OpenStep API. NeXT itself makes this distinction, Apple can do so as well. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: 23 Jan 1997 04:53:39 GMT Organization: Digital Fix Development Message-ID: <5c6qsj$2lv@news.digifix.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> In-Reply-To: <32E70F28.48B8@friday.com> On 01/22/97, Bill Bumgarner wrote: >Actually, tar really, really sucks as an archive tool... > >tar was designed for use as an archival tool for writing hierarchies of >files to a linear piece of media. As such, it lacks certain >conveniences such as 'random access', 'well organized directory >information', or any of the other conveniences of, say, Stuffit. > >Don't get me wrong-- tar provides a certain set of functinality that is >both convenient and highly functional... but to say it is superior to >Stuffit is ridiculous. > I certainly didn't say that it was superior, or that Stuffit was bad. A universally available format with the features of Stuffit (random access wise) and the free/clear compression algorithms of gzip would be a huge winner provided that the archive format and algorithms were made public so that it could become an 'all platform' solution. >If anything, Aladdin should release a version of Stuffit that can be >used from the command line... I'd certainly pay for a tool that give me >random access to my archives, a full-featured GUI w/drag-n-drop, and a >comparably featured command line utility. > As would I. Infact, I have, I've probably bought two or three tar/compress front ends on NEXTSTEP.. :-) >[Hey, Raymond, remember me? Probably not... I'm the person that fought >so, so hard for Stuffit to become an accepted file type on Connect and >CompuServe way back in the .7, .8 days... back when that stupid Huffman >tool ruled the mac world.] > >The only real advantage the various Unix tools have over the various >tools on other platforms is that they +work+ within an environment that >can be scripted (note that easily is nowhere to be found). But-- the >user interface is crap and it is quite easy for the user to mean one >thing and end up fatally wounding themselves (instead of just piercing >their foot). Its the cross-platform availability of tar that I thing is superior, not the format itself. > >Combine the UI experience of the comparable tools under Mac w/the >awesome functionality of the various unix tools and you have one hell of >a powerful system that one may actually have a hope of using without >hurting oneself. > -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 1997 05:13:17 GMT Organization: Digital Fix Development Message-ID: <5c6s1d$2oh@news.digifix.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> In-Reply-To: <5c4ed7$fjt@geraldo.cc.utexas.edu> On 01/21/97, William Raphael Hix wrote: >Scott Anguish (sanguish@digifix.com) wrote: >: On 01/20/97, William Raphael Hix wrote: >: >Garance A Drosehn (gad@eclipse.its.rpi.edu) wrote: >: >: raph@porter.as.utexas.edu (William Raphael Hix) wrote: >: > >: >Then you are essentially arguing that tar is of little use? >: >: Sounds to me that what he's saying is that its too clumsy for most >: casual users to learn, and that there is a market for a front end to it. >: >: Tar is of a great use to many people out there, isn't that obvious >: since almost everyone is adding its functionality and there are free >: versions of it available? >: > >Tar is of great use to Unix users. I use tar on my Unix box to aggregate >files which I then compress and download to my Mac where Stuffit >uncompresses and untars them. But most Mac users never encounter tar >files since Mac software distribution is done by Stuffit/BinHex. Yeah, I know, this is one of my major complaints. Stuffit is a closed system in this respect. >But you expect Rhapsody software distribution to work like NeXTStep? >Ports of apps from Unix to Rhapsody? This is another of those places >there the NeXT and Mac community are talking about apples and oranges >(I apologize for the pun). > Not sure what you mean by this.. >: >If this is then why bother including it on everyone's disk? >: >: Why? Well, lets see.. >: >: Its a universally available tool on ALL machines, without depending >: on owning a third party product. This means that an Apple user who >: downloads something from the Net has a tool to start from. > >But it doesn't do anything for a Mac user since Mac software in not in >tar format. Perhaps for Rhapsody this will change, but I think that >you are assuming things which aren't decide yet. Sure it does. It gives Apple users a method of dealing with the oft available tar files on the net. > >: Same can be said for compress, ftp, telnet, etc... > >And there are software tools available for free or cheap which handle most >of these in an GUI fashion familar to Mac users, so CLI version is of no >use to Mac users. Will it be the Mac users or the NeXT users who must >adapt. Both of course, we just don't know where who will give in. You don't seem to be arguing the point you were, namely that the unix utilities should be removed because they are infringing on third party markets. > >: >Even before the >: >new OS, Apple's usurpation of functionality was one of the main complaints >: >from developers. Apple is particularly beholden to their developers >: >now since without developer support, Rhapsody is OpenStep/PPC. > >: >... There will be pressure on Apple to drop such functions. >: >: Then they need to "value add" to their products. >: >: Even if they drop it from the OS CD, anyone can compile it for it, >: and still give it away. >: >: If they pressure Apple to drop basic functionality like this, then >: Apple should tell them to take a leap. >: > >What a NeXT user sees as basic functionality might seem like wasted disk >space to a Mac user. Dropping them also reduces Apple's support load, >perhaps lowering the cost. If it's a compiled freeware add-on it's not >Apple's job to support it. Use it at your own risk. With tech savvy >NeXT folks the risks of such are smaller than with typical desktop users. > >: >: >Case #2, the Unix utility A is a "poor" substitute for Mac application B. >: >In this case, what is the point of including this utility in the OS? >: >: Because its required by those who don't have the commercial product. >: >: Hell, better drop Edit.app from the release, its a RTF text editor, >: and the word processor people are going to scream. > >So Apple is supposed to provide free versions of everything in case you >can't afford (or don't want to spend the money on) the commercial version? No. What I'm saying is that you shouldn't remove the functionality from the Unix underpinnings to prop up a market. I've bent over backwards to help NeXT ISVs keep things together over the past 3 or 4 years at great personal time and expense. I'm not anti-commercial software in any respect. >The economics of a $100 dollar desktop OS are very different from those >of a workstation OS. In the case of Edit.app, Apple does provide Simple >Text. Should they provide both? > >: >Unix >: >compatibility comes the reply. Well, how important is Unix compatibility? >: >: Very. > >To a NeXT user. Too much Unix compatibility might make some Mac users >scared, or at least seem like a waste of disk space. > >: >It's clear from this thread that to NeXT users it's essential. But how >: >much does this matter to the Mac community that Apple is pitching Rhapsody >: >to? >: >: Oh, you mean like those piddly companies that have fortune 500 >: status? You know, those Enterprise installations Apple HAS to get to get >: back into the corporate market? > >Apple needs to appeal to their current users in order to survive long >enough for enterprise to take notice. Besides NeXT demonstrated that >even a solid reputation in the enterprise market is not enough to >keep a large company or hardware manufacturer alive. >: >: > Would they rather have the system take up less space or have Unix >: >compatibility 99% of them would never use. The feelings of NeXT users >: >(none of whom have compatible hardware) are secondary to the 10-100 times >: >larger Mac community. >: >: Well, scr*w you too. Apple has said today that OpenStep for other >: platforms will continue to live, so suddenly alot more people become >: relevant due to hardware compatibility. >: >: And again, what if an Enterprise application running on >: OpenStep/Solaris or OpenStep/Intel require these tools? Someone needs a new >: machine, Apple doesn't ship with the essential tools, so we better just buy >: another Intel box with OpenStep/Intel on it. > >You are taking this too personally. You said... "The feelings of NeXT users are secondary" my reply to that is that you better start to open up, or Apple's gonna die. >I'm not trying to rain on you parade. >Apple has said they will continue to support OpenStep on Intel and >Solaris, but I haven't heard anything clear from them about future >development, either as Rhapsody on other hardware or independently. Then you should be reading the letter that Dr. Gil now has on NeXT's WWW site. >Infoworld suggests that wrangling over these options is delaying >fundamental choices like which kernal to bring to Rhapsody. Yeah, well, you gotta fill that print space. <snip> >The 1% number is based on estimates of Linux installations on PCs. Perhaps >it should be a few %. It sounds like you really want Rhapsody to be a >cheap Unix, like a supported Linux. You're wrong. What I want is for Apple to take the best of what it has to offer, and the best of what OpenStep has to offer (rich framework, EOF, WOF, preemptive multi-tasking, etc...) and make the best, most openly compatible system available. >Mac users install Mac versions of >servers. Some are free, some cost money but are supported. If you want >Linux, get Linux. Don't ask millions of Mac users to accept Linux. I'm not. What I'm asking is don't cripple the OS just to save 20 Mb of install space. >: >: Will Apple prohibit compiling and distribution of find then? Who >: gets hurt by Apple including it? >: >: And what if someone writes a really cool freeware utility that uses >: find... do they have to supply it? > >Of course Apple will not prohibit or inhibit distribution of any software. >Apple just won't support it. I can just imagine calls to Apple which >get answered, "Well you need to add -print to tell it to print the list of >files it finds." Use at your own risk. > I doubt that Apple does that with A/UX. >: >Naturally, every real example is somewhere in between, but both of the >: >extreme cases argue against strong Unix compatibility. >: >: Yeah, compatibility is bad. :-| > >Personally, I'd love Unix compatibility in my Mac, so all the Unix >skills I have at work could be put to better use at home. But Apple >isn't pushing Rhapsody for us tech-heads, it's got to appeal to a wider >base that couldn't care less about Unix compatibility. Not having it and not using it are entirely different things. >: >: CyberDog is bad. It hurts Eudora and other mail companies, better >: kill it now. > >Apple did get pressure not to do Cyberdog, but evidently decided that >the time had come for an least primitive systemwide Internet services. >Perhaps for Rhapsody they'll add Unix compatibility to the list of things >necessary to the OS. > >: sendmail, that might piss off a mail-gateway company >: ppp - hell, someone might want to make a commercial version >: ftp, sed, awk, perl, - all useful, but might tread on someone's >: toes, gotta kill them. >: >: ftpd, httpd, Apache, INN - all server products that will compete >: with other products. They're free here, gotta kill them too. > >Most of these would not be used by enough users to justify inclusion in >the OS. Mac equivalents for most of the rest are available for free, >some from Apple. If it wasn't and there was demand, someone would have >ported it. Oh, but you want these exact versions. Get a Linux box >then. Mac users are largely happy with what they have, if only it'd run >stably, in protected memory with pre-emptive multitasking. > >: >It will be >: >interesting to see how Apple resolves this. Perhaps some add-on Unix >: >compatibility, even from a 3rd party. >: >: And lets not forget it will be free. > >Last time I heard OpenStep was far from free. It really sounds like you >want Linux. I doubt you'll be happy with the outcome, because the OS is >going to cost > $100 with or without complete BSD. > No, what I want is OpenStep/Rhapsody. But crippling power users for the purpose of protecting the naive (instead of altering the method they would use or be able to access the dangerous stuff) is stupid. As I said, I don't have anything against commercial products, hell, its the market I'm in. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: "David Every" <dke@adnc.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 97 07:24:07 +0000 Organization: adnc.com Message-ID: <AF0F659F-2158C@207.158.13.129> References: <5cc533$drv@dailyplanet.wam.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable nntp://news.adnc.com/comp.sys.next.advocacy, nntp://news.adnc.com/comp.sys.mac.advocacy, nntp://news.adnc.com/comp.sys.mac.system > Clone sales were estimated at between 350,000 to 500,000 units. Power > Computing is rumored to have sold a bulk of that number. Motorola > only started shipping machines in late 1996, Daystar sold about 5000 > boxes (mostly high end multi-cpu configs) APS and Umax? haven't heard > much about them at all. Do you have any idea where a 5.1 Million number > could be reached? Since I was the originator of that post (dont know how someone else got credit/blame) I can tell you where I read it - it was in a Dialy Professional Mac Journal I get - called MDJ (Mac Daily Journal). They were talking about MacOS sales (which included clones) and they mentioned the 5.1 million number over the 4.6 million the year before. -- David K. Every MacKiDo Warrior - The Power of the Macintosh Way! -- =A91997 DKE. Non-exclusive, royalty free license to distribute is granted to any service provider except Microsoft. By distributing this, Microsoft agrees to pay $1,000 per posting.
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 1997 15:08:30 GMT Organization: Airwindows Message-ID: <jinx6568-2501971010560001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> <Amta8De00iV_M6IB5S@andrew.cmu.edu> In article <Amta8De00iV_M6IB5S@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > > Ports of apps from Unix to Rhapsody? > Sure hope so. Doesn't any Mac user see some advantages to being able to > run your own personal web server on your own machine, or to be able to > send and receive electronic mail quickly and efficiently? We already can do all those things, just not on the scale you're thinking of :) Try 'run TinyMuck server software, IRC server software, a small net _backbone_ or a mail _router_ ' for a more accurate description of what we would be gaining. No sense in acting like we don't have any of that as we do have personal web servers available, and lord, can we ever do E-mail quickly and efficiently, by standards sendmail doesn't even address such as clarity of design and smoothness of operation :) and of course the ever popular live links to all sorts of net content in the E-mail :) We have 'personal' type stuff. We'll be gaining 'industrial-strength' type stuff. Jinx_tigr (aka Chris Johnson)
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 1997 15:26:18 GMT Organization: Airwindows Message-ID: <jinx6568-2501971028450001@news.sover.net> References: <32E3D1EA.7F8F@exnext.com> <AF0E1ECF-469D3@207.158.13.24> <omuFJuW00iV243UoxE@andrew.cmu.edu> In article <omuFJuW00iV243UoxE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > I am not saying that Apple should be strictly motivated by money, but > the possible financial value of a market is far more important than raw > marketshare in terms of numbers of users. Marketshare _times_ the > per-seat profit (or net worth, or invested capital, or whatever similar > measure you want to use) is a better estimate of the importance of a > market. For all that Apple sells far more Macs per year than Sun sells > SPARCstations, Sun is a bigger company because the Unix server market is > worth a lot more per seat. Is this actually true? If so, Apple could be looking at potentially high revenues out of sales of the very same extremely high-end machines that have always sold for Apple (or new ones made even more high-end for the purpose) Jinx_tigr (aka Chris Johnson)
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 1997 15:37:59 GMT Organization: Airwindows Message-ID: <jinx6568-2501971040260001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> <jinx6568-2401971226320001@news.sover.net> <32E91CBE.56EF@exnext.com> In article <32E91CBE.56EF@exnext.com>, jon@exnext.com wrote: > NeXTSTEP's Open and Save panels default to your home directory, > IIRC. So storing Edit documents in /NextApps would be more > work than putting them in ~/Library, since you'd have to do > more browsing to get there. Ah- that helps explain it. I _can_ set up my Mac to default to 'documents' or something, but instead I've always had each app default to the last folder used while in the app, which really reinforces my arguably odd organizational procedures :) the control panel for doing this is 'General Controls' by the way, for the few who aren't already going 'I knew that, don't condescend to me' ;) Often this means that there is no browsing at all- I go to an app which I've not used that much, and bam, it is anticipating me because the last time I used it I was geared to a particular task and area. Similar task- same area- no browsing. I bet they keep this as an option (which it currently is). Jinx_tigr (aka Chris Johnson)
Newsgroups: comp.sys.next.programmer From: stes@cwi.nl (David Stes) Subject: Sorting in Objective C Message-ID: <E4Ko8o.Ks7@cwi.nl> Sender: news@cwi.nl (The Daily Dross) Organization: CWI, Amsterdam Date: Sat, 25 Jan 1997 16:24:24 GMT Michael Hudson <sorry.no.email@nowhere.com> wrote: > OK. Can you write me a short bit of code that would sort an > array of any type in Objective-C? > (I don't really want a complete quicksort algorithm, but > somethnig that shows it would be possible) A style that I personally like, is sorting NOT by working inplace on the data, but by using a Class ... that sorts (Tree in the code below). id sortThem(id aCollection) { id sorted,elements,anElement; sorted = [Tree new]; elements = [aCollection eachElement]; while (anElement = [elements next]) [sorted add:anElement]; elements = [elements free]; return sorted; } This works because the |add:| message will send a |compare:| message to figure out where to put "anElement". It's also possible to create a Tree that uses a different selector as sorting criterium (sorted = [Tree newSel:@selector(dictCompare:)];) for instance. Actually the code above could be done shorter, now that I'm thinking of it. id sortThem(id aCollection) { return [[Tree new] addContentsOf:aCollection]; } The one liner above will sort the objects in "aCollection". Once you have the objects in sorted order, and if you'd want them as a _collection_ (where you could use an offset index, which you can't for a Tree), then [[Collection new] addContentsOf:aTree]; would do the trick. And if you'd like to remove duplicate entries, [[Set new] addContentsOf:aCollection]; One thing that would be really "cool", is having Block objects instead of just selectors for sorting. sorted = [Tree newSortBy:|id a,b; return [b compare:a];|] for a reverse compare. In this case, you can still get away easily by just passing along a selector, but I think even here the block syntax is nicer. Anyhow to be clear, the |...| syntax that I've used above isn't part of Objective C (currently). David.
From: robert@amo.mit.edu (Robert Lutwak) Newsgroups: comp.sys.next.programmer Subject: Writing a Mail.app bundle Date: 25 Jan 1997 16:58:29 GMT Organization: Erol's Internet Services Message-ID: <5cde3l$ik8@boursy.news.erols.com> Hi. I'd like to write a Mail.app bundle. Can somebody point me to some documentation to get started ? Thanks, Robert -- Robert Lutwak robert@amo.mit.edu
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 23 Jan 1997 02:17:40 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5c73ak$ics@csugrad.cs.vt.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> In article <maury-2001971522480001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5bshs8$e5n@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > (Win-like???? Are we talking about the same Windows? You know, that > > operating system that likes to dump files everywhere on your drive? > > Windows does NOT have a mandatory Applications folder or anything like > > that.) > How can you possibly say that after blasting me over not wanting /bin on > my drive! Easy. Go back and read your original statement. You said something to the effect that keeping everything in the same place was "Win-like". That is NOT Win-like. Unix /bin directories have nothing to do with Windows' behavior for placing files. > > I don't understand why you want to scatter your applications all over > > the filesystem. > Because it's MY file system. You don't have to like it, do what you wish. Not if it requires making compromises. NEXTSTEP has its restriction on file placement so it doesn't have to search the entire filesystem for things. Alternatives include keeping a database of locations or restructuring the filesystem to use file IDs, all of which have downsides in multiuser systems, efficiency, etc. > > I don't know anyone who does this. Even the Mac > > people tend to put everything in the Applications folder or a > > subdirectory of it. > Balogna, I can't think of a single Mac I've every had the pleasure of > using that had all of it's programs arranged such, and that's a large > number of Macs (in the hundreds). That's just _wrong_. Then I'm afraid I'm going to have to call you an idiot. Who are you to tell me what the Mac users I know do??!! I know a number of Mac users, and my summer job for the last few summers was at a completely Mac office, and when I say that "I don't know anyone who does this", I mean, _I don't know anyone who does this_. All of the Mac users I know either put things in the Applications folder (or a subdirectory thereof), or partly in the Applicatins folder and partly on the Desktop. Care to play any other mind-reading games? -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Concerning Function Overloading in Obj-C.(Re: Multiple Inheritance) Date: Sun, 26 Jan 1997 12:38:36 -0500 Organization: Demiurge Development Group Message-ID: <32EB969C.72DA@friday.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5c7vug$4s4@csugrad.cs.vt.edu> <SHESS.97Jan23151627@slave.one.net> <jchan-ya023580002401972255270001@news.apk.net> <5ccaka$n27@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit But [within objective-c] there are a number of ways to do control flow based on object type or based on what functionality the object supports. some examples: Assuming you have a method like: - eatObject: anObject { ... CODE HERE ... } The ... CODE HERE ... part could contain flow control like: * switch on membership within a specific class: if ([anObject isMemberOfClass: [NSArray class]]) { ... it's an NSArray ... } else if ... * switch on membership within a specific class or subclass of said class: if ([anObject isKindOfClass: NSClassFromString(@"NSView")]) { ... it's a view of some kind ... } * switch on the fact that it implements a specific method: if ([anObject respondsToSelector: @selector(performCalculation:with:)]){ ... it implements -performCalculation:with: ... } * switch on the fact that it implements some protocol (a protocol is a collection of methods. Conformance to a protocol means that an object implements all of the methods in the protocol. IN distributed objects, not only can a proxy (a representation of an object within a remote runtime) conform to a protocol, it can be limited to ONLY responding to methods from a protocol)): if ([anObject conformsToProtocol: @protocol(ProcessRFC822MessagesP)]) { ... it implements the RFC822 processing protocol ... } And remember, since it is objective-c, all of the above flexibility is available for any class in the runtime-- be it one linked into the system libraries, one that was dynamically loaded at runtime, or one that created on-the-fly by the program... b.bum Nathan M. Urban wrote: > > In article <jchan-ya023580002401972255270001@news.apk.net>, jchan@apk.net (Jerome Chan) wrote: > > > Can't we just pass the parameter as an id object and then do a switch based > > on the object type? > > No, the object type isn't an ordinal. You can't switch on it, just like > you can't switch on strings. > -- > Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Bill Bumgarner <bbum@friday.com> Newsgroups: comp.sys.next.programmer Subject: Re: Sorting in Objective C Date: Sun, 26 Jan 1997 13:31:11 -0500 Organization: Demiurge Development Group Message-ID: <32EBA2EF.A40@friday.com> References: <E4Ko8o.Ks7@cwi.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Within the foundation kit, NSArray already has API for sorting objects-- there is no need to implement your own sorting algorithm unless you have some collection of objects for which the built-in sorting algorithm just ain't good enough. Since you define the comparison function or method, the built-in algorithm is 'good enough' for 99% of all cases where you need to sort an array. - (NSArray *)sortedArrayUsingFunction:(int(*)(id element1, id element2, void *userData))comparator context:(void *)context Returns an array listing the receiver's elements in ascending order as defined by the comparison function comparator. context is passed to the comparator function as its third argument. - (NSArray *)sortedArrayUsingSelector:(SEL)comparator Returns an array listing the receiver's elements in ascending order, as determined by the comparison method specified by the selector comparator. -- So, assuming 'theArray' points to the array you wish to sort, and all of the objects within that array implement the method -compare: (a bunch of the foundation kit objects already do; like NSString and friends). You could: sortedArray = [theArray sortedArrayUsingSelector: @selector(compare:)]; Now-- if you had an array that contained a bunch of objects for which may not implement the sorting method... or may implement a variety of comparison methods (which, btw, would be an indication that someone wasn't following the suggested rules when defining their API :-), you could: int compare_func(id obj1, id obj2, void *context) { // if they both have compare:, compare 'em... if ([obj1 respondsTo: @selector(compare:)] && [obj2 respondsTo: @selector(compare:)]) return [obj1 compare: obj2]; // ok-- figure out how to compare 'em here and return -1 for // obj1 < obj2, 0 for obj1 == obj2 and 1 for obj1 > obj2 // (whatever) return 1; } b.bum
From: pbrown@ashkhabad.berkeley.edu (Paul R. Brown) Newsgroups: comp.sys.next.programmer Subject: Re: BASIC on NeXT? Date: 25 Jan 1997 19:06:49 GMT Organization: University of California, Berkeley Message-ID: <slrn5eklo4.30l.pbrown@ashkhabad.berkeley.edu> References: <glen_stewart-2401972320070001@stewart-3.pnet.msen.com> In article <glen_stewart-2401972320070001@stewart-3.pnet.msen.com>, Glen Stewart wrote: >Anyway, I'd love to be able to do BASIC programming in UNIX. Does anyone >here know if there is such a compiler available? GCC seems to be just >about everywhere (even on the Mac68k port), but BASIC is what I really >prefer. Well, if you *must*, then you have two choices. One is to write your own BASIC interpretter in C as an exercise (it's easy, really!), and the other is to grab the p2c distribution, a pascal -> c converter, which comes with just such a program. Paul
From: apuleius@ix.netcom.com (William Grosso) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Sat, 25 Jan 1997 19:05:09 GMT Organization: Netcom Message-ID: <32ea560c.2161748@nntp.ix.netcom.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> <milkweed-1801971759130001@port5.chester.smallmedia.com> <32E3A1E1.7BC@nowhere.com> <5c0ivv$7e4@gaea.titan.org> <32E64EF7.3D6A@nowhere.com> <5c7es1$7bc2@ddfservb.technet.net> <32E801FB.4475@taligent.com> On Thu, 23 Jan 1997 16:27:42 -0800, Rich Gillam <richard_gillam@taligent.com> wrote: > >Another point is that while the examples will work with collections of >any type, they won't (necessarily) work with collections where the >elements are of DIFFERENT types. Unless the element types define >comparison operations which compare them to not only other instances of >the same type, but to instances of any other types that are represented >in the collection (amd which are commutative), you'll either get bogus >results or a runtime exception. There is no way (I think) to define a >collection such that it is guaranteed to hold only instances of a >certain type. > Sure there is: add a method named something like - (void) setPrototype: (id) objectType allowSubclasses:( BOOL) subclassesAllowed which accepts an object and stores the class object corresponding to it. Then when things are added to the array, a quick check (either "do you instantiate this class" or "do you instantiate a subclass of this class") and you're done. If you really want to be sticky, use - initWithPrototype: (id) objectType allowSubclasses:( BOOL) subclassesAllowed and over-ride the standard init to throw an exception. That'll force the user to start with a typed array. You can also do this with selectors (pass in a selector which must be implemented by the object) or protocols (pass in a protocol object) or you could say to hell with it and just have your array use another object. E.g. the array implements - (void) setCheckingObject: newChecker; and newChecker implements the method - (BOOL) validateNewArrayEntry: (id) objectToValidate; This lets us do lots of neat stuff (you can type your array using an arbitrary predicate). Cheers, Andy "In the beginning, everything was even money" --Mike Caro
From: jq@papoose.quick.com (James E. Quick) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mach-O and localization, was Re: Apple-NeXT Conflicts? Followup-To: comp.sys.mac.advocacy,comp.sys.next.advocacy Date: 18 Jan 1997 12:44:59 -0500 Organization: PHCS Message-ID: <5br26r$h4o@papoose.quick.com> References: <petrichE3Ct2r.3AJ@netcom.com> <maury <maury-1401 <maury-1601971527030001@199.166.204.230> In article <maury-1601971527030001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <0mrHfT600iV945m0Ei@andrew.cmu.edu>, Charles W Swiger ><cs4w+@andrew.cmu.edu> wrote: > >> multiple sections supported by Mach-O are a straightforward extension of >> the venerable a.out format, which had precisely three sections: TEXT, >> DATA, and BSS. > > Ahhhhhhh. So (you see this coming), why did it stop there? Because that is all that was needed. a.out is a format for executable images - the output of a compiler. The TEXT section contained the actual machine code which is executed by the CPU. The DATA section contained all pre-initialized data. The BSS section contained all other data statically allocated global data space. BSS was separate from data to cut down on executable size, since pages of bss could simply be grabbed from the VM subsytem when needed. This discussion of Mach-o is entirely out of context. Mach-o, like a.out, is an executable image format. It specifies how the operating system organizes, loads, and addresses components of executable images running on the system. It is true that mach-o provides a similar set of functionality to Resource and Data forks under MacOS. But the underlying purpose of this format is different. p.s. Follow-ups have been trimmed as it is not appropriate to cross-post this the c.s.n.programming groups. -- ___ ___ | James E. Quick jq@quick.com / / / | Private HealthCare Systems NeXTMail O.K. \_/ (_\/ | Systems Integration Group (617) 895-3343 ) | "I don't think so," said Rene Descartes. Just then, he vanished.
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 25 Jan 1997 19:22:10 GMT Organization: Netcom Distribution: world Message-ID: <5cdmh2$j7f@dfw-ixnews11.ix.netcom.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <32E8F5E9.2620@nowhere.com> Michael Hudson <sorry.no.email@nowhere.com> wrote: > I can think of another reason why C++ took off, rather than Objective-C: > That looks nothing like C. > C++ code (unless it's very templatey) looks much like C. > I have never coded in pure C, but I'd say that the fact that C++ can > look like C must have made the transition less scary for many people. I think that your perceptions are biased because you know C++ and didn't come from a C background as I did. I used to follow the monthly "C++ Adviser" articles in _Unix Review_ as a means of trying to understand C++. Initially, I could understand what was happening because the syntax was very C-like. But as more and more syntactic additions to C++ occurred, I became less able to follow what was happening and finally quit reading the articles. For example, the frequent use of & in seemingly odd places is very confusing to me just as the use of [ and ] in Objective-C in seemingly odd places would be confusing to C programmers. But I'd be willing to wager that if a C programmer was handed a complex C++ code sample using most of the C++ language features and a similar Objective-C code sample, the confusion level would be similar. But I'd also be willing to wager that the C programmer could learn Objective-C MUCH faster than C++. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.lang.eiffel Subject: Re: NextStep & Mac Frameworks Date: 25 Jan 1997 19:29:09 GMT Organization: Netcom Distribution: world Message-ID: <5cdmu5$j7f@dfw-ixnews11.ix.netcom.com> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> <milkweed-2201972301440001@port10.chester.smallmedia.com> <32E85082.37DE@acm.org> Ian Joyner <i.joyner@acm.org> wrote: > Perhaps someone should encourage Metrowerks to get together with > an Eiffel compiler vendor or someone willing to write an Eiffel > compiler for CW. It sounds like they would be a really good match. > Having already written an Eiffel compiler in Pascal, I'm willing > to volunteer. IDE (or whatever Bertrand Meyer's company is called) has offered an Eiffel development environment for NEXTSTEP in the past. Not sure if an OPENSTEP version is available, but it probably wouldn't be too difficult to convert the NEXTSTEP version. If IDE offered Eiffel for the small NEXTSTEP market, they are likely to offer a version for the much larger Rhapsody market. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 18 Jan 1997 18:11:52 GMT Organization: Netcom Distribution: world Message-ID: <5br3p8$o2i@dfw-ixnews4.ix.netcom.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> <milkweed-1801970222100001@port5.chester.smallmedia.com> milkweed@plainfield.bypass.com (Anders Pytte) wrote: > So what kind of relationship exists between the number of methods in a > class, the depth of subclassing, and the time to resolve a method call? The number of methods shouldn't have any performance implication because the methods are hashed. The depth of subclassing probably directly affects the time to resolve a method call the first time a method is invoked on an object (or probably on any instance of a class), but because of method caching, the resolution time of subsequent invocations probably isn't proportional to subclassing depth. I don't know how method caching is implemented, but I've read that the average method invocation, although somewhat slower than a C function call, isn't much slower (whatever "much" means :-) > C++ _is_ getting old. But I don't think Java was designed for the purpose > of creating large class libraries or large or time-critical systems (even > aside from the fact that it is currently implemented as an interpreted > language). It's design - like Obj-C - reflects restrictive requirements of > an underlying layer as well as the latest thoughts about good programming. I suspect that compiled Java will evolve into a general object-oriented programming language that will gradually displace C++. As you've noted, much of the power of languages involves their libraries, and Java doesn't have those yet. > In some ways C++ is more pure and abstract because you don't worry about > the runtime overhead of creating objects of any little thing and stacking > zillions of them in a list (with compile-time binding most such methods > duck the virtual tables). I guess if I were to use Obj-C/Next I would > still do part of my development in C++. Objective-C supports ducking the message dispatch process as well. Programmers can ask for the pointer to the function that implements a method and use that if performance is an issue such as in large loops. There's no reason why C++ programmers wouldn't continue to use their C++ code and their C++ skills to write Model and maybe Controller classes in C++. > I think the idea of building an OS as an extensible class library is > superb, and my sense is that _that_ is what makes Next/OpenStep such a > dynamite environment, more than a particular choice of language. I can see > that Obj-C was designed to support just such an arrangement - would be > much messier with C++. Most of the advantages of Obj-C that have been > pointed out to me bear directly on this arrangement. Bingo! You've got it! > But this is a different issue than merely comparing the features of two > languages. Indeed, how often do we choose languages just on the basis of > their ideal qualities, abstracted from the realities of our enterprises? > Next has delivered a solution more than a language. > > The advantages of Obj-C don't seem as striking outside of that context. But we're talking about Rhapsody development, aren't we? This will use OPENSTEP libraries and their extensions (Apple technologies). So Objective-C should be pretty striking in this context. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: chao@copland.udel.edu (John David Chao) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 18 Jan 1997 16:01:39 -0500 Organization: University of Delaware Message-ID: <5brdnj$65l@copland.udel.edu> References: <AEEFE2B6-491909@204.246.66.19> <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <milkweed-1501970042260001@port5.chester.smallmedia.com> <kmrG7VK00iV945mAVH@andrew.cmu.edu> Charles W Swiger <cs4w+@andrew.cmu.edu> said: >Sure. Obj-C itself does not support MI or operator-overloading, but >Obj-C++ does. People using pure Obj-C generally seem to use forwarding I haven't heard of Obj-C++. Is Metrowerks going to have a compiler for it? How does it compare to Obj-C?
From: john_zollinger@arkona.com (John Zollinger) Newsgroups: comp.sys.next.programmer Subject: Re: Can one inherit from a class cluster? How? Date: Sat, 25 Jan 1997 20:45:48 GMT Organization: Arkona, LLC Message-ID: <32ea7027.61233939@news.xmission.com> References: <5c60fj$40qc@news.doit.wisc.edu> giddings@menominee.chem.wisc.edu (Michael Giddings) wrote: > >I was trying to implement a subclass of NSData that had an extra instance >variable in it designating the endian-ness of the machine it originated on >(so I could convert it appropriately when using Distributed Objects across >different architectures). The problem is, I can't seem to create a subclass >of NSData because it isn't really a class - it's a class cluster (it doesn't >give an error until I try to create an instance of the subclass at runtime, >then it fails). > >Has anyone run into this problem? A solution? > >The kluge I am using right now is just having another container object that >holds an NSData object. But there are a number of inconveniences in this >approach. Advice appreciated. Take a look at: http://www.next.com/NeXTanswers/HTMLFiles/2003.htmld/2003.html And look for the section titled: "CLASS CLUSTERS" towards the end. It tells you all about the class clusters and the steps necessary for doing what you want. Good luck, John Zollinger Software Engineering Director Arkona, LLC john_zollinger@arkona.com
From: no_spam@Glue.umd.edu (David T. Wang) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 25 Jan 1997 17:11:06 GMT Organization: University of Maryland, College Park, MD Message-ID: <5cdera$hli@dailyplanet.wam.umd.edu> David Every (dke@adnc.com) wrote: : > Clone sales were estimated at between 350,000 to 500,000 units. : Power : > Computing is rumored to have sold a bulk of that number. Motorola : > only started shipping machines in late 1996, Daystar sold about 5000 : > boxes (mostly high end multi-cpu configs) APS and Umax? haven't : heard : > much about them at all. Do you have any idea where a 5.1 Million : number : > could be reached? : Since I was the originator of that post (dont know how someone else : got credit/blame) I can tell you where I read it - it was in a Dialy : Professional Mac Journal I get - called MDJ (Mac Daily Journal). They : were talking about MacOS sales (which included clones) and they : mentioned the 5.1 million number over the 4.6 million the year before. Upgrades? perhaps upgrades from Sys 7.1 to 7.5 counted as a sale? : -- : David K. Every : MacKiDo Warrior - The Power of the Macintosh Way! : -- : =A91997 DKE. Non-exclusive, royalty free license to distribute is : granted to any service provider except Microsoft. By distributing : this, Microsoft agrees to pay $1,000 per posting.
From: soroos@u.washington.edu (Eric Soroos) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 25 Jan 1997 14:07:23 -0800 Organization: The Bungled and the Botched Message-ID: <soroos-ya023080002501971407230001@news.u.washington.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> <Amta8De00iV_M6IB5S@andrew.cmu.edu> <jinx6568-2501971010560001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <jinx6568-2501971010560001@news.sover.net>, jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) wrote: > Try 'run TinyMuck server software, IRC server software, a small net >_backbone_ or a mail _router_ ' for a more accurate description of what we >would be gaining. No sense in acting like we don't have any of that as we >do have personal web servers available, and lord, can we ever do E-mail >quickly and efficiently, by standards sendmail doesn't even address such >as clarity of design and smoothness of operation :) and of course the ever >popular live links to all sorts of net content in the E-mail :) > We have 'personal' type stuff. We'll be gaining 'industrial-strength' >type stuff. Procmail. I want procmail. Badly. eric - Current procmail setting: "toast lightly" -- soroos@u.washington.edu http://www.ce.washington.edu/~soroos
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 25 Jan 1997 20:51:41 GMT Organization: Global Objects Inc. Message-ID: <5cdrot$616@news.xmission.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> milkweed@plainfield.bypass.com (Anders Pytte) wrote: > But i have a few concerns. Using categories do i have access to private > members? If so, I see a danger, in that I could develop a set of > categories which would become invalid when the purveyer of my library > modified private data or method members. This _is_ a problem. Whenever you do something that is so tightly coupled to other code, you get into trouble. Of course, it depends on how tightly coupled you category code is--you can write it so that it goes via accessor methods and non-privates (taking a slight performance hit) and then it will be pretty well isolated from changes in the library. Of course, if you're using this to work around bugs, a new library release may obsolete your category any way, so it really depends upon the specific case as to how much of a problem this really is in practice. > More often I have wanted to modify the behavior of an existing method in a > base class (say there is a bug in the library). Is there any way I do that > in Obj-C? Or would I need to change the library source? No messing with the library source at all; you just use a combination of categories and/or -poseAs: (wich to use depends on what exactly you're trying to do) and you can get around just about anything--you can even play stunts like completely altering how GUI objects are rendered throughout your app, etc. (There's a hack out there that will turn all your app's windows into the style of the unreleased 4.0 PR1 GUI. :-) It uses the -poseAs: mechanism.) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 25 Jan 1997 20:51:19 GMT Organization: Global Objects Inc. Message-ID: <5cdro7$616@news.xmission.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <32E8F5E9.2620@nowhere.com> Michael Hudson <sorry.no.email@nowhere.com> wrote: > Nathan M. Urban wrote: > > [...Objective-C code...] > > I can think of another reason why C++ took off, rather than Objective-C: > That looks nothing like C. > C++ code (unless it's very templatey) looks much like C. > I have never coded in pure C, but I'd say that the fact that C++ can > look like C must have made the transition less scary for many people. While I agree that this is a _possible_ reason, it is also very, very sad. Why? When you move from a procedural language to an OOP language, you have to learn some _very_ different concepts. By retaining similar syntax, C++ makes it difficult to sort out which concepts are which, in the long run making things more confusing for a person learning a new paradigm. In Objective-C the two different paradigms are quite apparent; you know which is which at a glance just by looking at the code. Additionally, C++, by virtue of the explosion of new features over C (the syntax additions are legion in number) is actually _harder_ to learn than Objective-C, which has about 20 changes, if that! It may _look_ different, but it is closer to C than is C++, if you look at the language's grammar. Ironic, isn't it? Still, the way C++ "looks" more like C may well have made it seem less intimidating initially to many people--even though in reality Objective-C is much easier to learn. As a person who has learned both languages, I assure you Obj-C is a lot easier to learn and deal with. :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: font@MCS.COM (Font) Newsgroups: comp.sys.next.programmer Subject: Re: BASIC on NeXT? Date: 25 Jan 1997 19:22:00 -0600 Organization: MCSNet Services Message-ID: <5cebjo$h75$1@Venus.mcs.net> References: <glen_stewart-2401972320070001@stewart-3.pnet.msen.com> <slrn5eklo4.30l.pbrown@ashkhabad.berkeley.edu> pbrown@ashkhabad.berkeley.edu (Paul R. Brown) writes: >In article <glen_stewart-2401972320070001@stewart-3.pnet.msen.com>, Glen Stewart wrote: >>Anyway, I'd love to be able to do BASIC programming in UNIX. Does anyone >>here know if there is such a compiler available? GCC seems to be just >>about everywhere (even on the Mac68k port), but BASIC is what I really >>prefer. >Well, if you *must*, then you have two choices. One is to write your >own BASIC interpretter in C as an exercise (it's easy, really!), and >the other is to grab the p2c distribution, a pascal -> c converter, >which comes with just such a program. I seem to recall that porting the Bywater BASIC interpreter to NEXTSTEP wasn't difficult, but I don't recall where the Bywater BASIC interpreter can be found. However, there is a FreeBSD port of it which should refer one to the archive site (check from http://www.freebsd.org). -- font@mcs.net Wishes are like dishes.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 18 Jan 1997 06:30:31 GMT Organization: Global Objects Inc. Message-ID: <5bpqm7$lul@news.xmission.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5blksl$ruc@news.next.com> <milkweed-1601971618480001@port10.chester.smallmedia.com> <milkweed-1701970806260001@port5.chester.smallmedia.com> <5boc53$kft@dfw-ixnews11.ix.netcom.com> <milkweed-1701971832020001@port12.chester.smallmedia.com> <32E032F1.3D7@afs.com> "Gregory H. Anderson" <greg@afs.com> wrote: > That said, I really don't miss MI, whether or not someone thinks I would > be better off without it. I find objects-owning-objects (which I > described the other day) and delegation/forwarding sufficient. Ya know, the GOF book (Patterns book mentioned here earlier) even says that object composition is more important than inheritance. Which is what the Obj-C people have been saying all along. And that book is written from more of a C++ viewpoint, but it is also written by some people who really know what they are talking about! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: NeXT OS: Porting a UNIX app ? Date: Thu, 23 Jan 1997 14:10:01 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E4Gsoq.Boo@cam-ani.co.uk> References: <maury-2001971801140001@199.166.204.230> In article <maury-2001971801140001@199.166.204.230> maury@softarc.com (Maury Markowitz) writes: > I ran a lab of them. Sun 3/50's, based around the 68030. 3/50 = 68020 4Meg Ram 3/60 = 68020 up to 24Meg Ram 3/80 = 68030 Not THAT slow if you set them up right, and have realistic expectaitions of what they can do. $an
From: frank@this.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer Subject: Re: BASIC on NeXT? Date: 26 Jan 1997 01:10:04 GMT Organization: NO ORGANIZATION, INC. Message-ID: <5ceatc$sss@bias.ipc.uni-tuebingen.de> References: <glen_stewart-2401972320070001@stewart-3.pnet.msen.com> <slrn5eklo4.30l.pbrown@ashkhabad.berkeley.edu> Cc: pbrown@ashkhabad.berkeley.edu In <slrn5eklo4.30l.pbrown@ashkhabad.berkeley.edu> Paul R. Brown wrote: > In article <glen_stewart-2401972320070001@stewart-3.pnet.msen.com>, Glen Stewart wrote: > >Anyway, I'd love to be able to do BASIC programming in UNIX. Does anyone > >here know if there is such a compiler available? GCC seems to be just > >about everywhere (even on the Mac68k port), but BASIC is what I really > >prefer. > > Well, if you *must*, then you have two choices. One is to write your > own BASIC interpretter in C as an exercise (it's easy, really!), and > the other is to grab the p2c distribution, a pascal -> c converter, > which comes with just such a program. > Look in the comp.sources.[misc|unix] archive, there are several basic interpreters available in source. You have to recompile them yourself. And not even think about a GUI :-)... -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <luomat@nerc.com> Message-ID: <199701250636.BAA05669@nerc.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Timothy J Luoma <luomat@nerc.com> Date: Sat, 25 Jan 97 01:36:50 -0500 Subject: Need a little C-help Organization: Princeton Theological Seminary I would like to change this bit of code for PPP I can't read C much, so I'm floundering here. Lines 16-20 are the ones which control the bringing down of the link if the idle time has been met. I would like to replace the existing code with code which will: 1) send a message to /dev/console saying "Idle time exceeded, bringing down link" 2) execute "/usr/local/bin/pppdown" (preferably with the UID and GID of use who started this all, but that isn't crucial) 1 /* 2 * check_idle - check whether the link has been idle for long 3 * enough that we can shut it down. 4 */ 5 static void 6 check_idle(arg) 7 caddr_t arg; 8 { 9 struct ppp_idle idle; 10 time_t itime; 11 12 if (!get_idle_time(0, &idle)) 13 return; 14 itime = MIN(idle.xmit_idle, idle.recv_idle); 15 if (itime >= idle_time_limit) { 16 /* link is idle: shut it down. */ 17 syslog(LOG_INFO, "Terminating connection due to lack of activity."); 18 need_holdoff = 0; 19 lcp_close(0, "Link inactive"); 20 } else { 21 TIMEOUT(check_idle, NULL, idle_time_limit - itime); 22 } 23 } 24 Please note that this "idle" feature of PPP is purely voluntary -- a user DOES NOT have to set an idle time for themselves. My ISP has a 30 minutes idle time, and I would be using this to restrict my idle time to 5 or 10 minutes (which I can do without altering any C code, but just using the "options" file for PPP. However, I cannot effectively do that unless I can get a little more control over what happens when the idle time is reached. In Sum: this will allow me to free up a link to my ISP faster than if I cannot change this. Any help appreciated. TjL ps -- can anyone recommend a good "C for Dummies"-like book? I've made it 5 years using a NeXT without knowing any C or perl, but it looks like that might have to change. -- Tj Luoma (luomat@peak.org) If you have a web page about NeXTStep|OpenStep, email me the URL!
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 25 Jan 1997 20:44:16 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5cenf0$jen@crl.crl.com> References: <maury-0801971641590001@199.166.204.230> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1bm1$nhr@duke.squonk.net> <5c46rq$84c@geraldo.cc.utexas.edu> In article <5c46rq$84c@geraldo.cc.utexas.edu>, William Raphael Hix <raph@porter.as.utexas.edu> wrote: >Your use of tar seems predicated on a Rhapsody software distribution >system like most of Unix. Are you expecting lots of "here's the source >code now compile it yourself" apps ported from Unix to Rhapsody? >It's fundamental differences in expectations between the Mac and NeXT >communities which fuel this thread. Yes, there should be a lot of compile it yourself apps for Rhapsody. Most users won't see it, though. It wouldn't surprise me at all to see Apache, new versions of Bind, multicast routers, and other gizmos running on Rhapsody. It's a useful personal machine with plenty of shrink-wrapped apps, and it's a unix machine that does all sorts of unix things. The two markets are distinct, though, so most of group A won't know that group B exists. -- Don McGregor | "If C++ is your hammer, then every problem looks mcgredo@crl.com | like a thumb." -- will@dyson.microserve.com
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 23 Jan 1997 11:45:16 -0600 Organization: mementech, inc. Message-ID: <32E7A3AC.36B92050@screaming.org> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <AF0B6C4A966812791F@node26.tfs.net> <32E655AD.55D3@exnext.com> <32E78E99.1289@globalserve.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Drone wrote: > Jonathan W. Hendry wrote: > > > > No, the Mac GUI does not let you do *everything*. If there is something > > that is not in the GUI, you *cannot* do it. Unless, of course, some > > nice programmer comes along and writes a program that lets it happen. > > > > Well, DUH! Excellent! This is exactly the kind of honesty I'd like to hear more of from the Mac community. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: "Burton William Schlatter" <skateboy@walrus.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: PROPOSAL: how to implement Mac in Nextstep part 2 Date: Sat, 25 Jan 1997 22:51:38 -0500 Organization: Intellitech Corporation Message-ID: <skateboy-2501972251380001@p25.ts1.walrus.com> References: <5amli2$ol3@news.tuwien.ac.at> <E4Dsqs.6Cx@micmac.com> <5c7juq$7n5@news.tuwien.ac.at> <5c93k6$l5c@news3.digex.net> In article <5c93k6$l5c@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> wrote: > Yes, but ms dos, unix, and other system users are much bigger than > apple's market of say around 5million users with hardware capable > of running the upcoming OS. Yes, but as a Mac-only guy I eagerly await the more sophisticated NeXT approach to the UI, and I hope to see a lot of it ported over to Rhapsody. In fact, without knowing it, I've set my Finder up to be startlingly like what little I know of the NeXT UI. I used (use) Greg's Browser LONG before I heard it was based on NeXT's File Viewer, and I like it greatly. NeXTfolks/NeXTdevelopers: Don't sell your potential contribution to the MacOS short. Push for what you know to be better than what exists presently in the MacUI. If it's truly better, we'll (the Mac User community) know. Personally, I think that NeXT's UI concepts are exactly the kind of shake-up the MacOS needs. I mean, Gates needs SOMETHING to copy! ------------------------------------------------------ skateboy@walrus.com --- burt@wfmu.org ------------------------------------------------------
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Hard Drive as Folders? (was Re: MacWorld Exclusive: Apple's OS Plan) Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 19 Jan 1997 20:59:06 GMT Organization: ace dot net internet technologies Message-ID: <5bu1uq$hrc@darla.visi.com> References: <5ami95$ol3@news.tuwien.ac.at> <5b7ur5$oks@bignews.shef.ac.uk> <5bbv1d$c66@csugrad.cs.vt.edu> <jinx6568-1601971429460001@news.sover.net> <5bsipf$l4g@csugrad.cs.vt.edu> <32E1C3C0.3E5A@washdc.mindspring.com> Mike (indigo2@washdc.mindspring.com) wrote: : I'm not so sure I understand this completely. Tell me if I'm wrong, but : if this is the case, then I could have four 2Gb hard drives all mounted : at the same place in the file system and it would appear that I have one : 8Gb hard drive, right? And the OS will know when one fills up and begin : using available space on the next drive? And I could just keep on : growing my hard drive? That's not exactly what he meant, but it can be done with additional software. You can't mount multiple drives to the some mount point. Using standard UNIX filesystem conventions, one drive = one mount point. Typically on a NeXT box you might see a 1G drive mounted at / for the OS and home directories, and another 1G drive mounted at /Local for user/site extensions. : Could I set things up so that, using the four drive example above, two : of the drives are a mirror of the other two? And if I pulled one of the : drives, things would keep humming along? What you're describing is called software RAID, which lets you combine multiple drives into "logical drives" which span physical disks, offer performance tuning features, mirroring, hot swapping, etc. It's something generally reserved for large scale servers, but Apple would do well to offer some sort of RAID support in the future.. : Are these just fantasies of mine because I don't understand what you're : saying? Yeah, I've kind of wished for that under NEXTSTEP a couple times. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: giddings@menominee.chem.wisc.edu (Michael Giddings) Newsgroups: comp.sys.next.programmer Subject: Re: Doesn't anyone know about power management? (Does it work under NT?) Date: 23 Jan 1997 18:45:33 GMT Organization: University of Wisconsin - Madison Distribution: world Message-ID: <5c8bkd$2cco@news.doit.wisc.edu> References: <5c1vrs$ktg@uni2f.unige.ch> <5c6ia0$go7@belzebul.imaginet.fr> Cc: pjb@imaginet.fr,dami@cui.unige.ch In <5c6ia0$go7@belzebul.imaginet.fr> Pascal Bourguignon wrote: > In article <5c1vrs$ktg@uni2f.unige.ch> dami@cui.unige.ch (Laurent Dami) writes: > > > > For info: I'm using NS on a NEC Versa P laptop, and APM works just fine. > > I just suspend/resume very often, and never met any problem. But I know > > nothing about the kernel internals, sorry. > > One more data point: > > I'm using a DELL Lattitude XPi 90 ST, and I have to disable APM for the hardisk > would not resume when it's asleep. Then I would have to power off and on, and > then the file system is no more usable, and I have to reinstall it. > > __Pascal Bourguignon__ > I've discussed this issue with quite a few people, and the only portable machines I have heard of suspend/resume working under NeXTStep are the NEC's. If anyone has another machine that works, I'd like to hear about it. Last time I got info from NeXT, they claimed it was because most of the hardware makers don't correctly implement the 32 bit power management API's, because they don't need to under Windows (3.1 or 95). This may be true. But a counter to this is the fact that I know of several who claim suspend/resume work fine under Linux. Maybe Linux can still access the 16 bit protected-mode interfaces. Or maybe the mach kernel is doing something incorrectly. It is really hard to tell who is actually responsible. That has been my biggest frustration. NeXT points at the hardware mfgs., and they point back at the OS makers. It would be interesting to know whether suspend/resume works under Windows NT on the NEC machines (or any others). That may resolve the issue of where the problem is. Suspend/resume on NT does not work on my Toshiba, which would tend to support NeXT's claim of the hardware (bios) being at fault. But maybe NT just can't handle it on any machine. Does anyone have a system that correctly suspends/resumes under Windows NT? That would help clarify this. Thanks -- Michael Giddings giddings@chem.wisc.edu giddings@barbarian.com (608)258-1699 or (608) 692-2851 http://www.barbarian.com
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <luomat@nerc.com> Message-ID: <199701250752.CAA07705@nerc.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Timothy J Luoma <luomat@nerc.com> Date: Sat, 25 Jan 97 02:52:11 -0500 Subject: "/usr/lib/libposix.a is out of date" -- why/what/help? Organization: Princeton Theological Seminary "ld: table of contents for archive: /usr/lib/libposix.a is out of date; rerun ranlib(1) (can't load from it)" Why did this happen, how can I fix it, what does it mean, did something break (if so, is it bad?) sorry, I don't know anything about this stuff, just trying to figure it out as I go along. can I rerun "ranlib" on /usr/lib/libposix.a without causing problems in the future? Thanks TjL -- Tj Luoma (luomat@peak.org) If you have a web page about NeXTStep|OpenStep, email me the URL!
From: cb@guinan.mm.se (Christian Brunschen) Newsgroups: comp.sys.next.programmer,comp.sys.next.misc,comp.sys.next.software Subject: Loginwindow Workspace hook Date: 25 Jan 1997 23:56:20 GMT Organization: - Message-ID: <5ce6j4$aim@mn5.swip.net> Keywords: loginwindow dwrite Workspace hook Hi, I am trying to start a different program than Workspace at login time. The manual page for 'loginwindow' states that dwrite loginwindow Workspace /Users/cb/bin/loginprogram should make loginwindow start /Users/cb/bin/loginprogram instead of Workspace.app at login time. I have tried doing just that. Result ? Nothing. No change in the behaviour of loginwindow. Workspace still gets started, and my program doesn't. I am running 3.3 on Black 040 hardware. If anyone has any ideas, please share them with me. A search at NeXTAnswers revealed nothing. Best regards, // Christian Brunschen -- -- Christian Brunschen cb@mm.se
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: Writing a Mail.app bundle Date: 26 Jan 1997 05:26:59 GMT Organization: Digital Fix Development Message-ID: <5cepv3$469@news.digifix.com> References: <5cde3l$ik8@boursy.news.erols.com> In-Reply-To: <5cde3l$ik8@boursy.news.erols.com> On 01/25/97, Robert Lutwak wrote: >Hi. > >I'd like to write a Mail.app bundle. > >Can somebody point me to some documentation to get started ? > Documentation? Bwaahhh ha ha ha.. sorry, but its not documented... Grab the current source for EnhanceMail from the ftp.next.peak.org archive. Thats probably the best reference. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer Subject: Re: "/usr/lib/libposix.a is out of date" -- why/what/help? Date: 25 Jan 1997 23:30:30 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ceml6$mjl@csugrad.cs.vt.edu> References: <199701250752.CAA07705@nerc.com> In article <199701250752.CAA07705@nerc.com>, luomat@peak.org wrote: > "ld: table of contents for archive: /usr/lib/libposix.a is out of > date; rerun ranlib(1) (can't load from it)" > Why did this happen, how can I fix it, what does it mean, did > something break (if so, is it bad?) I got that after I applied that big patch for NS 3.3 that came out last spring. (I think.) I had to download libposix.a off their FTP site, and I think it worked after that. I don't know what causes it. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 05:33:02 GMT Organization: Global Objects Inc. Message-ID: <5bv02e$r6r@news.xmission.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <jinx6568-1601971411390001@news.sover.net> jinx6568@sover.net (Chris Johnson) wrote: > [...] the > GNU implementations were less prone to being dumb hacks... > > Thus, I am less interested in finding out how you feel about it as I am > in asking Garance whether the standard NeXT stuff bears more resemblance > to the GNU stuff than the dumb hacks. I suspect it must resemble the GNU > or the unix-savvy NeXTians would be less confident. So, Garance, is it so? NeXT seems to have used GNU stuff where they can. Some things are a little bit out of date, though, and the UNIX propellerheads would really like to see them updated. But, yes, there's a _lot_ of GNU under the hood. And this certainly seems to be a good thing. gcc, gnutar, gzip, gnumake, and more...without the GNU tools, you wouldn't have a NeXT. :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep game development Date: 20 Jan 1997 05:31:53 GMT Organization: Global Objects Inc. Message-ID: <5bv009$r6r@news.xmission.com> References: <5btm97$i2m@castor.cca.rockwell.com> <AF08223B-1FFD9@198.68.42.204> "Lawson English" <english@primenet.com> wrote: > Erik M. Buck <embuck@palmer.cca.rockwell.com> said: > >A direct to screen API does exist for NeXTstep but it is not portable for > >obvious reasons to other OpenStep/Hardware combinations. > > That is very strange. The Mac has always allowed direct-drawing to the > video buffer via an API that is consistent with all video hardware that > works on the Mac, regardless of who makes it. > > Apple is even making it cross-platform as part of its Games Sprockets, > so that it will work with Windows 95. Before I begin, this is an area where Apple technology, IMHO, probably exceeds NeXT technology, and so there will be a blending in of Apple's technology. Why is NeXT behind in this area? Look at the size of the company and then the market segments they have targeted and you realize that doing something for game developers would have wasted precious resources NeXT needed to put elsewhere. It is a matter of business sense and priorities. (Not that NeXT has ever really been guilty of good business sense, but this is one case where I think they did the right thing, even though, as a game developer myself, I sort of wish it had been different.) You've got a few things at play here. First, NeXT never designed their systems for games. The fact that DPS is fast enough to support them and the fact that the power of the development system makes it nice for game developers are sheer happenstance and not in there by design. Remember how closed the first Macs were? Jobs tried to keep the NeXT boxes closed that way, too. This arrogance of "my way is the bast" pervaded into the access of the screen--"you WILL use DPS". When it came time to do NEXTIME, it was found that video direct to screen could be more efficiently done if you bypassed DPS (which is no surprise--you want to blast bits to the screen, not have DPS doing all sorts of transformations on them). So along comes Interceptor, a way to bypass DPS. But, NeXT being arrogant as they are didn't make it public and they used various reasons (most already discussed here) to justify that action. Probably one of the real reasons behind it was the fact that the API was not originally designed to be cross platform or particularly portable. Not was it ever designed for public consumption. In fact, Interceptor as it exists today will probably never be made public. My suspicion is that something _like_ the Interceptor, probably using Apple's technology for this, will become the API for game developers. Given the mass market of Apple, _something_ will have to be made available! If they don't, then game developers will figure out how to bypass (read: hack around) DPS and then you'll get a very "non-NeXT" piece of software. What I mean by that is this: Because of DPS, any NeXT app will work on any machine running OPENSTEP. No matter what video hardware is used. It "just works." That is the "NeXT way". Now, if you write to the metal, and you don't make video routines that work on *every* possible video configuration, then somewhere down the road you'll hit the situation where the user has to go to the control panel and change the bit depth and/or screen resolution before they can run a particular program. <Rant on> This is one thing about WinXX that is particularly odious to me--I want to run in 1600x1200 and don't want to have to change that every stinking time I want to play such and such a game! And I don't want to have to drop to 256 color mode, either. I prefer using 16 bit (or better) true color mode! <Rant off> So, NeXT wants to avoid this situation and they way they did it is to force you to go through DPS, which will adjust for *any* hardware you throw at it, assuming you've got the device driver. Well, the arrogance here is that NeXT is saying that they can do it better than you can, so that's why you don't get Interceptor. [Fact is, in most cases this is true, but that doesn't make it any less arrogant IMHO.] The non-portable part of Interceptor, as I see it, isn't a cross platform problem but rather a problem with needing code for every possible video configuration out there (or risk annoying people by forcing them to use the video config you deign to provide). Of course, making code that will do this multi-format buffer writing and so on and making it faster than the highly optimized code for the same purpose that already exists in DPS is a tall order. Many will try to use this sort of an API and end up with code that only equals DPS in proformance or, perhaps is worse. Some will do better, but the speed gains will be on the order of a 10% gain at best, given the results of people I've talked to who have used Interceptor. That said, if you make your imaging buffers for your game such that they match the screen's video layout (you can query the AppKit to get that info) then you can bypass most of DPS since it will recognize that it can just memcpy() your buffer to the screen. That's what most of my games do--build the buffer and draw it using my own code [and often DPS compositing, which is very fast since it is almost a simple memcpy()] and then tell DPS to blast it on out. And it is very fast! Of course, having written that code, it is almost Interceptor-ready at that point, since all Interceptor will let me do is blast my pixmap to the VRAM myself instead of asking DPS to do it... So, summary: you can build the pixmaps without DPS. Interceptor lets you do the memcpy instead of asking DPS. You may get as much as a 10% speed increase because your code can be micro-optimized over DPS by not needing to handle certain generic cases. BUT, look at what you lose: (a) easy multiple screen support. My games can be played by having a window straddle a screen and have half in 32 bit color and half in 4-bit monochrome, and _I_ didn't have to write code to deal with that-- it just works. (b) remote screen support. By bypassing DPS, you can't NXHost quite as easily, so running an app and displaying it on a remote screen isn't trivial to do any more. DPS is what does all the work there, and bypassing it will hurt. (c) automatic support of any bit depth, buffer layout, and planar/meshed configurations, without you having to worry about them. Of course, for a _game_ maybe those things are _worth_ giving up to give a truly state of the art experience, and it is for the developer, not NeXT or Apple, to decide. DPS is good enough to support many games, so developers can make use of it should they want, but there are cases where the advantages of DPS are moot and writing to the metal just makes more sense. Well, anyway, keeping the Interceptor API private may have worked in a small marketplace that can't support development of entertainment software, BUT in a mass market, the game folks are going to go to the metal, and NeXT/Apple can't prevent that. They'll always feel they can do better than NeXT/Apple--and in some cases they are right. So, in order to avoid the situation I ranted about above, it seems NeXT/ Apple will have to provide an API to bypass DPS--for those who want to--whether it is justified or not that developers do so. What I expect to see is something with Interceptor's ability to bypass DPS but with a better API, probably resembling the features of what Apple already has. (ie, a melding of technologies). As a game developer, the possibilities are exciting, and I hope this isn't all just wishful thinking. I've been wrong before, but I really, really hope this is one of the times I'm right. :-) -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mult. Inh. in Objective C (Was: NextStep & Mac Frameworks) Date: 19 Jan 1997 21:58:11 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5bun03$ett@csugrad.cs.vt.edu> References: <Mmr4U_u00iWm0EIyg0@andrew.cmu.edu> <kmrG7VK00iV945mAVH@andrew.cmu.edu> <1997Jan19.121152.449@prim.demon.co.uk> <YmsZ_6y00iWT01J_Y_@andrew.cmu.edu> In article <YmsZ_6y00iWT01J_Y_@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Excerpts from netnews.comp.sys.next.programmer: 19-Jan-97 Re: Mult. Inh. > in Objective.. by Dave Griffiths@prim.demo > > Obj-C by itself is pretty useless, you need at least either the Object or > > NSObject class. The latter came into being, what, two years ago? Not sure > > what the Gnu people are doing, but that might constitute a third version. > My understanding is that the GNUstep people are going to create an > OpenStep-compliant implementation which will be freely available under > the GPL. > And no, I don't speak for them, so if anyone from that project wishes to > confirm and/or amplify and/or correct me, please do so. :-) Your understanding is correct. To the original poster: GNU's base class is NSObject. It used to be Object, but they've changed things over so that everything inherits from NSObject now. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: sugee@imap2.asu.edu Newsgroups: comp.sys.next.programmer Subject: Re: Cost of a NeXT Web Site? Date: 17 Jan 1997 17:17:17 GMT Organization: Arizona State University Message-ID: <5boc6t$4dn@news.asu.edu> References: <5bjnet$b79@news.asu.edu> <5bk8vv$3im@news.digifix.com> P.S. I can understand people being a bit tight lipped about this. However, if I am able to get a survey or cross-section, this would give me a fair idea I think. Scott Anguish (sanguish@digifix.com) wrote: : On 01/15/97, sugee@imap2.asu.edu wrote: : > : >I doubt that many advocates and customers like Chylser, CyberSlice, : >Nissan, and etc. as the list goes on, will argue about the merits of : >using NeXT's Web technologies for deploying their Web sites. We have all : >heard plenty and are proud of what is being accomplished. : > : >However, what I haven't heard anything about, something which curiously : >dawned on me recently and after reviewing what some of these folks are : >doing, is the cost of implementing and deploying these Web Sites. Can : >anybody provide approximate costs or actual figures of sites like these? : >I do respect people's anonymity. : > : Thats likely not something that you're going to have much luck : finding out, the spectrum is pretty wide there. : There are some WebObjects projects like Stepwise (a : NEXTSTEP/OpenStep product registry) that are based on EOF and WOF and it : took perhaps 20-40 hours to implement. (The back end OpenStep UI has : probably taken about as long). Of course I've re-written it a number of : times now so thats a rather poor example. : I've written sample catalog applications in WebObjects in a matter : of a weekend. : However I know of _much_ larger scale projects that have been in : development for 6-8 months with a pretty good team of people on it (4-6).. : : -- : Scott Anguish DBS Online - http://www.dbs-online.com/DBS : sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Mystery bug from hell Date: 17 Jan 1997 11:06:19 GMT Organization: MHPCC Message-ID: <5bnmfb$7q1@kaopala.mhpcc.edu> I've got a bug that depends on the order in which I declare two fields in a global structure variable. My hunch is that I'm doing something wrong when declaring global varibles. Everything works when I declare a structure like this: typedef struct { char recordFD; char Field_1; char Field_2; } menu_struct; But the bug occurs when I declare it like this: typedef struct { char recordFD; char Field_2; char Field_1; } menu_struct; I have had wierd problems before from variables declared outside of a method's interface. But I don't know what I'm doing wrong. Here is a sketch of the program structure, in 3 abbreviated files: A header file, "global.h" is imported into all the other source code files: ----------------------------------------------------------------------------- #import <appkit/appkit.h> typedef struct { char recordFD; char Field_2; char Field_1; } menu_struct; void Assign_with_Function (); extern menu_struct m; ----------------------------------------------------------------------------- A file "Controller.m" contains the GUI methods, and has the bug: ----------------------------------------------------------------------------- #import "Controller.h" #import "global.h" menu_struct m; /* Home of the declaration */ @implementation Controller - mainMethod:sender { Assign_with_Function(); /* Assigning through a function call works fine */ [self Assign_with_Method:self]; /* Assigning through a method gives the bug */ return self; } - Assign_with_Method:sender { printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* produces: m.Field_1 = sprintf(&m.Field_1, "y"); printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* produces: m.Field_1 = y, m.Field_2 = sprintf(&m.Field_2, "y"); printf("m.Field_1 = %c, m.Field_2 = %c\n", m.Field_1 , m.Field_2); /* THE BUG!! Now you get : m.Field_1 = return self; } @end ----------------------------------------------------------------------------- The function "Assign_with_Function()" is defined in its own file "Assign.c", and works fine: ----------------------------------------------------------------------------- #include "head.h" void Assign_with_Function () { sprintf(&m.Field_1, "y"); sprintf(&m.Field_2, "y"); } ----------------------------------------------------------------------------- The bug is that the variable "m.Field_1" loses its assigned value when "m.Field_2" is assigned. Any tips will be GREATLY appreciated. ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sun, 19 Jan 1997 22:16:20 -0800 Organization: Modulation Message-ID: <32E30DB4.7126@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Blake Stone wrote: > > Alan Lovejoy (alovejoy@concentric.net) wrote: > > > With the CLI tools under Unix, sending a message in C is a one-liner: > > > > > > system("echo 'This is the contents of the message.^D' | mail -s 'My > > > Subject' '<cs4w@andrew.cmu.edu>'"); > > > The same could be done in C without using the system() > > function. But it would be ugly and awkward by comparison. > > However, the fault lies both with C and with the standard C > > library. > > There is no inherent fault of C or C++ that would make this > awkward. I said "by comparison." Let's see: #include <mailLib.h> ... MailTool *mt; mt = new MailTool; mt->sendMessage("<cs4w@andrew.cmu.edu>", "MySubject", "This is the contents of the message."); free(mt); ... In my personal opinion, it's more awkward "by comparison." Your mileage may vary. > The fact that the standard C library doesn't include a > cross platform standard mail API isn't exactly unique. Very few > standard language libraries do. Agreed. > > In some other programming language, such as Smalltalk (hey, you > > knew this was coming, right?), coding the above could be as > > simple as: > > > > MailTool > > sendMessage: 'This is the contents of the message.' > > withSubject: 'My Subject' > > to: '<cs4w@andrew.cmu.edu'. > > Whereas in Objective-C this becomes unbearably complicated? > > [ MailTool sendMessage: "This is the contents of the message." > withSubject: "My Subject" > to: "<cs4wandrew.cmu.edu>" ] ; Hey, I didn't disparage **Objective-C** in any way! In fact, I like the language. I hope it becomes more widely available thanks to Rhapsody. However, I should point out that the above Smalltalk code can be typed in to any pane of any window (in the Smalltalk IDE) that accepts text input. Once typed in, it can be executed just by selecting it using the mouse, and then picking "do it" from the operate menu associated with that text pane. > ... both examples assume that somebody has provided the > hypothetical MailTool API, which AFAIK isn't a standard piece of > either language. Well, the "MailTool" class would be about two hundred lines of code in VisualWorks Smalltalk (roughly 30 methods). About 4 hours work to get fully tested and debugged. I would expect Objective-C in OpenStep to be roughly the same. In the case of C, however, multiply those numbers by a factor of 10. > > If it were this simple in C (for everything, not just sending > > mail), then perhaps the system() function would be used much > > less. > > Yes, it's true, if there were an API function or method for every > conceivable purpose life would be very easy. There isn't. There > probably will never be. In the mean time, the system() function > can be VERY handy if you know that your target system fully > supports the tools you intend to use. Yes, the system() function is a necessity in today's world. I think the goal of Rhapsody (and all Unixes) should be to continuously make it less so over time. Perhaps one day... -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 17:21:32 GMT Organization: Netcom Distribution: world Message-ID: <5boces$kft@dfw-ixnews11.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <5bn20b$lmn@sjx-ixn6.ix.netcom.com> <maury-1701971146010001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <5bn20b$lmn@sjx-ixn6.ix.netcom.com>, aisbell@ix.netcom.com (Art > Isbell) wrote: > > > As has been stated on several occasions, OPENSTEP programs aren't > > *required* to use Unix shell utilities. > > Yes I know, but also look at the many examples of those that _do_. We probably wouldn't have these examples to look at (and more importantly, *use*) if these shell utilities weren't available *and* their functionality wasn't duplicated in functional or class APIs. You made the point that if all the functionality of shell utilities were available in function or class libraries, then these shell utilities wouldn't be necessary for apps to use. This is a valid point, but one which hasn't been achieved yet. It's a worthy goal, but until that happens, don't rip out the shell utilities just to save a few MB of cheap disk space. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 17 Jan 1997 17:28:44 GMT Organization: Netcom Distribution: world Message-ID: <5bocsc$kft@dfw-ixnews11.ix.netcom.com> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > Seeing as OpenStep runs over NT, > it's demonstratable that you can rip out ALL the Unix utils and end up > with a working system. But you and I don't know whether OPENSTEP/Mach relies on Unix shell utilities and whether OPENSTEP/NT replaces this reliance with DOS utilities that are available under NT (probably not likely considering the paucity of functionality available with DOS utilities under NT compared with the richness Unix includes). OPENSTEP isn't a total self-contained cocoon. It depends on functionality offered by the underlying operating system. If you start ripping out this functionality, you may break things. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442 is planning on the Unixness is clear > from Hancock and Amelio's comments. It sounds like by the time of > the unified release, the GUI will be much more familiar to Mac users > than NeXT users, certainly more than cleaning some rough edges. > The question is whether the de-unixizing will be cosmetic or deeper. > As someone who's life would be better with grep on my hard disk, I > hope that such features will still be accessible if you want to use > it, but I'm far from certain. I agree that they face time pressure > but they also face pressure from current Mac users to produce a > system which is at least familiar. Given Apple's limited time, I think it's possible to make a good guess as to how they will handle this issue without mucking around in the BSD sources. They don't even need a programmer to do it, either: all they need to do is remove Terminal.app from the default installation for Rhapsody, and UNIX is immediately invisible to the user. As far as the user is concerned, it won't even exist as far as they know. Of course, they'll need programmers to provide GUI equivalents of any remaining gaps in system administration, but we knew they were going to do that anyway, right? So the only question is how to keep Mac users from freaking out when they accidentally double-click on Terminal.app: [simple: make it an optional install.] I believe that this course of action would be the absolute best use of Apple's resources in this vein. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 20 Jan 1997 15:53:39 GMT Organization: Indiana University, Bloomington Message-ID: <5c04e3$gh9@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <32E296A4.4261@concentric.net> <5bu93k$ka6@ds2.acs.ucalgary.ca> <32E30DB4.7126@concentric.net> NNTP-Posting-User: glhansen In article <32E30DB4.7126@concentric.net>, Alan Lovejoy <alovejoy@concentric.net> wrote: >Yes, the system() function is a necessity in today's world. > >I think the goal of Rhapsody (and all Unixes) should be to continuously >make it less so over time. Perhaps one day... Why? -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: dwy@ace.net (David Young) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 17 Jan 1997 23:00:23 GMT Organization: ace dot net internet technologies Message-ID: <5bp0a7$ouv@darla.visi.com> References: <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b8scv$6ue@darla.visi.com> <maury-1501971750540001@199.166.204.230> <5bkh7r$big@darla.visi.com> <maury-1601971544430001@199.166.204.230> <jinx6568-1701971519160001@news.sover.net> Chris Johnson (jinx6568@sover.net) wrote: : Here is a serious question- how prevalent _is_ bytestream manipulation : in the standard Mac software base? I'd imagine pretty common. See below. : : Certainly something like an IRC program lends itself to bytestream : manipulation. It is just possible that things like video editors _can_ : operate on bytestreams though clearly there is non-linear stuff you could : do that begins to touch on other ways of handling data. What's a video editor? A program that deals with a video stream. cat foo.avi |avi2mpeg | mpegscale 0.7 > foo.mpeg I'm not saying that's better or worse than a graphical interface, but i can see where it'd be useful. : On the other hand, how does one abstract a Photoshop CMYK image in : layers with a selection outline on the cyan plane that is being used to do : a feathered blur? I think, though I could be wrong, that even with : databases and spreadsheets the linkages of something like ClarisWorks are : stepping past the ability of a single byte stream to describe what is : going on. This is the reason we have applications and the clipboard, or on NEXTSTEP, services. Select a square of a bitmap in, say, NXPaint, or something, and do Services -> Photoshop -> Gaussian Blur.. It'd be good. -- # david young: oo developer, think new ideas east/onramp # vox: 212.629.6800 x170 phax: 212.629.6850 # net: david_young@thinkinc.com (MIME ok, NeXTmail better)
From: "Jonathan W. Hendry" <jon@steeldriving.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 17 Jan 1997 17:32:12 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32DFFDEC.74E@steeldriving.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > > Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: > : Why, because they <gasp> may be useful? :) > > Example, does the existance of tar, a reasonably able backup utility with > a really unfriendly UI, make companies like Alladin or Dantz who make backup > software more or less eager to port to Rhapsody? I think less likely, > because the number of potential buyers for Stuffit is reduced by the > existance of tar and freeware extentions. There's a Mac program that handles tar, that was free (I think). Did Dantz or Aladdin die out when that came out, about 5 years ago? -- Jonathan W. Hendry jon @ exnext . com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sun, 19 Jan 1997 12:53:05 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Distribution: world Message-ID: <ImsZy1y00iWT41JBZF@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> In-Reply-To: <maury-1601971549250001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 16-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. > > Why? Various scripting languages are all the rage now. JavaScript, > > WebScript, VBScript, etc. plus what proponents sell as advanced > > 4th-generation languages (4GLs) which are usually interpreted. The Unix > > Read it carefully, I was taling about calling these things from the > command line, not the command line itself or using it as a person. IE, > programs should not have to call things by "pretending" to typing in CLI > commands. Sure. That's why the kernel provides a system call API. But that's not what you're arguing about-- you seem to be claiming that it is wrong for a program to execute a CLI utility to perform some task. And that's silly. Why don't you show me how you'd use system calls on any OS you'd like to send email? With the CLI tools under Unix, sending a message in C is a one-liner: system("echo 'This is the contents of the message.^D' | mail -s 'My Subject' '<cs4w@andrew.cmu.edu>'"); -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
Date: Sun, 26 Jan 1997 14:09:46 -0500 From: dea@astral.magic.ca (Don Andrachuk) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Message-ID: <dea-ya023480002601971409470001@news.magic.ca> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> <5c4rhc$o1k@ccpnws.in2p3.fr> <jdoherty-2301972150580001@aus-tx9-13.ix.netcom.com> Organization: DEA Systems Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 8bit In article <jdoherty-2301972150580001@aus-tx9-13.ix.netcom.com>, jdoherty@ix.netcom.com (John Doherty) wrote: >In article <5c4rhc$o1k@ccpnws.in2p3.fr>, mullere@in2p3.fr (Eric Muller) wrote: > >| Bill Bumgarner (bbum@friday.com) wrote: >| (some stuff deleted) >| : If anything, Aladdin should release a version of Stuffit that can be >| : used from the command line... I'd certainly pay for a tool that give me >| : random access to my archives, a full-featured GUI w/drag-n-drop, and a >| : comparably featured command line utility. >| >| If you use MPW you can have the Stuffit tools, they come with Stuffit Deluxe. > >But the v3.5 tools, at least, are incomplete (I don't have StuffIt 4): >can't add to an existing archive, can't extract fewer than all the files >from an archive, can't even list the contents of an archive. *All* of those things are possible with version 4. Not only that, but Aladdin's True Finder Integration control panel provides these features completely transparently at the Finder. -- Don Andrachuk DEA Systems
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Compiler version in newest OS? Date: 27 Jan 1997 15:08:08 GMT Organization: The Ohio State University Message-ID: <5cigco$bou@charm.magnus.acs.ohio-state.edu> My understanding is that NeXT's compiler (cc) is comparable (derived from?) some version of the gnu c compiler. I have NS3.2/3.3 Developer, and am wondering whether the compiler that comes with 4.0 (or are we up to 4.1?) is comparable to a more recent gnu compiler. A version number would answer my question. Is it 2.7.2? Thank you for the information. Randy Jackson -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Concerning Function Overloading in Obj-C.(Re: Multiple Inheritance) Date: 27 Jan 97 09:50:44 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan27095044@howard.one.net> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5c7vug$4s4@csugrad.cs.vt.edu> <SHESS.97Jan23151627@slave.one.net> <jchan-ya023580002401972255270001@news.apk.net> <5ccaka$n27@csugrad.cs.vt.edu> In-reply-to: nurban@csugrad.cs.vt.edu's message of 25 Jan 1997 01:52:58 -0500 In article <5ccaka$n27@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: In article <jchan-ya023580002401972255270001@news.apk.net>, jchan@apk.net (Jerome Chan) wrote: > Can't we just pass the parameter as an id object and then do a > switch based on the object type? No, the object type isn't an ordinal. You can't switch on it, just like you can't switch on strings. I know this will get me in trouble, but ... you shouldn't be switching on the class/type of an object in any case. That's the reason you use message dispatch (so the runtime does the switch for you). For those few times when it really is cleaner to do an explicit switch, if()...elseif() clauses aren't _too_ painful. [This does totally ignore the problem or match-ordering. If B subclasses A, what do you do when your switch switches on both A _and_ B?] :-), -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: MWRon@metrowerks.com (MW Ron) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.lang.pascal.mac,comp.sys.mac.programmer.tools,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.games,comp.sys.mac.oop.misc,comp.arch.embedded,comp.lang.java.programmer,comp.sys.next.misc,comp.sys.next.programmer Subject: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: Mon, 27 Jan 1997 10:33:00 -0500 Organization: Metrowerks Message-ID: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY CodeWarrior(R) To Be Hosted On Sun Microsystems(R)' Solaris(TM)-based UNIX(R) Workstations AUSTIN, Texas--January 27, 1997--Metrowerks Inc. (NASDAQ: MTWKF, TSE/ME:MWK), one of the world's leading providers of software development tools, today announced that it had signed a letter of intention to acquire the principle assets of The Latitude Group, Inc., of Mountain View, Calif. Latitude's principle assets include a porting library which allows Mac(TM) OS applications to be ported to UNIX-hosted operating systems, including Sun Microsystems' Solaris 2.3+, Silicon Graphics(R)' IRIX(TM) 5.2+ and Hewlett-Packard(R)'s HP-UX(R) 9.03+. The Latitude porting libraries redirect Mac OS commands to the target operating system, with a UNIX library containing a portable implementation of the Mac OS API at its core. Metrowerks will also take over providing the Latitude porting technology to The Latitude Group, Inc.'s existing clients already under contract. Metrowerks intends to use the Latitude porting library to port CodeWarrior to run on Sun Microsystems' Solaris-based UNIX workstations in order to offer this platform as a host for embedded systems development. Sun's Solaris-based UNIX workstations are widely used by embedded systems programmers worldwide. The Latitude porting libraries will be incorporated in a new product, CodeWarrior Latitude. CodeWarrior Latitude will continue to support the UNIX-hosted operating systems outlined above. Metrowerks also plans to extend CodeWarrior Latitude to enable the port of Mac OS applications to run on Rhapsody, Apple's Next Generation OS. This will allow Metrowerks' existing clients to more easily port their existing applications to Rhapsody. As part of the agreement between Metrowerks and The Latitude Group, Inc., David Hempling, president and CEO of The Latitude Group, Inc., will join Metrowerks as the technical lead for CodeWarrior Latitude. Mr. Hempling was a co-founder of Quorum Software Systems Inc., which created Latitude. "The Latitude porting technology offers Metrowerks a great opportunity to move CodeWarrior to UNIX," said Jean Belanger, chairman and chief executive officer. "By offering embedded systems versions of CodeWarrior on Windows, Mac OS and, now, UNIX, our embedded story will be more compelling than ever. Implementing support for Rhapsody in CodeWarrior Latitude will allow Mac OS developers to move their applications to Apple's Next Generation OS much faster than would otherwise be the case." Pricing and Availability Metrowerks plans to ship CodeWarrior Latitude in the summer of 1997. CodeWarrior Latitude will include all available targets in one library package and will sell for $399. UNIX-hosted versions of CodeWarrior for embedded development will be available in late 1997. About Metrowerks Founded in 1985, Metrowerks develops, markets and supports a complete line of programming tools for building applications for a number of operating systems intended for use on desktop computers or embedded systems, including Mac(TM) OS, Windows(R) 95, Windows NT(TM), PlayStation(TM) OS, BeOS(TM) and Palm OS(TM), running on a number of microprocessors including 68K, PowerPC(TM), MIPS(TM) and x86 microprocessors. Metrowerks' CodeWarrior products are used by over 65,000 registered users in 70 countries. Additional information on Metrowerks and its products is available via e-mail at "info@metrowerks.com", from our web site at "http://www.metrowerks.com", or by calling (800) 377-5416 or (512) 873-4700. ### Metrowerks, the Metrowerks logo and CodeWarrior are registered trademarks of Metrowerks Inc. Apple and Macintosh are registered trademarks, and Mac is a trademark, of Apple Computer, Inc. Windows and WindowsNT are registered trademarks or trademarks of Microsoft Corp. in the United States and other countries. All other company and product names may be registered trademarks or trademarks of their respective companies/holders, and are hereby recognized. Statements in this press release regarding CodeWarrior Latitude are forward looking statements that involve risks and uncertainties, including successful and timely development of CodeWarrior Latitude and customer acceptance of the product. -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: WM Inspector Question... Date: 27 Jan 1997 15:27:00 GMT Organization: Rockwell Avionics - Collins Message-ID: <5cihg4$fsr@castor.cca.rockwell.com> References: <5cgjaq$9g7@news.iastate.edu> Cc: logic@friley253.res.iastate.edu In <5cgjaq$9g7@news.iastate.edu> ??? wrote: > Hello all, > I have a simple question: I would like to have a bitmap (on > top of a button) in my WM Inspector Panel. Add the image to the images suitcase in IB.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:36:08 -0500 Organization: Atria Software Message-ID: <maury-2701971236080001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <5c3ltv$ljg$1@majipoor.cygnus.com> In article <5c3ltv$ljg$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > I don't think that's the way you've been coming across, and while I don't > have an article to quote, I do seem to remember you advocating specifically > that things like access to the CLI and the Unix utilities be removed > entirely. From _my_ machine, yes. From _your_ machine? What the heck do I care? > I don't think there's really a problem with a shared library that impliments > the same functionality as the unix CLI tools. Well good. > I don't think anyone has said > "you shouldn't do that", I think they've been saying either: > > a) that's fine, but don't take away what I've already got, or > b) why reinvent the wheel a) I don't want to. b) because there are better (way better) wheels. > I presonally don't subscribe to the latter.. sometimes in order for your > wheels to work with the next generation of carts/wagons/cars/etc, you need to > reinvent them. Just don't take away/break what is already there. That's my point all along. And in some cases you have to break code, Apple just did by buying NeXT after all. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:34:10 -0500 Organization: Atria Software Message-ID: <maury-2701971234100001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> In article <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > mv, rm, and so forth-- those generally don't do much besides parse the > command line and execute the appropriate system call. What a concept! > That API doesn't exist right now. You don't say. Huh. > Apple does not have the time to create such an API Ever? > I also question whether they can duplicate all of > the functionality without having to undergo years of user feedback and > debugging-- and Unix has undergone decades worth of testing. NT did, took about three years. > OpenStep is another evolutionary step along the road towards the great > Mecca in which good programs and reliable operating systems are > available to all computer users. Exactly, I propose nothing more than the next obvious step. > The existance of OpenStep does not mean that Rhapsody can dump the Unix > CLI utilities without breaking far too many things (as I've explained in > previous articles). Once again, the Unix utilities cannot be an > optional part of Rhapsody without Apple having to replace that > functionality with something else. What exactly do you think I've been calling for in this endless thread? > NT provides a POSIX-compliant environment, does it not? POSIX, or > S/VID, or one of those standards defines POSIX-compliant command-line > utilities which are precisely the ones shipped with modern Unices (and > are largely backwards-compatible with the BSD 4.3 utilities). None of which appear to be on either my NT server or workstation. > make, sh, perl, diff, awk, sed, lex, yacc, grep, tar, cc, ld, as, emacs, gdb? Analogues of all of these already exist on the current Mac OS. In many case, the exact code exists, tar and emacs come to mind, and many others use grep, BBEdit for instance. Things like make, cc and yacc are definitely not needed as they come as a part of a single IDE, the product being greater than the sum of it's parts. Perl is a particularly interesting one, because you can download MacPerl from the net for free. It takes the Perl scripts and it in turn generates AEvents for other applications, allowing Perl to do things on the Mac that you can't do under Unix (selecting cells in a live spreadsheet would be an example). So, all of these exist. Next set... > Or what about system daemons like inetd, sendmail, netinfod, telnetd, ftpd? Why one would wish to telnet to anything these days is beyond me, they all seem to be examples of places where the distributed OOPS code has not caught up to their code. It's a good idea in the world of text based CLI's, but that's the point of this thread, why telnet in when you can simply call the object over the net? Oh well... As to the rest inetd is not really needed (if you want it it would be easy to create though, hmmmmm), netinfod I don't know (and my Sun box has no man page for), sendmail exists in many forms, and ftpd's functionality exists in countless numbers of Mac products. Keep going, let's see some more examples of these things that are so hard to write Apple couldn't possibly do it (even though they exist on every platform I know of). > Available evidence suggests that a lot of people implement popular Unix > tools like make, sh, diff, and so forth for non-Unix operating systems > since those tools are especially useful for developers and > administrators because they provide a large amount of functionality. Exactly, so let's make them even more standarized, modern and portable. Maury
Newsgroups: comp.sys.next.programmer From: allan@ali.bc.ca (Allan Noordvyk) Subject: Re: "/usr/lib/libposix.a is out of date" -- why/what/help? Message-ID: <E4oELw.Axy@gateway.ali.bc.ca> Sender: nobody@gateway.ali.bc.ca Cc: luomat@nerc.com Organization: A.L.I. Technologies, Inc. Date: Mon, 27 Jan 1997 16:46:43 GMT References: <199701250752.CAA07705@nerc.com> In comp.sys.next.programmer Timothy J Luoma wrote: > > > "ld: table of contents for archive: /usr/lib/libposix.a is out of > date; rerun ranlib(1) (can't load from it)" > > > Why did this happen, how can I fix it, what does it mean, did > something break (if so, is it bad?) > > sorry, I don't know anything about this stuff, just trying to > figure it out as I go along. > > can I rerun "ranlib" on /usr/lib/libposix.a without causing > problems in the future? It usually means that the creation time of the file has changed, probably due to it being copied from one place to another (using the -p flag with the cp command will prevent this). Since this is a system library, the only way this could have happened is if you were mucking around with the file or installed a patch which forgot to preserve the build time when overwriting the file. Try running ranlib on the file to rebuilt the table of contents and seeing if everything works OK. ciao -- Allan Noordvyk, Software Artisan e-mail: allan@ali.bc.ca ALI Technologies Voice: 604.279.5422 x 317 Richmond, Canada Fax: 604.279.5468 * NeXT and MIME mail welcome * "I have never seen anything fill up a vacuum so fast and still suck." -- Rob Pike, commenting on The X Window System
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:19:29 -0500 Organization: Atria Software Message-ID: <maury-2701971219300001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu <maury-2101971141510001@199.166.204.230> <cmtJIyO00iV0A5bPI8@andrew.cmu.edu> In article <cmtJIyO00iV0A5bPI8@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > What kind of program? A precompiled executable in the architechtures' > machine language, or an interpreted program which requires an > interpreter (ie, /bin/sh) and commands (ie, /bin/mount, /bin/find, > /bin/grep, /etc/inetd, /usr/lib/sendmail, etc). Both. > What type of program calls the OOPS shared library? All. > Gee-- lots of people disagree with Maury, therefore they must all be > confused and not understand what I mean. It couldn't possibly be the > case that Maury is wrong.... If this is so obvious, why do I still get "why do you hate Unix so much" questions in every reply? > Yes. I suspect I understand them better than you do. What is the > largest number of computers that you've had responsibility to administer? Hmmm, good question. About 100, it could have been about 150 but I never really counted. > No-- code written to use the Unix CLI utilities would be portable to all > users of Rhapsody Oh, now THAT'S a very interesting definition of portable. > Rhapsody can either be Unix-compatible, or it can have > Unix-compatibility as an optional add-on, which would mean that Rhapsody > would have to have some non-optional replacement for the Unix utilities > which would mean that some Rhapsody systems are guaranteed to not be > Unix-compatible (because they didn't have the optional add-on installed). Which is exactly what NT is offering and selling the pants off of Unix. > Making Unix an optional part of Rhapsody means that Apple has to rip > Unix out of Rhapsody and replace it with some non-optional alternative > that provides similar functionality. Your operating system won't do > anything if it can't boot, and Unix systems can't boot without the Unix > CLI utilities. Then fix it. I'm not talking about today. Or tomorrow. Someday. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:15:40 -0500 Organization: Atria Software Message-ID: <maury-2701971215410001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> In article <smtIiRO00iV0M5bOIB@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > That is simply not true for every problem. I never said anything about "every problem". Let's hear your percentage then. 80%? 90%? > Again, OO programming is one paradigm out of many. It is not always the > best solution to every possible problem, although it is very good for a > lot of problems. And thus if you're using it (which you are in OpenStep after all) then wouldn't you like consistency? Don't you _want_ to have access to the best solution for most problems? So why not have it? > I can use fork()/exec() (which is more controllable in terms of handling > stdin, stdout, etc that system()) on every POSIX-compliant operating > system and every Unix system around. But that's a TINY portion of the computer market. A better solution that's not platform dependant would allow easier access to the rest of the market. What's funny about this thread is that while people seem fond of telling me this is nothing more than a "religious" anti-Unix rant, it appears the arguments offered in return are exactly that indeed. What's everyone so afraid of? Work? > Such code is portable to more operating system/hardware plaform > combinations than any other system call API that is available today. > How is this not cross-platform? It is however, NOT portable out of the box to the vast majority of _computers_ in the world. There's nothing inherent in OpenStep that I can see that has such a limitation that could stop it from running over, say, Win3.1. > You do realize that the fastest and most efficient web servers are > written by preforking child servers-- such a design beats a > multithreaded web server in pretty much every regard. That's because few Unixen have fast threading services, a point well hashed out in other threads (of the message sort). > Nothing-- it's not terribly difficult at all. Why don't you understand > that almost every single point you've made in several articles, > including this one, have been wrong? You agree with most of them (3 out of 4 to be exact), yet they are wrong. Your logic escapes me. > 'I don't think this will mangle it at all. Quite the opposite in some > cases. If you want the shell utilities, click Custom Install, click > "Unix utilities". End of issue.' > > If the Unix CLI utilities are not shipped as a core element of the > operating system with _every_ copy of Rhapsody, then they will not > available on _some_ Rhapsody systems. > > Software currently available for Unix, including essentials such as the > system boot procedure (/etc/rc and friends) and networking and email > (machd, netinfod, nfsd, sendmail, telnet, ftp, etc) depends on those CLI > utilities. And the average Mac user will never have any need of them, and doesn't want to either. I've been running on the Mac for about 7 years now, never used any one of those, and most likely won't in the future either. Yet on the off chance that _someone_ might on _their_ machine, I have to install this stuff on _my_ machine. > Do you understand? No, you again make all this sound like a bad thing. > If you make Unix optional, Rhapsody will no longer be Unix-compatible > because you would have to replace the current Unix functionality with > something else that is not optional-- this is the case with OpenStep on > NT. Doing constitutes "ripping out Unix", since the operating system > would no longer be a Unix operating system. I see. So if I delete, say, grep, off of my hard drive, Unix stops working? > And guess what? Apple bought NeXT because "Apple needed a truly modern > operating system and NeXT had an exceptional operating system with > modern services and API's." This descibes OS certainly, but do you truly offer up grep as a paradigm of modern programming? > All of this to save $3 worth of disk space? No, to make... a) programming easier b) programming more consistent c) the system more portable d) the system easier to use But who want's any of those, eh? Maury
From: pjb@imaginet.fr (Pascal Bourguignon) Newsgroups: comp.sys.next.programmer Subject: Re: BASIC on NeXT? Date: 27 Jan 1997 06:30:48 GMT Organization: ImagiNET Message-ID: <5chi2o$gmm@belzebul.imaginet.fr> References: <5cebjo$h75$1@Venus.mcs.net> In article <5cebjo$h75$1@Venus.mcs.net> font@MCS.COM (Font) writes: > pbrown@ashkhabad.berkeley.edu (Paul R. Brown) writes: > > >In article <glen_stewart-2401972320070001@stewart-3.pnet.msen.com>, Glen Stewart wrote: > >>Anyway, I'd love to be able to do BASIC programming in UNIX. Does anyone > >>here know if there is such a compiler available? GCC seems to be just > >>about everywhere (even on the Mac68k port), but BASIC is what I really > >>prefer. > > >Well, if you *must*, then you have two choices. One is to write your > >own BASIC interpretter in C as an exercise (it's easy, really!), and > >the other is to grab the p2c distribution, a pascal -> c converter, > >which comes with just such a program. > > I seem to recall that porting the Bywater BASIC interpreter to > NEXTSTEP wasn't difficult, but I don't recall where the Bywater > BASIC interpreter can be found. However, there is a FreeBSD port of > it which should refer one to the archive site (check from > http://www.freebsd.org). > -- > font@mcs.net Wishes are like dishes. Here is the smallest basic interpreter I ever found on Usenet (it really works!): /*------------------------------------------------------------------------*/ #define O(b,f,u,s,c,a)b(){int o=f();switch(*p++){X u:_ o s b();X c:_ o a b();default:p--;_ o;}} #define t(e,d,_,C)X e:f=fopen(B+d,_);C;fclose(f) #define U(y,z)while(p=Q(s,y))*p++=z,*p=' ' #define N for(i=0;i<11*R;i++)m[i]&& #define I "%d %s\n",i,m[i] #define X ;break;case #define _ return #define R 999 typedef char*A;int*C,E[R],L[R],M[R],P[R],l,i,j;char B[R],F[2];A m[12*R],malloc (),p,q,x,y,z,s,d,f,fopen();A Q(s,o)A s,o;{for(x=s;*x;x++){for(y=x,z=o;*z&&*y== *z;y++)z++;if(z>o&&!*z)_ x;}_ 0;}main(){m[11*R]="E";while(puts("Ok"),gets(B) )switch(*B){X'R':C=E;l=1;for(i=0;i<R;P[i++]=0);while(l){while(!(s=m[l]))l++;if (!Q(s,"\"")){U("<>",'#');U("<=",'$');U(">=",'!');}d=B;while(*F=*s){*s=='"'&&j ++;if(j&1||!Q(" \t",F))*d++=*s;s++;}*d--=j=0;if(B[1]!='=')switch(*B){X'E':l=-1 X'R':B[2]!='M'&&(l=*--C)X'I':B[1]=='N'?gets(p=B),P[*d]=S():(*(q=Q(B,"TH"))=0,p =B+2,S()&&(p=q+4,l=S()-1))X'P':B[5]=='"'?*d=0,puts(B+6):(p=B+5,printf("%d\n",S ()))X'G':p=B+4,B[2]=='S'&&(*C++=l,p++),l=S()-1 X'F':*(q=Q(B,"TO"))=0;p=B+5;P[i =B[3]]=S();p=q+2;M[i]=S();L[i]=l X'N':++P[*d]<=M[*d]&&(l=L[*d]);}else p=B+2,P[ *B]=S();l++;}X'L':N printf(I)X'N':N free(m[i]),m[i]=0 X'B':_ 0 t('S',5,"w",N fprintf(f,I))t('O',4,"r",while(fgets(B,R,f))(*Q(B,"\n")=0,G()))X 0:default:G() ;}_ 0;}G(){l=atoi(B);m[l]&&free(m[l]);(p=Q(B," "))?strcpy(m[l]=malloc(strlen(p )),p+1):(m[l]=0,0);}O(S,J,'=',==,'#',!=)O(J,K,'<',<,'>',>)O(K,V,'$',<=,'!',>=) O(V,W,'+',+,'-',-)O(W,Y,'*',*,'/',/)Y(){int o;_*p=='-'?p++,-Y():*p>='0'&&*p<= '9'?strtol(p,&p,0):*p=='('?p++,o=S(),p++,o:P[*p++];} /*------------------------------------------------------------------------*/
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Number of digits in setDoubleValue: Date: 27 Jan 1997 08:49:11 GMT Organization: MHPCC Message-ID: <5chq67$gdm@kaopala.mhpcc.edu> Is there any way to control the number of digits displayed in a textField? I am calling: [fieldMatrix setDoubleValue:(double) value at:2]; and it gives at most 6 digits in the display. It also automatically drops to lower numbers of digits when it can. I don't see anything in /NextLibrary/Documentation/NextDev/TextField.rtf that mentions control over digits printed. I would like to be able to fix the number of digits at the precision of the floating point number. Perhaps this has changed in OpenStep? -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 14:04:29 -0500 Organization: Atria Software Message-ID: <maury-2701971404290001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> In article <gmtamKS00iV_I6IBY8@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Correct. A multiuser computer system has conventions for where you > should place common files (like applications, fonts, and other such > resources) which are supposedly intended for use by all users. Well that about says it all. Computers should not do what we tell them to, it should be the other way around and that's completely logical. FYI, the Mac allows you to stew most files around as you like, and has no problems finding them, running them etc. This is true for both mutiple and single user machines. > For that matter, single-user computer systems have some of those > conventions too-- what else did you think the special nature of the > "System folder" represents under MacOS? Something that should have been destroyed many moons ago. > Are you willing to accept empirical evidence from the real world as to > which of our respective definitions is more valid, or does that not > interest you? _empirical_? No. You wouldn't be either. > You're kidding, right? If this is actually true, (a) provide some > details 25 Macs of varying types on a mixture of Ether and LocalTalk bridged by a FastPath V. One PC XT (a real one) using LocalTalk and a modem to talk to a bank. Another 25 or so 386 PC's on (get this) ArcNet. Another set of 386's. Lots of Unix boxes of various types, an IBM mini (43 something) and several DEC minis (the largest a 6220). All sorts of software, backed by servers running on PathWorks. I handled the Macs and PC's, their software and their connection to the network and servers. > (b) why aren't you making any sense? I am, why don't you understand me? No one else seems to be having a problem understanding me. With the exception of one other post (the person's first that I can see) everyone seems to agree that a new core of utilities would be a great thing. > How can you possibly have "administered" a large network of computers > (presumably Macs) if you did not have some conventions for what was on > each computer and where such common functionality was to be located? The Mac cares not where the stuff is located. I had to replace a dead drive one time and rebuild it off the file server. I was surprised to find all the applications being installed into a subfolder of a subfolder in a "Personal" folder. Hey, worked for them. > How did you figure out how many licenses of various software packages > were needed? I counted. I tried some more "fancy" solutions like various network mappers/responders, but never found them to be all that useful. For the most part the machines didn't die too often, and when they did I'd get the hardware guys to replace anything that really died (drives and such) and I handled the rest including training. Even so it was so little work that the position was nulled, I moved on, and no one had to replace me. > The point was, I was showing a real-world example of roughly as many > Macs that did have a convention for filesystem layout as you stated that > you were familiar with which did not have such a convention. And this > refutes your attempt to claim that Macs in general do not have such > conventions. Har! It does not at all refute it, you're arguing the general from the specific! Really now. Hey, the guy that got me into Macs now works at a place with something like 500 desktops in a 50/50 ratio of Macs to PC's, lots of portables, a BIG network etc etc. They don't have any standards for file locations either. Counterexample to the specific. Maury
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.lang.eiffel Subject: Re: NextStep & Mac Frameworks Date: Tue, 28 Jan 1997 08:48:00 +1100 Organization: Unisys Message-ID: <32ED2290.2DB3@acm.org> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> <milkweed-2201972301440001@port10.chester.smallmedia.com> <32E85082.37DE@acm.org> <5c9v18$95r@muller.loria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dominique Colnet wrote: >Ian Joyner wrote: > |> Perhaps someone should encourage Metrowerks to get together with > |> an Eiffel compiler vendor or someone willing to write an Eiffel > |> compiler for CW. It sounds like they would be a really good match. > |> Having already written an Eiffel compiler in Pascal, I'm willing > |> to volunteer. > Yes, but it is now time to use Eiffel to write Eiffel compilers :-) True! But on the machine that I wrote the Eiffel compiler on, the compilation system was all done in Pascal, which included lexical analysis, parsing, intermediate code, optimization, code generation, implementation of lots of the stuff in the "Dragon book". Thus my Eiffel "Language Processor" is less than 30,000 lines of Pascal, which includes generating most of ELKS 95. And yes it does 90% of Eiffel, included all of Multiple inheritance with selects, generics, etc, etc, and is native code generating. But the compiler support stuff accounts for probably 200,000 lines worth. Who says you can't do serious stuff in Pascal? In another environment, I would do it in Eiffel. I can probably boast having the best Eiffel compiler 'not' on the market today! ------------------------------------------------------------------------ Ian Joyner | "for when lenity and cruelty play | All opinions are Internet email: | for a kingdom, the gentler | personal and are i.joyner@acm.org | gamester is the soonest winner" | not Unisys | William Shakespeare Henry V | official comment ------------------------------------------------------------------------
From: mshores@iastate.edu Newsgroups: comp.sys.next.programmer Subject: WM Inspector help... Date: 27 Jan 1997 14:28:09 GMT Organization: Iowa State University, Ames, Iowa Distribution: world Message-ID: <5cie1p$qfv@news.iastate.edu> Summary: WM Inspector help... (using bitmaps) Keywords: WM Inspector image bitmap Hello all, I am not certain that my pervious message was posted correctly, so I will post it again. I am having a problem getting a bitmap to appear when I create a WM Inspector. I understand that it is a bundle, and therefore different from an app, but even when I link in the bitmap, it still won't appear. Does anyone know how the programmer(s) of the 'lib' WM Inspector did it? (Thier logo appears next to some copyright info in the lower left hand corner) Thanks! Matt
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.sysadmin,comp.sys.next.programmer,comp.sys.next.software Subject: Re: vgrind help? Problem solved! Date: 27 Jan 1997 15:02:05 GMT Organization: The Ohio State University Message-ID: <5cig1d$bm8@charm.magnus.acs.ohio-state.edu> References: <5bltdk$ioq@charm.magnus.acs.ohio-state.edu>?nus` <5cfv2r$lf6@papoose.quick.com> In-Reply-To: <5cfv2r$lf6@papoose.quick.com> Thank you Mr. Quick! Your response solved my vgrind problem. And here I thought big and little endian problems were mostly a thing of the past. Silly me. Randy J On 01/26/97, James E. Quick wrote: >In article <5bltdk$ioq@charm.magnus.acs.ohio-state.edu>, >Randy Jackson <randyj@lubra.sbs.ohio-state.edu> wrote: >>When I try to use vgrind, I get the following: >> >># vgrind area.cc >>pscat: trouble reading .ct file >>lpr: stdin: empty input file >># >> >> >>What do I need to do to so that vgrind works? > >Ahah . . . You did not mention what architecture or version you >are using but it sounds to me like you are on an intel box. The @?Correct assumption.@ >transcript font files are endian dependant, and I think that they >are compiled bigendian on the CD. What you need to do is rebuild >these fonts. > >This is complicated somewhat by the fact that the script used for >rebuilding includes a configuration script which hardcodes a path >specific to the original source environment, not the installation >environment. > >Try this: >cd /usr/lib/transcript/troff.font > >Modify the script fragment ./config so that: > PSLIBDIR=$REALPSLIBDIR > >Now move the current font directories out of the way since the build >script will not build a new font directory if the old one is in place. > mkdir old > for map in *.map > do $dir=`basename $map .map` > mv $dir old/ > done > >Now that you have moved the old font directories out of the way, >build new ones. > for map in *.map > do $dir=`basename $map .map` > ./addtroff.sh $dir $map > done > >Now if you are satified, you can now delete the old dir. >-- > ___ ___ | James E. Quick jq@quick.com > / / / | Private HealthCare Systems NeXTMail O.K. >\_/ (_\/ | Systems Integration Group (617) 895-3343 > ) | "I don't think so," said Rene Descartes. Just then, he vanished. > -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: randyj@lowana.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Novice PB question Date: 28 Jan 1997 02:35:30 GMT Organization: The Ohio State University Message-ID: <5cjoli$lo0@charm.magnus.acs.ohio-state.edu> Since NS 1.0, and from then until now, I have written c++ code on the next, without bothering with the GUI. I decided today to give Project Builder a try, so I followed the directions in Chapter 15 for Simple.app -- yes, I have problems with simple.app! When I get to the point of building the code, I get the error: invalid option -lang-objc But for the life of me, I don't see where I am specifying that option. Is there a default set of compiler options that PB calls, (I don't see CFLAGS defined in any of the three makefiles). Most importantly, what do I need to do to get past this problem? Thanks. Randy -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu
From: aconti@interaccess.com (Aaron J. Conti) Newsgroups: comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.misc Subject: miscTableScroll object in the MiscKit Date: Mon, 27 Jan 97 10:35:08 PST Organization: InterAccess, Chicago's best Internet Service Provider Message-ID: <5cilns$ddn@nntp.interaccess.com> Mime-Version: 1.0 I am trying to use the table scroll from the miscKit. So far, I have used it in a couple different programs. Every time that I have used it so far, it has only been for displaying information. This allows me to fill all of the fields in the table programatically. Now I need to use it to display a list of item and let the user fill in values in the second and third columns. I can't seem to figure out what I am not setting to allow the user to select a single cell as apposed to a row and enter data into the cell. Any information on how to do this (or if it is impossible) would be appreciated. Please respond by e-mail to prichard@isdinc.com. I don't have reqular news access and had to borrow somebody else's account for this. Peter Richardson prichard@isdinc.com
From: flight@mathi.uni-heidelberg.de (Gregor Hoffleit) Newsgroups: comp.sys.next.programmer Subject: Re: Emacs for OpenStep Date: 27 Jan 1997 16:55:31 GMT Organization: InterNetNews at News.BelWue.DE (Stuttgart, Germany) Message-ID: <5cimm3$f03$1@news.belwue.de> References: <32E52CE3.1A0B@friday.com> <7x4tgay96w.fsf@burrow.muc.de> <32E779DF.2A65@friday.com> <32E97084.4C31@friday.com> Bill Bumgarner (bbum@friday.com) wrote: : Hmmm... still crashing. : I'll have to go and ping the next-emacs porting list and see where their : efforts stand-- I'd much rather run 19.34 than 19.28 anyway. http://nice.ethz.ch/~chris/emacs.html and ftp://nice.ethz.ch/pub/emacs-for-ns/ Thanks to Christian Limpach, the Emacs-for-NS beta version is now based on GNU Emacs 19.34b. On the ftp site, you'll find a patch for OS. It's supposed to work. Gregor -- | Gregor Hoffleit Mathematisches Institut, Uni HD | | flight@mathi.uni-heidelberg.de INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771 fax 54-8312 | | PGP Key fingerprint = 23 8F B3 38 A3 39 A6 01 5B 99 91 D6 F2 AC CD C7 |
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:00:13 -0500 Organization: Atria Software Message-ID: <maury-2701971200130001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c16dv$586@dismay.ucs.indiana.edu> <maury-2101971157140001@199.166.204.230> <EmtHxhi00iV0Q5bK5h@andrew.cmu.edu> In article <EmtHxhi00iV0Q5bK5h@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Besides, which other platforms are you talking about besides NT? Last > time I checked, OpenStep on top of Unix was available for pretty much > every hardware platform available nowadays. I'm not talking about OpenStep, just OS's in general. Maury
From: sams@best.com (Samuel G. Streeper) Newsgroups: comp.sys.next.programmer Subject: Re: Calling ObjC from C function... Date: 27 Jan 1997 18:44:29 -0800 Organization: BEST Internet Communications Message-ID: <sams.854418885@shellx> References: <32ec3ca9.0@192.33.12.30> jklein@freon.artificial.com (jon klein) writes: >if I'm using some code that is best done (or only done, in this case) >in C, how can I get back to objective C code. Here's my situation... There's no real problem with going back to objc syntax; From the BackSpace example: void timedEntryFunction (DPSTimedEntry timedEntry, double timeNow, void *theObject) { [(id)theObject doDistributorLoop]; } The real problem is that "self" is a hidden argument in all method invocations, so if you try this: myFunction() { [self doSomething]; } The compiler will not know what self is. Best way is probably to pass it in as an argument: myFunction(id self) { [self doSomething]; } Only other thing is to make sure the compiler is in objective-c mode, which it wouldn't be by default on a ".c" file, but it would be on a ".m" file. I just rename sources to make the right thing happen automatically, but you could turn it on with the appropriate compiler flag. (If memory serves, it's something like "-objc") cheers, -sam
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:38:42 -0500 Organization: Atria Software Message-ID: <maury-2701971238420001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bmjkk$p15@dismay.ucs.indiana.edu> <maury-1701971140380001@199.166.204.230> <5bp3f3$1j2@dismay.ucs.indiana.edu> <maury-2001971519140001@199.166.204.230> <8mt0xGe00iV0I52lR_@andrew.cmu.edu> <maury-2101971149510001@199.166.204.230> <MmtJU5W00iV0A5bPoY@andrew.cmu.edu> In article <MmtJU5W00iV0A5bPoY@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Unix operating systems need Unix shells and Unix utilities to function. Current Unix OS's yes. Unix didn't support a GUI in the past either. Now it does. Are you proposing that because current Unix systems need these old command line utilities that every one from now on should rely on them too? Or do you think that no one should try to make it better? > Rhapsody needs to be a Unix operating system because Unix is a crucial > component that provides the operating system functionality that was > missing in MacOS which Apple believes people want. (And not just > current Mac users, either but _new_ users....). And so does NT. > It may well be true that most people don't ever want to use Unix > directly. That's why Apple choose to buy NeXT, since NEXTSTEP does the > best job of providing the functionality of Unix while still providing a > very user-friendly environment that allows normal users to do their work > without ever having to see or think about Unix _if_ they don't want to. Oh I agree. > But, if using Unix is so abhorrent to you, you have alternatives-- you > could stick with MacOS 7.x, or switch to Windows NT. I'm not saying Unix is bad Chuck, I'm saying it could be better. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:22:01 -0500 Organization: Atria Software Message-ID: <maury-2701971322010001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <5c46k6$ma0@ds2.acs.ucalgary.ca> In article <5c46k6$ma0@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca (Blake Stone) wrote: > Why you're wasting so much time advocating something that doesn't > exist and isn't likely exist in the near future. You might as > well advocate teleportation over automobiles for all the good > it's likely to do. Geee, there's a worldview I like: nothing's going to change, don't bother trying. I suppose I should waste my time on something more constructive? Smoking perhaps? > I would _love_ to see a complete OO paradigm used to completely > reinvent a modern operating system API Great! > I think that you are > hopelessly underestimating the effort involved. Perhaps, Be did it, then ported it to a new platform, then another, in three years. They had to do the hard part to, write a new GUI to go with it, their own kernal, and a new file system too. > Microsoft has > just begun the chore and even though they've got money to burn > they don't expect to be done any time soon. NT's running just fine actually. > You mean aside from your stating that it would make life easier > for developers and make the system more cross platform if they > were removed? Replaced. Replaced. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 12:40:47 -0500 Organization: Atria Software Message-ID: <maury-2701971240480001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <gmt17KG00iV0A52nk5@andrew.cmu.edu> <maury-2101971151450001@199.166.204.230> <omtJeke00iV0A5bQJe@andrew.cmu.edu> In article <omtJeke00iV0A5bQJe@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Are you claiming that removing functionality does make programming > easier, or that you have not suggested removing functionality by making > the Unix utilities optional? Are you claiming that I have ever said anything even remotely like this? > An API stands for "application programming interface" and it refers to a > convention by which a software component is used by other software. The > Unix utilities have an API defined for their command line usage. OOPS API's. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:32:39 -0500 Organization: Atria Software Message-ID: <maury-2701971332390001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> In article <5c4pde$s64@bignews.shef.ac.uk>, mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > "The PC market doesn't want Unix any more than the Mac market does." So far so good. > I submit that Linux's success refutes this statement, and your subsequent > post does not alter this. What success? Can you provide solid numbers of any sort? Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:44:27 -0500 Organization: Atria Software Message-ID: <maury-2701971344270001@199.166.204.230> References: <5c5dce$f0q@ds2.acs.ucalgary.ca> In article <5c5dce$f0q@ds2.acs.ucalgary.ca>, bstone@acs3.acs.ucalgary.ca (Blake Stone) wrote: > "In fact, I've been constantly and unwaveringly suggesting that > all of them should indeed be API's, when in the current case they > are not." Because I think this is the way the system should evolve? > I'm not sitting around waiting for it to happen. Instead, I > wrote the ThreadKit for OOing the threading APIs in Mach. Great! > wrote a standard object interface for card games, which became > the definitive NeXTSTEP Solitaire. Fab! > I wrote object interfaces to > hide the differences between CGI and ISAPI. Great! (what is the later BTW?) > I've translated the > object interfaces to DirectX to Delphi. I've written wrappers to > hide MAPI behind an object interface. Great, keep it up! > I'm making it better as fast as I can. I just don't expect to be > done any time soon. What have you been doing? Debating Unix users who think it's a stupid idea, impossible, unlikely or not important. You are apparently not one of them. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:40:46 -0500 Organization: Atria Software Message-ID: <maury-2701971340460001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <Mmt0c0i00iV0052yVd@andrew.cmu.edu> <maury-2101971141510001@199.166.204.230> <32E5F50A.2637@spvi.com> In article <32E5F50A.2637@spvi.com>, steve@spvi.com wrote: > OK.. so what happens when I get my shiny new GUI app that expects > 'system("tar cf - *.gif | mail .... )' to work and the user neglected to > install 'tar'? This is the _point_ Steve. GUI apps should not have to call things like 'system("tar cf - *.gif | mail .... )' to work, they should be able to call OOPS libraries to work, ones that work on any platform. If that OOPS library then turns around and calls 'system("tar cf - *.gif | mail .... )', hey, fine. But as soon as you _base_ your code on it you're less portable. > want to risk breaking so much code? I would think the whole spiel > compares in size (more or less) to a complete installation of any modern > office productivity suite. :-) Probably smaller in fact. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:42:18 -0500 Organization: Atria Software Message-ID: <maury-2701971342190001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <maury-2001971529140001@199.166.204.230> <5c1cb7$nhr@duke.squonk.net> <maury-2101971209420001@199.166.204.230> <jinx6568-2201971125520001@news.sover.net> In article <jinx6568-2201971125520001@news.sover.net>, jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) wrote: > Isn't forking preferable when you consider a multiprocessing system > that could toss the forked process off to another processor? There's no real difference actually, if the libraries are "correctly" written. All of the newer Apple code has been for a few years now. Maury
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sun, 19 Jan 1997 12:55:06 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <AmsZzuG00iWTI1JC5T@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> In-Reply-To: <5bm1pa$i8u@geraldo.cc.utexas.edu> Excerpts from netnews.comp.sys.next.advocacy: 16-Jan-97 Re: MacWorld Exclusive: App.. by William Raphael Hix@port > Donald R. McGregor (mcgredo@crl.com) wrote: > : 3. I think all the unix utilities oughta be in there, in their > : full glory and grime. > > The existance of a lot of Unix utilities in Rhapsody would be a > tremendous disincentive to some Mac developers to port their software > to the new OS. Umm, why? I'd really love to hear someone give a coherent explanation. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:27:12 -0600 Organization: mementech, inc. Message-ID: <32ED0190.3748A5A6@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <5c4as9$4m2@duke.squonk.net> <maury-2701971329320001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > Garance A Drosehn > > Note that I'm serious that I want the abilities which happen to be > > in the unix utilities, and I want Rhapsody released this year. > > Me too. I also want it to get better in the future. > > > you have an alternate source for all these utilities, one which > > will not delay Rhapsody, that might well be fine with me (depending > > on how good the replacement is, I guess). However, I think your > > position would be much more crediable if you could point at a > > specific alternate source for all these utilities. > > Hmmm, I don't know if I can, although Be provides many of them > in it's OS. This is true. Be provides them through a vanilla bash shell on a standard CLI. Be's limited POSIX support is enough to get many standard unix utilities to run. One can also write CLI programs using classes from Be's framework. The same is true for CLI programs on NeXTstep. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: Re: brk and sbrk Date: 27 Jan 1997 17:35:46 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5cip1j$aln@netty.york.ac.uk> References: <5c7pr0$4e6@crcnis3.unl.edu> On 23 Jan 1997 13:41:51 GMT, Rex Dieter <rdieter@math.unl.edu> wrote: > I'm involved in a software porting venture... the software at hand uses the > functions brk and sbrk. The NEXTSTEP man pages say these functions are not > supported. Are there any other functions available to provide similar > functionality? they might not be documented, but they are still there. if you're not worried about portability to non-mach-based openstep platforms, then i'd just go ahead and use them in the same way as usual. rog.
From: jsamson@istar.ca (Jean-Paul C. Samson) Newsgroups: comp.sys.next.programmer Subject: Communicating with Subprocesses (NSTasks) with NSPipes Date: 27 Jan 1997 17:45:25 GMT Organization: iSTAR Internet Incorporated Message-ID: <5cipjl$li@news.istar.ca> I've been trying to figure out how to create a subprocess and then communicate between the main and this child process in OPENSTEP. NSTask provides functionality for starting up a subprocess and connecting pipes to its standard input and output. However, in the main process I need to be able to watch the incoming pipe for data. NEXTSTEP used to have a DPSAddFD() function to have the Display PostScript server trigger a handling function when data was received via a file descriptor. This function no longer exists in OPENSTEP. I can find no documentation on NSPipes or NSFileHandles. The conversion scripts example uses the out-of-date and unavailable NSPosixFileDescriptor class to mimic the DPSAddFD() behavior. Does anybody know how I can achieve the equivalent to DPSAddFD() using NSPipes? -- -===================================================================- Jean-Paul C. Samson -=- jsamson@istar.ca -=- NeXTmail & MIME welcome -============- http://www.cs.ualberta.ca/~jeanpaul/ -=============- -===================================================================-
From: Michael.Gentry@spammers.not.welcome Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 27 Jan 1997 19:33:02 GMT Organization: InternetMCI Message-ID: <5civte$dd1@news.internetmci.com> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E3A1E1.7BC@nowhere.com> <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <32E8F5E9.2620@nowhere.com> In-Reply-To: <32E8F5E9.2620@nowhere.com> On 01/24/97, Michael Hudson wrote: >I can think of another reason why C++ took off, rather than >Objective-C: >That looks nothing like C. >C++ code (unless it's very templatey) looks much like C. >I have never coded in pure C, but I'd say that the fact that C++ can >look like C must have made the transition less scary for many people. Funny, I know ANSI C quite well, and I think C++ looks quite intimidating and unlike C. I dabbled in C++ a little, thinking it was the "thing" to learn, and was quite intimidated and frustrated by it. For me, C++ was quite an unfriendly beast and seemed to promote the worst features of C through new and obscure syntax (not to mention adding it's own "bad" elements -- like method implementations in the interface). Objective-C was so easy to learn (a day or two, tops), I never had time to be intimidated or experience feelings of resentment. Instead, I was able to focus on OO concepts with a simple and rather ANSI C-like language (my opinion, I'm sure). - mrg (michael DOT gentry AT mci DOT com) -- "We love Java, but we believe in choice." - Brad Silverberg, Microsoft Corporation, December 1996
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:14:39 -0500 Organization: Atria Software Message-ID: <maury-2701971314390001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <SHESS.97Jan21090558@howard.one.net> <maury-2101971218370001@199.166.204.230> <SHESS.97Jan21213327@slave.one.net> In article <SHESS.97Jan21213327@slave.one.net>, shess@one.net (Scott Hess) wrote: > Sorry, perhaps I need to clarify - I'm not arguing about whether Unix > utilities _should_ be converted to OOP libraries. I'm telling you why > they _won't_ be so converted. I wouldn't be quite so sure personally. With the ability to drive the market one can do wonders. No one in the Unix community can really do this as it stands. Actually, they could, but they are spending time on other portions of the OS as it stands, like GUI implementation and such. Nothing wrong with that, programming costs money. > The secret, here, is that Unix has a very hard restriction on > communications at a very low level. For the most part, communication > is either via stream input, stream output, or command-line arguments. > Any program, to be useful, has to come in under that bar. For that > reason, I don't _have_ to understand the entire collection of Unix > utilities, I only have to understand those I use. Ok, with you so far. > For a 1:1 library which provided a suitable stream abstraction, things > would be just the same. On the other hand, a library which was that > faithful to the source would be almost useless. I think that's just about what this thread has been about actually. The problem is the lack of standardization at that stream level though, there are lots and lots of methods for solving the problem, which is the same problem as having none in this particular case. > For instance, take your directory-listing API. Under Unix, you > essentially end up with a stream of bytes. Very simple. With an API, > you'd want a stream of objects of some sort which would represent > files. From there you'd query the file objects for various info you > were interested in, probably using LISP mapcar style semantics. This > is already quite a bit more complicated than a stream of bytes. Only if you wish to display that as a list of bytes. I agree that it's not trivial to make the streams look like "old" streams from the old utilities, but it doesn't strike me as particularly difficult either (flattening objects isn't all that hard, the reverse is not so easy). Regardless it seems self-evident that it's harder to go the other way than back. The Mac does a fine job of streaming out text directories (try this: View by Name, Select All, Copy - now check your clipboard) when needed as well as offering a richer structure than ls when it's not. (Now one feature I'd love in the Finder would be the Be-like ability to change the filtering of the directory's contents in the window title bar) > Beyond that, though, you need to make certain that things work in > entire frameworks. For instance, the directory-listing API should > easily extend into the find(1) type API, and also into the > file-manipulation API, and file-access API, etc, etc. An API thus has > a significant amount of under-the-surface structure which makes > everything work together. I think the goal would be to make a system that gave you all the abilities and was not necessarily have backward compatibility as it's first concern - that would be the function of the wrappers. Many of the command line utilities (and the code base of the shell's themselves) seem to be overly concerned with string manipulation - great in CLI's, but useful all around for sure. I'm thinking of things like Perl's internal string stuff, grep, even one-offs like indent, cat etc. Aside from their interaction with the file system (like find or ls) most of these could easily be duplicated in a single string object, or a string object with an associated searching class(es). Where the commands do intersect with the file classes, some of the issue is solved by having the string like portions of the file system be strings. Now before anyone tells me how impossible (or even unlikely) this is, Be is doing it. Now. > That structure _will_ make the framework harder to understand. Any > specific operation is likely to be harder to understand, though once > you get the "hang" of it, you can probably do pretty well. But the > learning curve will necessarily be steeper than command-line Unix. I really don't believe this at all. For instance MacPerl gives you Perl on the Mac. It's Perl, and it works on the Mac's psuedo-OO file system. And Be takes it the next step from there. > [Keep in mind that we're talking an entire system of frameworks that > have to work together. Millions of lines, at a minimum, and I'd > expect the class count to be in the thousands - let alone the method > count!] Oh now here I really disagree, I think the resulting class structure would be quite small. Maury
Newsgroups: comp.sys.next.programmer From: jmpiuze@qc.bell.ca (Jean-Marc Piuze) Subject: [Q] Where can I find SYLK specifications Message-ID: <E4oAnG.44D@on.bell.ca> Sender: news@on.bell.ca (news admin) Organization: Bell Sygma Solution Telecom Date: Mon, 27 Jan 1997 15:21:16 GMT Even after using many shearching engines, I still can't find-out specifications of the SYmbolic LinK file format!... I wish to write information for spreadsheet directly in SYLK format (ascii like). Is there any web site releasing this information? Or there isprobably books about this!? Anyone can help? Please send me a short email.. Thank's! Bye, jmpiuze
Newsgroups: comp.sys.next.programmer From: fgalot@x-lan.alienor.fr Subject: Pb while drawing a matrix! Message-ID: <E4oFuH.857@x-lan.alienor.fr> Sender: news@x-lan.alienor.fr Organization: x&lan Date: Mon, 27 Jan 1997 17:13:29 GMT I'd like to add a TextFieldcells matrix to a custom object. But it appears that my matrix is displayed in the superView and in my object!!! The way I create my object: { [[superView window] disableFlushWindow]; newObject = [TexteVariableMulti alloc]; [newObject initFrame:&newRect ....]; [superView addSubview:newObject]; [newObject display]; [[[superView window] reenableFlushWindow] flushWindow]; break; } Where : @implementation TexteVariableMulti - initFrame:(NXRect *)frameRect .... { [super initFrame:frameRect text:text alignment:mode]; [self calcLine]; [self setOpaque:YES]; /*allouer une matrice nbCol colonnes, ((nbVar-1)/nbCol)+1 lignes*/ matrixField = [[MatrixTxtVar alloc] initFrame:frameRect mode:NX_TRACKMODE cellClass:[TextFieldCell class] numRows:(int)(((nbVar-1)/nbCol)+1) numCols:nbCol]; [matrixField setCellBackgroundGray:1]; [matrixField setEnabled:NO]; [matrixField setEmptySelectionEnabled:YES]; [self addSubview:matrixField]; return self; } - drawSelf:(const NXRect *)rects :(int)rectCount { TextFieldCell *cellField; char buf[100]; int i,j; int lignes; int nbCellDess=0; NXRect frameMatrix; lignes=(int)(((nbVariables-1)/nbColonnes)+1); [self setClipping:YES]; [self setBackgroundGray:1]; PSsetgray(1); NXRectFill(&bounds); [self setFont:myFont]; [self setTextColor:couleurText]; [self setEditable:NO]; NXPing(); aRedessiner = NO; NXEraseRect(&bounds); [matrixField renewRows:0 cols:nbColonnes]; [matrixField lockFocus]; for (i=0;i<lignes;i++) { [matrixField addRow]; for(j=0;j<nbColonnes;j++,nbCellDess++) { if(nbCellDess<nbVariables) { cellField = [matrixField cellAt:i :j]; [cellField setEnabled:NO]; [cellField setSelectable:NO]; [cellField setEditable:NO]; [cellField setBordered:NO]; [cellField setTextColor:couleurText]; [cellField setFont:myFont]; strcpy(buf,*(ptSurChaines+nbCellD ess)); [cellField setStringValue:buf]; } else { cellField = [matrixField cellAt:i :j]; [cellField setEnabled:NO]; [cellField setSelectable:NO]; [cellField setEditable:NO]; [cellField setBordered:NO]; [cellField setFont:myFont]; [cellField setStringValue:""]; } } } [matrixField sizeToFit]; [matrixField unlockFocus]; [matrixField moveTo:(*(rects+0)).origin.x+3 :(*(rects+0)).origin.y+3]; [matrixField getFrame:&frameMatrix]; [self sizeTo:frameMatrix.size.width :frameMatrix.size.height]; return self; } But if I do [superView display]; My object is displayed!!!! -- --------------------------------------- | O_O | O_O -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fred Galot fgalot@x-lan.alienor.fr
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 14:33:57 -0600 Organization: mementech, inc. Message-ID: <32ED1135.22DC2715@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > mmalcolm crawford <m.crawford@shef.ac.uk> wrote: > > > "The PC market doesn't want Unix any more than the Mac market does." > > So far so good. > > > I submit that Linux's success refutes this statement, and your > > subsequent post does not alter this. > > What success? Can you provide solid numbers of any sort? I think, since you were the one that asserted that the PC market doesn't want UNIX, that the burden to provide the figures is yours. Merely shrugging your shoulders and asking "where is it?" is not enough to support your claim. I'll give you a start, though. You can begin by adding the seats of intel boxes running any of the following: NeXTstep Solaris/x86 FreeBSD RedHat Linux Caldera Linux Debian Linux Slackware Linux Acme Linux generic download-the-source Linux NetBSD SCO Minix Don't be put off by the fact that this list seems to indicate that at least one person out in the PC world wants UNIX. That would be me. I'm single-handedly keeping all of them in business. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: enigma <llay@ieng9.ucsd.edu> Newsgroups: comp.sys.next.programmer Subject: Compiling C++? Date: Mon, 27 Jan 1997 18:47:21 -0800 Organization: University of California, San Diego Message-ID: <Pine.GSO.3.94.970127183159.23390D-100000@ieng9.ucsd.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi, This question is probably in a FAQ somewhere, but I just didn't know where to look... I'm using NSFIP 3.2 and trying to compile a C++ program for school. I thought NS has added support for C++ in addition to Objective C (which IMHO is far better than C++). Yet when I tried to compile the program, it gave me some sort of error about "reaching the end of the program" unexpectedly and complained about some undefined function/object/whatever. This program I'm trying to compile, compiled and runs successfully on the school's computer using g++ compiler--so it can't be something wrong with the source code... This send me digging through the developer's manuals, which only mentioned in passing about the "-x" option to cc for specifying the language. When I gave it the c++ language (as mentioned in the manual), it gave me error, saying unknown language. Since 3.2 don't come with g++ (does it come with newer version of OS?), I'm completely lost here. Any help appreciated. Thanks Luke.
From: andrewc@vasci.com (Andrew Cunningham) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.lang.pascal.mac,comp.sys.mac.programmer.tools,comp.sys.mac.programmer.misc,comp.sys.mac.programmer.games,comp.sys.mac.oop.misc,comp.arch.embedded,comp.lang.java.programmer,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: Mon, 27 Jan 1997 13:15:20 -0800 Organization: Vibro-Acoustic Sciences Inc Message-ID: <andrewc-2701971315200001@192.2.2.3> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> In article <MWRon-2701971033010001@aumi1-a12.ccm.tds.net>, MWRon@metrowerks.com (MW Ron) wrote: > METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY If anyone is interested in my experience (which has been quite positive overall) as a C/C++ Latitude developer feel free to email me. We have ported our application ,AutoSEA, to HP-UX and SGI. In a nutshell, Latitude gives you System 6.0.7 + 32 Bit Quickdraw plus a smattering of Syustem 7 API's. No magic there. Things that have no equivalent on a UNIX platform are just not there (e.g. Process Manager etc). The speed is pretty good - Latitude is a mature product that is now up to V3.x. I dearly hope Metrowerks provides SGI and (particularly) HP-UX C++ compilers as the native ones are bloody awful! Andrew -------------------------- Andrew Cunningham Vibro-Acoustic Sciences Inc 5355 Mira Sorrento Pl #100 San Diego CA 92121 USA Ph: +1-(619) 597 7535 Fax: +1-(619) 597 7414 e-mail: andrewc@vasci.com http://www.vasci.com -- Andrew Cunningham Vibro-Acoustic Sciences Inc Ph: +1-(619) 597 7535 Fax: +1-(619) 597 7414 e-mail: andrewc@vasci.com
From: "Thomas L. Ferrell" <f44@ornl.NoSpam.gov> Newsgroups: comp.sys.next.programmer Subject: Re: BASIC on NeXT? Date: 28 Jan 1997 06:28:51 GMT Organization: Oak Ridge National Lab Message-ID: <5ck6b3$mj9@stc06.ctd.ornl.gov> References: <5cebjo$h75$1@Venus.mcs.net> <5chi2o$gmm@belzebul.imaginet.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit See http://www.fys.ruu.nl/~bergmann/basic.html for Basic on all platforms. I think also that Chipmunk Basic has a UNIX port in progress, tho the Mac version is the best. tom Remove NoSpam from my email address to reply.
From: uli@tallowcross.uni-frankfurt.de (Uli Zappe) Newsgroups: comp.sys.next.programmer Subject: gdb displays double values incorrectly??? Date: 28 Jan 1997 01:42:00 GMT Organization: Frankfurt University Computing Center Message-ID: <5cjlh8$89j@tallowcross.uni-frankfurt.de> Hi, I just encountered the following problem: In a program I use a variable of the type double. While the program actually works correctly and e.g. fprintf(stdout, "%f", variable) prints out the correct value, gdb shows some variation in the low bits. E.g. 199701270707 (correct value) becomes 199701266432 in gdb's/Edit.app's variable browser. Is this a known bug, or what is it?? Any ideas/experiences? Thanks for any insight! Bye Uli -- ______________________________________________________________________ Uli Zappe E-Mail: uli@tallowcross.uni-frankfurt.de (NeXTMail,Mime,ASCII) PGP on request Lorscher Strasse 5 WWW: - D-60489 Frankfurt Fon: +49 (69) 9784 0007 Germany Fax: +49 (69) 9784 0042 staff member of NEXTTOYOU - the German NEXTSTEP/OPENSTEP magazine ______________________________________________________________________
From: Hal Bouma <hbouma@erols.com> Newsgroups: comp.sys.next.programmer Subject: Need advice for books Date: Mon, 27 Jan 1997 18:25:25 -0500 Organization: Bethesda Softworks Message-ID: <32ED3965.3B17@erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I'm finally getting a machine to run NeXTStep this week. (After a 3 year wait!) Since I haven't ran a UNIX based machine including NS before, I would like any advice for some good books on how to run a UNIX system (expecially any that deal with NS) along with any recommendations for books regarding programming for NeXTStep and Objective C. I would also appreciate information on where I might be able to buy these books, even if its to ask around on comp.sys.next.marketplace. I would prefer email responses, but I will stop by to read what is posted on here. Thanks! Hal Bouma hbouma@erols.com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 18:24:31 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> In-Reply-To: <5c6o55$ojc@geraldo.cc.utexas.edu> Excerpts from netnews.comp.sys.next.programmer: 23-Jan-97 Re: MacWorld Exclusive: App.. by William Raphael Hix@port > : There are some problems I see with that suggestion. Let me present just > : the ones that would affect Mac users and not discuss any of the problems > : that would affect Unix users. > : > : 3) Remember Copland? Apple already tried and _failed_ to write their > : own replacement operating system for MacOS 7.x. > : > : While the brain-trust they've gained by acquiring NeXT's engineers would > : undoubtedly be of assistance in creating a new operating system, NeXT's > : engineers have already created their own operating system to do > : preemptive multitasking, good virtual memory, and so forth-- NEXTSTEP, > : which is based off of a reasonably sophisticated Mach kernel and BSD 4.x > : Unix and GNU utilities. > > The problem with Copland was reportedly making the old Mac Toolbox work > on a modern kernal. OpenStep is to solve that problem, not necessarily > the rest of NeXTStep. Well, Apple didn't have to buy NeXT in order to have the OpenStep API be available. All they had to do was fix their operating system so that the MacOS had the minimum level of functionality (PMT, good VM, IPC, etc) required for OpenStep to work on a platform. Apple could have paid NeXT on the order of $10 - 50 million for NeXT to port OpenStep to the MacOS, or Apple could have implemented their own version, or they could even have helped the GNUStep project along. All three would have been much cheaper alternatives. Apple bought NeXT for more than just OpenStep. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 19:05:57 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <smvI=Zu00iWT8I_XpC@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <gmt17KG00iV0A52nk5@andrew.cmu.edu> <maury-2101971151450001@199.166.204.230> <omtJeke00iV0A5bQJe@andrew.cmu.edu> <maury-2701971240480001@199.166.204.230> In-Reply-To: <maury-2701971240480001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 27-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Are you claiming that removing functionality does make programming >> easier, or that you have not suggested removing functionality by making >> the Unix utilities optional? > > Are you claiming that I have ever said anything even remotely like this? I can only think of the above two ways of interpreting what you meant by your comment. If you want to restate what you meant more clearly, go ahead.... >> An API stands for "application programming interface" and it refers to a >> convention by which a software component is used by other software. The >> Unix utilities have an API defined for their command line usage. > > OOPS API's. I take it you acknowledge that the Unix CLI's do inf fact have an "API"? With regard to "object oriented", let's see: Modularity: Each Unix CLI utility is an object and we can combine them pretty freely. You can substitute different implementations of things like sort or grep (say GNU's for your vendor's) and not have to change anything, even through the new version may have a completely different internal implementation. Encapsulation: We're considering each utility as an object, and they encapulate their internal data very well (since each is a seperate process). Polymorphism: Well, we're using typeless ASCII with conventions like whitespace to seperate fields and CR and/or LF to indicate line breaks-- that implies we have some level of polymorphism, at least at the data level. However, the Unix CLI's do not have an inheritence hierarchy (except for a few exceptions along the lines of fgrep/grep/egrep). If you insist that OO has to have a predefined inheritence system, maybe they aren't fully OO. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 00:30:34 GMT Organization: Indiana University, Bloomington Message-ID: <5cjhba$54s@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> NNTP-Posting-User: glhansen In article <maury-2701971215410001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >> I can use fork()/exec() (which is more controllable in terms of handling >> stdin, stdout, etc that system()) on every POSIX-compliant operating >> system and every Unix system around. > > But that's a TINY portion of the computer market. A better solution >that's not platform dependant would allow easier access to the rest of the >market. MacOS and Unix pretty much *are* the computer market, except for Windows. Making MacOS 8 compatible with Unix is a no-brainer, since it practically *is* Unix. OS/2 is POSIX-compliant, so no problem there. BeOS is heading towards POSIX-compliance and can run Mac binaries anyway, so there's no problem there. They both have their own programming models that aren't compatible with anything else, so nobody else can use specially designed BeOS or OS/2 software anyway. But as long as the code is POSIX-compliant we can all share. So if we can use fork() and exec() and the rest of it, then we've cornered pretty much the entire market except for Windows. What about Windows? I really, REALLY don't want Apple to try to put the entire Windows API into the new MacOS and make it the standard programming model. Bad news. We have SoftWindows if we need it. Maybe MetroWerks will port PowerPlant to Windows and we'll have a common API. Or we could use Java. At any rate, I really don't think a Windows-compatible API is something Apple should try to work into the system. Given all of that, what's the problem with fork() and exec()? What can be a more generic way of implementing them? -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Dirk Vleugels <vleugels@do.isst.fhg.de> Newsgroups: comp.sys.next.programmer Subject: SPARC OpenStep & GCC Date: 19 Jan 1997 23:01:32 +0100 Organization: FhG ISST Dortmund, Germany Sender: vleugels@po Message-ID: <y7yhgkd5npf.fsf@do.isst.fhg.de> Hi, i installed OpenStep 1.0 on a Creator2 running Solaris 2.5.1, and i'm quite impressed. Question: I do have the header files NS* & stuff + the shared libraries: total 12108 lrwxrwxrwx 1 root other 14 Jan 19 03:25 libAppKit.so -> libAppKit.so.1* -rwxr-xr-x 1 bin bin 4282152 Aug 9 03:13 libAppKit.so.1* lrwxrwxrwx 1 root other 18 Jan 19 03:25 libFoundation.so -> libFoundation.so.1* -rwxr-xr-x 1 bin bin 1346060 Aug 3 04:04 libFoundation.so.1* lrwxrwxrwx 1 root other 20 Jan 19 03:25 libObjcSelector.so -> libObjcSelector.so.1* -rwxr-xr-x 1 bin bin 363328 Aug 3 04:04 libObjcSelector.so.1* lrwxrwxrwx 1 root other 18 Jan 19 03:25 libidlRuntime.so -> libidlRuntime.so.1* -rwxr-xr-x 1 bin bin 32508 Aug 3 04:04 libidlRuntime.so.1* lrwxrwxrwx 1 root other 12 Jan 19 03:24 libobjc.so -> libobjc.so.1* -rwxr-xr-x 1 bin bin 119316 Aug 3 04:04 libobjc.so.1* drwxr-xr-x 3 bin bin 512 Jan 19 03:25 locale/ Is it possible to develop software with the free GCC? Do i need the AppBuilder? I couldn't find a SUN ObjC compiler + OpenStep SDK. Any hints (please reply also by mail)? Dirk -- "It's 206 ms to Chicago, we've got a full disk of GIFs, half a meg of hypertext, it's dark, and we're wearing sunglasses." "Click it." -- <bluesbros@bluesbros.com>
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 19:47:52 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <AmvImse00iWT4I_dgv@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> In-Reply-To: <maury-2701971404290001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 27-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Correct. A multiuser computer system has conventions for where you >> should place common files (like applications, fonts, and other such >> resources) which are supposedly intended for use by all users. > > Well that about says it all. Computers should not do what we tell them > to, it should be the other way around and that's completely logical. Look, I'm not interested in defending a strawman position you've created yourself. Did I ever say that computers should not do what people tell them too? Conventions are developed by humans to provide a system of organization that can be used by computers to help humans work better-- but these conventions are human inventions. > FYI, the Mac allows you to stew most files around as you like, and has > no problems finding them, running them etc. This is true for both mutiple > and single user machines. Really? Let's consider a simple example, a file named 'Readme.doc'. Under a multiuser MacOS machine, how can one user double-click on that document and have it open in Word, while another user can double-click that precise same document (without changing any attribute of that document) and have it open in some other word processor? >> For that matter, single-user computer systems have some of those >> conventions too-- what else did you think the special nature of the >> "System folder" represents under MacOS? > > Something that should have been destroyed many moons ago. Maybe we should get rid of directories, too, and just have all of the files in one flat data space? Why did we ever come up with conventions to organize things in the first place? >> Are you willing to accept empirical evidence from the real world as to >> which of our respective definitions is more valid, or does that not >> interest you? > > _empirical_? No. That speaks for itself. > You wouldn't be either. I've run one too many beta test programs to not appreciate the value of real-world feedback even if it conflicts with my own opinions and theories. Just because you refuse to accept real-world evidence, Maury, does not mean that everyone else refuses to acknowledge consensual reality.... [ ... ] >> The point was, I was showing a real-world example of roughly as many >> Macs that did have a convention for filesystem layout as you stated that >> you were familiar with which did not have such a convention. And this >> refutes your attempt to claim that Macs in general do not have such >> conventions. > > Har! It does not at all refute it, you're arguing the general from the > specific! Really now. You made an existential claim-- that out of all of the hundreds of Macs you were familiar with, none of them had filesystem conventions. From this, you implicitly generalized that all Macs do not have such conventions, so Pohl's argument was therefore incorrect. However, all one has to do to refute an existential claim like yours is to find a single counterexample, as I did. The fact that I can point to lots of Macs (and other computers) and show machines with such conventions indicates that it's a standard practice, at least in some environments. [ ... ] -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 00:45:21 GMT Organization: Cygnus Support Message-ID: <5cji71$5lf$1@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> <5cjhba$54s@dismay.ucs.indiana.edu> Cc: glhansen@copper.ucs.indiana.edu In <5cjhba$54s@dismay.ucs.indiana.edu> Gregory Loren Hansen wrote: > What about Windows? I really, REALLY don't want Apple to try to put the > entire Windows API into the new MacOS and make it the standard programming > model. Bad news. We have SoftWindows if we need it. Maybe MetroWerks > will port PowerPlant to Windows and we'll have a common API. Or we could > use Java. At any rate, I really don't think a Windows-compatible API is > something Apple should try to work into the system. > No need to worry, Openstep for NT exists, and soon Openstep for Win95 will too. :-) Thus, there is a common API for MacOS8/Rhapsody and Windows, and it's not a compromise of "our side" of the fense. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: rr@xs4all.nl (rr) Newsgroups: comp.sys.next.programmer Subject: old NeXTStep version and PPP Date: Sat, 18 Jan 1997 02:11:46 +0100 Organization: XS4ALL, networking for the masses Message-ID: <rr-1801970211460001@ztm07-20.dial.xs4all.nl> Hi, This may not be the right place for these questions... My excuses in advance. I have a NeXTCube running an old version of NeXTSTep (2.x). I want to get my email with it. I also have a modem that came with it ( HSD InterFax 24/96 NX -not much but ok for just email, Iguess) I not sXXt about UNIX. I'm having a lot of trouble getting this setup to work for me. I want to get/send email. That's not too much to ask for such a beatifull machine. I gather I have to set up uucp. I find the manual not very clear on this, but maybe I'm just stupid. I'm also wondering if there is a version of PPP that will work with this old version of NeXTSTep. Does anybody know this ? Also, last the Cube with this version of NeXTStep doesn't seem to read macintosh-floppies the manual says it can with the help of some software, but doesn't state what or where to get it. Does anybody know this ? help is much appreciated, Rodney
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: cancel <32ec3ca9.0@192.33.12.30> Control: cancel <32ec3ca9.0@192.33.12.30> Date: 27 Jan 97 09:18:55 GMT Organization: University of Massachusetts, Amherst Message-ID: <32ec72ff.0@192.33.12.30> Article cancelled from within tin [v1.2 PL2]
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 22:20:07 -0600 Organization: mementech, inc. Message-ID: <32ED7E77.3C7FDC1A@screaming.org> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > Apple could have paid NeXT on the order of $10 - 50 million for NeXT to > port OpenStep to the MacOS, or Apple could have implemented their own > version, or they could even have helped the GNUStep project along. All > three would have been much cheaper alternatives. > > Apple bought NeXT for more than just OpenStep. I suppose that depends upon what one means when they say "for OpenStep". On the one hand, Apple could have used it for free, or less expensively. On the other hand, if they bought NeXT for the ownership of that API, they could have still done it just "for OpenStep". Perhaps I'm picking nits, but I think that ownership of the API was implied. Of course, we know damn well that OpenStep is not the only NeXT technology or resource that Apple went sweet on. In order to maintain a clear message, they have to stress OpenStep above all else, but we'll see them promote more of their acquired technology once they've survived the transition. They know what assets they've purchased, including the talent of NeXT's engineers. OpenStep is merely the main course. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: svenifer@snet.net Newsgroups: comp.sys.next.programmer Subject: Converting ascii or dbf to objects? Date: 28 Jan 1997 14:21:12 GMT Organization: "SNET dial access service" Message-ID: <5cl20o$8cj@goofy.snet.net> Any advice on what classes I would use to read in data files in ascii or dbf format to create objects which would later be NSarchived. I am using OPENSTEP 4.0 Developer. Thanks Sven
From: svenifer@snet.net Newsgroups: comp.sys.next.programmer Subject: creating objects from ascii or dbf files? Date: 28 Jan 1997 14:25:47 GMT Organization: "SNET dial access service" Message-ID: <5cl29b$8g2@goofy.snet.net> Any advice on how create objects from ascii or dbf files using OPENSTEP 4.0? Thanks Sven
From: Lars Immisch <lars@ibp.de> Newsgroups: comp.sys.next.programmer Subject: Re: Need a little C-help Date: Mon, 27 Jan 1997 13:50:28 +0100 Organization: Immisch, Becker & Partner Message-ID: <32ECA494.4851@ibp.de> References: <199701250636.BAA05669@nerc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Timothy J Luoma wrote: > > I would like to change this bit of code for PPP > > I can't read C much, so I'm floundering here. > > Lines 16-20 are the ones which control the bringing down of the > link if the idle time has been met. > > I would like to replace the existing code with code which will: > 1) send a message to /dev/console saying "Idle time > exceeded, bringing down link" > > 2) execute "/usr/local/bin/pppdown" (preferably with the > UID and GID of use who started this all, but that isn't crucial) I don't know about /dev/console... Is that syslog entry not sufficient? About executing a script. Hmmm. The pppd I know already executes a script when the link goes down. It is called ip_down by default, but this can be overridden... Your pppd sources appear to be different from the ones I know, so be warned. The pppd sources I know have a function called run_program in main.c. This can be used to execute a script; as a model, have a look at ipcp_script() in ipcp.c. e.g, you would do something like: static void tjl_script(char* script, int unit) { char strgid[32]; char struid[32]; char* argv[3]; sprintf(strgid, "%d", getgid()); sprintf(struid, "%d", getuid()); argv[0] = script; argv[1] = struid; argv[2] = strgid; // run script with arguments argv, don't exit if it does not exist run_program(script, argv, 0, unit); } You would call this after, say, line 19 of your example as: tjl_script("/usr/local/bin/pppdown", 0); Lars -- mailto:lars@ibp.de http://www.ibp.de/~lars Yesterdays yellow yoyo can make you yawn today
From: logic@friley253.res.iastate.edu (???) Newsgroups: comp.sys.next.programmer Subject: Re: WM Inspector Question... Date: 28 Jan 1997 06:21:12 GMT Organization: Iowa State University, Ames, Iowa Message-ID: <5ck5so$lor@news.iastate.edu> References: <5cgjaq$9g7@news.iastate.edu> <5cihg4$fsr@castor.cca.rockwell.com> In-Reply-To: <5cihg4$fsr@castor.cca.rockwell.com> On 01/27/97, Erik M. Buck wrote: >In <5cgjaq$9g7@news.iastate.edu> ??? wrote: >> Hello all, >> I have a simple question: I would like to have a bitmap (on >> top of a button) in my WM Inspector Panel. > >Add the image to the images suitcase in IB. > > Erik, I am not sure if you got my EMAIL response, but I tried that, and it still cannot find it. I get no image. I check to make sure I wasn't setting the button as transparent or anything... is this a normal problem? Matt
From: Lars Immisch <lars@ibp.de> Newsgroups: comp.sys.next.programmer Subject: Re: Compiler version in newest OS? Date: Mon, 27 Jan 1997 17:27:10 +0100 Organization: Immisch, Becker & Partner Message-ID: <32ECD75E.A07@ibp.de> References: <5cigco$bou@charm.magnus.acs.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Jackson wrote: > > My understanding is that NeXT's compiler (cc) is comparable (derived from?) > some version of the gnu c compiler. I have NS3.2/3.3 Developer, and am > wondering whether the compiler that comes with 4.0 (or are we up to 4.1?) is > comparable to a more recent gnu compiler. A version number would answer my > question. Is it 2.7.2? 3.3's cc is gcc 2.2.2. I _think_ 4.1 still does not have 2.7.2, but this will hopefully be confirmed by someone who has 4.1. I am using gcc 2.7.2 on my 3.3 station, though. It is very easy to build a version from the source distribution on prep.ai.mit.edu I should note, however, that I do not use gcc 2.7.2 for Objective-C development or with ProjectBuilder-generated makefiles. -- mailto:lars@ibp.de http://www.ibp.de/~lars Yesterdays yellow yoyo can make you yawn today
From: far@ix.netcom.com(Felipe A. Rodriguez) Newsgroups: comp.sys.next.programmer Subject: Re: Calling ObjC from C function... Date: 28 Jan 1997 06:44:41 GMT Organization: Netcom Message-ID: <5ck78p$6at@dfw-ixnews3.ix.netcom.com> References: <sams.854418885@shellx> In article <sams.854418885@shellx> sams@best.com (Samuel G. Streeper) writes: >jklein@freon.artificial.com (jon klein) writes: >>if I'm using some code that is best done (or only done, in this case) >>in C, how can I get back to objective C code. Here's my situation... > >There's no real problem with going back to objc syntax; >From the BackSpace example: > >void timedEntryFunction (DPSTimedEntry timedEntry, > double timeNow, void *theObject) >{ [(id)theObject doDistributorLoop]; >} > >The real problem is that "self" is a hidden argument in all >method invocations, so if you try this: > > myFunction() > { [self doSomething]; > } > >The compiler will not know what self is. Best way is probably >to pass it in as an argument: > > myFunction(id self) > { [self doSomething]; > } > >Only other thing is to make sure the compiler is in objective-c >mode, which it wouldn't be by default on a ".c" file, but >it would be on a ".m" file. I just rename sources to make the >right thing happen automatically, but you could turn it on >with the appropriate compiler flag. (If memory serves, >it's something like "-objc") > >cheers, >-sam One thing I do is route through the app delegate: myFunction() { [[NXApp delegate] doSomething]; } -- Felipe A. Rodriguez # Francesco Sforza became Duke of Milan from Agoura Hills, CA # being a private citizen because he was # armed; his successors, since they avoided far@ix.netcom.com # the inconveniences of arms, became private (NeXTmail preferred) # citizens after having been dukes. (MIMEmail welcome) # --Nicolo Machiavelli
Newsgroups: comp.sys.next.programmer From: fgalot@x-lan.alienor.fr Subject: My color disappears when I paste ? Message-ID: <E4poIn.BEB@x-lan.alienor.fr> Sender: news@x-lan.alienor.fr Organization: x&lan Date: Tue, 28 Jan 1997 09:18:22 GMT I want to do a cut-paste with : paste => anObject=NXReadObject(stream); NXCloseTypedStream(stream); [vueFond addSubview:anObject]; [anObject display]; where : - read:(NXTypedStream *)typedStream { [super read:typedStream]; .... couleurText = NXReadColor(typedStream); .... } and : copy => NXWriteRootObject(stream, anObject); NXCloseTypedStream(stream); where : - write:(NXTypedStream *)typedStream { .... NXWriteColor(typedStream, couleurText); .... } But the first time the object is redrawn (there is [self setTextColor:couleurText]; there) there is no color??? Thanks for help. -- --------------------------------------- | O_O | O_O -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fred Galot fgalot@x-lan.alienor.fr
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 03:51:45 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cken1$6co@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2101971218370001@199.166.204.230> <SHESS.97Jan21213327@slave.one.net> <maury-2701971314390001@199.166.204.230> In article <maury-2701971314390001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > Now before anyone tells me how impossible (or even unlikely) this is, Be > is doing it. Now. Yeah, and how long is it going to be before Be has even _close_ to the number of utilities functions Unix has, neatly modularized in OOP libraries. A long, long, _long_ time. And a lot of the current Be utilities are actually Unix ones running under POSIX emulation. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: scholz@leo.org (Bernhard Scholz) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 28 Jan 1997 19:34:09 GMT Organization: Institut fuer Informatik der Universitaet Muenchen Message-ID: <5clkbh$7s1@xenia.informatik.uni-muenchen.de> References: <5b52nv$39e@news.xmission.com> <5b698t$qsa@flood.weeg.uiowa.edu> clay@herky.cs.uiowa.edu (Matthew Clay) wrote: > >Think virtual. If it can't be done with virtual member functions, then >think dynamic_cast. If it still can't be done, think type_info. Each is >is small, additional layer over C, so you pay for what you use. If you >need more dynamism, and a great many problems do not, C++ is a poor choice. Ah, blurb. Think practical. Objective-C is much more like Smalltalk and much easier to learn and understand than C++. Why should I think e.g. about virtual member functions or all the other shit, if I could write it in a unique way in Objective-C? You should definitly watch the Be developer corner, and look what problems they do have, because C++ is rather complex and doesn't allow you to simply implement your design. In Objective-C or Smalltalk (or other equal languages) you can take your design and simply write it down. In C++ you have to take a further step and think about how to write it down in C++. A mistake in C++ could block further development! IMHO practiced showed, that Objective-C (and much more Smalltalk) is the better choice. However the market promotes C++ (because it is more like C(!), yes this was the winner strategy). This comparance is like Windows to NEXTSTEP. Everybody who ever used both, knows which one is better --- but the market thinks different. Folks, this is getting to be and advocacy thread.... Greetings, Bernhard. -- Bernhard Scholz http://www.leo.org/~scholz/ Peanuts FTP Admin http://peanuts.leo.org/ scholz@leo.org, (StuSta ONLY: boerny@xenia.stusta.mhn.de)
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 14:12:26 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5clj2q$76p@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2701971314390001@199.166.204.230> <5cken1$6co@csugrad.cs.vt.edu> <maury-2801971223060001@199.166.204.230> In article <maury-2801971223060001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5cken1$6co@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > Yeah, and how long is it going to be before Be has even _close_ to the > > number of utilities functions Unix has, neatly modularized in OOP > > libraries. > Most of it's done as far as I can tell. Look again. BeOS is nowhere near as mature as Unix. The current OOP APIs have a lot of the core functionality of Unix's base API (e.g., POSIX), but the BeOS APIs do not encapsulate nearly as many utility routines as the Unix command-line programs. It does not have OOP replacements for all, or even many, of the Unix command-line utilities. > > A long, long, _long_ time. And a lot of the current Be > > utilities are actually Unix ones running under POSIX emulation. > Uhh, not really unless you look at raw numbers. I _am_ looking at raw numbers. What does "a lot" mean? Fake numbers? Obviously, the BeOS utilities which are written to the BeOS API are not the ones running under POSIX emulation. But BeOS does not have nearly as many native utilities. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Briones Garcia Jorge Alfonso <at138@solarium.cs.buap.mx> Newsgroups: comp.sys.next.programmer Subject: Looking for Examples Date: Tue, 28 Jan 1997 12:31:45 -0600 (CST) Organization: A Poorly Internet Site. Message-ID: <Pine.SUN.3.90.970128122950.477I-100000@solarium.cs.buap.mx> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII I am learning to programming in NEXTSTEP 3.1. I am looking for examples, if you have some please send to me. Any help would be greatly appreciated... Thanks.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 12:29:22 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <EmvXRme00iWU85Qrg9@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <32ED7E77.3C7FDC1A@screaming.org> In-Reply-To: <32ED7E77.3C7FDC1A@screaming.org> Excerpts from netnews.comp.sys.next.advocacy: 27-Jan-97 Re: MacWorld Exclusive: App.. by Pohl Longsine@screaming. >> Apple could have paid NeXT on the order of $10 - 50 million for NeXT to >> port OpenStep to the MacOS, or Apple could have implemented their own >> version, or they could even have helped the GNUStep project along. All >> three would have been much cheaper alternatives. >> >> Apple bought NeXT for more than just OpenStep. > > I suppose that depends upon what one means when they say "for > OpenStep". On the one hand, Apple could have used it for > free, or less expensively. On the other hand, if they bought > NeXT for the ownership of that API, they could have still > done it just "for OpenStep". Perhaps I'm picking nits, but > I think that ownership of the API was implied. Wasn't OpenStep (the API) submitted to a standards organization like OMG? OpenStep is not a proprietary standard that Apple can alter at will, although they certainly are the primary group responsible for improving the standard. > Of course, we know damn well that OpenStep is not the only NeXT > technology or resource that Apple went sweet on. In order to > maintain a clear message, they have to stress OpenStep above > all else, but we'll see them promote more of their acquired > technology once they've survived the transition. I didn't see that from the letters I've seen from Gil Amelio. The very first reason given for Apple acquiring NeXT is because they have complementary technologies and missing pieces. As Gil said, NeXT had a solid operating system that Apple can use, and Apple has a large installed base that gives NeXT users and developers some volume. > They know what assets they've purchased, including the talent of > NeXT's engineers. OpenStep is merely the main course. I'd agree with you, but I'm looking at this from the perspective of a developer who likes cross-platform API's which allow me to not have to maintain seperate code trees and have to work hard to port my software. The installed base of current Mac users appear to be looking for a more stable operating system from Apple, and most of them could care less about Unix or the CLI, and they probably aren't as interested in gaining OpenStep as they are a decent OS to go with their GUI, their current applications, and Apples' ease-of-use. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 22:11:45 GMT Organization: Global Objects Inc. Message-ID: <5cltj1$2nc@news.xmission.com> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> <jinx6568-2401971226320001@news.sover.net> <32E91CBE.56EF@exnext.com> <jinx6568-2501971040260001@news.sover.net> jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) wrote: > In article <32E91CBE.56EF@exnext.com>, jon@exnext.com wrote: > > NeXTSTEP's Open and Save panels default to your home directory, > > IIRC. So storing Edit documents in /NextApps would be more > > work than putting them in ~/Library, since you'd have to do > > more browsing to get there. > > Ah- that helps explain it. I _can_ set up my Mac to default to > 'documents' or something, but instead I've always had each app default to > the last folder used while in the app, which really reinforces my arguably > odd organizational procedures :) the control panel for doing this is > 'General Controls' by the way, for the few who aren't already going 'I > knew that, don't condescend to me' ;) > > Often this means that there is no browsing at all- I go to an app which > I've not used that much, and bam, it is anticipating me because the last > time I used it I was geared to a particular task and area. Similar task- > same area- no browsing. > > I bet they keep this as an option (which it currently is). One thing that _some_ NEXTSTEP apps have implemented--and I like this a lot--is a variable "set" of default directories for the Open/Save panel. When you first run the app, the default directory is your home, but you can add other directories to an extra pop-up menu that they added to the Open/Save panel. That way you have a list of places you can jump to really quickly. Sort of like a shelf for the Open/Save panel, but using up less real estate. I've found this to be handy in OpenWrite, since I can switch my "working" mode to change which group of documents I'm working on, etc. Another cool thing is the way you can drag a folder out of a WorkSpace browser and drop it on an Open/Save panel and the panel will jump to that folder, or the folder that houses the file you dropped on the panel... Definitely some improvements could be made to the standard OPENSTEP environment as far as this goes... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 12:38:05 -0500 Organization: Atria Software Message-ID: <maury-2801971238060001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> In article <AmvImse00iWT4I_dgv@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > >> Correct. [snip] > Look, I'm not interested in defending a strawman position you've created > yourself. Did I ever say that computers should not do what people tell > them too? Yes, as a matter of fact. You agreed with a statement by saying "Correct." at the first line there, and the statement I made was exactly that. > Under a multiuser MacOS machine, how can one user double-click on that > document and have it open in Word, while another user can double-click > that precise same document (without changing any attribute of that > document) and have it open in some other word processor? Use MEO, the prefs are stored locally. For single machine/multiuser situation you have the same problem and I'd love to hear what resources the Mac provides for mapping this on a per folder basis. > Maybe we should get rid of directories, too, and just have all of the > files in one flat data space? Why did we ever come up with conventions > to organize things in the first place? Now who's creating strawmen? > > _empirical_? No. > > That speaks for itself. That's right, I trust test results and numbers > I've run one too many beta test programs to not appreciate the value of > real-world feedback Real world feedback is not empirical because it can be quantified. > does not mean that everyone else refuses to acknowledge consensual > reality.... How existential of you. > You made an existential claim-- that out of all of the hundreds of Macs > you were familiar with, none of them had filesystem conventions. From > this, you implicitly generalized that all Macs do not have such > conventions, so Pohl's argument was therefore incorrect. No actually I was countering your claim that everyone that runs such systems has such standards. In fact I can now raise that (with a little reflection) to something on the order of 1000 Macs, none of which I know of have defined places in which to place files. Your claim: most networks do this My claim: hogwash Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 17:35:27 -0500 Organization: Atria Software Message-ID: <maury-2801971735280001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> <32EE7205.CCA9263@screaming.org> In article <32EE7205.CCA9263@screaming.org>, Pohl Longsine <pohl@screaming.org> wrote: > That's because it's largely meaningless. It means that NT customers > are relatively uninterested in the POSIX API, not that PC customers > are relatively uninterested in a UNIX OS. Well fair enough. But since those OS's (Win) form something on the order of 70% of the market share of OS's being sold today, that means the vast majority of the market doesn't want Unix. So fine, Linux could be up to 25%. Now let's see YOUR numbers. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 17:33:12 -0500 Organization: Atria Software Message-ID: <maury-2801971733120001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2701971314390001@199.166.204.230> <5cken1$6co@csugrad.cs.vt.edu> <maury-2801971223060001@199.166.204.230> <5clj2q$76p@csugrad.cs.vt.edu> In article <5clj2q$76p@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Look again. BeOS is nowhere near as mature as Unix. The current OOP > APIs have a lot of the core functionality of Unix's base API (e.g., > POSIX), but the BeOS APIs do not encapsulate nearly as many utility > routines as the Unix command-line programs. It does not have OOP > replacements for all, or even many, of the Unix command-line > utilities. Ok, let's see... it has a complete lib for file access, including documents and databases, as well as supporting powerful searching, sorting and information extraction from any of the objects in the data store. It has a complete string manipulation library too. Development is handled by CodeWarrior, so a lot of those utilities aren't needed. It seems we're down to some of the networking daemons now. > I _am_ looking at raw numbers. What does "a lot" mean? Fake numbers? How about total amount of time the user spends using them? Total number of invocations. Sure there might be 1000 unconverted Unix utils, but does anyone use them? Maury
Newsgroups: comp.sys.next.programmer From: spill@netcom.com (David Stein) Subject: Do I wait for OpenStep 4.2? Message-ID: <spillE4qtED.IJ3@netcom.com> Organization: Netcom On-Line Services Date: Wed, 29 Jan 1997 00:01:25 GMT Sender: spill@netcom.netcom.com I am about to purchase OpenStep 4.1 Enterprise Academic Bundle, which means that I get OpenStep and OpenStep Developer. I have just found out that Next is planning to release Developer 4.2 some time in February. Are there any glaring problems with OpenStep Developer (for NT) ver. 4.1 that I should know about? In other words, should I really care that 4.2 is coming out in less than a month? Will my life with 4.1 be miserable, while my life with 4.2 would be beautiful if I waited? Or, do I have nothing to worry about? What about OpenStep for Mach? Are there any terrible problems (besides NT look and feel) with Enterprise which Mach lets me avoid? Sincerely, David Stein spill@netcom.com
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 15:39:17 -0600 Organization: mementech, inc. Message-ID: <32EE7205.CCA9263@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > Pohl Longsine <pohl@screaming.org> wrote: > > > I think, since you were the one that asserted that the PC market > > doesn't want UNIX, that the burden to provide the figures is > > yours. > > Not really, because I did provide strong evidence in the form of NT. > NT's POSIX support has either been muted or removed entirely in 4.0 (along > with support for OS/2 text mode programs and OS/2's HPFS disk format as > well) and yet no one said a thing. That's because it's largely meaningless. It means that NT customers are relatively uninterested in the POSIX API, not that PC customers are relatively uninterested in a UNIX OS. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: EOF 2.0, EOModeler crashes Date: Tue, 28 Jan 1997 11:52:36 +0100 Organization: Microcomp GmbH , Cologne, Germany Message-ID: <32EDDA74.6BF@microcomp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo ! Openstep 4.1 for NT, EOF 2.0 I tried 'Create subclass' in EOModeler. After assigning new class name for subclass, the inspector for setting parent class includes all records duplicate and it is impossible to save such model. (Error: NSConcreteMutableArray index(1) beyond bounds) Does anybody has experience with it ?
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 20:53:21 GMT Organization: Indiana University, Bloomington Message-ID: <5clp01$7tq@dismay.ucs.indiana.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2701971215410001@199.166.204.230> <5cjhba$54s@dismay.ucs.indiana.edu> <5cji71$5lf$1@majipoor.cygnus.com> NNTP-Posting-User: 1073745024 In article <5cji71$5lf$1@majipoor.cygnus.com>, John Rudd <jrudd@cygnus.com> wrote: >In <5cjhba$54s@dismay.ucs.indiana.edu> Gregory Loren Hansen wrote: >> What about Windows? I really, REALLY don't want Apple to try to put the >> entire Windows API into the new MacOS and make it the standard programming >No need to worry, Openstep for NT exists, and soon Openstep for Win95 will >too. :-) > >Thus, there is a common API for MacOS8/Rhapsody and Windows, and it's not a >compromise of "our side" of the fense. Let me see if I understand you correctly. There is a single OpenStep API that handles menus and managing windows and dialog boxes and memory allocation and printing and disk drives and networking and threading and everything else you'd do with the OS, and it will work correctly whether that program be compiled under MacOS or Windows or Linux or whatever else you're running? There are equivelants in OpenStep to fork() and exec() and GetNewCWindow() and TrackGoAway() and everything? If all of that's true, I'd have no problem just keeping POSIX for compatibility reasons while everyone else programs under OpenStep. But considering Maury's point of having something besides fork() and exec() for compatibility with a wider range of machines, I still think Unix machines and Unix software outnumbers OpenStep running on NT/95. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Multiple classes for single entity ? Date: Tue, 28 Jan 1997 12:06:51 +0100 Organization: Microcomp GmbH , Cologne, Germany Message-ID: <32EDDDCB.6877@microcomp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo ! In EOF 1.0 was possible to let superclass choose subclass to instantiate for each row. It was implemented by overwriting the method -initWithPrimaryKey:entity: and the choice was based on primary key. (EOF DeveloperGuide 1.0, pages 51-52) I tried the same in EOF 2.0 with the method -initWithEditingContext:classDescription:globalID but this doesn't work. Any ideas ? Petr
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 15:05:48 -0600 Organization: mementech, inc. Message-ID: <32EE6A2C.3F304074@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-2101971218370001@199.166.204.230> <SHESS.97Jan21213327@slave.one.net> <maury-2701971314390001@199.166.204.230> <5cken1$6co@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Nathan M. Urban wrote: > maury@softarc.com (Maury Markowitz) wrote: > > > Now before anyone tells me how impossible (or even unlikely) this > > is, Be is doing it. Now. > > Yeah, and how long is it going to be before Be has even _close_ to the > number of utilities functions Unix has, neatly modularized in OOP > libraries. A long, long, _long_ time. And a lot of the current Be > utilities are actually Unix ones running under POSIX emulation. ^^^^^^^^^^ There's that misused word again. No offense meant, but those POSIX calls are genuine, bonafide system calls, as with any other POSIX implementation. No emulation involved. At worst, some of them may be wrappers for more general calls. At any rate, Be's class hierarchy will probably be a lot more interesting in about 10 years, assuming they can break out of their C++ funk. ;-) -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 19:47:30 -0600 Organization: mementech, inc. Message-ID: <32EEAC32.5D8EEA06@screaming.org> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> <32EE7205.CCA9263@screaming.org> <maury-2801971735280001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > Pohl Longsine <pohl@screaming.org> wrote: > > > That's because it's largely meaningless. It means that NT customers > > are relatively uninterested in the POSIX API, not that PC customers > > are relatively uninterested in a UNIX OS. > > Well fair enough. But since those OS's (Win) form something on the > order of 70% of the market share of OS's being sold today, that means the > vast majority of the market doesn't want Unix. > So fine, Linux could be up to 25%. Now let's see YOUR numbers. I need show you no numbers. I made no claim, let alone one so subjective as the size of the pie slice required for a product to be called "wanted" by a particular market. You think 70% is about it, huh? Might it depend upon the size of the pie, perhaps. Maybe also the rate of growth of the pie? Would it not also depend upon the rate of piracy for those systems, and the rate at which Windows is replaced by Linux on second-hand systems? Might the statistic be skewed the fact that Microsoft's sales figures include a copy of Windows per every PC that shipped to a consumer who installed something else over it? Does your statistic cover international use of Linux on PCs? I think the PC market is sufficiently difficult to analyze that statements like "The PC market does not want UNIX" are devoid of meaning. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: David Matiskella <davidm@netscape.com> Newsgroups: comp.sys.next.programmer Subject: Re: MacWorld Exculsive: Apple's OS Plan Unveiled!!! Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 16:46:15 -0800 Organization: Another Netscape News Server User Message-ID: <32EE9DD1.4A9B@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > > FYI, the Mac allows you to stew most files around as you like, and has > > no problems finding them, running them etc. This is true for both mutiple > > and single user machines. > > Really? Let's consider a simple example, a file named 'Readme.doc'. > > Under a multiuser MacOS machine, how can one user double-click on that > document and have it open in Word, while another user can double-click > that precise same document (without changing any attribute of that > document) and have it open in some other word processor? Oh this is easy. Just drag word to the Trash can and empty the trash. When you double click on the application it will say that it can't find the application and it will ask you which application you want to use. While I wouldn't recommend doing this it doesn't modify the document. The MacOS really wasn't designed for more than one user in the current version. IE each of your users has to go through quite a bit of effort to have their own customized look and most applications only have 1 set of preference files. This is a relatively easy problem to fix and it by no means depends on fixed locations for applications and so on. In fact Copland was supposed to handle multiple users with different preferences. I would guess that it will make it into Raphsody. I would also bet that you will not by default get a login prompt when you boot up Raphsody since a lot of Apples customers don't need/want it. Why don't we debate the really important questions like "How many buttons is the mouse going to have?" or "How many CLI programs will barf upon seeing mac file names with / and space in them?" > -Chuck > > Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer > ----------------+---------------------+--------------------- > I know you're an optimist if you think I'm a pessimist.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 20:05:08 -0500 Organization: Atria Software Message-ID: <maury-2801972005080001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> In article <8mvbN9600iV1I6469b@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > If Apple developed an OpenStep implementation of their own, rather than > just paying royalties, etc for NeXT's OPENSTEP implementation, Apple > would _own_ their code and implementation. They wouldn't owe NeXT a > dime, since OpenStep is an "open standard". And that will allow them to sell it on other platforms? I think not. > In order to keep NeXT's customer list, Apple needs to provide an > operating system, development environment, and so forth which is > comparible to the functionality of NeXT's current products. And they wouldn't be able to get any of them unless they first purchased it. Maury
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 16:57:29 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <8mvbN9600iV1I6469b@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> In-Reply-To: <maury-2801971121360001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 28-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Apple could have paid NeXT on the order of $10 - 50 million for NeXT to >> port OpenStep to the MacOS > > Yes, but that wouldn't have allowed them to sell it, If Apple developed an OpenStep implementation of their own, rather than just paying royalties, etc for NeXT's OPENSTEP implementation, Apple would _own_ their code and implementation. They wouldn't owe NeXT a dime, since OpenStep is an "open standard". > nor would it have got them NeXT's customer list. Those alone are probably > worth more to Apple than a new OS for the Mac. In order to keep NeXT's customer list, Apple needs to provide an operating system, development environment, and so forth which is comparible to the functionality of NeXT's current products. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 29 Jan 1997 00:19:09 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cmmkd$q4@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-210197105714 <maury-2801971735280001@199.166.204.230> In article <maury-2801971735280001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <32EE7205.CCA9263@screaming.org>, Pohl Longsine > <pohl@screaming.org> wrote: > > That's because it's largely meaningless. It means that NT customers > > are relatively uninterested in the POSIX API, not that PC customers > > are relatively uninterested in a UNIX OS. > Well fair enough. But since those OS's (Win) form something on the > order of 70% of the market share of OS's being sold today, that means the > vast majority of the market doesn't want Unix. They don't want the Mac either, apparently. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 29 Jan 1997 00:18:07 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cmmif$o9@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <5cjhba$54s@dismay.ucs.indiana.edu> <5cji71$5lf$1@majipoor.cygnus.com> <5clp01$7tq@dismay.ucs.indiana.edu> In article <5clp01$7tq@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > Let me see if I understand you correctly. There is a single OpenStep API > that handles menus and managing windows and dialog boxes and memory > allocation and printing and disk drives and networking and threading and > everything else you'd do with the OS, and it will work correctly whether > that program be compiled under MacOS or Windows or Linux or whatever else > you're running? Yes.. well, almost all of that. Menus, windows, dialog boxes: yes Memory allocation: standard C malloc() type stuff, plus Obj-C memory management Printing: graphical objects typically know how to print themselves, as they are PostScript Disk drives: NSFileManager does most file management, but it is not part of the official OpenStep API, though it is present in NeXT implementations Networking: no socket classes, but Portable Distributed Objects Threading: NSThread, though the class isn't as nice as it could be.. probably from having to offer a lowest-common-denominator thread API across platforms. OpenStep apps will compile under OPENSTEP for Mach (all architectures), OPENSTEP/NT, Solaris OpenStep, and Rhapsody.. not Linux until the GNUstep project is finished. > There are equivelants in OpenStep to fork() and exec() NSTask is available for that, but it also is not part of the official spec and I only know for sure that it's in the NeXT implementations. > and GetNewCWindow() and TrackGoAway() and everything? I don't know what those are. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 29 Jan 1997 00:22:42 GMT Organization: The University of Iowa Message-ID: <5cm58i$fq6@flood.weeg.uiowa.edu> References: <5clkbh$7s1@xenia.informatik.uni-muenchen.de> From article <5clkbh$7s1@xenia.informatik.uni-muenchen.de>, by scholz@leo.org (Bernhard Scholz): > clay@herky.cs.uiowa.edu (Matthew Clay) wrote: >> >>Think virtual. [... deleted ... ] >>need more dynamism, and a great many problems do not, C++ is a poor choice. > > Think practical. Objective-C is much more like Smalltalk and much easier to > learn and understand than C++. Why should I think e.g. about virtual member > functions or all the other shit, if I could write it in a unique way in > Objective-C? If everything looks like an object, than you're right, C++ is probably not the right choice. But how many problems really look that way? One of the biggest faults of Smalltalk is it's Number hierarchy. From a practical standpoint, numbers just don't make good objects. First, because we've been subjected to algebra from grade 8 and on, just don't think of + as being much like message that you send to a integer object. It's not that it is an impossible view, just not much like our everyday experience. Second, it misses out the fact that we often add integers to integers, and often know this at compile-time. Again, this doesn't mean Smalltalk can't add, just that it misses some fundamental optimizations (realities). Objective-C strives for practicality here, leaving purity to Smalltalk. My point above was that a great many problems do not require generality that Smalltalk and Objective-C both offer _and_ impose. The greatest feature of C++ is you pay for what you use. You get to decide how much abstraction a problem requires to solve cleanly, not the system. You have total control which, perhaps in the hands of beginner, may be too much control. But then that's the philosophy of C isn't it? To criticize C++ for being too powerful, and offering too many features, is like criticizing PhotoShop because it's too power and has too many features. > IMHO practiced showed, that Objective-C (and much more Smalltalk) is the > better choice. However the market promotes C++ (because it is more like C(!), > yes this was the winner strategy). This comparance is like Windows to > NEXTSTEP. Everybody who ever used both, knows which one is better --- but the > market thinks different. This is totally silly and sounds like crying over spilled milk. Objective-C is a great language -- I haven't claimed otherwise -- as is Smalltalk. What I do object to is "C++ is too hard" or "you can't write great software in C++" or "templates are a hack"-type comments. Those statements are as uninformed as "Objective-C is a pitiful language because it failed in the marketplace". -mc
From: sangria@inlink.com (Sang K. Choe) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 01:23:47 GMT Organization: InLink Message-ID: <32f9a559.1557269312@mambo> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> <32EE7205.CCA9263@screaming.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, 28 Jan 1997 15:39:17 -0600, Pohl Longsine <pohl@screaming.org> wrote: >Maury Markowitz wrote: >> Pohl Longsine <pohl@screaming.org> wrote: >.. >> Not really, because I did provide strong evidence in the form of NT. >> NT's POSIX support has either been muted or removed entirely in 4.0 (along >> with support for OS/2 text mode programs and OS/2's HPFS disk format as >> well) and yet no one said a thing. > >That's because it's largely meaningless. It means that NT customers >are relatively uninterested in the POSIX API, He's also incorrect. NT 4.0's POSIX subsystem is still quite intact and supported. A large chunk of the utilities shipped with the ResKit would be useless were this the case. I would also think the guys over at SoftWay would be rather pissed if the POSIX subsystem was no longer supported--seeings how some of their major product lines are designed to work with the existing POSIX subsystem. -- Sang. ******************************************************** * Sang K. Choe sangria@inlink.com * * http://sangria.inlink.com/index.html * * finger: sang@sangria.inlink.com * ********************************************************
From: "Keith L. Swallow" <swallow@oar.net> Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: TCL for NeXT (HELP) Date: Tue, 28 Jan 1997 20:27:09 -0500 Organization: OARnet Message-ID: <32EEA76D.41C67EA6@oar.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: swallow@oar.net Hello all, I need to find a copy of tcl or instructions for installing tcl 7.6 on a next with nextmach 1.0 .. I know its old... But it is what I have to work with. SO any assistance would be gratfully appreciated. Please just reply to this by mailing me : swallow@oar.net Also sorry for cross posting... I wanted to hit everybody that might be able to help... thanks again... -Sincerly Keith Lee Swallow Thanks again... --
From: Guenter Szolderits <guenter@etm.co.at> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 09:12:17 +0100 Organization: ETM Ges.m.b.H. Message-ID: <32EF0661.6A64@etm.co.at> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> <maury-2701971234100001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu>, Charles William Swiger > <cs4w+@andrew.cmu.edu> wrote: > > NT provides a POSIX-compliant environment, does it not? POSIX, or > > S/VID, or one of those standards defines POSIX-compliant command-line > > utilities which are precisely the ones shipped with modern Unices (and > > are largely backwards-compatible with the BSD 4.3 utilities). > > None of which appear to be on either my NT server or workstation. The POSIX subsystem of Windows NT is only POSIX.1, which does'nt include any POSIX commands. Some POSIX commands are part of the Windows NT Resource Kit, which must be purchased separately. I consider the POSIX subsystem of Windows NT as useless. You can get much better utilities (even for porting Unix programs to NT) from third party vendors. Guenter -- Guenter Szolderits | e-mail: guenter@etm.co.at E T M , Kasernenstr. 29 | Phone: +43 2682 67555-0 A-7000 Eisenstadt Austria | Fax: +43 2682 67555-107
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Re: Compiling C++? Date: 28 Jan 1997 15:27:26 GMT Organization: The Ohio State University Message-ID: <5cl5su$id@charm.magnus.acs.ohio-state.edu> References: <Pine.GSO.3.94.970127183159.23390D-100000@ieng9.ucsd.edu> In-Reply-To: <Pine.GSO.3.94.970127183159.23390D-100000@ieng9.ucsd.edu> For starters, you have to name the file with an extension the compiler recognizes as c++. also, include the g++ library with -lg++. Randy On 01/27/97, enigma wrote: >Hi, > >This question is probably in a FAQ somewhere, but I just didn't know where >to look... > >I'm using NSFIP 3.2 and trying to compile a C++ program for school. I >thought NS has added support for C++ in addition to Objective C (which >IMHO is far better than C++). > >Yet when I tried to compile the program, it gave me some sort of error >about "reaching the end of the program" unexpectedly and complained about >some undefined function/object/whatever. This program I'm trying to >compile, compiled and runs successfully on the school's computer using g++ >compiler--so it can't be something wrong with the source code... > >This send me digging through the developer's manuals, which only mentioned >in passing about the "-x" option to cc for specifying the language. When I >gave it the c++ language (as mentioned in the manual), it gave me error, >saying unknown language. > >Since 3.2 don't come with g++ (does it come with newer version of OS?), >I'm completely lost here. > >Any help appreciated. Thanks > >Luke. > > -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: ProjectBuilder hurdle Date: 28 Jan 1997 15:31:23 GMT Organization: The Ohio State University Message-ID: <5cl64b$jv@charm.magnus.acs.ohio-state.edu> My last post was drafted in a fatigued state, and omitted much info. It appears in modified form below. I use NSFIP 3.3. My Developer package is labeled 3.2, and arrived with the 3.3 User upgrade. I have applied the Developer patches. Now, Since NS 1.0, and from then until now, I have written c++ code on the next, without bothering with the GUI. I decided today to give Project Builder a try, so I followed the directions in Chapter 15 of the Developer Documentation for Simple.app -- yes, I have problems with simple.app! When I get to the point of building the code, I get the error: invalid option -lang-objc But for the life of me, I don't see where I am specifying that option. Is there a default set of compiler options that PB calls, (I don't see CFLAGS defined in any of the three makefiles, and the cc man page doesn't provide any direction). Most importantly, what do I need to do to get past this problem? Thanks. Randy -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: shaffer@durer.phyast.pitt.edu (C. David Shaffer) Newsgroups: comp.sys.next.programmer Subject: Re: Compiler version in newest OS? Date: 28 Jan 1997 15:47:16 GMT Organization: University of Pittsburgh Message-ID: <SHAFFER.97Jan28104717@durer.phyast.pitt.edu> References: <5cigco$bou@charm.magnus.acs.ohio-state.edu> <32ECD75E.A07@ibp.de> In-reply-to: Lars Immisch's message of Mon, 27 Jan 1997 17:27:10 +0100 Here's what I get on my NeXTStation running NS3.3: ernie> cc -v Reading specs from /lib/m68k/specs NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8 ernie> David --- -- David Shaffer Department of Physics Wayne State College Wayne, NE 68787 shaffer@phyast.pitt.edu
From: sangria@inlink.com (Sang K. Choe) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 01:17:28 GMT Organization: InLink Message-ID: <32f8a413.1556942734@mambo> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Tue, 28 Jan 1997 11:19:22 -0500, maury@softarc.com (Maury Markowitz) wrote: >In article <32ED1135.22DC2715@screaming.org>, Pohl Longsine ><pohl@screaming.org> wrote: > >> I think, since you were the one that asserted that the PC market >> doesn't want UNIX, that the burden to provide the figures is >> yours. > > Not really, because I did provide strong evidence in the form of NT. >NT's POSIX support has either been muted or removed entirely in 4.0 (along >with support for OS/2 text mode programs and OS/2's HPFS disk format as >well) and yet no one said a thing. What? NT 4.0 still supports POSIXs and OS/2 1.3 non-PM applications. POSIX support is still built in otherwise, you need to explain to me how some of my POSIX utilities are able to run. OS/2 support is still built in because NT still offers ways to manipulate the OS/2 1.x subsystem via the Registry--silly to keep that feature in there if they were going to drop the support. As for HPFS, the driver is no longer officially supported. However, you can shoe horn the support back in. Not that it's important, you can run OS/2 subsystem on both FAT and NTFS. The only real use of HPFS was if you were dual booting the system between NT and OS/2. -- Sang. ******************************************************** * Sang K. Choe sangria@inlink.com * * http://sangria.inlink.com/index.html * * finger: sang@sangria.inlink.com * ********************************************************
From: suckow@bln.sel.alcatel.de (Ralf Suckow) Newsgroups: comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 29 Jan 1997 09:14:51 GMT Organization: Alcatel SEL AG Berlin Distribution: world Message-ID: <5cn4eb$38q@slbh00.bln.sel.alcatel.de> References: <5cm58i$fq6@flood.weeg.uiowa.edu> Matthew Clay writes > My point above was that a great many problems do not require generality that > Smalltalk and Objective-C both offer _and_ impose. The greatest feature of ======================= > C++ is you pay for what you use. You get to decide how much abstraction a ================================ > problem requires to solve cleanly, not the system. You have total control > which, perhaps in the hands of beginner, may be too much control. But then > that's the philosophy of C isn't it? To criticize C++ for being too powerful, =================== > and offering too many features, is like criticizing PhotoShop because it's =============================== > too power and has too many features. The problem with C++ is that it offers too many features while being not powerful enough, more than than, it is really weak. You pay for what you don't get. I don't mean features when I say "you don't get it with C++", I mean design choices, software modularity and flexibility. Read that B. Cox book! I'm really tired of all that C++ discussion (at work, not in the netnews), because it eats up alot of time and possibilities. C++ is the hardest barrier on the way towards objects in programming, it permanently prevents people from concentrating on the real issues and writing good software. The only hope I have is that it seems to get to an end now. Yours, ------------------------ Ralf.Suckow@bln.sel.alcatel.de | All opinions are mine.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 21:42:30 -0600 Organization: mementech, inc. Message-ID: <32EEC726.B7EE739@screaming.org> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > > > If Apple developed an OpenStep implementation of their own, rather than > > just paying royalties, etc for NeXT's OPENSTEP implementation, Apple > > would _own_ their code and implementation. They wouldn't owe NeXT a > > dime, since OpenStep is an "open standard". > > And that will allow them to sell it on other platforms? I think not. It's true. Caldera could hire a few programmers to implement OpenStep, make sure it passes the compliancy suite, and then sell it with their Linux distribution for whatever price the market would bear. I'm not kidding. -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 22:24:06 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> In-Reply-To: <maury-2801971238060001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 28-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >>>> Correct. > [snip] >> Look, I'm not interested in defending a strawman position you've created >> yourself. Did I ever say that computers should not do what people tell >> them too? > > Yes, as a matter of fact. You agreed with a statement by saying > "Correct." at the first line there, and the statement I made was exactly > that. That "Correct" was part of this statement: CWS> Correct. A multiuser computer system has conventions for where you CWS> should place common files (like applications, fonts, and other such CWS> resources) which are supposedly intended for use by all users. MM> Well that about says it all. Computers should not do what we tell them MM> to, it should be the other way around and that's completely logical. Those two statements >>>NOT<<< identical. You deliberately removed the rest of what I said! You also conveniently ignored my point that conventions are created by humans, and not by computers. Do us all a favor, Maury-- stop trying to distort what I've said in such a contrived fashion. (A) You aren't fooling anyone, and (B) I've already had more than enough experience with revisionists on Usenet to not want to deal with it ever again. >> Under a multiuser MacOS machine, how can one user double-click on that >> document and have it open in Word, while another user can double-click >> that precise same document (without changing any attribute of that >> document) and have it open in some other word processor? > > Use MEO, the prefs are stored locally. For single machine/multiuser > situation you have the same problem and I'd love to hear what resources > the Mac provides for mapping this on a per folder basis. Are you asking me or Usenet in general? It sounds like you do not have an answer for the case of a single multiuser machine. >> Maybe we should get rid of directories, too, and just have all of the >> files in one flat data space? Why did we ever come up with conventions >> to organize things in the first place? > > Now who's creating strawmen? You've been telling us all how filesystem conventions for the structure of directories is bad, and how the MacOS lets you put files whereever you want to which is good. >>> _empirical_? No. >> >> That speaks for itself. > > That's right, I trust test results and numbers. You obviously don't understand what the word means. Webster's sez: em-pir-i-cal \-i-kel\ also em-pir-ic \-ik\ adj 1: relying on experience or observation alone often without due regard for system and theory 2: originating in or based on observation or experience (empirical data) 3: capable of being verified or disproved by observation or experiment (empirical laws) Go find your own dictionary and look it up. >> I've run one too many beta test programs to not appreciate the value of >> real-world feedback > > Real world feedback is not empirical because it can be quantified. Oh, god. Could someone else explain this to Maury? He apparently isn't listening when I show him that he's completely wrong. For example: If I count the number of users who report a problem with a certain aspect of a program, I've just quantified real-world feedback. [ ... ] >> You made an existential claim-- that out of all of the hundreds of Macs >> you were familiar with, none of them had filesystem conventions. From >> this, you implicitly generalized that all Macs do not have such >> conventions, so Pohl's argument was therefore incorrect. > > No actually I was countering your claim that everyone that runs such > systems has such standards. Go look up the previous articles. > In fact I can now raise that (with a little > reflection) to something on the order of 1000 Macs, none of which I know > of have defined places in which to place files. > > Your claim: most networks do this > My claim: hogwash My claim was that "most networks _that_ _I_ _personally_ _have_ _experience_ _with_ 'do this'." I have never once made a claim that all computers in the world 'do this', or even that most computers 'do this'. Sigh, -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 27 Jan 1997 13:29:32 -0500 Organization: Atria Software Message-ID: <maury-2701971329320001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <5c4as9$4m2@duke.squonk.net> In article <5c4as9$4m2@duke.squonk.net>, Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: > "OpenStep on WindowsNT" is a product that runs upon an already- > existing operating system, which is to say, WindowsNT. OpenStep > itself does not include (it the specification) anything about Unix > utilities. Yup. > WindowsNT, the operating system (or environment, whatever) includes > many tools similiar to the tools in the land of Unix. Yup. > Thus, OpenStep > did not include Unix utilities. Yup. > However, in the case of Rhapsody, there is no already-existing > operating system. Yup. > There are no tools which already exist. Thus, > if you do not use the unix utilities from something like NeXTSTEP, > you will have to get them from somewhere else. Yup. > Where do you propose to get them? I haven't. > As near as I can tell, you are proposing that someone develops > some libraries which reimplement all the same utilities. This > might well produce a superior result, but it won't do that by > the time WWDC rolls around. Yup. > Note that I'm serious that I want the abilities which happen to be > in the unix utilities, and I want Rhapsody released this year. Me too. I also want it to get better in the future. > you have an alternate source for all these utilities, one which > will not delay Rhapsody, that might well be fine with me (depending > on how good the replacement is, I guess). However, I think your > position would be much more crediable if you could point at a > specific alternate source for all these utilities. Hmmm, I don't know if I can, although Be provides many of them in it's OS. Maury
From: ga@ed4u.com (G. Gordon Apple, PhD) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Sat, 25 Jan 1997 11:20:37 -0700 Organization: Advanced Communications Engineering, Inc. Message-ID: <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> > >> which BTW means having function overloading because operators > >> by definition are functions. > > > > No. Operator overloading is NOT a subset of function overloading. > > Operators on objects are methods, which are not functions, at least in > > Objective-C. (Note that "function overloading" refers to C functions, > > not mathematical ones.) Which is actually making my point. "Operators" are by definition "functions" in the mathematical sense. You then responded to me in the context of Objective C. There is a substantial schism between people whose profession is writing code vs. those who write code to get a job done, e.g., mathematicians and engineers. Many times, the output of the latter moves into the domain of the former, especially as the power of PCs (in the generic sense) continues to increase. For example, I have often seen relatively new programmers dismiss the need for FORTRAN compilers. They have no concept of the vast libraries of FORTRAN code that runs much of the engineering world today and keeps the rest of the world running. One of the big advantages of C++ (e.g., over FORTRAN or C) is the ability to take the abstract mathematical concept of an "operator" and implement it in code in a way that is still recognizable. Galois fields and complex numbers may be considered highly specialized to some professional shrink-wrap application programmers, but they are very basic in many engineering areas. IMHO, giving that up is a giant step backwards. -- G. Gordon Apple, PhD The Ed4U Project Advanced Communications Engineering, Inc. Redondo Beach, CA ga@ed4u.com www.ed4u.com
Newsgroups: comp.sys.next.programmer From: Fabien_Roy@free.fdn.org Subject: Re: mmap/munmap under mach Message-ID: <E4rMwt.D5K@free.fdn.fr> Sender: news@free.fdn.fr Organization: Fabien Roy Consultant. References: <32E98C21.2568@friday.com> <1997Jan24.113948.592@gamelan.shnet.org> Date: Wed, 29 Jan 1997 10:38:53 GMT FYI here is my workaround: /* * @(#)map.c 1.0 of 20 December 1996 * * Copyright (c) 1996 by Fabien Roy. * Written by Fabien Roy and Robert Ehrlich. * Fabien_Roy@free.fdn.fr Robert.Ehrlich@inria.fr * Not derived from licensed software. * * Permission is granted to anyone to use this software for any * purpose on any computer system, and to redistribute it freely, * subject to the following restrictions: * * 1. The author is not responsible for the consequences of use of * this software, no matter how awful, even if they arise * from defects in it. * * 2. The origin of this software must not be misrepresented, either * by explicit claim or by omission. * * 3. Altered versions must be plainly marked as such, and must not * be misrepresented as being the original software. * */ #include <sys/types.h> #include <sys/mman.h> #include <stdlib.h> #include <syscall.h> caddr_t mmap(caddr_t addr, size_t len, int prot, int flags, int fd, off_t off) { int pagelessone = getpagesize() -1; int size; caddr_t pageaddress; /* round to next page size */ size = (len + pagelessone) & ~pagelessone; /* allocate aligned pages */ if (!(pageaddress = (caddr_t) valloc(size))) return (caddr_t) -1; /* map it */ if (syscall(SYS_mmap, pageaddress, size, prot, flags, fd, off)){ free(pageaddress); return (caddr_t) -1; } return pageaddress; } void munmap(caddr_t addr, size_t len) { syscall(SYS_munmap,addr,len); free(addr); } -- Fabien Roy --------------------------------------------------------------------- Fabien_Roy@free.fdn.org (NextMail/MIME accepted) Fabien Roy Consultant NEXTSTEP/OPENSTEP/EOF Consultant, SYBASE DBA 10 rue de la DEFENSE 93100 MONTREUIL, France Tel: 33 (0)1 45 28 32 23 Fax: 33 (0)1 48 55 09 90 GSM: 33 (0)6 60 46 36 83
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Tue, 28 Jan 1997 12:23:05 -0500 Organization: Atria Software Message-ID: <maury-2801971223060001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2101971218370001@199.166.204.230> <SHESS.97Jan21213327@slave.one.net> <maury-2701971314390001@199.166.204.230> <5cken1$6co@csugrad.cs.vt.edu> In article <5cken1$6co@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Yeah, and how long is it going to be before Be has even _close_ to the > number of utilities functions Unix has, neatly modularized in OOP > libraries. Most of it's done as far as I can tell. > A long, long, _long_ time. And a lot of the current Be > utilities are actually Unix ones running under POSIX emulation. Uhh, not really unless you look at raw numbers. In most applications the only "traditional" calls you'll typically see will be to streams, everything else is handled by new OOPS based APIs, including file handling. Maury
From: colnet@loria.fr (Dominique Colnet) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.lang.eiffel Subject: Re: NextStep & Mac Frameworks Date: 29 Jan 1997 11:29:59 GMT Organization: CRIN & INRIA-Lorraine - Nancy - FRANCE Message-ID: <5cncbn$nq6@muller.loria.fr> References: <AEEFE2B6-491909@204.246.66.19> <1997Jan3.081621.1@eisner> <5ajc89$r1s@nntp1.apple.com> <32CD396A.3DC@exnext.com> <1997Jan3.154332.1@eisner> <5b0uh1$lqc@priv-sys04-le0.telusplanet.net> <1997Jan8.171354.1@eisner> <5b1k0n$fr3@sjx-ixn2.ix.netcom.com> <toolz-1101972317210001@news> <tbrown-ya023580001401970003470001@news.netset.com> <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <5bkjj6$big@darla.visi.com> <acurylo-1601971109400001@van0217.tvs.net> <ENGELHART.M-2101971010080001@17.128.202.195> <milkweed-2101971304100001@port1.chester.smallmedia.com> <32E6A101.7010@acm.org> <milkweed-2201972301440001@port10.chester.smallmedia.com> <32E85082.37DE@acm.org> <5c9v18$95r@muller.loria.fr> <32ED2290.2DB3@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In article <32ED2290.2DB3@acm.org>, Ian Joyner <i.joyner@acm.org> writes: |> Dominique Colnet wrote: |> >Ian Joyner wrote: |> > |> Perhaps someone should encourage Metrowerks to get together with |> > |> an Eiffel compiler vendor or someone willing to write an Eiffel |> > |> compiler for CW. It sounds like they would be a really good match. |> > |> Having already written an Eiffel compiler in Pascal, I'm willing |> > |> to volunteer. |> > Yes, but it is now time to use Eiffel to write Eiffel compilers :-) |> |> True! But on the machine that I wrote the Eiffel compiler on, the |> compilation system was all done in Pascal, which included lexical |> analysis, parsing, intermediate code, optimization, code generation, |> implementation of lots of the stuff in the "Dragon book". Thus my |> Eiffel "Language Processor" is less than 30,000 lines of Pascal, For information, our SmallEiffel compiler is about 50,000 lines Eiffel source code for about 300 classes. |> which includes generating most of ELKS 95. And yes it does 90% of |> Eiffel, included all of Multiple inheritance with selects, generics, |> etc, etc, and is native code generating. But the compiler support |> stuff accounts for probably 200,000 lines worth. Who says you can't |> do serious stuff in Pascal? Not me ! |> |> In another environment, I would do it in Eiffel. I can probably |> boast having the best Eiffel compiler 'not' on the market today! Yes. To have the best Eiffel compiler on the market, one must do better than SmallEiffel ;-) -- ------------------------------------------------------------ Dominique COLNET -- Talk Eiffel with SmallEiffel Talk Eiffel C.R.I.N. (Centre de Recherche en Informatique de Nancy) POST: CRIN,BP 239,54506 Vandoeuvre les Nancy Cedex,FRANCE EMAIL: colnet@loria.fr VOICE:+33 0383593079 FAX:+33 0383413079
From: Michel Coste <mic@micmac.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 09:35:19 GMT Organization: MiCMAC Sender: news@micmac.com Message-ID: <E4rJyv.72J@micmac.com> References: <5ami95$ol3@news.tuwien.ac.at> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <jinx6568-2201971205130001@news.sover.net> <5c9g5b$nrl@csugrad.cs.vt.edu> <jinx6568-2401971226320001@news.sover.net> <32E91CBE.56EF@exnext.com> <32E93645.21D43FE@screaming.org> Cc: pohl@screaming.org This was written in comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system (<32E93645.21D43FE@screaming.org>) by Pohl Longsine: > Jonathan W. Hendry wrote: > > For instance, Edit.app is found in /NextApps. It's local to each > > machine. If you saved your documents with it, you'd lose access > > to them if you move to another machine. > > A traditional multi-machine environment would have the user's > home directory on an NFS server, with the user authentication > done by a NetInfo or NIS server. The mountpoint for the home > directories would be the same on all the machines so that any > person could walk up to any NeXTstep machine and still get their > own environment and data. A setup where a user could not access > their data when they logged onto another machine is poorly administered. > Well I guess you read it too fast... =:) mc
From: tim@apple.com (Tim Olson) Newsgroups: comp.sys.next.programmer Subject: Re: Number of digits in setDoubleValue: Date: 28 Jan 1997 03:27:00 GMT Organization: Apple Computer, Inc. / Somerset Sender: -Not-Authenticated-[8230] Message-ID: <5cjrm4$7v9@cerberus.ibmoto.com> References: <5chq67$gdm@kaopala.mhpcc.edu> Xdisclaimer: No attempt was made to authenticate the sender's name. In article <5chq67$gdm@kaopala.mhpcc.edu> altenber@acpub.duke.edu (Lee Altenberg) writes: > Is there any way to control the number of digits displayed in a textField? > > I am calling: > [fieldMatrix setDoubleValue:(double) value at:2]; > > and it gives at most 6 digits in the display. It also automatically drops to > lower numbers of digits when it can. I don't see anything in > /NextLibrary/Documentation/NextDev/TextField.rtf that mentions control over > digits printed. I would like to be able to fix the number of digits at the The TextFieldCell associated with the TextField inherits methods from the Cell class, one of which is (something like, typing from memory): - setFloatingPointDisplay (BOOL)autoRange: (unsigned)leftDigits: (unsigned)rightDigits At least it did in NeXTSTEP 2.1. -- Tim Olson Apple Computer, Inc. (tim@apple.com)
From: Lars Immisch <lars@ibp.de> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: Wed, 29 Jan 1997 13:01:30 +0100 Organization: Immisch, Becker & Partner Message-ID: <32EF3C1A.5648@ibp.de> References: <5clkbh$7s1@xenia.informatik.uni-muenchen.de> <5cm58i$fq6@flood.weeg.uiowa.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Matthew Clay wrote: > If everything looks like an object, than you're right, C++ is probably > not the right choice. But how many problems really look that way? One of > the biggest faults of Smalltalk is it's Number hierarchy. From a practical > standpoint, numbers just don't make good objects. First, because we've > been subjected to algebra from grade 8 and on, just don't think of + as > being much like message that you send to a integer object. It's not that > it is an impossible view, just not much like our everyday experience. Second, > it misses out the fact that we often add integers to integers, and often > know this at compile-time. Again, this doesn't mean Smalltalk can't add, > just that it misses some fundamental optimizations (realities). Objective-C > strives for practicality here, leaving purity to Smalltalk. Which Smalltalks Number hierarchy are you talking about? Parcplace or Smalltak V? IMO Parcplace's Number hierarchy is nicely optimized by it's double dispatching strategy. (This implies that ArithmeticValue subclasses have to be abelian, which is not as general as it might be, but heck, thats what optimization is about). So I do not agree that it misses fundamental optimizations. I have often thought that, in contrary to your opinion, the Number hierarchy (of Parcplace's) is one of Smalltalks better features. Where else can you multiply 4 Gig with 2 and still get the correct result? Or express 1/3 correctly? Lars -- mailto:lars@ibp.de http://www.ibp.de/~lars Yesterdays yellow yoyo can make you yawn today
From: Lars Immisch <lars@ibp.de> Newsgroups: comp.sys.next.programmer Subject: Re: ProjectBuilder hurdle Date: Wed, 29 Jan 1997 14:26:44 +0100 Organization: Immisch, Becker & Partner Message-ID: <32EF5014.6DA@ibp.de> References: <5cl64b$jv@charm.magnus.acs.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Jackson wrote: [deletia] > When I get to the point of building the code, I get the error: > > invalid option -lang-objc > > But for the life of me, I don't see where I am specifying that > option. Is there a default set of compiler options that PB calls, > (I don't see CFLAGS defined in any of the three makefiles, and the cc man page > doesn't provide any direction). > > Most importantly, what do I need to do to get past this problem? I have no clue why you see this behaviour, but the PB Makefiles include the template ones in /NextDeveloper/Makefiles/app and a set of CFLAGS is defined in common.make. Hope this helps. Lars -- mailto:lars@ibp.de http://www.ibp.de/~lars Yesterdays yellow yoyo can make you yawn today
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 17:30:13 GMT Organization: Airwindows Message-ID: <jinx6568-2801971232440001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> <5cjhba$54s@dismay.ucs.indiana.edu> In article <5cjhba$54s@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > What about Windows? I really, REALLY don't want Apple to try to put the > entire Windows API into the new MacOS and make it the standard programming > model. Bad news. We have SoftWindows if we need it. Maybe MetroWerks > will port PowerPlant to Windows and we'll have a common API. Or we could > use Java. At any rate, I really don't think a Windows-compatible API is > something Apple should try to work into the system. Good God, no! What a sure recipe for disaster. "Hi folks, we now can offer you General Protection Faults" ;) Total madness, it ain't gonna happen. Nobody buys and sticks with Apple because they want the Windows API... and nobody will buy future Macs for the purpose of getting the Windows API... there is just no chance of this happening. SoftWindows (or something like WABI) will fill whatever minor need is present. People do not _get_ either a Mac or a Unix box to run Windows programs. Those who want that get a Wintel PC, in great numbers. Leave them to it, and work on going beyond what Wintel's capable of. Jinx_tigr (aka Chris Johnson)
From: ehutch@hypnos.norden1.com (E. Hutchinson) Newsgroups: comp.sys.next.programmer,misc.jobs.offered,chi.jobs Subject: NEXTSTEP/Objective C/Career Position/ILL Date: 29 Jan 1997 15:15:58 GMT Organization: Norden 1 Communications Message-ID: <5cnpje$bc7@tofu.alt.net> Programmer/analyst NEXTSTEP----------Commercial experience Objective C-------Commercial experience Career Position---Excellent Position Relocation -------Company Assistance Working Conditions-Excellent To Be Considered---Fax resume or mail a hard copy. -- ehutch@norden1.com (419) 893-6367 [fax] Omni Search (419) 893-6334 [voice] 1310 Craig Maumee, Ohio 43537
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: Re: TCL for NeXT (HELP) Date: 29 Jan 97 09:53:04 Organization: Is a sign of weakness Message-ID: <SHESS.97Jan29095304@howard.one.net> References: <32EEA76D.41C67EA6@oar.net> In-reply-to: "Keith L. Swallow"'s message of Tue, 28 Jan 1997 20:27:09 -0500 In article <32EEA76D.41C67EA6@oar.net>, "Keith L. Swallow" <swallow@oar.net> writes: I need to find a copy of tcl or instructions for installing tcl 7.6 on a next with nextmach 1.0 .. I know its old... But it is what I have to work with. SO any assistance would be gratfully appreciated. Please just reply to this by mailing me : swallow@oar.net I've posted a copy of tcl7.6 modified to compile under NeXTSTEP3.3 to my home page. Getting it to compile under NS1.0 will likely be a chore, since a lot has happened since then. If you told us what goes wrong when you try to ./configure and compile it, well, then we might be able to help more. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: Compiler version in newest OS? Date: Tue, 28 Jan 97 22:54:12 +0100 Organization: Warty Wolfs Message-ID: <9701282154.AA05544@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In article <5cigco$bou@charm.magnus.acs.ohio-state.edu>, you wrote: > My understanding is that NeXT's compiler (cc) is comparable (derived from?) > some version of the gnu c compiler. I have NS3.2/3.3 Developer, and am > wondering whether the compiler that comes with 4.0 (or are we up to 4.1?) is > comparable to a more recent gnu compiler. A version number would answer my > question. Is it 2.7.2? Still based on 2.5.8: tom@basil 51) cc -v Reading specs from /lib/m68k/specs NeXT Computer, Inc. version cc-478, gcc version 2.5.8 tom@basil 52) hostinfo Mach kernel version: NeXT Mach 4.1: Thu Sep 26 22:54:37 PDT 1996; root(rcbuilder):Objects/mk-183.27.obj~2/RELEASE_M68K The OS/NT (aka OPENSTEP Enterprise) compiler is based on 2.7.2 (or was it 2.6.3? -- memory fails me:-/) -- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ IC Group <tom@icgned.nl> (work) __/__/__/ "Any magic sufficiently advanced is indistinguishable __/ _/_/ from a perl script" -- Larry Wall, mangled
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Re: ProjectBuilder hurdle Date: 29 Jan 1997 15:56:23 GMT Organization: The Ohio State University Message-ID: <5cnrv7$ien@charm.magnus.acs.ohio-state.edu> References: <5cl64b$jv@charm.magnus.acs.ohio-state.edu>? <32EF5014.6DA@ibp.de> In-Reply-To: <32EF5014.6DA@ibp.de> On 01/29/97, Lars Immisch wrote: >Randy Jackson wrote: >[deletia] >> When I get to the point of building the code, I get the error: >> >> invalid option -lang-objc >> >> But for the life of me, I don't see where I am specifying that >> option. Is there a default set of compiler options that PB calls, >> (I don't see CFLAGS defined in any of the three makefiles, and the cc man page >> doesn't provide any direction). >> >> Most importantly, what do I need to do to get past this problem? > >I have no clue why you see this behaviour, but the PB Makefiles include >the template ones in /NextDeveloper/Makefiles/app and a set of CFLAGS is >defined in common.make. > >Hope this helps. Thanks for the tip, but nowhere in my CFLAGS is -lang-objc defined as an option. In fact, -ObjC is, and that is what PB is recommending in the error message window. Strange. Randy > >Lars > >-- >mailto:lars@ibp.de >http://www.ibp.de/~lars > >Yesterdays yellow yoyo can make you yawn today > -- Randy Jackson, Associate Professor ,_ o __o Geography, The Ohio State University / //\, _`\<,_ 1036 Derby Hall, 154 North Oval Mall \>> | (*)/ (*) Columbus OH 43210-1361 \\, FAX (614) 292 6213 randyj@lubra.sbs.ohio-state.edu http://www.geography.ohio-state.edu/faculty/jackson/
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 10:52:54 -0500 Organization: Atria Software Message-ID: <maury-2901971052540001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> <32EE7205.CCA9263@screaming.org> <32f9a559.1557269312@mambo> In article <32f9a559.1557269312@mambo>, sangria@inlink.com (Sang K. Choe) wrote: > NT 4.0's POSIX subsystem is still quite intact and supported. A large > chunk of the utilities shipped with the ResKit would be useless were > this the case. Sorry, again I am a victim of poor use of a term. I'm not really referring to the POSIX API in this case, but utilities. For instance, nowhere on my drive can be found any of the standard utils - yes I know they are not a part of POSIX. > I would also think the guys over at SoftWay would be rather pissed if > the POSIX subsystem was no longer supported--seeings how some of their > major product lines are designed to work with the existing POSIX > subsystem. SoftWay... the guys that do the Unix compatibility stuff for NT? Maury
From: stage1@bortibm5.in2p3.fr Newsgroups: comp.sys.next.programmer Subject: X11toNX programming Date: Wed, 29 Jan 1997 19:44:58 +0100 Organization: In2p3 Message-ID: <32EF9AAA.41C6@bortibm5.in2p3.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I would like to know if somebody has rewritten the libX11 functions in order to work with NeXTSTEP, for exemple, in programming the ImageMagic/libX11_subs.c ? Bye
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 29 Jan 1997 18:40:42 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5co5ja$lv8@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <5c4ed7$fjt@geraldo.cc.utexas.edu> <5c6s1d$2oh@news.digifix.com> Scott Anguish (sanguish@digifix.com) wrote: : On 01/21/97, William Raphael Hix wrote: : > : >Tar is of great use to Unix users. I use tar on my Unix box to aggregate : >files which I then compress and download to my Mac where Stuffit : >uncompresses and untars them. But most Mac users never encounter tar : >files since Mac software distribution is done by Stuffit/BinHex. : : Yeah, I know, this is one of my major complaints. Stuffit is a : closed system in this respect. Closed? Stuffit opens a much wider range of formats than any Unix utility I've encountered, making it a very good cross-platform tool. Of course that's the payware version. The freeware is merely a decoder for the most common Mac formats. You have to pay for added functionality which most users don't care about. : : >But you expect Rhapsody software distribution to work like NeXTStep? : >Ports of apps from Unix to Rhapsody? This is another of those places : >there the NeXT and Mac community are talking about apples and oranges : >(I apologize for the pun). : > : : Not sure what you mean by this.. : Software for NeXT consists of a strong set of utilities provided by NeXT as part of the OS, a relatively few shrink-wrapped apps, some compiled shareware and a lot of compilable software drawing on NeXT's Unix legacy. NeXT users therefore depend heavily on the core set of utilites which are part of the OS and their Unix derived apps (arriving in tar files). Software for Macs consists of a minimal set of utilities as part of the OS, a large number of shrink-wrapped apps, utilities and shareware, and almost no compilable software. Therefore Apple users expectations include paying additional for higher powered utilities and most of their apps. With Rhapsody, these 2 sets of expectations must be reconciled. From the NeXT side the consensus seems to be much like NeXTStep with a much larger selection of payware. The Mac users expections don't even have Unix legacy apps on the radar. These are the apples and oranges I described above. Note it is possible to reconcile these expectations, but how Apple will choose to do so is an open question. : >But it doesn't do anything for a Mac user since Mac software in not in : >tar format. Perhaps for Rhapsody this will change, but I think that : >you are assuming things which aren't decide yet. : : Sure it does. It gives Apple users a method of dealing with the oft : available tar files on the net. : Currently, those Mac users who need to deal with tar files buy the complete Stuffit. However, almost none do because they never encounter them. Under Rhapsody this might change, if it keeps Unix compatability and if Unix apps are important. While these might be essential to some people, for the majority of Mac users these are not important features so Apple might drop it or make you pay more for it. : >You are taking this too personally. : : You said... : : "The feelings of NeXT users are secondary" : : my reply to that is that you better start to open up, or Apple's : gonna die. There are what a few hundred thousand NeXT users, barely supporting a company much smaller than Apple. While Apple would love to have these people, particularly those in enterprise, they need to attract their current users if they are going to make a go of it. : >I'm not trying to rain on you parade. : >Apple has said they will continue to support OpenStep on Intel and : >Solaris, but I haven't heard anything clear from them about future : >development, either as Rhapsody on other hardware or independently. : : Then you should be reading the letter that Dr. Gil now has on NeXT's : WWW site. : I did read the letter. I found Apple's careful wording to leave as much undecided as it explained. Apple has pledged to continue support and development for OpenStep Developer and Enterprise (but no mention of User which I found odd), so current Next users would seemingly be at least as well off as they were. Apple has also said that the OpenStep API will be a core part of Rhapsody and that apps written to the API will work under Rhapsody. This might be all the compatability NeXT users get. Since the API interacts directly with the kernal, most of the /bin parts of Unix aren't necessary for the API. Apple has not said that Rhapsody will be based on or compatible with OpenStep/Mach. It could be that this has not been fully decided. If they change to a different kernal, replacing the full BSD layer is additional work. Since the API access the kernal directly, the full BSD layer is only necessary for Unix compatibility, which Apple might decide is unimportant or they might decide that users should pay more for Unix compatibility. Current Mac users pay for such aditional features. I expect that this issue will become clearer once Apple settles on a kernal. Hopefully then they'll start filling in the outline of Rhapsody. Apple has also not pledged to bring Rhapsody to other hardware. Hancock had hinted about the possibility, but nothing solid has come out. Apple could intend to develop Rhapsody and OpenStep in parallel in which case Rhapsody might never make it to Intel hardware. Apple might also make Rhapsody the basis of NeXTStep 5. I doubt that the final decision has been made. Over the next year, as they wrestle Rhapsody into existance on the Mac, they'll have plenty of time to thrash out their other options. : : >Infoworld suggests that wrangling over these options is delaying : >fundamental choices like which kernal to bring to Rhapsody. : : Yeah, well, you gotta fill that print space. And just because you don't like it means it can't be true. Of course all such news should be taken with a grain of salt. But there has to be some reason that Apple hasn't presented more info to developers about where they're going now that it's a month after the purchase. : >The 1% number is based on estimates of Linux installations on PCs. Perhaps : >it should be a few %. It sounds like you really want Rhapsody to be a : >cheap Unix, like a supported Linux. : : You're wrong. : : What I want is for Apple to take the best of what it has to offer, : and the best of what OpenStep has to offer (rich framework, EOF, WOF, : preemptive multi-tasking, etc...) and make the best, most openly compatible : system available. Like the rest of us, you want to have your cake and eat it too. Apple might decide that your flavor of cake is not popular enough. Or more likely they'll sell you your more exotic flavor at a higher price. : >Mac users install Mac versions of : >servers. Some are free, some cost money but are supported. If you want : >Linux, get Linux. Don't ask millions of Mac users to accept Linux. : : I'm not. What I'm asking is don't cripple the OS just to save 20 Mb : of install space. Microsoft and Apple both now sell millions of copies of OS's which to your definition are crippled. If Apple thinks that they can better position Rhapsody in the market place sans Unix compatibility, they'll do it. They've guaranteed a modern OS using the OpenStep API to replace the ToolBox. I hope that they also include Unix compatibility but I won't be surprised if I have to pay more for it. : : >: Will Apple prohibit compiling and distribution of find then? Who : >: gets hurt by Apple including it? : >: : >: And what if someone writes a really cool freeware utility that uses : >: find... do they have to supply it? : > : >Of course Apple will not prohibit or inhibit distribution of any software. : >Apple just won't support it. I can just imagine calls to Apple which : >get answered, "Well you need to add -print to tell it to print the list of : >files it finds." Use at your own risk. : : I doubt that Apple does that with A/UX. Apple never tried to sell A/UX to their entire user base. People who bought A/UX were much more technically savy than the intended audience of Rhapsody. : >Personally, I'd love Unix compatibility in my Mac, so all the Unix : >skills I have at work could be put to better use at home. But Apple : >isn't pushing Rhapsody for us tech-heads, it's got to appeal to a wider : >base that couldn't care less about Unix compatibility. : : Not having it and not using it are entirely different things. Of course, but Apple has a long history of making people pay for functionality beyond its definition of basic. I doubt Apple will see Unix compatibility as basic (surveys of the prosps of Rhapsody indicate a profound apathy towards it), so it might very well be an add-on, perhaps one you have to buy. : >Last time I heard OpenStep was far from free. It really sounds like you : >want Linux. I doubt you'll be happy with the outcome, because the OS is : >going to cost > $100 with or without complete BSD. : > : : No, what I want is OpenStep/Rhapsody. But crippling power users for : the purpose of protecting the naive (instead of altering the method they : would use or be able to access the dangerous stuff) is stupid. : : As I said, I don't have anything against commercial products, hell, : its the market I'm in. I have no doubt that Apple will ship Rhapsody, fully compliant with the OpenStep API, for $100-200 dollars, giving power users access to all the features of the expanded API. I think that the open questions are "How much will Rhapsody be like OpenStep/Mach, and how much it'll cost to make it so?" Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: Looking for Examples Date: 29 Jan 1997 15:45:38 GMT Organization: Rockwell Avionics - Collins Message-ID: <5cnrb2$eki@castor.cca.rockwell.com> References: <Pine.SUN.3.90.970128122950.477I-100000@solarium.cs.buap.mx> Cc: at138@solarium.cs.buap.mx In <Pine.SUN.3.90.970128122950.477I-100000@solarium.cs.buap.mx> Briones Garcia Jorge Alfonso wrote: > > I am learning to programming in NEXTSTEP 3.1. > I am looking for examples, if you have some please send > to me. > > Any help would be greatly appreciated... > Thanks. > See the MiscKit from next-ftp.peak.org This includes thousands of lines of source code See NeXT's mini-examples ftp.next.com See the /NeXTDeveloper/Examples directory
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 29 Jan 1997 11:09:30 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cnsnq$sq6@csugrad.cs.vt.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> In article <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) wrote: > One of the big advantages of C++ (e.g., over > FORTRAN or C) is the ability to take the abstract mathematical concept of > an "operator" and implement it in code in a way that is still > recognizable. In fact, that's just about the only reason I would find C++ useful. > Galois fields and complex numbers may be considered highly > specialized to some professional shrink-wrap application programmers, but > they are very basic in many engineering areas. IMHO, giving that up is a > giant step backwards. Giving up operator overloading is a giant step backwards, for those in engineering areas. For those in other areas, C++ is a giant step backwards. Should've campaigned for operator overloading in FORTRAN 90. (Or is it in there? It's been a while since I looked at it. I don't remember it being in there.) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 11:27:38 -0500 Organization: Atria Software Message-ID: <maury-2901971127380001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> <maury-2701971234100001@199.166.204.230> <32EF0661.6A64@etm.co.at> In article <32EF0661.6A64@etm.co.at>, Guenter Szolderits <guenter@etm.co.at> wrote: > The POSIX subsystem of Windows NT is only POSIX.1, which does'nt include > any POSIX commands. Some POSIX commands are part of the Windows NT > Resource Kit, which must be purchased separately. Thank you for the clarification. > I consider the POSIX subsystem of Windows NT as useless. You can get > much better utilities (even for porting Unix programs to NT) from third > party vendors. Many of whom advertize in BackOffice it seems. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 11:11:12 -0500 Organization: Atria Software Message-ID: <maury-2901971111120001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> In article <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > That "Correct" was part of this statement: Which was agreeing with an _earlier_ statement, which you didn't quote. > Those two statements >>>NOT<<< identical. You deliberately removed the > rest of what I said! You also conveniently ignored my point that > conventions are created by humans, and not by computers. The context of the argument is that it's OK to have the computers define where certain file types can be stored because that's quite "natural". I've been saying it's not. > Do us all a favor, Maury-- stop trying to distort what I've said in such > a contrived fashion. As soon as you stop redefining every term used. > already had more than enough experience with revisionists on Usenet to Colour me surprised. > Are you asking me or Usenet in general? You. I'm asking YOU what resources the machines YOU run have for matching document types to applications based on that document's location. I would like to know how your file location "standards" solve the problem you posed to me in which the location of the file then defines which application is used with it. > You've been telling us all how filesystem conventions for the structure > of directories is bad, and how the MacOS lets you put files whereever > you want to which is good. I think it is. I think the limitations imposed on this by the System Folder is just that, an imposition. Perhaps a needed one, but an imposition none the less. More examples of this would be worse. > 1: relying on experience or observation alone often without due regard > for system and theory This is of course the definition that is most often applied, as in empirical vs. quantitative evidence. If you wish to redefine that term as well to be (2) or (3), be my guest, but don't "hammer" me for using the most common definition. > For example: If I count the number of users who report a problem with a > certain aspect of a program, I've just quantified real-world feedback. ^^^^^^^^^^ Agreed. What portion exactly did you think I was disagreeing with? > Go look up the previous articles. I did. > My claim was that "most networks _that_ _I_ _personally_ _have_ > _experience_ _with_ 'do this'." I have never once made a claim that all > computers in the world 'do this', or even that most computers 'do this'. That's certainly not how it read, nor how you used it in the argument. This particular portion of the thread stated after another Mac user expressed concern that the NeXT OS required you to place certain files in particular places, something he appeared to be uncomfortable with. After a chain of messages you implied that this was quite natural behaviour, and that your computers had such a standard. I have been repeatedly stating that what you do is fine, but that I don't want that on _my_ machine, I want to put the files where I wish. Now who's being revisionist? Maury
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 29 Jan 1997 11:19:10 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cnt9u$tgi@csugrad.cs.vt.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> In article <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) wrote: > There is a substantial schism between people > whose profession is writing code vs. those who write code to get a job > done, e.g., mathematicians and engineers. I forgot to mention this in the last post, but I find that statement highly insulting. The implication is that only mathematicians and engineers write code "to get a job done". ALL programmers write code to get a job done. Are you implying that non-engineering applications aren't real work? Not everyone's problem domain is limited to engineering code. Note that here I am speaking as someone who has done numerical analysis and scientific computing, on supercomputers, in FORTRAN, as well as written Mathematica libraries which use (Mathematica's equivalent of) operator overloading. Operator overloading is almost a necessity when working with mathematical expressions -- I would not want to do without it in that case -- but I feel its inclusion in a general-purpose programming language such as C++ is not generally worth the problems it causes, especially because of what it does to code readability in large software engineering projects. Operator overloading _improves_ code readability in mathematical domains, but usually harms it in other domains where operations do not map to C++ operator symbols in a canonical way. It's a case of giving programmers too much rope to hang themselves by. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: tone@wildfire.com (Tone <DoD>) Newsgroups: comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 29 Jan 1997 19:07:36 GMT Organization: Wildfire Communications, Inc. Distribution: world Message-ID: <5co75o$2e@gnus.wildfire.com> References: <jesjones-ya023580001001972219400001@news.halcyon.com> >In article <5b52nv$39e@news.xmission.com>, don@globalobjects.com wrote: >> * C++ has all these nifty features (syntactic sugar) that I can use >> to increase my productivity. Too bad that the next guy that comes >> along--to maintain my code--can't figure out what the hell I did. >> Most Objective-C code is very nearly self documenting. The simpler >> designs mean the maintenance guys can come in and quickly find and fix >> problems. If there are any. You could argue that good and bad >> programming styles affect this comparison--and yes they sure do--but >> C++ promotes arcane usage and bad style because of its haphazard >> design whereas Objective-C does a lot to help promote good design. >> Plus, how many syntax elements does C++ add to C? Has anyone ever >> sat down and counted? Compare Objective-C's number--I think it is >> in the _teens_. So which is going to be easier to debug? I agree, and I think many people who studied C++ very closely do, too. Java backs away from many of C++'s needless complexities. I'm not pointing to Java as a perfect language, but as one that received a lot of thought by people willing to make serious decisions (e.g.: removing the pre-processor) who had GREAT experience and knowledge of how C++ had attempted to improve the task of software authoring and maintenance. I call C++ a "gutter language" :) I've been using it for about 4 years, but probably not expertly. I think nearly all C++ programmers are under-achieving in their work in part because of the complexity of the language. C++'s great benefits, IMHO (not all are language-based, but reflect it's history and broad acceptance): the // comment GREAT STUFF, SERIOUSLY! Anything that makes adequate commenting simpler to do must be applauded its OO nature Again, I do not think C++ is a great OO language. But the fact that it IS an OO language is worthy of respect, given that it succeeded so broadly. Thank you C++! C++'s problems: Complexity! Multiple inheritance. Need the behavior, I agree, but this approach (while pure) introduces SO MANY issues of object footprint and function binding that it is a terrible loss in the end. The "interface" hack of Objective C and Java is so simple that its less pure nature is really easy to excuse. References and pointers. Why have both? They are essentially the same thing! I'm probably missing something here... Templates. Wow, is this a complex bastard son of the macro. Seems pasted on, to me. Operator overloading. This is really cool! It is also incredibly counter-productive to making large software projects drawing on code from various component providers (the kind of software OO is meant to support) impossible. "What does THIS plus sign do?" is not a question a programmer should ever ask himself. tone
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 11:00:20 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <AmvrEIO00iV6A287Fy@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> In-Reply-To: <maury-2801972005080001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 28-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> If Apple developed an OpenStep implementation of their own, rather than >> just paying royalties, etc for NeXT's OPENSTEP implementation, Apple >> would _own_ their code and implementation. They wouldn't owe NeXT a >> dime, since OpenStep is an "open standard". > > And that will allow them to sell it on other platforms? I think not. Really? If Apple developed their own OpenStep implementation for NT themselves, what prevents them from selling that environment to NT users? (Under the context that Apple didn't buy NeXT, of course.) >> In order to keep NeXT's customer list, Apple needs to provide an >> operating system, development environment, and so forth which is >> comparible to the functionality of NeXT's current products. > > And they wouldn't be able to get any of them unless they > first purchased it. Agreed. Apple started with a reasonably friendly user interface back in 1984. They've done okay on the strength of being user-friendly, but they've had 12+ years during which the they've only managed to make their OS cooperatively multitasking. Apple failed to write an OS which was powerful enough and stable enough to appeal to MCCA customers. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 28 Jan 1997 18:37:19 GMT Organization: Cygnus Support Message-ID: <5clh0v$qbl$5@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> Cc: maury@softarc.com In <maury-2801971119220001@199.166.204.230> Maury Markowitz wrote: > In article <32ED1135.22DC2715@screaming.org>, Pohl Longsine > <pohl@screaming.org> wrote: > > > I think, since you were the one that asserted that the PC market > > doesn't want UNIX, that the burden to provide the figures is > > yours. > > Not really, because I did provide strong evidence in the form of NT. > NT's POSIX support has either been muted or removed entirely in 4.0 (along > with support for OS/2 text mode programs and OS/2's HPFS disk format as > well) and yet no one said a thing. > > Then in order to _support_ the claim that Unix is wanted on the PC > world, Linux was offered. Unfortunately no numbers were provided with it. > Take a look at SCO's Unix offerings. They started off with a Unix clone (Xenix) that was practically the only PC unix option, and the demand was strong enough that they eventually bought the intellectual propperty of Unix. They're a strong growing company with a significant portion of the Unix market. And they only deploy on the PC. Next, take a look at the stats for web servers.. (No, I don't have them to give you, but I have seen them in the past .. and you can probably find them yourself). A significant portion of the web servers out there are based on linux, freebsd, or netbsd. And NONE of the commercial platforms are putting a significant dent in that.. including non-Unix PCs. Third, take a look at the volume of diskspace devoted to Linux and *Bsd archives. These wouldn't exist if there was a near zero interest in Unix on the PC... and there are growing and thriving business based on those free PC Unices.. that wouldn't happen if there wasn't a demand in the PC marketplace for Unix (though, that may be the tail wagging the dog.. Probably some of that is Unix people going to the PC because the PC has free Unices). You don't need hard numbers to see that this is true. The information above wouldn't be true if there wasn't such a demand. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 11:24:59 -0500 Organization: Atria Software Message-ID: <maury-2901971124590001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-210197105714 <maury-2801971735280001@199.166.204.230> <5cmmkd$q4@csugrad.cs.vt.edu> In article <5cmmkd$q4@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > They don't want the Mac either, apparently. Apparently? I think it's a good bet. Maury
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 29 Jan 1997 16:34:00 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5cnu5o$eus@geraldo.cc.utexas.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@cs Jonathan W. Hendry (jon@exnext.com) wrote: : Andy Templeman wrote: : > : > Apple already sell Unix boxes for people who want to run Unix servers. : > You can buy today a Network server 700 which runs AIX. How will Apple be : > exposing themselves to a new market by offering a second unix operating : > system? : : What about people who want Unix, but not a server? There are : lots of people running Unix as a workstation OS. They'd love : to have lots of polished productivity apps. Right now, if : they want them, they've got to go to NT. : : There's a huge difference between offering Yet Another Unix (AIX, : or A/UX) and offering a robust, user-friendly Unix which runs lots : of useful, polished applications. : Unfortunately, the number of users who want a Unix OS and productivity apps is small (even though it includes me 8-)). Apple would be better served concentrating on larger markets, like content development, publishing, and the like, where the Apple name on a robust, stable and fast OS will quickly gain favor. Hopefully, we Unix users will get what we want, but I'm not holding my breath. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 11:27:03 -0500 Organization: Atria Software Message-ID: <maury-2901971127030001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2801971223060001@199.166.204.230> <5clj2q$76p@csugrad.cs.vt.edu> <maury-2801971733120001@199.166.204.230> <5cmmpi$11g@csugrad.cs.vt.edu> In article <5cmmpi$11g@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > Ok, let's see... it has a complete lib for file access, including > > documents and databases, as well as supporting powerful searching, sorting > > and information extraction from any of the objects in the data store. It > > has a complete string manipulation library too. Development is handled by > > CodeWarrior, so a lot of those utilities aren't needed. It seems we're > > down to some of the networking daemons now. > > Uh huh. Go look around the bin directories of a Unix system sometime. Right, and I find the same thing. This is the _point_, Be has recreated much of this, something Chuck claims is practically impossible and no one should waste their time on. > You'd be surprised. And a lot of them are used by higher-level scripts > without you even knowing about them, rather than directly. Code coverage numbers please. Regardless many do specific one off functions that could be portions of a single object. cat would be a good example. Maury
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 15:43:38 -0500 Organization: Atria Software Message-ID: <maury-2901971543380001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> <Amvtefa00iV6M288Ja@andrew.cmu.edu> In article <Amvtefa00iV6M288Ja@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > When I write commercial software, OO is useful for about 80% of the code. Ok, good. > If by "consistency" you mean that I have to use the "best solution for > most problems" for every problem, then no. That's not what I mean. I mean when you are writing that 80% of the code that is OO based, you'd likely want to keep it that way. > I have no interest in developing software for a lowest common > demoninator Quite the opposite, I believe this allows for newer code that's better than currently prodivide. > which does not understand fork() and exec(). That's not what I was talking about, I was talking about the _way_ you call it. > No. I have better things to do with my programming time than trudge > through slime trying to write functional code in the abscence of a > reasonable operating system which provides a reasonable development > environment and reasonable library routines. Who said anything about lacking library routines? You'll have more, and perhaps better ones. > OpenStep demands a certain baseline functionality from the operating > system. Windows NT and Unix systems provide that. Windows 95 is > somewhat iffy, but adequate. Windows 3.1 and the MacOS aren't > adequate-- they don't provide enough functionality (eg, preemptive > multitasking for the machd to service Mach messages in time) to support > an OpenStep implementation. Uhhh, and? My point was not to select a single OS, but to show that more code is better than less code in this case. > As for the context switching overhead, if there is a system where > switching between processes is faster than switching between threads in > one process, you're looking at a completely broken thread implementation. That is indeed what I was referring to, and you seem to have it reversed. > Gee, could it be that you were batting well above average in this > particular case, and that someone could easily find other articles where > you didn't do nearly as well? So that's what this thread is for you now? A "count the times I find something wrong in a Maury post"? > > I see. So if I delete, say, grep, off of my hard drive, Unix stops > > working? > > Yes: No, only if there's no grep-stub calling the new code. Who's suggesting that? > I don't see how that matters at all. Grep is used by the operating > system to perform essential functionality. So, does that mean it _should_? > Those are nice goals. The existence of the Unix CLI utilities on a > system does not prevent any of these goals from occurring. I agree, but it doesn't help any. > In fact, I think tools like grep make programming easier, and they make > the system easier to use. And both would be even _easier_ too. But hey, if you think they're good enough, who am I to tell you different? Maury
From: nobody@REPLAY.COM (Anonymous) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: Tar vs. Stuffit [was Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!!] Date: 29 Jan 1997 20:04:03 +0100 Organization: Replay and Company UnLimited Sender: replay@basement.replay.com Message-ID: <5co6v3$6b3@basement.replay.com> References: <maury-0801971641590001@199.166.204.230> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@csugrad.cs.vt.edu> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1osd$c0s@news.digifix.com> <32E70F28.48B8@friday.com> <5c4rhc$o1k@ccpnws.in2p3.fr> <jdoherty-2301972150580001@aus-tx9-13.ix.netcom.com> <dea-ya023480002601971409470001@news.magic.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <dea-ya023480002601971409470001@news.magic.ca>, dea@astral.magic.ca (Don Andrachuk) wrote: > In article <jdoherty-2301972150580001@aus-tx9-13.ix.netcom.com>, > jdoherty@ix.netcom.com (John Doherty) wrote: > > >In article <5c4rhc$o1k@ccpnws.in2p3.fr>, mullere@in2p3.fr (Eric Muller) wrote: > > > >| Bill Bumgarner (bbum@friday.com) wrote: > >| (some stuff deleted) > >| : If anything, Aladdin should release a version of Stuffit that can be > >| : used from the command line... I'd certainly pay for a tool that give me > >| : random access to my archives, a full-featured GUI w/drag-n-drop, and a > >| : comparably featured command line utility. > >| > >| If you use MPW you can have the Stuffit tools, they come with Stuffit > Deluxe. > > > >But the v3.5 tools, at least, are incomplete (I don't have StuffIt 4): > >can't add to an existing archive, can't extract fewer than all the files > >from an archive, can't even list the contents of an archive. > > *All* of those things are possible with version 4. Not only that, but > Aladdin's True Finder Integration control panel provides these features > completely transparently at the Finder. > > -- > Don Andrachuk > DEA Systems Stuffit Lite 3.05 had an OK applescript interface. (It was removed from 3.5 and later versions of Stuffit Lite)
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 15:28:34 -0500 Organization: Atria Software Message-ID: <maury-2901971528340001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2801971733120001@199.166.204.230> <5cmmpi$11g@csugrad.cs.vt.edu> <maury-2901971127030001@199.166.204.230> <5co4fc$8n4@csugrad.cs.vt.edu> In article <5co4fc$8n4@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > <snicker> For sufficiently small definitions of "much". Maybe so, but on the other hand portions of their OS is much richer than anything offered in "standard" Unixen that I am aware of. Their file/document system is a certainly one good example, volumes are simply large databases storing objects. I think this is something I'd like to see in the future NeXT OS as well. Hey, at least they're trying. Maury
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 24 Jan 1997 13:10:04 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5catts$508@csugrad.cs.vt.edu> References: <ga-1501971324330001@cust81.max27.los-angeles.ca.ms.uu.net> <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> <32E8F5E9.2620@nowhere.com> In article <32E8F5E9.2620@nowhere.com>, none wrote: > Nathan M. Urban wrote: > > [anArray replaceObjectAtIndex:i withObject:obj2]; > > [anArray replaceObjectAtIndex:j withObject:obj1]; > > [obj1 release]; // decrement the reference count > I can think of another reason why C++ took off, rather than Objective-C: > That looks nothing like C. Thank goodness. I hate the C++ method-calling syntax. That probably is one of the reasons, though. I think that having a different syntax is a pretty poor reason not to learn a language, but I'm sure many C programmers did feel more comfortable with C++'s syntax. Too bad Java made the same mistake. > I have never coded in pure C, but I'd say that the fact that C++ can > look like C must have made the transition less scary for many people. I suppose. Once you get used to Obj-C's syntax, though, a lot of people like it better. It makes it clearer that you are sending a message to and object rather than accessing a structure field or calling a function (which you are NOT doing), and lets you alternate pieces of the method name with the parameters it takes. I prefer [anArray replaceObjectAtIndex:i withObject:obj2]; to anArray.replaceObjectAtIndex_withObject(i,obj2); or anArray.replace(i,obj2); even if the latter is shorter, because the former is more readable. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: alanf@izzy.net Newsgroups: comp.sys.next.programmer Subject: Broken Pipe? Date: 29 Jan 1997 17:38:10 GMT Organization: "Comshare, Inc." Message-ID: <5co1u2$kpn$1@inet-prime.comshare.com> In the 3.2 developer environment, I'm working on an app that redirects the stdin and stdout from a shell process to pipes, that in turn are connected to text objects. I've used a similar program in the Garfinkel/Mahoney book as reference. The shell's stdout is connected to fromProcess[1], the end of the pipe fromProcess[0] is being watched by DPSWatchFD (3.2, remember?). DPSWatchFD calls a printer function that messages the text object. This appears to work fine... the arguments I pass the shell via execv are echoed back, and appear in the text object. The other text object delegates to a method that writes to the pipe toProcess[1]... the other end of the pipe should be connected to the stdin of the shell: ------code fragment------------------------------------- syslog(1,"hello from child process"); close(0); /* stdin */ close(1); /* stdout */ close(toProcess[1]); close(fromProcess[0]); syslog(1,"reassigning stdin and stdout"); dup2(toProcess[0], 0); /* stdin */ dup2(fromProcess[1], 1); /* stdout */ close(2); /* stderr */ dup2(fromProcess[1], 2); /* stderr */ execv(argv[0], argv); -------------------------------------------------------------- The shell script should (and initially does) simply echos to stdout whatever comes in on stdin. The debugger indicates whatever I type into the "inbound" text object is making it to the pipe, however I receive nothing coming back from the other pipe. I believe I've traced everything I can with the debugging tools, the other side of the pipes are inaccessible. Any thoughts on how to sort this one out? Please cc: any responses to my email. Regards, Alan Frabutt (alanf@izzy.net)
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 29 Jan 1997 13:21:32 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5co4fc$8n4@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2801971733120001@199.166.204.230> <5cmmpi$11g@csugrad.cs.vt.edu> <maury-2901971127030001@199.166.204.230> In article <maury-2901971127030001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5cmmpi$11g@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > Ok, let's see... it has a complete lib for file access, including > > > documents and databases, as well as supporting powerful searching, sorting > > > and information extraction from any of the objects in the data store. It > > > has a complete string manipulation library too. Development is handled by > > > CodeWarrior, so a lot of those utilities aren't needed. It seems we're > > > down to some of the networking daemons now. > > Uh huh. Go look around the bin directories of a Unix system sometime. > Right, and I find the same thing. This is the _point_, Be has recreated > much of this, <snicker> For sufficiently small definitions of "much". -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 13:44:59 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Amvtefa00iV6M288Ja@andrew.cmu.edu> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> In-Reply-To: <maury-2701971215410001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 27-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> That is simply not true for every problem. > > I never said anything about "every problem". Let's hear your percentage > then. 80%? 90%? When I do system administration tasks, I rarely find OO paradigms useful, whereas the Unix CLI utilities are useful 95+% of the time. When I write commercial software, OO is useful for about 80% of the code. >> Again, OO programming is one paradigm out of many. It is not always the >> best solution to every possible problem, although it is very good for a >> lot of problems. > > And thus if you're using it (which you are in OpenStep after all) then > wouldn't you like consistency? Don't you _want_ to have access to the > best solution for most problems? If by "consistency" you mean that I have to use the "best solution for most problems" for every problem, then no. I'd rather use the "best solution for most problems" when it's appropriate, and use other solutions for the other times when they are better choices. > So why not have it? I do have NEXTSTEP and I'm more than slightly familiar with OpenStep-- I've had it for over 6 six years now. You don't need to advocate OpenStep to me. >> I can use fork()/exec() (which is more controllable in terms of handling >> stdin, stdout, etc that system()) on every POSIX-compliant operating >> system and every Unix system around. > > But that's a TINY portion of the computer market. A better solution > that's not platform dependant would allow easier access to the rest of the > market. I have no interest in developing software for a lowest common demoninator which does not understand fork() and exec(). I could care less about writing code that will work under the MacOS or under MS-DOS and Windows 3.1. > What's funny about this thread is that while people seem fond of telling > me this is nothing more than a "religious" anti-Unix rant, it appears the > arguments offered in return are exactly that indeed. > > What's everyone so afraid of? Work? No. I have better things to do with my programming time than trudge through slime trying to write functional code in the abscence of a reasonable operating system which provides a reasonable development environment and reasonable library routines. >> Such code is portable to more operating system/hardware plaform >> combinations than any other system call API that is available today. >> How is this not cross-platform? > > It is however, NOT portable out of the box to the vast majority of > _computers_ in the world. There's nothing inherent in OpenStep that I can > see that has such a limitation that could stop it from running over, say, > Win3.1. OpenStep demands a certain baseline functionality from the operating system. Windows NT and Unix systems provide that. Windows 95 is somewhat iffy, but adequate. Windows 3.1 and the MacOS aren't adequate-- they don't provide enough functionality (eg, preemptive multitasking for the machd to service Mach messages in time) to support an OpenStep implementation. >> You do realize that the fastest and most efficient web servers are >> written by preforking child servers-- such a design beats a >> multithreaded web server in pretty much every regard. > > That's because few Unixen have fast threading services, a point well > hashed out in other threads (of the message sort). Nonsense. Who cares what the thread startup costs are when you can compare preforking servers versus prespawning a multithreaded server? As for the context switching overhead, if there is a system where switching between processes is faster than switching between threads in one process, you're looking at a completely broken thread implementation. > > Nothing-- it's not terribly difficult at all. Why don't you understand > > that almost every single point you've made in several articles, > > including this one, have been wrong? > > You agree with most of them (3 out of 4 to be exact), yet they are > wrong. Your logic escapes me. Gee, could it be that you were batting well above average in this particular case, and that someone could easily find other articles where you didn't do nearly as well? [ ... ] >> If you make Unix optional, Rhapsody will no longer be Unix-compatible >> because you would have to replace the current Unix functionality with >> something else that is not optional-- this is the case with OpenStep on >> NT. Doing constitutes "ripping out Unix", since the operating system >> would no longer be a Unix operating system. > > I see. So if I delete, say, grep, off of my hard drive, Unix stops > working? Yes: % grep grep /etc/rc* /etc/rc:if ifconfig -a | grep -v "127.0.0.1" | grep -v "0.0.0.0" | grep -s inet; then /etc/rc: /usr/bin/egrep 'enable.+YES' ) >/dev/null 2>&1 /etc/rc: if [ -n "`ifconfig -a | grep en0 `" -o -n "`ifconfig -a | grep tr0 `" ]; then /etc/rc.local:pid=`ps cax | egrep nmserver | awk '{print $1;}'` /etc/rc.net:pid=`ps cax | egrep nmserver | awk '{print $1;}'` Your system won't have the loopback interface correctly configured, and the Mach nameserver won't be reinitialized correctly. >> And guess what? Apple bought NeXT because "Apple needed a truly modern >> operating system and NeXT had an exceptional operating system with >> modern services and API's." > > This descibes OS certainly, but do you truly offer up grep as a paradigm > of modern programming? I don't see how that matters at all. Grep is used by the operating system to perform essential functionality. > > All of this to save $3 worth of disk space? > > No, to make... > > a) programming easier > b) programming more consistent > c) the system more portable > d) the system easier to use > > But who want's any of those, eh? Those are nice goals. The existence of the Unix CLI utilities on a system does not prevent any of these goals from occurring. In fact, I think tools like grep make programming easier, and they make the system easier to use. I think that the world would be a better place if every operating system supported the POSIX API and command line utilities, because that would make programming more consistance and operating systems more portable. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 29 Jan 1997 18:40:15 GMT Organization: Cygnus Support Message-ID: <5co5if$slt$2@majipoor.cygnus.com> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> Cc: maury@softarc.com In <maury-2801972005080001@199.166.204.230> Maury Markowitz wrote: > In article <8mvbN9600iV1I6469b@andrew.cmu.edu>, Charles William Swiger > <cs4w+@andrew.cmu.edu> wrote: > > > If Apple developed an OpenStep implementation of their own, rather than > > just paying royalties, etc for NeXT's OPENSTEP implementation, Apple > > would _own_ their code and implementation. They wouldn't owe NeXT a > > dime, since OpenStep is an "open standard". > > And that will allow them to sell it on other platforms? I think not. > Then you don't know what an "open standard" is. Anyone can download the Openstep Spec from NeXT's ftp site. Anyone can impliment a set of libraries and system daemons that meet that spec. NeXT has no ability to say or do anything other than "that does [or doesn't] meet the requirements set down in the Openstep Spec" wrt to how the implimentor markets, distributes, deploys, or uses their implimentation of the specification anymore than those who wrote the Posix standard can tell Linus T how to distribute Linux. This is pretty much what GnuStep is.. a GNU implimentation of the Openstep libraries. NeXT and Apple will have no control over that implimentation, no right to require royalties, no right to limit what platforms it is distributed for (including their own platforms), etc. The only thing they could possibly do is stop circulating the Spec (which doesn't affect those who already have copies, it only prevents new copies _of_the_spec_ from being created and distributed), and stop allowing the anyone to claim "openstep compliance" even if they are openstep compliant or otherwise use the openstep name (the latter still wouldn't affect Gnustep, since they decided not to be called "Gnu Openstep"). This is what it means to be an "Open Standard". Anyone can impliment the standard, and they own their implimentation fully. The entity which creates the standard only owns the standard itself, and the name of the standard, and has _no_ control over the implimentations themselves. > > In order to keep NeXT's customer list, Apple needs to provide an > > operating system, development environment, and so forth which is > > comparible to the functionality of NeXT's current products. > > And they wouldn't be able to get any of them unless they first purchased it. > Not _necessarily_ true. They could have built a Rhapsody like system out of the Mklinux project. There is already a faction of Gnustep working to be sure it will deploy on Mklinux. Depending on whether you consider BSD (as opposed to simply 'unix-like') a requirement, mklinux already plans to allow multiple-server-OS's, and BSD-lites (a BSD 4.4 Mach Server OS) is as free as Linux. That could be ported to mk. Take those (their existing mk kernel, BSD-lites, Gnustep), put a upgraded Mac GUI on it, and create GUI admin tools, and they're probably closer to Rhapsody than they ever got with Copeland. They might even be able to ship something Rhapsody like in a year, if they worked at it. What they got from NeXT was all of that pre-canned, with several years of maturity and stability, and people whose "expert" credentials are impeccable (are there truely any professional linux experts out there? some.. but experts with all or most of mklinux?). They also got a coherent and working set of components. Rolling their own would have meant endless meaningless internal debates about whether their Gnustep needed to be GX or DPS, etc, etc, etc. Apple doesn't need to spend the next 2 years arguing over which group of standards to ship in one package, they need to deploy a working package. The last thing "they got" may sound strangest.. Especially coming from a Cygnus employee.. They got a proprietary implimentation. Why is that important? Because if they just took those free software packages, added a few new things, and shipped that.. just about anyone else could replace what they've got in about the same amount of time without paying a penny to Apple. At that point Apple becomes a Support body, not much of a Development body (though, that's arguable.. Cygnus is probably best known for supporting free software packages, but we also do a lot of development on them, and we even get a good chunk of revenue from having done that). Even if they managed to keep Development, it would imply a major restructuring of their business model.. not something they need to be saying to their investors right now. I mean.. if you're an investor who has put a lot of money in to Apple's proprietary past (and not gone out to invest in a company like Cygnus), how are you going to feel about the value of your stock if Amelio shows up tomorrow and says "HEY! We're going to become a free software company!" I'd think it was cool. But I don't know that you'd get the same reaction from Apple's current stock holders. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: headi@now.ch (Daniel Scheidegger) Newsgroups: comp.sys.next.programmer Subject: How bad can a file descriptor be? Date: Wed, 29 Jan 1997 13:42:28 GMT Organization: NOW GmbH, Zuerich, Switzerland Sender: news@now.ch Message-ID: <E4rvEs.K1G@now.ch> Hi all, maybe one can help me with this problem: I'm in the process to port an application from OpenStep/Mach to OS/NT 4.1 which uses NSFileHandles for TCP/IP-communication. I'm going trough the normal process of creating a socket, connecting it to the remote system and creating a NSFileHandle for asynchron I/O. This works very well on OS/Mach. But the same code generates the following exception under OS/NT: -[NSConcreteFileHandle availableData]: Bad file descriptor. What can be the reasons for this? Netstat tells me, that the connection exists, so, whats bad with my file descriptor? Thanks for every hint Daniel -- Daniel Scheidegger Software Engineer, System Administrator NOW GmbH, Scheideggstr. 73, CH-8038 Zuerich ++41-1-2898025 / dscheide@now.ch
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.system,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sun, 19 Jan 1997 13:48:20 -0800 Organization: Modulation Message-ID: <32E296A4.4261@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.advocacy: 16-Jan-97 Re: MacWorld > Exclusive: App.. by Maury Markowitz@softarc. > > > Why? Various scripting languages are all the rage now. JavaScript, > > > WebScript, VBScript, etc. plus what proponents sell as advanced > > > 4th-generation languages (4GLs) which are usually interpreted. The Unix > > > > Read it carefully, I was taling about calling these things from the > > command line, not the command line itself or using it as a person. IE, > > programs should not have to call things by "pretending" to typing in CLI > > commands. > > Sure. That's why the kernel provides a system call API. > > But that's not what you're arguing about-- you seem to be claiming that > it is wrong for a program to execute a CLI utility to perform some task. > And that's silly. Why don't you show me how you'd use system calls on > any OS you'd like to send email? > > With the CLI tools under Unix, sending a message in C is a one-liner: > > system("echo 'This is the contents of the message.^D' | mail -s 'My > Subject' '<cs4w@andrew.cmu.edu>'"); The same could be done in C without using the system() function. But it would be ugly and awkward by comparison. However, the fault lies both with C and with the standard C library. In some other programming language, such as Smalltalk (hey, you knew this was coming, right?), coding the above could be as simple as: MailTool sendMessage: 'This is the contents of the message.' withSubject: 'My Subject' to: '<cs4w@andrew.cmu.edu'. If it were this simple in C (for everything, not just sending mail), then perhaps the system() function would be used much less. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: Darren Reely <dreely@cyberstore.ca> Newsgroups: comp.sys.next.programmer Subject: Re: Porting from NS to Rhapsody Date: 19 Jan 1997 21:52:26 GMT Organization: Cyberstore Systems Inc. Message-ID: <5bu52q$hoc@scipio.cyberstore.ca> References: <5aubl0$aql@abel.ic.sunysb.edu> <tbrown-ya023580001701972114140001@news.netset.com> tbrown@netset.com (Ted Brown) wrote: >A microkernel change should pose much of a problem You can already move >from OpenStep/Mach to OpenStep/NT. I think you meant to say a microkernel change should'nt pose much of a problem. Darren http://www.bcog.org/~dreely
From: sangria@inlink.com (Sang K. Choe) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 01:17:26 GMT Organization: InLink Message-ID: <3304f650.1643531640@mambo> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <0mrz3kS00iVGI9e7EM@andrew.cmu.edu> <maury-2001971516170001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-2101971057140001@199.166.204.230> <5c2r53$3i3@bignews.shef.ac.uk> <maury-2101971324190001@199.166.204.230> <5c4pde$s64@bignews.shef.ac.uk> <maury-2701971332390001@199.166.204.230> <32ED1135.22DC2715@screaming.org> <maury-2801971119220001@199.166.204.230> <32EE7205.CCA9263@screaming.org> <32f9a559.1557269312@mambo> <maury-2901971052540001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed, 29 Jan 1997 10:52:54 -0500, maury@softarc.com (Maury Markowitz) wrote: >In article <32f9a559.1557269312@mambo>, sangria@inlink.com (Sang K. Choe) wrote: > >> NT 4.0's POSIX subsystem is still quite intact and supported. A large >> chunk of the utilities shipped with the ResKit would be useless were >> this the case. > > Sorry, again I am a victim of poor use of a term. I'm not really >referring to the POSIX API in this case, but utilities. For instance, >nowhere on my drive can be found any of the standard utils - yes I know >they are not a part of POSIX. So go and download them. You can find a decent set for free at www.cygnus.com. Or you can get another set from U of Texas. Or you can try the enhanced POSIX package from SoftWay in their OpenNT product. The POSIX 2 compliant tools/sdk should be available RSN. > SoftWay... the guys that do the Unix compatibility stuff for NT? Yep. -- Sang. ******************************************************** * Sang K. Choe sangria@inlink.com * * http://sangria.inlink.com/index.html * * finger: sang@sangria.inlink.com * ********************************************************
From: David Matiskella <davidm@netscape.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Wed, 29 Jan 1997 15:24:36 -0800 Organization: Another Netscape News Server User Message-ID: <32EFDC32.3ADC@netscape.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Rudd wrote: > > In <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> G. Gordon > Apple, PhD wrote: > > > >> which BTW means having function overloading because operators > > > >> by definition are functions. > > > > > > > > No. Operator overloading is NOT a subset of function overloading. > > > > Operators on objects are methods, which are not functions, at least in > > > > Objective-C. (Note that "function overloading" refers to C functions, > > > > not mathematical ones.) > > > > Which is actually making my point. "Operators" are by definition > > "functions" in the mathematical sense. You then responded to me in the > > context of Objective C. There is a substantial schism between people > > whose profession is writing code vs. those who write code to get a job > > done, e.g., mathematicians and engineers. Many times, the output of the > > latter moves into the domain of the former, especially as the power of PCs > > (in the generic sense) continues to increase. > > > > For example, I have often seen relatively new programmers dismiss the > > need for FORTRAN compilers. They have no concept of the vast libraries of > > FORTRAN code that runs much of the engineering world today and keeps the > > rest of the world running. One of the big advantages of C++ (e.g., over > > FORTRAN or C) is the ability to take the abstract mathematical concept of > > an "operator" and implement it in code in a way that is still > > recognizable. Galois fields and complex numbers may be considered highly > > specialized to some professional shrink-wrap application programmers, but > > they are very basic in many engineering areas. IMHO, giving that up is a > > giant step backwards. > > > > > > Ok... just out of curiosity, for those cases where you need to change the way > objects "add" or "multiply" etc, to reflect their implimentation or > whatever.. > what is wrong with an "Add:" method, instead of "+:" or "+"? > > It's slightly more verbose, but it's not really more or less readable to say: > > foo = [ComplexA add: ComplexB]; > > than > > foo = ComplexA + ComplexB; > > -- > John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd > =========Intel: Putting the backward in backward compatible.============ > Smalltalk == Astronaut's tools. Awkward at first, but exceptional design > C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick. If you take that attitude why should the language even have operators? Why not write c=Add(a,b) for every data type? What makes the built in ones special? Depending on what you are doing operator overloading is a godsend. If you are writing programs that depend on custom math types it makes your code a lot simplier. With just 1 operator its not bad but imagine if you want to do something like m=m1*m2*m3*m4 where the m's are a bunch of matrices. That is a hell of a lot easier to read than m=Matrix_Mult(Matrix_Mult(Matrix_Mult(m1,m2),m3),m4). If you aren't doing math heavy things like FEM, 3d graphics and the like, you might not miss them, but if you are you really do miss them whenever you have to deal with a language that doesn't have them. All IMNHO of course David Matiskella
Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: Adobe Bravo Message-ID: <E4sCBp.sx@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <8D0E511.09B600067E.uuout@moondog.com> <Pine.OSF.3.91.970128132843.24689B-100000@sable.ox.ac.uk> Date: Wed, 29 Jan 1997 19:47:49 GMT Ravi Mendis <lady0098@sable.ox.ac.uk> wrote: > > On Mon, 27 Jan 1997, SHEPPARD GORDON quoted: > > A new graphical infrastructure for the Web. (Adobe Bravo) > > 07/01/96 > > Advanced Imaging > > > > TEXT/TYPOGRAPHY FEATURES > > > > As I've noted, text support in Bravo is not tied to any specific font > > technology. Applications can interchangeably work with Type 1, Type 1 > > multiple master, TrueType and the new "OpenType" technology recently > > announced by Adobe and Microsoft. Open Type is a universal font format that > > will combine TrueType and Type 1 font technologies to streamline management > > of existing fonts and provide a font format to handle the next generation of > > type for personal computers and the Internet. > > How about supporting QuickDraw GX Typography? Well shouldn't be a problem as far as "fonts" are concerned. But typography here does not include the "WorldScript" stuff since that would contradict with Bravos "portabilty". Things would look different on a Mac if it would only perform the ligature etc. stuff on that platform. But this whole issue is pretty useless as documetns which use GX fonts could not be displayed on e.g. Win95 boxes as long as you don't have them...etc. pp. I am still not really sure what Bravo is all about. It seems like a stripped down DPS system without all the interpreter stuff (PSwarps etc.). Seems like NeXTs/Apples DPS is perfectly suited for Bravo since it might just be an aditional layer on top of that (if they include antialiasing into DPS text rendering) What is this talk about support for "scalable PostScript line-art". Thats not EPS support...is it ? It can't be since then Bravo would not fit into a few hundred kilobytes (but then...how "few" is "few". DPS is only a "few hunderte" k too) And does Bravo build on top of the underlying drawing system (GDI, QuickDraw..) ? I supos not..sicne then results could not be really predicted. So it might just blit framebuffers. > * Collect graphical objects, characters and images to be painted multiple times into a display list cache. While almost all features are DPS alike (besides antialiasing and "save to PDF") I am not sure what this is about. These display lists seem to be more then a DPS "gstate" ?. Is that a PDF-style "base operationg" instruction set. To some degree it seems funny that the Java/Bravo systems are about to rebuild OpenStep. Add in the OpenDoc/Java thing and Rhapsody looks more then interesting. Aloha Tomi P.S. Sorry for crossposting...but shouldn't this migrate to the programmer group ?
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 29 Jan 1997 21:47:34 GMT Organization: Cygnus Support Message-ID: <5coghm$287$5@majipoor.cygnus.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> Cc: ga@ed4u.com In <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> G. Gordon Apple, PhD wrote: > > >> which BTW means having function overloading because operators > > >> by definition are functions. > > > > > > No. Operator overloading is NOT a subset of function overloading. > > > Operators on objects are methods, which are not functions, at least in > > > Objective-C. (Note that "function overloading" refers to C functions, > > > not mathematical ones.) > > Which is actually making my point. "Operators" are by definition > "functions" in the mathematical sense. You then responded to me in the > context of Objective C. There is a substantial schism between people > whose profession is writing code vs. those who write code to get a job > done, e.g., mathematicians and engineers. Many times, the output of the > latter moves into the domain of the former, especially as the power of PCs > (in the generic sense) continues to increase. > > For example, I have often seen relatively new programmers dismiss the > need for FORTRAN compilers. They have no concept of the vast libraries of > FORTRAN code that runs much of the engineering world today and keeps the > rest of the world running. One of the big advantages of C++ (e.g., over > FORTRAN or C) is the ability to take the abstract mathematical concept of > an "operator" and implement it in code in a way that is still > recognizable. Galois fields and complex numbers may be considered highly > specialized to some professional shrink-wrap application programmers, but > they are very basic in many engineering areas. IMHO, giving that up is a > giant step backwards. > > Ok... just out of curiosity, for those cases where you need to change the way objects "add" or "multiply" etc, to reflect their implimentation or whatever.. what is wrong with an "Add:" method, instead of "+:" or "+"? It's slightly more verbose, but it's not really more or less readable to say: foo = [ComplexA add: ComplexB]; than foo = ComplexA + ComplexB; -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 29 Jan 1997 00:21:54 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cmmpi$11g@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2801971223060001@199.166.204.230> <5clj2q$76p@csugrad.cs.vt.edu> <maury-2801971733120001@199.166.204.230> In article <maury-2801971733120001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5clj2q$76p@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > Look again. BeOS is nowhere near as mature as Unix. The current OOP > > APIs have a lot of the core functionality of Unix's base API (e.g., > > POSIX), but the BeOS APIs do not encapsulate nearly as many utility > > routines as the Unix command-line programs. It does not have OOP > > replacements for all, or even many, of the Unix command-line > > utilities. > Ok, let's see... it has a complete lib for file access, including > documents and databases, as well as supporting powerful searching, sorting > and information extraction from any of the objects in the data store. It > has a complete string manipulation library too. Development is handled by > CodeWarrior, so a lot of those utilities aren't needed. It seems we're > down to some of the networking daemons now. Uh huh. Go look around the bin directories of a Unix system sometime. > > I _am_ looking at raw numbers. What does "a lot" mean? Fake numbers? > How about total amount of time the user spends using them? Total number > of invocations. Sure there might be 1000 unconverted Unix utils, but does > anyone use them? You'd be surprised. And a lot of them are used by higher-level scripts without you even knowing about them, rather than directly. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 20:28:10 -0500 Organization: Steel Driving Software, Inc. Message-ID: <32EFF92A.526D@subsequent.com> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@cs <5cnu5o$eus@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: > Unfortunately, the number of users who want a Unix OS and productivity > apps is small (even though it includes me 8-)). Apple would be better > served concentrating on larger markets, like content development, > publishing, and the like, where the Apple name on a robust, stable and > fast OS will quickly gain favor. Hopefully, we Unix users will get what > we want, but I'm not holding my breath. You're assuming that the only way to market a Unix OS is as a Unix OS. This is not a good assumption. Rhapsody will have copious features which will allow it to be marketed to people who don't care one whit about Unix. Apple need only mention the Unix feature as one among dozens. The best bet would be to emphasize it in some marketing campaigns, and de-emphasize it in others. When trying to sell to techies, sell the Unix, along with everything else. When selling to artists, sell the power, ease of use, Display Postscript, and software - sell it as a Macintosh. There's no logical reason for Apple to use Unix marketing techniques to market their Unix operating system. There just isn't. Most Rhapsody users won't care what's under the hood - but that's not an argument against using Unix. -- "Liar. Liar. Liar. Liar. Liar. Hateful liar. That's what she is." - ELLIOT J. ABELSON A Los Angeles lawyer who represents Scientology speaking about the Pinellas-Pasco medical examiner
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 30 Jan 1997 03:45:35 GMT Organization: Airwindows Message-ID: <jinx6568-2901972248010001@news.sover.net> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> <maury-2901971111120001@199.166.204.230> In article <maury-2901971111120001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > That's certainly not how it read, nor how you used it in the argument. > This particular portion of the thread stated after another Mac user > expressed concern that the NeXT OS required you to place certain files in > particular places, something he appeared to be uncomfortable with. After > a chain of messages you implied that this was quite natural behaviour, and > that your computers had such a standard. I have been repeatedly stating > that what you do is fine, but that I don't want that on _my_ machine, I > want to put the files where I wish. Hm. Maury, it might even be me you're talking about as I sometimes have documents in a folder with their applications- for rarely used things that I want to be localized. I did mention this. I also have stuff in Engine/Desktop Folder, which is a subdirectory of Engine my hard disk. It is a real live subdirectory- it just happens to show different behavior (a screen-shaped window without borders or scrollbars.) I download Kaleidoscope color schemes. These have to go in Engine/System Folder/Extensions/Kaleidoscope Color Schemes or they won't work at all. I don't think twice about it and bear Greg Landwebe (who _is_ God, after all ;) ) no ill will for not making Kaleidoscope capable of hunting all over local and network disks for possible locations of color schemes. (I just wish he'd document the col# resource ;) ) You know? I don't think anybody will notice or care. Let the NeXTos be NeXTos. We'll deal. This is not hard stuff. Jinx_tigr (aka Chris Johnson)
From: sangria@inlink.com (Sang K. Choe) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 01:15:49 GMT Organization: InLink Message-ID: <3303f619.1643476734@mambo> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> <maury-2701971234100001@199.166.204.230> <32EF0661.6A64@etm.co.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Wed, 29 Jan 1997 09:12:17 +0100, Guenter Szolderits <guenter@etm.co.at> wrote: >Maury Markowitz wrote: >>.. >> > NT provides a POSIX-compliant environment, does it not? ... >> >> None of which appear to be on either my NT server or workstation. > >The POSIX subsystem of Windows NT is only POSIX.1, which does'nt include >any POSIX commands. Some POSIX commands are part of the Windows NT >Resource Kit, which must be purchased separately. Or you can download a fairly complete set from CyGnus (www.cygnus.com) for free. -- Sang. ******************************************************** * Sang K. Choe sangria@inlink.com * * http://sangria.inlink.com/index.html * * finger: sang@sangria.inlink.com * ********************************************************
From: kennel@lyapunov.ucsd.edu (Matt Kennel) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Date: 29 Jan 1997 21:19:26 GMT Organization: The University of California at San Diego Message-ID: <5coesu$cm8@news1.ucsd.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> Maury Markowitz (maury@softarc.com) wrote: : In article <8mvbN9600iV1I6469b@andrew.cmu.edu>, Charles William Swiger : <cs4w+@andrew.cmu.edu> wrote: : > If Apple developed an OpenStep implementation of their own, rather than : > just paying royalties, etc for NeXT's OPENSTEP implementation, Apple : > would _own_ their code and implementation. They wouldn't owe NeXT a : > dime, since OpenStep is an "open standard". : And that will allow them to sell it on other platforms? I think not. Of course, they could sell it on anything they wanted.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 23:17:17 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Umw23BG00iVDIHXH8J@andrew.cmu.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> <maury-2901971111120001@199.166.204.230> In-Reply-To: <maury-2901971111120001@199.166.204.230> Excerpts from netnews.comp.sys.next.advocacy: 29-Jan-97 Re: MacWorld Exclusive: App.. by Maury Markowitz@softarc. >> Those two statements >>>NOT<<< identical. You deliberately removed the >> rest of what I said! You also conveniently ignored my point that >> conventions are created by humans, and not by computers. > > The context of the argument is that it's OK to have the computers define > where certain file types can be stored because that's quite "natural". > I've been saying it's not. Read what I just said. Now ask yourself, "who defined the conventions being used under an operating system like NEXTSTEP?" Was it (a) the humans who wrote NEXTSTEP, or (b) the computers running NEXTSTEP? [ ... ] >> Are you asking me or Usenet in general? > > You. I'm asking YOU what resources the machines YOU run have for > matching document types to applications based on that document's > location. I would like to know how your file location "standards" solve > the problem you posed to me in which the location of the file then defines > which application is used with it. My problem was how two users on a multiuser machine can have different default applications for the same exact file. Under NEXTSTEP, each user has a set of preferences built up and controlled by the WorkSpace which indicates which application should open which type of file. NEXTSTEP solves the problem I described just fine. MacOS doesn't. MacOS allows you to put files anywhere because single-user machines can get away with fewer conventions than multiuser machines have. >> You've been telling us all how filesystem conventions for the structure >> of directories is bad, and how the MacOS lets you put files whereever >> you want to which is good. > > I think it is. I think the limitations imposed on this by the System > Folder is just that, an imposition. Perhaps a needed one, but an > imposition none the less. More examples of this would be worse. We're never going to agree on this topic, clearly. Since Apple is moving to a multiuser operating system, I expect to see Rhapsody have more conventions rather than fewer, and I consider that to be a good thing for a variety of reasons that I've already explained. Deal with it. >> 1: relying on experience or observation alone often without due regard >> for system and theory > > This is of course the definition that is most often applied, as in > empirical vs. quantitative evidence. And what is the difference between those two? > If you wish to redefine that term as well to be (2) or (3), be my guest, > but don't "hammer" me for using the most common definition. I was quoting from Webster's dictionary-- I wasn't "redefining" anything, I was using what most people consider a good reference for the meaning of standard English words. >> For example: If I count the number of users who report a problem with a >> certain aspect of a program, I've just quantified real-world feedback. > ^^^^^^^^^^ > Agreed. What portion exactly did you think I was disagreeing with? Your claim that you can't quantify real world feedback? Can't you even manage to remember what you've said when it was quoted in the article that you've responded to? -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: cliff@shell.ablecom.net (Cliff Tuel) Newsgroups: comp.sys.next.programmer Subject: Re: Compiler version in newest OS? Date: 29 Jan 1997 15:42:58 -0800 Organization: PDH, Inc. Message-ID: <5cona3$fjn@shell.ablecom.net> References: <5cigco$bou@charm.magnus.acs.ohio-state.edu> <32ECD75E.A07@ibp.de> Lars Immisch <lars@ibp.de> said... |3.3's cc is gcc 2.2.2. I _think_ 4.1 still does not have 2.7.2, but this |will hopefully be confirmed by someone who has 4.1. OPENSTEP Enterprise 4.1 / Mach: "In this release, the Mach compiler is based on the GNU C compiler version 2.5.8. The compilers Windows and PDO compilers [sic] shipped with the OPENSTEP Enterprise release are based on the GNU C compiler version 2.7.2." % cc -v Reading specs from /lib/i386/specs NeXT Computer, Inc. version cc-478, gcc version 2.5.8 Also... "The GDB debugger in OpenStep 4.0 for Mach (and later versions) is based on the version 4.14 release from GNU/FSF." -- Cliff Tuel -- NeXTSTEP/OPENSTEP Wrangler -- cliff@pdh.com -- cliff@ablecom.net PDH Inc / 2635 North First Street Suite 224 / San Jose California / 95134-2032
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 05:17:47 GMT Organization: Cygnus Support Message-ID: <5cpats$f4t$1@majipoor.cygnus.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> Cc: davidm@netscape.com In <32EFDC32.3ADC@netscape.com> David Matiskella wrote: > John Rudd wrote: > > > > Ok... just out of curiosity, for those cases where you need to change the way > > objects "add" or "multiply" etc, to reflect their implimentation or > > whatever.. > > what is wrong with an "Add:" method, instead of "+:" or "+"? > > > > It's slightly more verbose, but it's not really more or less readable to say: > > > > foo = [ComplexA add: ComplexB]; > > > > than > > > > foo = ComplexA + ComplexB; > > > If you take that attitude why should the language even have operators? > Why not write c=Add(a,b) for every data type? What makes the built in > ones special? Depending on what you are doing operator overloading is a > godsend. If you are writing programs that depend on custom math types it > makes your code a lot simplier. With just 1 operator its not bad but > imagine if you want to do something like m=m1*m2*m3*m4 where the m's are > a bunch of matrices. That is a hell of a lot easier to read than > m=Matrix_Mult(Matrix_Mult(Matrix_Mult(m1,m2),m3),m4). If you aren't > doing math heavy things like FEM, 3d graphics and the like, you might > not miss them, but if you are you really do miss them whenever you have > to deal with a language that doesn't have them. All IMNHO of course > David Matiskella > I can see the case against using named _prefix_ notation functions, but that's not at all the same as _infix_ method names. [[[[matrixA times: matrixB] times: matrixC] times: matrixD]; is not significantly harder to read than: matrixA * matrixB * matrixC * matrixD; Especially if you need to add parenthises for some reason. It _is_ more wordy, but it's still easy to read. I'm also not entirely sure I'd agree that operator overloading is a godsend.. The times I've had to keep track of all of that in a C++ program (writing an arbitrary precision math lib) it was really little better than syntactic sugar. -- John "kzin" Rudd jrudd@cygnus.com http://www.cygnus.com/~jrudd =========Intel: Putting the backward in backward compatible.============ Smalltalk == Astronaut's tools. Awkward at first, but exceptional design C++ == A hammer. A SLEDGEHAMMER. Not cast metal, a big rock on a stick.
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: How to make "STOP" button? Date: 30 Jan 1997 01:36:31 -0500 Organization: Duke University, Durham, NC, USA Message-ID: <5cpfhf$84f@news.duke.edu> What is the standard (or just a good) method for enabling a user to stop a process in process? I have a method which iterates a dynamical system: - iterate:sender { while (loopConditionMet) { Iterate(dynamicalSystem); } return self: } Can I just stick some method call in the loop that checks to see if I've pressed a "STOP" button on my application? if ( [stopButton isPressed] ) exit; What would be the implementation of [stopButton isPressed] ? Thanks much, Lee Altenberg altenber@acpub.duke.edu
From: J.Penning@t-online.de (Jrg Penning) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Simple questions Date: 25 Jan 1997 22:42:43 GMT Organization: Telekom Online Internet Gateway Message-ID: <5ce293$tqv@news00.btx.dtag.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, I have a few questions about Objective-C: - What is the type 'Class' good for? Why shouldn't I use 'id'? - What will happen on [self free] AT THE END of some method? I'm running NSfIP 3.3 and I'm looking for a garbage collector. Any recommendations? Thanks, Joerg. -- Joerg Penning email j.penning@t-online.de
From: morbius@sure.net (Morbius) Newsgroups: comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Wed, 29 Jan 1997 14:33:09 -0800 Organization: Mind's I Inc. Message-ID: <morbius-2901971433090001@pm824.sure.net> References: <maury-0801971641590001@199.166.204.230> <32E3EA94.142F@exnext.com> <maury-210197105714 <maury-2801971735280001@199.166.204.230> <5cmmkd$q4@csugrad.cs.vt.edu> In article <5cmmkd$q4@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > In article <maury-2801971735280001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > > > In article <32EE7205.CCA9263@screaming.org>, Pohl Longsine > > <pohl@screaming.org> wrote: > > > > That's because it's largely meaningless. It means that NT customers > > > are relatively uninterested in the POSIX API, not that PC customers > > > are relatively uninterested in a UNIX OS. > > > Well fair enough. But since those OS's (Win) form something on the > > order of 70% of the market share of OS's being sold today, that means the > > vast majority of the market doesn't want Unix. > > They don't want the Mac either, apparently. An unfortunate case of the market/public resisting change. There is a distinction, however. Resisting change, regardless of type (Mac), vs. resisting an OS intended for the "control freak" and/or "geek" (Unix). Something about throwing the baby with the water, comes to mind...:) Morbius -- "Nyuck, nyuck, nyuck!..." Curly
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.programmer,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 30 Jan 1997 04:07:08 GMT Organization: Airwindows Message-ID: <jinx6568-2901972309330001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn3bm$22l@duke.squonk.net> <maury-1701971150370001@199.166.204.230> <5bumdc$evr@csugrad.cs.vt.edu> <maury-2001971530280001@199.166.204.230> <5c1358$k5v$1@majipoor.cygnus.com> <maury-2101971203450001@199.166.204.230> <smtIiRO00iV0M5bOIB@andrew.cmu.edu> <maury-2701971215410001@199.166.204.230> <Amvtefa00iV6M288Ja@andrew.cmu.edu> In article <Amvtefa00iV6M288Ja@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > by Maury Markowitz@softarc. > > I see. So if I delete, say, grep, off of my hard drive, Unix stops > > working? > Yes: > % grep grep /etc/rc* > /etc/rc:if ifconfig -a | grep -v "127.0.0.1" | grep -v "0.0.0.0" | grep > -s inet; then > /etc/rc: /usr/bin/egrep 'enable.+YES' ) >/dev/null 2>&1 > /etc/rc: if [ -n "`ifconfig -a | grep en0 `" -o -n "`ifconfig -a | > grep tr0 `" ]; then > /etc/rc.local:pid=`ps cax | egrep nmserver | awk '{print $1;}'` > /etc/rc.net:pid=`ps cax | egrep nmserver | awk '{print $1;}'` > Your system won't have the loopback interface correctly configured, and > the Mach nameserver won't be reinitialized correctly. ...just as if you somehow deleted HMGetMenuResID from the Mac Toolbox (or wherever it hides), MacOS stops working. Actually you can't- if I was up for it I'd option drag my active System file onto the desktop to make a copy, drag that onto ResEdit, and I could cite specific code resources that you could actually delete, that would make MacOS stop working. WDEF 0 would do nicely ;) The difference is that you can't actually treat MacOS toolbox calls or code resources as a user program. Under Unices you actually can, though they are not much more friendly than toolbox calls- but in some ways, for some uses, they are more friendly than toolbox calls, because their limits are sharply defined and they deal with a very very simple data type. One does not expect DisposPixMap to throw up a confirmation dialog, why should rm? It's just a question of burying rm so Grandma never sees it, and if anybody can do this Apple can. I _loved_ the Unix-Hater's Handbook. I found it delightful, hilarious, insightful, useful in its points of warning. Yet I am _still_ warming to the idea of Unix- because it will no longer be in anyone's face. There is clearly a lot that can be done by those crufty little code fragments of a utility library Unix has- they are appalling compared with, say, Aladdin products for file handling, but compare them to Apple event handling and Gworld manipulation and the little Unix utilities begin to look appealingly easy and sensible. Perhaps that's just my bias, but there it is. Grep is a toolbox call. Normal users ought never to know it's there, they get a GUI search box with all the options logically presented and clearly labelled, and _that_ does the 'toolbox call' and keeps track of what oddly named arguments grep requires. They're no less oddly named than wdef masks ;) you give the wdef a single number which is a binary _mask_ to set various switches. Picture using _that_ as a user program ;) Jinx_tigr (aka Chris Johnson)
From: david@pfi.ibk.baum.ethz.ch (David C. EKCHIAN) Newsgroups: comp.sys.next.programmer Subject: Compile ObjC in C++ fail with 4.1 Date: 30 Jan 1997 11:54:48 GMT Organization: Swiss Federal Institute of Technology (ETHZ) Message-ID: <5cq268$6vs@elna.ethz.ch> Hi Folks, With OpenStep 4.0 or NextStep 3.3, one could compile ObjC and C++ code together with the -ObjC++ directive, and link all together. We only had to give the directive in the Build Attributes of the Project Inspector. Fine. With the new 4.1 makefile, it fails. All *.m files automatically get an -ObjC flag (see NONRECURSIVE_MFLAGS in flags.make and the implicitrules.make file). I renamed all my *.m files to *.M as workaround so that they are compiled as Objective-C++ files. Do you have another idea or proposition? Have fun, David. -- o _ /-;c ___ David C. EKCHIAN ______________________________________(@)#\(@)___
From: david@pfi.ibk.baum.ethz.ch (David C. EKCHIAN) Newsgroups: comp.sys.next.programmer Subject: Failure in 4.1 if French language defined. Date: 30 Jan 1997 12:02:05 GMT Organization: Swiss Federal Institute of Technology (ETHZ) Message-ID: <5cq2jt$6vs@elna.ethz.ch> Hi Folks, If you choosed French as primary language, you'll probably encounter that problem soon: - your application won't run normally - you get many warnings on your Console like: > *** /NextLibrary/Frameworks/AppKit.framework/Versions/B/ > Resources/French.lproj/Printing.strings: > *** End of input expected; > Parse error line 97 (position 3048) for units: (); > Next token is 'OK' This is a BUG. In the file "Printing.strings", line 97, there is a " ." too much... Remove it! Enjoy 4.1. David. -- o _ /-;c ___ David C. EKCHIAN ______________________________________(@)#\(@)___
From: david@pfi.ibk.baum.ethz.ch (David C. EKCHIAN) Newsgroups: comp.sys.next.programmer Subject: Dynamic flag in 4.0 and 4.1 Date: 30 Jan 1997 11:46:13 GMT Organization: Swiss Federal Institute of Technology (ETHZ) Message-ID: <5cq1m5$6vs@elna.ethz.ch> Hi all, A question about the dynamic flag of the compiler. The Release notes say: > Notes Specific to Release 4.0 > New Features > Dynamically Linked Shared Libraries > The compiler tools now allow you to build and develop dynamic shared > libraries and support the programs that use these libraries, including > programs that use bundles. > All object files that are part of a dynamic shared library or that are > to be in an executable should be compiled with the -dynamic flag. The > -dynamic flag is now the default. They mean ALL compiled files then, hey? OK, I compiled with that flag on OpenStep 4.0, but now, with 4.1, I got new makefiles and -dynamic is no more the default! What shall I do? Reading the release notes for OpenStep 4.1, one read: > Notes Specific to Release 4.1 > The dynamic linker now has the environment variable > DYLD_FRAMEWORK_PATH to better support the development of > frameworks. See the man page for details. Nice. And what shall I do with that DYLD_FRAMEWORK_PATH? Any help appreciated, have a nice day, See also my thread "Compile ObjC in C++ fail with 4.1", David. -- o _ /-;c ___ David C. EKCHIAN ______________________________________(@)#\(@)___
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: How to make "STOP" button? Date: 30 Jan 1997 02:45:05 GMT Organization: MHPCC Message-ID: <5cp1vh$a0h@kaopala.mhpcc.edu> What is the standard (or just a good) method for enabling a user to stop a process in process? I have a method which iterates a dynamical system: - iterate:sender { while (loopConditionMet) { Iterate(dynamicalSystem); } return self: } Can I just stick some method call in the loop that checks to see if I've pressed a "STOP" button on my application? if ( [stopButton isPressed] ) exit; What would be the implementation of [stopButton isPressed] ? Thanks much, Lee -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 00:46:12 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5cor0k$4o4@usenet.rpi.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> David Matiskella <davidm@netscape.com> wrote: > John Rudd wrote: > > Ok... just out of curiosity, for those cases where you need to > > change the way objects "add" or "multiply" etc, to reflect > > their implimentation or whatever.. what is wrong with an "Add:" > > method, instead of "+:" or "+"? > > > > It's slightly more verbose, but it's not really more or less > > readable to say: > > > > foo = [ComplexA add: ComplexB]; > > > > than > > > > foo = ComplexA + ComplexB; > > If you take that attitude why should the language even have > operators? Why not write c=Add(a,b) for every data type? What > makes the built in ones special? Because the operator is then part of the language, and you can know what it does (by looking at the language specification). You know that if you have a bug, it's very unlikely to be that "+" operator, as long as that "+" operator isn't overloaded. If you overload the operator, then someone looking at your code might think it does something other that what you were thinking of when you wrote it. For most good examples I have seen used to justify operator overloading, my gut reaction is "Why not support that data type in the language?". Not that ObjectiveC supports something like complex numbers, but it would be nice if it did. My own preference is that there was some degree of operator overloading, perhaps even limited to some special operators (eg: you could define what "[+]" means as an operator, but not what "+" itself means). I can see situations where the capability is useful, but I'd also like to see it used sparingly. I hate it when someone starts saying "Oh, gee, let's see what function I could bind to the "+" operator for this class of objects". Due to programmers like that, I would like "overloadable" operators to look different than standard ones. > If you aren't doing math heavy things like FEM, 3d graphics and > the like, you might not miss them, but if you are you really do > miss them whenever you have to deal with a language that doesn't > have them. All IMNHO of course - - David Matiskella The above ramblings are just my own opinions too, of course. And they probably need to be thought out a bit more... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 01:29:30 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5cothq$4o4@usenet.rpi.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5cnt9u$tgi@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: > ga@ed4u.com (G. Gordon Apple, PhD) wrote: > > > There is a substantial schism between people whose profession > > is writing code vs. those who write code to get a job done, > > e.g., mathematicians and engineers. > > I forgot to mention this in the last post, but I find that > statement highly insulting. The implication is that only > mathematicians and engineers write code "to get a job done". > ALL programmers write code to get a job done. Are you implying > that non-engineering applications aren't real work? I'm not insulted. I think I know what he means. In my case, I'm as interested in the process of programming as I am in the result. People in some other fields may write a program to get some task done, but they don't care about programming per se. I understand that they don't care about the same things I care about. That's why I'm a systems programmer, and they are in whatever fields they are in. I see no reason to be insulted by that. Think of programming like a car. Everyone may be using a car to get to some important destination, but only mechanics are interested in how the *car* itself works. That does not make your destination more (or less) important than the destination of a mechanic, it just means you care about different things. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <luomat@nerc.com> Message-ID: <199701300102.UAA01397@nerc.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Timothy J Luoma <luomat@nerc.com> Date: Wed, 29 Jan 97 20:02:46 -0500 Subject: Counting remaining INODES Followup-To: poster,comp.sys.next.programmer Organization: Princeton Theological Seminary How can I tell how many inodes are left on my HD? (midnight commander can tell me I've got: Free nodes 206327 (85%) of 241664 and I want to know how it does that.) Anyone have a code/program/command-I-don't-know that does this? Does it work on other drives (SyQuest SCSI, for example)? Thanks! TjL ps -- please CC me on reply? I've set followups to me and the newsgroup -- Tj Luoma (luomat@peak.org) If you have a web page about NeXTStep|OpenStep, email me the URL!
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 30 Jan 1997 10:27:31 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cqel3$vp5@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2901971127030001@199.166.204.230> <5co4fc$8n4@csugrad.cs.vt.edu> <maury-2901971528340001@199.166.204.230> In article <maury-2901971528340001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > but on the other hand portions of their OS is much richer than > anything offered in "standard" Unixen that I am aware of. Their > file/document system is a certainly one good example, volumes are simply > large databases storing objects. I think this is something I'd like to > see in the future NeXT OS as well. Hey, at least they're trying. I agree about the database filesystem. It's wonderful. A couple of years ago, NeXT was planning on adding something like a database and/or object file system to Mecca (the release of NEXTSTEP that eventually became OPENSTEP for Mach 4.0) -- I can't remember the details -- but it wasn't a high enough priority for NeXT's current market and goals. Maybe now it will be, especially with NT's Object File System coming out and all. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 29 Jan 1997 16:53:04 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5cnv9g$g3e@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c1bm1$nhr@duke.squonk.net> <5c46rq$84c@geraldo.cc.utexas.edu> <5cenf0$jen@crl.crl.com> Donald R. McGregor (mcgredo@crl.com) wrote: : In article <5c46rq$84c@geraldo.cc.utexas.edu>, : William Raphael Hix <raph@porter.as.utexas.edu> wrote: : >Your use of tar seems predicated on a Rhapsody software distribution : >system like most of Unix. Are you expecting lots of "here's the source : >code now compile it yourself" apps ported from Unix to Rhapsody? : >It's fundamental differences in expectations between the Mac and NeXT : >communities which fuel this thread. : : Yes, there should be a lot of compile it yourself apps for Rhapsody. : Most users won't see it, though. Well, compile-your-self apps require a compiler. Do you expect this to be part of Rhapsody or do you expect to buy it from Metrowerks? I don't expect cc to be standard equipment on Rhapsody. Is cc a standard part of OpenStep/Mach user or do you need the Developer or Academic packages? : : It wouldn't surprise me at all to see Apache, new versions of Bind, : multicast routers, and other gizmos running on Rhapsody. It's a : useful personal machine with plenty of shrink-wrapped apps, and : it's a unix machine that does all sorts of unix things. The two : markets are distinct, though, so most of group A won't know : that group B exists. I'd be truly happy with such an OS. I'm just not expecting Rhapsody, in its base configuration, to offer all of this. Since, as you say group A won't care about these Unix features, the much smaller group B might have to pay extra. Current Mac users who are member of group B pay hundreds of dollars for software like MachTen, MacNFS, or MacX. Even if Apple takes this split approach, Mac-Unix users and NeXT users would be better off than they are now. They'd get access to common productivity apps plus all the Unix features they want for a cost probably much less than the current price of OpenStep/Mach. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: flege@iese.fhg.de (Oliver Flege) Newsgroups: comp.sys.next.programmer Subject: WebObjects & gifs from a db Date: 30 Jan 1997 15:40:07 GMT Organization: Fraunhofer Gesellschaft: Institut iese Message-ID: <5cqfcn$k32@iese.iese.fhg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi, can anybody think of a way store picture-data in an RDBMS such as Oracle and to make them appear on Web-pages generated by WebObjects WITHOUT creating temporary files that contain the image data (i.e. is there a way to transmit those images by bypassing the usual IMG-Tags which only work with the URL of a file to be loaded.) If you can think of how to do that - please let me know. -- ----------------------------------------------------------------- Oliver Flege Fraunhofer Institute for Experimental Software Engineering (IESE) Sauerwiesen 6 tel (+49) 6301 707 220 67661 Kaiserslautern fax (+49) 6301 707 200 Germany e-mail flege@iese.fhg.de ----------------------------------------------------------------- 'A fool with a tool is still a fool.'
From: jwdb@fygir.nl (Jan-Willem de Bruijn) Newsgroups: comp.sys.next.programmer Subject: Loads of bugs in Developer 4.0/Mach Date: 30 Jan 1997 16:11:00 GMT Organization: XS4ALL, networking for the masses Sender: @news.xs4all.nl Message-ID: <5cqh6k$bt5$1@news1.xs4all.nl> Please tell me that we're not the only ones experiencing problems with OPENSTEP Developer 4.0 for Mach/Intel. I have collected a long list of bugs and would like to know whether other developers have seen the same ones. Some are minor, but others are really irritating, almost to the point of making development impossible. Thanks in advance for your sympathy :-) ;-) :-( Also if anyone knows if these bugs have been addressed in 4.1, please tell me about it. ============================================================================ Gripes about ProjectBuilder Release 4.0 (v268.5) ------------------------------------------------ *) it sometimes turnes RTF formatted source code into ASCII source code *) it sometimes refuses to set breakpoints in source code with the mouse, although it is possible by typing, but when the breakpoint has been reached it complains that the source code file does not exist *) the editor does not wrap properly *) sometimes when switching from the launch window to a source code window portions of the source code disappear, leaving white space which is only filled in when scrolling out of sight and back again *) the editor places opened files slightly too high (off the screen) *) the editor sometimes scrolls when you want to set a breakpoint causing it to appear in the wrong place *) changing the font of a selection in RTF formatted source code sometimes applies it to the complete file *) When debugging it (first) tries to link with frameworks using the wrong suffix: ',_debug' instead of '_debug'. (It notices this itself.) *) When making the main project builder window the key window, the selected file often changes from the last one accessed (as displayed in the panel containing the list of loaded files). This is very annoying if one wants to look up an accompanying header or implementation file. *) searching in the current file does not work *) the connection to the projectServer often breaks up (perhaps it crashes) *) often the Find panel fails to select the found text *) sometimes all keyboard shortcuts in the Services menu disappear *) it sometimes crashes Gripes about OPENSTEP 4.0 / Mach / Intel ---------------------------------------- *) NSBundle's classNamed method seems out of order, returning nil *) NSImage's imageNamed ditto. *) several class methods of NSApplication used in debugging are not declared in the header file *) even in List mode an NSMatrix always selects at least one cell. Even programmatically selecting the (-1, -1) combination selects the first enabled cell. * when launched InterfaceBuilder says 'objc: class SoundView not linked into application' ========================================================================= -- Jan-Willem de Bruijn - F Y G I R logistic information systems
From: Robert F Tobler <rft@cg.tuwien.ac.at> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 16:26:53 GMT Organization: Vienna University of Technology, Austria Message-ID: <5cqi4d$ilq@news.tuwien.ac.at> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> <5cpats$f4t$1@majipoor.cygnus.com> jrudd@cygnus.com (John Rudd) wrote: > [[[[matrixA times: matrixB] times: matrixC] times: matrixD]; you could even use tagged parameters to get something like: [matrixA times: matrixB times: matrixC times: matrixD] But for objective-c, I'd still like to have the possibility to use the following special method names: [matrixA +: matrixB] [matrixA -: matrixB] aso. This would be a nice compromise, in that it enables a rather short notation for custom objects, which is still different from the built-in operators which work on the primitive C-types. ------------------------------------------------------------------------ Robert F. Tobler - tel:+43(1)58801-4585,fax:5874932 Institute of Computer Graphics - mailto:rft@cg.tuwien.ac.at Vienna University of Technology - http://www.cg.tuwien.ac.at/~rft/
From: ag082@freenet.hamilton.on.ca (Andrew Orr) Newsgroups: comp.sys.next.programmer Subject: Need money for Programming costs? Date: 30 Jan 1997 14:56:08 GMT Organization: Hamilton-Wentworth FreeNet, Ontario, Canada. Message-ID: <5cqcq8$t11@main.freenet.hamilton.on.ca> To Find out more about this sensational money making opportunity Email me at <andyorr@freenet.hamilton.on.ca> with "30 days" as your subject for all the FREE details. DO IT NOW and Make Money! Andrew A. Orr, <andyorr@freenet.hamilton.on.ca> -- Andrew A. Orr, U.E.L., Dipl. President of the Andrew Club http://www.freenet.hamilton.on.ca/~ag082/Profile.html "Life is like a bowl of Cherries, fifty percent pits!" --- AAO
From: Michael Hudson <sorry.no.email@nowhere.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Thu, 30 Jan 1997 17:15:39 +0000 Organization: University of Leicester, UK Message-ID: <32F0D73B.F18@nowhere.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit David Matiskella wrote: > If you take that attitude why should the language even have operators? > Why not write c=Add(a,b) for every data type? What makes the built in > ones special? Depending on what you are doing operator overloading is > a godsend. If you are writing programs that depend on custom math > types it makes your code a lot simplier. With just 1 operator its not > bad but imagine if you want to do something like m=m1*m2*m3*m4 where > the m's are a bunch of matrices. That is a hell of a lot easier to > read than m=Matrix_Mult(Matrix_Mult(Matrix_Mult(m1,m2),m3),m4). But you shouldn't do that anyway: You'll create 3 temporaries, or more if Matrix_Mult takes it parameters by value (Read your Meyer's). What you should do is m.Assign(m1); m.Multiply_Equals(m2); m.Multiply_Equals(m3); m.Multiply_Equals(m4); Or if Assign & Multiply_Equals return a reference to the Matrix you can chain the above into: m.Assign(m1).Multiply_Equals(m2).Multiply_Equals(m3) .Multiply_Equals(m4); Which is a little easier on the eye. NB: You're example implies operator overloading in the "m=" at the beginning. > If you aren't > doing math heavy things like FEM, 3d graphics and the like, you might > not miss them, but if you are you really do miss them whenever you > have to deal with a language that doesn't have them. All IMNHO of > course > David Matiskella Agreed. It does need watching however. If the operator you're overloading makes the program the slightest bit less intuitive, don't do it. If you have complex numbers, vectors, large integers then it makes sense. Overloading *= to scale a bitmap does not. Having member functions return references enables the chaining method shown above, which can help to compact the code. -- Regards, Michael Hudson Please don't email this address - it's not mine.
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 11:36:39 -0500 Organization: Atria Software Message-ID: <maury-3001971136390001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> <5coesu$cm8@news1.ucsd.edu> In article <5coesu$cm8@news1.ucsd.edu>, kennel@lyapunov.ucsd.edu (Matt Kennel) wrote: > Of course, they could sell it on anything they wanted. Apple can't seel it's own products to these people, writing new code wouldn't change that. Hiring people who know how to sell into this market would. Maury
From: alanf@izzy.net Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Adobe Bravo Date: 30 Jan 1997 16:58:24 GMT Organization: "Comshare, Inc." Message-ID: <5cqjvg$s1g$1@inet-prime.comshare.com> References: <8D0E511.09B600067E.uuout@moondog.com> <Pine.OSF.3.91.970128132843.24689B-100000@sable.ox.ac.uk> <E4sCBp.sx@shinto.nbg.sub.org> Cc: tomi@shinto.nbg.sub.org In <E4sCBp.sx@shinto.nbg.sub.org> Thomas Engel wrote: <snip> > To some degree it seems funny that the Java/Bravo systems are about to > rebuild OpenStep. Add in the OpenDoc/Java thing and Rhapsody looks more then > interesting. > Yup. Hilarious. Back in December, I attended a Sun presentation where they showed off a (primitive)JavaStation. The presenter indicated at that point the deal between Adobe and Sun regarding Bravo had gone South... so what's the 2D API with Java now, anyway? I think the low-end nature of the JavaOS and it's native UI will leave plenty of room for Apple. As I remember, the phrase "low-end" was repeated like a mantra at the Java presentation. Regards, Alan Frabutt (alanf@izzy.net) disclaimer: my opinions are not necessarily my employers...
From: Richard Goldstein <rickg@eng.sun.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: Adobe Bravo Date: 30 Jan 1997 09:14:00 -0800 Organization: SunSoft, Inc Sender: rickg@upuaut Message-ID: <ku7hgjz13xj.fsf@upuaut.eng.sun.com> References: <8D0E511.09B600067E.uuout@moondog.com> <Pine.OSF.3.91.970128132843.24689B-100000@sable.ox.ac.uk> <E4sCBp.sx@shinto.nbg.sub.org> tomi@shinto.nbg.sub.org (Thomas Engel) writes: > > I am still not really sure what Bravo is all about. It seems like a stripped > down DPS system without all the interpreter stuff (PSwarps etc.). > Seems like NeXTs/Apples DPS is perfectly suited for Bravo since it might just > be an aditional layer on top of that > You can already get such a layer for DPS, the Modello class library for DPS on ftp.x.org in /contrib/devel_tools/DPS/. Currently it just uses DPS/X, though the few X dependencies are designed to be replaced for non-X DPS. rick -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Richard M. Goldstein richard.goldstein@Eng.Sun.COM 64-bit Linkers, Libs & Executables SunSoft, Inc. "Without time we pick up all the streams, and find the leaves that drift out inbetween..." -Kirkwood
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Counting remaining INODES Date: Thu, 30 Jan 1997 12:06:08 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <4mwBI0i00iVGQ4m2ZG@andrew.cmu.edu> References: <199701300102.UAA01397@nerc.com> In-Reply-To: <199701300102.UAA01397@nerc.com> Excerpts from netnews.comp.sys.next.programmer: 29-Jan-97 Counting remaining INODES by Timothy J Luoma@nerc.com > How can I tell how many inodes are left on my HD? [ ... ] > Anyone have a code/program/command-I-don't-know that does this? Sure. 'df -i'. > Does it work on other drives (SyQuest SCSI, for example)? Yes-- assuming they have a BSD filesystem on them, of course. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 13:02:48 -0600 Organization: mementech, inc. Message-ID: <32F0F058.5AB00B2C@screaming.org> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> <maury-2901971111120001@199.166.204.230> <jinx6568-2901972248010001@news.sover.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Re: filesystem conventions on Mac and NeXT. For what it's worth, I'd like to offer a confession. I break the conventions on my NeXTstep system all the time. (Of course, I have to log on as god in order to do this...) Whenever I have a software package that requires a license key, I keep a copy of the key in the same folder that I keep the application. (One such document per directory full of applications.) So text files aren't put in /LocalApps by convention, and I break the convention a little so that I always know where to find the license keys. NeXTstep doesn't care that I do this, as long as I do it intentionally. Fortunately, if I'm logged on as a mortal, it won't allow me to accidentally drop any of my stuff into the application folders that all of my family members share. It also doesn't allow the toddler to drag my files out of my folders, or to damage the system at all, short of yanking the cord out of the wall. Note that anybody who wants their NeXTstep system to simulate the free-form nature of the Macintosh can just always be logged on as root. [...but don't come cryin' to me... ;-] -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: Thu, 30 Jan 1997 18:06:49 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E4u2BE.CnM@cam-ani.co.uk> References: <5cqh6k$bt5$1@news1.xs4all.nl> In article <5cqh6k$bt5$1@news1.xs4all.nl> jwdb@fygir.nl (Jan-Willem de Bruijn) writes: > > Please tell me that we're not the only ones experiencing problems with > OPENSTEP Developer 4.0 for Mach/Intel. > > I have collected a long list of bugs and would like to know whether other > developers have seen the same ones. Some are minor, but others are really > irritating, almost to the point of making development impossible. > > Thanks in advance for your sympathy :-) ;-) :-( Yes... It's full of bugs. C++ crashes if certain functions are empty xxx::xxx() {}; will not produce a valid object. This one alone took me weeks to track down, as it crashes much later. ObjC++ isn't even supported on NT. I forget how many other bugs I reported (the above being the most memorable), but it was in double figures. I do remember that it crashed halfway through the install when I got bored and moved the mouse! Basically 4.0 is even worse than 3.1 (and that had a good excuse). Both 2.0 and 3.0 were sufficiently stable that I ran them for years without bothering to upgrade (never even saw 2.1, I'm still on 3.2+foundation at home). 4.0 is a disaster. > Also if anyone knows if these bugs have been addressed in 4.1, please tell me > about it. following the bad experience of 4.0 I haven't been able to convince anyone to spring another $X000 on 4.1 (or 4.2). $an
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 11:47:18 -0500 Organization: Atria Software Message-ID: <maury-3001971147180001@199.166.204.230> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> <maury-2901971111120001@199.166.204.230> <Umw23BG00iVDIHXH8J@andrew.cmu.edu> In article <Umw23BG00iVDIHXH8J@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Now ask yourself, "who defined the conventions being used under an > operating system like NEXTSTEP?" Was it (a) the humans who wrote > NEXTSTEP, or (b) the computers running NEXTSTEP? Yes, and every source of power in the world indirectly comes from stars as well. This is a great way to hide the entire discussion, but also hides the entire complexity of what's going on. The OS that places more limitations on the user in terms of document and file placement is automatically a less flexible OS for that user by definition. It doesn't matter if that OS was written by programmers, Martians, or other computers. > NEXTSTEP solves the problem I described just fine. MacOS doesn't. > MacOS allows you to put files anywhere because single-user machines can > get away with fewer conventions than multiuser machines have. Thius is true, but was to have been solved under Copeland in a similar fashion - the folder manager would return different handles to the Prefs folder depending who was logged in. > Since Apple is moving to a multiuser operating system, I expect to see > Rhapsody have more conventions rather than fewer, and I consider that to > be a good thing for a variety of reasons that I've already explained. The "variety of reasons" you've outlined could all be solved in other, more user friendly, ways. Login prefs for MEO would have the same effect and yet not impose file locations on the user. > Deal with it. "Deal with it"? > And what is the difference between those two? quantitative : "here are the numbers that show..." empirical: "everyone knows that..." > I was quoting from Webster's dictionary-- I wasn't "redefining" > anything, I was using what most people consider a good reference for the > meaning of standard English words. Yes, but I'm a physicist before computer geek, and these are the definitions I've heard and used since grade school. > Your claim that you can't quantify real world feedback? ^^^^^^^^ Yes, in a quantitative measurement. Maury
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.advocacy,comp.sys.mac.advocacy Date: Thu, 30 Jan 1997 12:14:19 -0600 Organization: mementech, inc. Message-ID: <32F0E4FB.7EC5F566@screaming.org> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> <maury-2801971121360001@199.166.204.230> <8mvbN9600iV1I6469b@andrew.cmu.edu> <maury-2801972005080001@199.166.204.230> <5coesu$cm8@news1.ucsd.edu> <maury-3001971136390001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > kennel@lyapunov.ucsd.edu (Matt Kennel) wrote: > > > Of course, they could sell it on anything they wanted. > > Apple can't seel it's own products to these people, writing > new code wouldn't change that. Hiring people who know how to > sell into this market would. I think I see the misunderstanding here. You were talking about the whether or not Apple could achieve a healthy ROI on a clean-room OpenStep implementation. I think everybody else in this thread thought that you were questioning whether or not Apple could have legally done so, according to OpenStep's license, rather than purchasing NeXT. Of course, nothing was preventing Apple from adopting OpenStep as an API if they didn't want to pay NeXT for the port or buy the company outright. They could have just redirected their programmers to the task, passed compliancy tests, and slapped whatever price tag on the product they wanted to, without so much as a single phone call to NeXT -- and it would have been perfectly legal to do so. You are correct, though, that there are other issues involved in making such a strategy succeed, sales being one of them. [followups redirected] -- pohl@screaming.org |"Reality is that which when you stop believing http://screaming.org/ | in it doesn't go away." -- Philip K. Dick ----------------------+---------------------------------------------- OpenStep Inferno Java | Making the world safe for platform diversity.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 16:37:05 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cr4a1$t2@csugrad.cs.vt.edu> References: <5c9h5n$rju@csugrad.cs.vt.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5cnt9u$tgi@csugrad.cs.vt.edu> <ga-3001971300120001@cust9.max55.los-angeles.ca.ms.uu.net> In article <ga-3001971300120001@cust9.max55.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) wrote: > No such slight was intended. Apologies if it came accross that way. I > was simply trying to distingush between those whose primary profession is > writing code for shrink-wrap software vs those whose primary profession is > other than writing code but accasionally have to do it to accomplish > something in their (non-programming) field. Maybe I should have said > "those who write code to get a (non-programming) job done. Complex > numbers are extremely common in engineering/physice, etc. but not so > common in most commercial software packages. Is that better, or am I just > getting in deeper here? No, I see the distinction you were trying to make. That's why there are special-purpose programming languages. Dropping operator overloading is a miserable choice for an engineering language, since you don't typically run into the software-maintenance and other disadvantages you get in big shrink-wrap products. For your purposes, dropping operator overloading is a big step backwards.. on the other hand, I think that _having_ operator overloading can be a big step backwards for OOP programming in general. Maybe C++ will be increasingly relegated to such engineering applications as Fortran is now, as the software engineering movement shifts toward better languages. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: clay@herky.cs.uiowa.edu (Matthew Clay) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.next.programmer Subject: Re: Bad mouthing templates Date: 30 Jan 1997 19:04:31 GMT Organization: The University of Iowa Message-ID: <5cqrbv$mvo@flood.weeg.uiowa.edu> References: <32EF3C1A.5648@ibp.de> From article <32EF3C1A.5648@ibp.de>, by Lars Immisch <lars@ibp.de>: > Matthew Clay wrote: >> ... a fault of Smalltalk is it's Number hierarchy. From a practical >> standpoint, numbers just don't make good objects. First, because we've >> been subjected to algebra from grade 8 and on, just don't think of + as >> being much like message that you send to a integer object. It's not that >> it is an impossible view, just not much like our everyday experience. Second, >> it misses out the fact that we often add integers to integers, and often >> know this at compile-time. Again, this doesn't mean Smalltalk can't add, >> just that it misses some fundamental optimizations (realities). Objective-C >> strives for practicality here, leaving purity to Smalltalk. > > Which Smalltalks Number hierarchy are you talking about? Parcplace or > Smalltak V? Actually I was speaking of the older coerce: generality: framework they used to use in ParcPlace. From my recollection, Smalltalk V did not support a similar Number hierarchy and instead used the base capabilities of the underlying hardware. "Fault" above was probably too strong of a word -- "less than desirable in the common case" would be more apt. I don't dislike the coerce: generality: framework, it's a very nice example of negotiation between two objects. It does however leave a lot to be desired on the performance end of things. > IMO Parcplace's Number hierarchy is nicely optimized by it's double > dispatching strategy. (This implies that ArithmeticValue subclasses have > to be abelian, which is not as general as it might be, but heck, thats > what optimization is about). So I do not agree that it misses > fundamental optimizations. Double-dispatching is indeed a nice optimization, but of course, you still have the overhead of method lookup, plus the space overhead for tags, etc. Perhaps an aggressive optimizer could discover many of the common cases, like integer + integer. I am not familiar enough with current Smalltalk implementations to comment. > I have often thought that, in contrary to your opinion, the Number > hierarchy (of Parcplace's) is one of Smalltalks better features. Where > else can you multiply 4 Gig with 2 and still get the correct result? Or > express 1/3 correctly? Of course this is easy enough in C++ to assign as a 1st or 2nd homework in my C++ course (for intermediate students with no C++ experience) when discussing operator overloading :) Supporting this kind of flexibility, without burdening everyone else who simply want to add 1 and 2, is a key feature of C++ A common trend, especially in functional languages, seems to be supporting greater varieties of number systems in programming languages. Perhaps Fortran has lost its appeal or Mathematica is too sophisticated or slow? -mc
From: ga@ed4u.com (G. Gordon Apple, PhD) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Thu, 30 Jan 1997 13:00:12 -0700 Organization: Advanced Communications Engineering, Inc. Message-ID: <ga-3001971300120001@cust9.max55.los-angeles.ca.ms.uu.net> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5cnt9u$tgi@csugrad.cs.vt.edu> In article <5cnt9u$tgi@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > In article <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net>, ga@ed4u.com (G. Gordon Apple, PhD) wrote: > > > There is a substantial schism between people > > whose profession is writing code vs. those who write code to get a job > > done, e.g., mathematicians and engineers. > > I forgot to mention this in the last post, but I find that statement > highly insulting. The implication is that only mathematicians and > engineers write code "to get a job done". ALL programmers write code to > get a job done. Are you implying that non-engineering applications > aren't real work? Not everyone's problem domain is limited to > engineering code. No such slight was intended. Apologies if it came accross that way. I was simply trying to distingush between those whose primary profession is writing code for shrink-wrap software vs those whose primary profession is other than writing code but accasionally have to do it to accomplish something in their (non-programming) field. Maybe I should have said "those who write code to get a (non-programming) job done. Complex numbers are extremely common in engineering/physice, etc. but not so common in most commercial software packages. Is that better, or am I just getting in deeper here? -- G. Gordon Apple, PhD The Ed4U Project Advanced Communications Engineering, Inc. Redondo Beach, CA ga@ed4u.com www.ed4u.com
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 14:30:07 -0500 Organization: Atria Software Message-ID: <maury-3001971430080001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2901971127030001@199.166.204.230> <5co4fc$8n4@csugrad.cs.vt.edu> <maury-2901971528340001@199.166.204.230> <5cqel3$vp5@csugrad.cs.vt.edu> In article <5cqel3$vp5@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > I agree about the database filesystem. It's wonderful. A couple of > years ago, NeXT was planning on adding something like a database and/or > object file system to Mecca (the release of NEXTSTEP that eventually > became OPENSTEP for Mach 4.0) -- I can't remember the details -- but it > wasn't a high enough priority for NeXT's current market and goals. This is the one thing I seem to see by looking at what has and has not been done in the NeXT OS'en - ie, the portions of the code that are "new" tend to be lumped around the areas they were interested in at that time. > Maybe now it will be, especially with NT's Object File System coming > out and all. Is it coming out? I thought it was on hold again? Maury
From: julie@ok.com Organization: The.Copy.Cat Shop. Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5cr4m1$5f@mtinsc04.worldnet.att.net> Message-ID: <cancel.5cr4m1$5f@mtinsc04.worldnet.att.net> Control: cancel <5cr4m1$5f@mtinsc04.worldnet.att.net> References: <5cr4m1$5f@mtinsc04.worldnet.att.net> Date: Fri, 31 Jan 1997 00:44:38 +1 EMP/ECP spam cancelled by hweede@berlin.snafu.de. This is an ongoing spam whose Breidbart index already is above 20. See my report "TheCopyCatShop" or "summary of auto-cancels" in news.admin.net-abuse.bulletins. Subject was: Complete Canon Computer System at Closout Price.
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Suddenly DPS "Error: rangecheck;" after compile Date: 30 Jan 1997 09:14:27 GMT Organization: MHPCC Message-ID: <5cpopj$om2@kaopala.mhpcc.edu> I've had this happen to me numerous times while developing applications using Interface Builder and Project Builder under NEXTSTEP 3.3/Intel: I recompile and launch the app, and I suddenly get DPS errors, and the App icon on the bottom of the screen stays "white". Jan 29 22:52:09 localhost BuggyApp[11919]: DPS client library error: PostScript program error, DPSContext f47a0 Jan 29 22:52:09 localhost BuggyApp [11919]: %%[ Error: rangecheck; OffendingCommand: ufill ]%% Jan 29 22:52:09 localhost BuggyApp [11919]: DPS client library error: Invalid tag in returned object, DPSContext f47a0, data 1049532 Jan 29 22:52:09 localhost BuggyApp [11919]: DPS client library error: Invalid tag in returned object, DPSContext f47a0, data 1036052 Now, sometimes, this disappears as mysteriously as it appeared. But right now, it ain't so I'm posting this. I also had a situation where the app had been giving this error, but stopped (on a 32 bit color NS/Intel system) but when I compiled it for NeXT hardware, it gave a DPS error (with the white icon) on a monochrome NeXTstation. Any tips will be greatly appreciated. -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Re: Suddenly DPS "error ... Date: 30 Jan 1997 09:37:59 GMT Organization: MHPCC Message-ID: <5cpq5n$rjt@kaopala.mhpcc.edu> Ah, I think I found the problem. I had resized a group border around a display View where it just nicked off the top of the View. When I enlarged the border a bit, the DPS error disappeared. Sorry to take up the bandwidth. Perhaps this tip is useful info for others. -- ======================================================================= Lee Altenberg, Ph.D. Research Affiliate, University of Hawai`i at Manoa Office: Maui High Performance Computing Center 550 Lipoa Parkway, Suite 100 Kihei, Maui HI 96753 Phone: (808) 879-5077 x 296 (work), (808) 879-5018 (fax) E-mail: altenber@mhpcc.edu <MIME and NeXT Mail o.k.> Web: http://pueo.mhpcc.edu/~altenber/ =======================================================================
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.lang.objective-c Subject: "static inline" methods would be nice ... Date: 30 Jan 97 14:22:25 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Jan30142225@howard.one.net> Something I'd like to see in Objective-C would be static inline methods. Say you have something like the Storage object, and you have a method like: @implementation Storage . -(void *)elementAt:(unsigned)index; { if( index<numElements) { return dataPtr+index*elementSize; } return NULL; } . @end This is obviously going to take much more time to dispatch than it will take to execute. If you're calling that method a couple million times, the dispatch overhead starts to add up. In the past, I've tended to build a custom subclass to handle the situation by storing the data internally and operating on it directly. [Admittedly, I'll lever off of something like Storage by using Storage to store the actual data, and then retaining an internal pointer to dataPtr which I can then iterate over.] While that soluation does somewhat promote encapsulation (you've moved the processing code closer to the data), it doesn't promote reuse. If you could instead say something like: @interface Storage : Object {...} . -(void *)elementAt:(unsigned)index; { if( index<numElements) { return dataPtr+index*elementSize; } return NULL; } . @end (note we're in the interface file, now) the compiler could (presumably) be smart enough to take something like: -(void)workWith:(Storage *)aStorage { unsigned ii, cc=[aStorage count]; for( ii=0; ii<cc; ii++) { doSomethingWith( [aStorage elementAt:ii]; } } and inline the -elementAt: reference, lift common subexpressions, and make it look like this more optimal code: -(void)workWith:(Storage *)aStorage { void *dataPtr; unsigned ii, cc=aStorage->numElements, ss=aStorage->elementSize; dataPtr=aStorage->dataPtr; for( ii=0; ii<cc; ii++) { doSomethingWith( dataPtr); dataPtr+=ss; } } Note that you can drop the numElements comparision, because you know ii can't be larger. You can step dataPtr directly rather than multiplying all of the time. Certain values for elementSize might also allow you to increment that easily. The one thing the above doesn't do is the check for nil implied by [aStorage elementAt:ii]. That check could also potentially be lifted from the loop. Excepting doSomethingWith(), the overhead for this method would be substantially lower than if it did the dispatch every time. Obviously, there are certain problems. For instance, if you implement a version of -elementAt: in a subclass of Storage, it's not going to get called in the above. So there would have to be warnings for that type of thing (perhaps the compiler could even toss in an optional exception for the case where aStorage re-implements -elementAt:). On the other hand, I'm not sure how much of a problem that would be. Objective-C tends to promote use of composition rather than subclassing in many cases, moreso than C++. Given a Storage class that inlines many methods, it's pretty likely that you'd rather use the existing Storage class without subclassing it. Same with List, NSArray, etc, etc. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Zen of Dummies in a Nutshell>
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 30 Jan 1997 11:43:47 -0800 Organization: Cygnus Solutions Message-ID: <qdd8unx824.fsf@blues.cygnus.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> <32F0D73B.F18@nowhere.com> [normally I'd send this by e-mail, but Michael seems downright determined not to get any.] Michael Hudson <sorry.no.email@nowhere.com> writes: > David Matiskella wrote: > > [...] That is a hell of a lot easier to read than > > m=Matrix_Mult(Matrix_Mult(Matrix_Mult(m1,m2),m3),m4). > > [...] > NB: You're example implies operator overloading in the "m=" at the > beginning. Um, why on earth do you think it implies that? If Matrix is typedef'd as a pointer to a multi-dimensional array, and Matrix_Mult returns that type, you can handle the assignment without operator overloading. I know we silly C programmers did something like the above before C++ reared its head out of the muck... -- Stephen L. Peters speters@cygnus.com PGP fingerprint: BFA4 D0CF 8925 08AE 0CA5 CCDD 343D 6AC6 "What, do you think soup is a biped?" -- Crow, MST3K
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 30 Jan 1997 16:31:13 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cr3v1$4f@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-2901971528340001@199.166.204.230> <5cqel3$vp5@csugrad.cs.vt.edu> <maury-3001971430080001@199.166.204.230> In article <maury-3001971430080001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5cqel3$vp5@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > I agree about the database filesystem. It's wonderful. A couple of > > years ago, NeXT was planning on adding something like a database and/or > > object file system to Mecca (the release of NEXTSTEP that eventually > > became OPENSTEP for Mach 4.0) -- I can't remember the details -- but it > > wasn't a high enough priority for NeXT's current market and goals. > This is the one thing I seem to see by looking at what has and has not > been done in the NeXT OS'en - ie, the portions of the code that are "new" > tend to be lumped around the areas they were interested in at that time. Well, obviously. That's how it is with any OS. > > Maybe now it will be, especially with NT's Object File System coming > > out and all. > Is it coming out? I thought it was on hold again? I dunno. It may be just more Microsoft vaporware to paralyze the market. Last I heard it was due out in 1998. Anyone have better info? -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Thu, 30 Jan 1997 19:30:36 -0500 Organization: Atria Software Message-ID: <maury-3001971930360001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-2901971528340001@199.166.204.230> <5cqel3$vp5@csugrad.cs.vt.edu> <maury-3001971430080001@199.166.204.230> <5cr3v1$4f@csugrad.cs.vt.edu> In article <5cr3v1$4f@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Well, obviously. That's how it is with any OS. Sure, but in this particular case that seems to result in the OS being pulled in many seemingly random directions. When they started they had the "chore" of building the best (and first) commercial OOPS based OS. They got started on that in convincing fashion, but since then we have differing directions following market trends. That too is par for the course. However one must contrast this to Be, where it's being created ex-nihlo. This is not a comment on NeXT as much as it is a statement of realities of the market. > I dunno. It may be just more Microsoft vaporware to paralyze the > market. Last I heard it was due out in 1998. Anyone have better > info? Well I heard that it was to be a part of the overall OOPS effort. However recent comments from MS seem to imply (rather directly actually) that the kernel of all future OS's will be the NT kernel. What they didn't say, but seem to imply, is that that's the _current_ NT kernel. And I don't have the reference handy any more (I'm thinking BackOffice though) as I read this when I was in Ireland, but I got the impression that the OOPS disk system was on indefinite hold too. Not the driver side of things (no info one way or the other there) but the "your disk is just a big object store" format seems to have disappeared completely. Maury
From: sanjeev@ee.umr.edu (Sanjeev Agarwal) Newsgroups: comp.sys.next.programmer Subject: Help... [CD ROM on next]... Date: 31 Jan 1997 01:19:21 GMT Organization: UMR Missouri's Technological University Message-ID: <5crhap$a58$3@news.cc.umr.edu> I had installed a CD ROM driver (6x) on Pentium 133 running NS 3.3. Of late I cannot seem to access the CD ROM driver (for music CDs or otherwise). I was wondering what could have gone wrong. Could it have been some bug in CD Player that comes with the system. What do I need to do to correct this. Thank you .. Sanjeev
From: sanjeev@ee.umr.edu (Sanjeev Agarwal) Newsgroups: comp.sys.next.programmer Subject: Help.. [Network Printer].. Date: 31 Jan 1997 01:20:05 GMT Organization: UMR Missouri's Technological University Message-ID: <5crhc5$a58$4@news.cc.umr.edu> HI, We have a pentium 133 running NextStep 3.3. I was trying to connect a Network printer (postScript printer) to this machine. What do I need to do for this to work. Thank you very much .. Sanjeev
From: Andrew Orr <ag082@freenet.hamilton.on.ca> Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5cqcq8$t11@main.freenet.hamilton.on.ca> Control: cancel <5cqcq8$t11@main.freenet.hamilton.on.ca> Date: 30 Jan 1997 18:10:32 GMT Organization: Hamilton-Wentworth FreeNet Message-ID: <cancel.5cqcq8$t11@main.freenet.hamilton.on.ca> ancelling MMF. Article cancelled from within tin [v1.3 unoff BETA release 970104] Path: hwfn!james!ag082 From: ag082@freenet.hamilton.on.ca (Andrew Orr) Newsgroups: comp.sys.next.programmer Subject: Need money for Programming costs? Date: 30 Jan 1997 14:56:08 GMT Organization: Hamilton-Wentworth FreeNet, Ontario, Canada. Lines: 16 Message-ID: <5cqcq8$t11@main.freenet.hamilton.on.ca> NNTP-Posting-Host: james.freenet.hamilton.on.ca X-Newsreader: TIN [version 1.2 PL2-HWFN] To Find out more about this sensational money making opportunity Email me at <andyorr@freenet.hamilton.on.ca> with "30 days" as your subject for all the FREE details. DO IT NOW and Make Money! Andrew A. Orr, <andyorr@freenet.hamilton.on.ca> -- Andrew A. Orr, U.E.L., Dipl. President of the Andrew Club http://www.freenet.hamilton.on.ca/~ag082/Profile.html "Life is like a bowl of Cherries, fifty percent pits!" --- AAO
From: sven Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 30 Jan 1997 20:42:34 GMT Organization: "SNET dial access service" Message-ID: <5cr13q$gl@goofy.snet.net> References: <5cqh6k$bt5$1@news1.xs4all.nl> In-Reply-To: <5cqh6k$bt5$1@news1.xs4all.nl> On 01/30/97, Jan-Willem de Bruijn wrote: > >Please tell me that we're not the only ones experiencing problems with >OPENSTEP Developer 4.0 for Mach/Intel. > >I have collected a long list of bugs and would like to know whether other >developers have seen the same ones. Some are minor, but others are really >irritating, almost to the point of making development impossible. > You are not alone. Also irritated, Sven
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 31 Jan 1997 04:11:26 GMT Organization: Netcom Distribution: world Message-ID: <5crrde$19s@dfw-ixnews8.ix.netcom.com> References: <5cqh6k$bt5$1@news1.xs4all.nl> jwdb@fygir.nl (Jan-Willem de Bruijn) wrote: > Please tell me that we're not the only ones experiencing problems with > OPENSTEP Developer 4.0 for Mach/Intel. You're not :-) > Also if anyone knows if these bugs have been addressed in 4.1, please tell me > about it. Most of your listed bugs have been fixed in 4.1/Mach, but 4.1/NT isn't as solid as the Mach version. But 4.1 Developer still doesn't feel finished to me. 4.2 is rumored to be just around the corner. I bet 4.2 will be pretty solid. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 CaseServ: OPENSTEP Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
Newsgroups: comp.sys.next.programmer,comp.lang.objective-c From: hhoff@schwaben.de.NOSPAM (Holger Hoffstaette) Subject: Re: "static inline" methods would be nice ... Distribution: comp Sender: news@flop.schwaben.de Organization: NeXT Ghetto People feat. St.Eve Message-ID: <E4uF2G.3IK@flop.schwaben.de> References: <SHESS.97Jan30142225@howard.one.net> Date: Thu, 30 Jan 1997 22:42:16 GMT Scott Hess wrote: >(lots about method inlining) Good points - but I think what might be necessary is the equivalent of (shudder) Java's final keyword, so the compiler knows about what can be pessimized and what should not. Not sure how this would work out if you start playing with perform: and friends.. I've (sort of) solved the overhead of unnecessary method dispatch by extending e.g. any collection classes with more 'comfortable' methods that tend to do a lot of stuff at once, and do not use repeated method dispatch, but rather access their methods' implementation by using a straight C function call. Turns out to work great, encapsulates the C uglyness in a single (or several, but at least defined) places, and helps tremendously during large collection sweeps (for example repeated munging of arrays-of-dictionaries in a WOF app). Also, you can start with a shoddy implementation at first, and then tune those parts that suck the performance without really disturbing any other methods' implementation.. Holger -- Object web weaver | @work: hhoff@media-group.de Media group | @home: hhoff@schwaben.de (NeXTmail & PGP ok) Stuttgart, Germany | OPENSTEP. Resistance is futile.
From: Nigel Pearson <nigel@ind.tansu.com.au> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 31 Jan 1997 16:27:20 +1100 Organization: Telstra Australia Message-ID: <32F182B8.78E0@ind.tansu.com.au> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c4a19$bja@geraldo.cc.utexas.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit William Raphael Hix wrote: >...Imagine the following version of basic version of Rhapsody. > > 1) A Mach 3ish kernal (could be from NeXT, Apple, PPC Linux, Sun) > > 2) A stripped down version of the BSD emulated services... > > 3) OpenStep... > > This would be MacOS 8, selling for about $100... > > In addition there would be the optional Unix Application Environment (UAE) > or perhaps the NeXT Application Environment (NAE) ... Perhaps it'd even have > a OpenStep 4.2 mode for the appearence manager. This'd be full Unix > compatibility (perhaps even with binary compatibility with AIX for PPC > apps), except no cc, X11R6, perhaps no NFS. All of these would I'm sure > be available from third parties. Hell, if Mach is in there somewhere, it may be pretty easy to port the current MkLinux to it. Just change the MkLinux kernel from being a monolithic kernel to a kernel interface layer which implements Linux services ontop of the Mach 3 microkernel. ... > Would this satisfy everyone? It would me. -- | Nigel Pearson, nigel@ind.tansu.com.au |"so we came up with a golden rule | | Telstra IN Platforms, Sydney, Aust. | whatever works for you | | Office: 9206 3468 Fax: 9281 1301 | so we started up a whole new school| | Mobile: 014 611 322 Home: 9579 3293 | where nothing's absolute" C.Peacock|
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 31 Jan 1997 00:32:15 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5cs04v$a0h@csugrad.cs.vt.edu> References: <maury-0801971641590001@199.166.204.230> <maury-3001971430080001@199.166.204.230> <5cr3v1$4f@csugrad.cs.vt.edu> <maury-3001971930360001@199.166.204.230> In article <maury-3001971930360001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: > In article <5cr3v1$4f@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > Well, obviously. That's how it is with any OS. > Sure, but in this particular case that seems to result in the OS being > pulled in many seemingly random directions. > ... but since then we have > differing directions following market trends. That too is par for the > course. However one must contrast this to Be, where it's being created > ex-nihlo. This is not a comment on NeXT as much as it is a statement of > realities of the market. Just wait. Be will get pulled in differing directions following market trends, just like everyone else. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: 6jim@acb2.cgs.edu (Jim Kieley) Newsgroups: comp.sys.next.programmer Subject: OS 4.0 - cannot exec cpp-precomp Date: 30 Jan 1997 23:47:17 GMT Organization: The Claremont Colleges Message-ID: <5crbu5$c55$1@cinenews.claremont.edu> I am not up on Openstep even though I have it installed on a couple machines. A long story made short: things that comile fine under NS 3.3 produce the following error under Openstep 4.0: cc: installation problem, cannot exec cpp-precomp: No such file or directory Any explanation or help would be appreciated. Jim Kieley jim@cgs.edu
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: Fri, 31 Jan 1997 10:36:59 +0100 Organization: Microcomp GmbH , Cologne, Germany Message-ID: <32F1BD3B.25CB@microcomp.de> References: <5cqh6k$bt5$1@news1.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 4.0 is very bad. If you would use Apple's codenames style for future OS versions (Sonata, Rhapsody etc.) then 4.0 should be called REQUIEM. 4.1 is better , but still not sufficiently. I didn't have a day without "malfunction". I wonder about useless discussions on Net what fantastic features will Rhapsody include, how easy will be support every platform etc. Such prophets should try develop with Openstep and they will get real. Petr Novak
From: Alan Lovejoy <alovejoy@concentric.net> Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Mon, 20 Jan 1997 15:45:39 -0800 Organization: Modulation Message-ID: <32E403A3.788@concentric.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <32DEDCB2.24E6@concentric.net> <maury-1701971144500001@199.166.204.230> <32DFF7DB.167B@concentric.net> <maury-2001971514370001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32DFF7DB.167B@concentric.net>, Alan Lovejoy > <alovejoy@concentric.net> wrote: > > > This would make it more difficult to use C, FORTRAN, COBOL, BASIC, RPG, > > Assembly and other non-OO languages with the OS. > > You make that sounds like a bad thing. It's a bad thing if you want to attract customers who intend to use those languages, and don't want to change. Personally, I think those languages are seriosly sub-optimal in many ways and for many usages, but Apple can't afford to alienate potential customers. > But seriously, this strikes me as a problem for data-processing like > tasks only. The entire GUI is already OOPS lib based, and I don't see > anyone crying over that. Do you? OpenStep is a framework for writing GUI-based apps. If such frameworks exist for C, FORTRAN, COBOL, BASIC, RPG or Assembly (I don't think they do in all cases), then those frameworks are not compatible with OpenStep. And a COBOL shop would be interested in porting their existing apps over to Rhapsody, which would mean porting over their existing framework(s) for doing GUI apps (if they have such). And the original question wasn't the API for OpenStep, but rather the API to the kernel and the standard UNIX utilities. Those had better be accessible to COBOL and FORTRAN, or else a large and important base of potential customers will not use Rhapsody (I wish they'd change languages, but they won't). > Although I haven't even used ObjC on the NeXT platform yet, I > understand that many (all) of the above languages already exist. Are they > all limited to creating programs that run from the CLI only? If not, it > seems this isn't much of a problem after all. Don't know. I'm not all that familiar with NextStep/OpenStep per se. > > more difficult to use OO languages whose object models were not compatible > > with the one used to implement the kernel and libraries. > > Only in their current form. Apple's got more and more code being based > on SOM, which has no such limitation. Good. > > One could perhaps use CORBA/SOM/DSOM to address such issues. But CORBA exacts > > a noticeable performance penalty. > > Well I might be missing something here, but I always believed that if > your compiler talked SOM, there was no inherent overhead. I've heard differently. But I could be wrong. I'd be happy to wrong on this pont, actually. -- Alan L. Lovejoy |==============================================| Smalltalk Consultant | Beware of Geeks bearing GIFs! | alovejoy@concentric.net |==============================================|
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 31 Jan 1997 11:37:22 -0500 Organization: Atria Software Message-ID: <maury-3101971137220001@199.166.204.230> References: <maury-0801971641590001@199.166.204.230> <maury-3001971430080001@199.166.204.230> <5cr3v1$4f@csugrad.cs.vt.edu> <maury-3001971930360001@199.166.204.230> <5cs04v$a0h@csugrad.cs.vt.edu> In article <5cs04v$a0h@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > Just wait. Be will get pulled in differing directions following market > trends, just like everyone else. Of course, it's a truism. But for now they have a more complete package, ignoring the tools side that is. Maury
From: Software Solutions International <softsolint@stealth.net> Newsgroups: comp.sys.next.programmer Subject: Part time help needed - Mid town New York Date: Fri, 31 Jan 1997 10:28:18 -0600 Organization: Software Solutions International Message-ID: <32F21DA2.3AD3@stealth.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: softsolint@stealth.net One of our clients is interested in enhancing their software written in objective C. They are looking for programmers with objective C experience. If you are interested in part time ( evening and/or weekend) work please contact the undersigned as soon as possible or reply back so that we can contact you. Vimal Software Solutions Phone 212-480-2112 Fax: 212-480-2114
From: msoori@genetics.bio-rad.com (msoori) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 31 Jan 1997 17:09:56 GMT Organization: Bio-Rad Laboratories Message-ID: <msoori-3101970909560001@ms.genetics.bio-rad.com> References: <5c9h5n$rju@csugrad.cs.vt.edu> <5capi6$mqk@flood.weeg.uiowa.edu> <ga-2501971120370001@cust92.max27.los-angeles.ca.ms.uu.net> <5coghm$287$5@majipoor.cygnus.com> <32EFDC32.3ADC@netscape.com> <5cpats$f4t$1@majipoor.cygnus.com> In article <5cpats$f4t$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > I can see the case against using named _prefix_ notation functions, but > that's not at all > the same as _infix_ method names. > > [[[[matrixA times: matrixB] times: matrixC] times: matrixD]; > > is not significantly harder to read than: > > matrixA * matrixB * matrixC * matrixD; > > Especially if you need to add parenthises for some reason. It _is_ more > wordy, but it's still > easy to read. Give me a break! What about more complex functions? This is now begining to look like lisp with "()" replaced by "[]" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Mahesh P. Sooriarachchi. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Work: msoori@genetics.bio-rad.com | ~ ~ Home: mahesh@value.net | This space for rent! ~ ~ Home Page: http://value.net/~mahesh/ | ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: jinx6568@sover.net.egg.sausage.and.spam (Chris Johnson) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy,comp.sys.next.programmer Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 31 Jan 1997 18:49:55 GMT Organization: Airwindows Message-ID: <jinx6568-3101971352280001@news.sover.net> References: <maury-0801971641590001@199.166.204.230> <maury-0901971045180001@199.166.204.230> <5b3scd$8et@argo.patnet.caltech.edu> <maury-1001971415220001@199.166.204.230> <5b7chs$bi3@ra.patnet.caltech.edu> <maury-1501971742190001@199.166.204.230> <5bll0l$me7@dfw-ixnews2.ix.netcom.com> <maury-1601971549250001@199.166.204.230> <ImsZy1y00iWT41JBZF@andrew.cmu.edu> <32E296A4.4261@concentric.net> <cmshmdm00iVE09CsxH@andrew.cmu.edu> <32E3158E.5785@concentric.net> <Qmt04oO00iV0M52u8d@andrew.cmu.edu> <maury-2101971109420001@199.166.204.230> <cmtJ1Ry00iV0M5bOpK@andrew.cmu.edu> <maury-2701971234100001@199.166.204.230> <32EF0661.6A64@etm.co.at> <3303f619.1643476734@mambo> In article <3303f619.1643476734@mambo>, sangria@inlink.com (Sang K. Choe) wrote: > >The POSIX subsystem of Windows NT is only POSIX.1, which does'nt include > >any POSIX commands. Some POSIX commands are part of the Windows NT > >Resource Kit, which must be purchased separately. > Or you can download a fairly complete set from CyGnus (www.cygnus.com) > for free. > -- Sang. This is precisely the issue raised by some of the discussions over Rhapsody. If Rhapsody does not include the set, then maintainers (who are already used to telnetting into a box and using those tools since they are accessible through telnet) cannot depend on the tools being there. The potential of a user to download them for personal use is sort of irrelevant- odds are there are more refined tools available, anyhow. The issue is the default existence of certain really crude but functional tools that can be remotely accessed using existing methods. I've actually come to realize I'm strongly in favor of having these things in Rhapsody- hell, they'd fit on my existing hard disk which is a mere 280 megs. It is interesting to see that this ball has already been dropped by NT. Is this Cygnus package popular, or is it rarely found installed in actual systems? There could be a situation developing in which 'if you want to be sure of Unix-type remote access on a non 'unix' system, you have to get your users Macs'. Jinx_tigr (aka Chris Johnson)
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy Date: 31 Jan 1997 21:21:24 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5ctnok$ptf@geraldo.cc.utexas.edu> References: <maury-0801971641590001@199.166.204.230> <5bok4a$q23@geraldo.cc.utexas.edu> <5bq05v$7t9@duke.squonk.net> <5c0b1d$aiu@geraldo.cc.utexas.edu> <5c0fue$2e7@csugrad.cs.vt.edu> <32E3D1EA.7F8F@exnext.com> <maury-2001971748370001@199.166.204.230> <5c1daj$nhr@duke.squonk.net> <5c6o55$ojc@geraldo.cc.utexas.edu> <wmvHYjC00iV1M6ZF1w@andrew.cmu.edu> Charles William Swiger (cs4w+@andrew.cmu.edu) wrote: : Excerpts from netnews.comp.sys.next.advocacy: 28-Jan-97 Re: MacWorld : Exclusive: App.. by Maury Markowitz@softarc. : > nor would it have got them NeXT's customer list. Those alone are probably : > worth more to Apple than a new OS for the Mac. : : In order to keep NeXT's customer list, Apple needs to provide an : operating system, development environment, and so forth which is : comparible to the functionality of NeXT's current products. : But will Rhapsody be it, or will OpenStep 5? be developed in parallel? This is one of the questions Apple has yet to answer clearly. It might be that Apple hasn't decided yet. This decision will determine how much of Rhapsody's expanded API makes it to Intel hardware, and how fast. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: tbutler@tfs.net (Travis Butler) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Fri, 31 Jan 1997 17:10:38 -0600 Organization: The Wandering Powerbook... Message-ID: <AF17D80E96687E79C@node23.tfs.net> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> In article <Emt1MN_00iV0052vBl@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.advocacy: 20-Jan-97 Re: MacWorld >Exclusive: App.. by Maury Markowitz@softarc. >>> I don't understand why you want to scatter your applications all over >>> the filesystem. >> >> Because it's MY file system. You don't have to like it, do what you wish. > >Well, if you want to scatter your applications around even though it >makes your computer less functional and harder for other people to use, >you can. I don't see why anyone would want to make their computer >harder to use, but then, that's just my preference for thinking >rationally showing through.... Funny, I put all my graphics applications in a Graphics folder, all my utilities in a Utilities folder, all my internet applications in an Internet folder, a subfolder to the Communications folder where I put all my communications applications... I guess I just am not thinking rationally. <sarcasam off> I know other users who have a folder for each of their applications, and put all the documents from that application in a subfolder within that folder. Who am I to argue if it works for them? Bottom line: Different strokes for different folks, and there is *no* One True Way to Organize. Period. >>> I don't know anyone who does this. Even the Mac >>> people tend to put everything in the Applications folder or a >>> subdirectory of it. >> >> Balogna, I can't think of a single Mac I've every had the pleasure of >> using that had all of it's programs arranged such, and that's a large >> number of Macs (in the hundreds). That's just _wrong_. > >No, it's not, although I am unsurprised to discover that a Mac advocate >has not had exposure to large computer networks administered by an >organization. For example, CMU has hundreds of Macs in the clusters >with a very consistent filesystem layout. > >Most Mac users here like the idea, so they generally arrange their >computers in similar ways to the cluster machines-- and there are well >over 1000 Macs on campus here. Great. You're managing an organizational network in a lab situation, and you have other users arranging their machines so that there's less confusion for them when they use one of the lab machines. That's fine for them, but it doesn't say anything about all the individual Macs in use out there, not to mention all the network situations where it's one individual using the same Mac all day every day. Is it not more efficient for that user to arrange his system the way that's fastest and easiest for him to work with? Lab situations are IMHO an isolated situation that have, and *should* have, little influence on the way other people run their systems. Users in a lab, where any user might find himself using any computer, benefit from a standardized setup; but when one user is working with one computer, it makes more sense to organize it in the way that's most efficient for *them*. From another post: In article <gmtamKS00iV_I6IBY8@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.advocacy: 21-Jan-97 Re: MacWorld >Exclusive: App.. by Maury Markowitz@softarc. >>> I don't see why anyone would want to make their computer >>> harder to use, but then, that's just my preference for thinking >>> rationally showing through.... >> >> Oh, it's terribly rational for the computer to dictate where the user >> places files, rather than the other way around. > >Correct. A multiuser computer system has conventions for where you >should place common files (like applications, fonts, and other such >resources) which are supposedly intended for use by all users. This is probably where most of the difference is coming from. I don't *want* a multiuser computer system, with all of the security kaka that involves. We're talking about *personal computers* here, and there's a reason for the word "personal" in the label -- these are computers designed for use by one person. As I said, I believe lab systems and servers are the exceptions, not the rule that you should design a personal computer OS around. The explosion of the computer market since the late 70's has been driven by personal computers -- not servers, not workstations, not multi-user systems. I think there's a reason for that. I want a system that I can control myself, set up any way I please to fit *my* habits and working patterns, without having to jump through security and permission hoops designed for multiuser setups my computer will never be used in. To bring back a metaphor from the '80s -- I oppose the high priests of the MIS department, and support individual user empowerment. To repeat the quote: >> Oh, it's terribly rational for the computer to dictate where the user >> places files, rather than the other way around. > >Correct. This is the antithesis of the personal computer movement, and it's the exact opposite of everything the Mac has stood for. I don't know if you paid much attention to the early Mac market, or Apple's early advertising -- but I still remember an early Mac demo, and the speech-synthesis application that went with it: "Wouldn't it be easier to teach computers about people, rather than teaching people about computers?" That philosophy is one of the things that's kept me loyal to the Mac, through thick and thin: the computer should adapt to the user, and computing power should be used to make things easier for the user -- not the other way around. The computer is there for the user, after all, not the user for the computer. >For that matter, single-user computer systems have some of those >conventions too-- what else did you think the special nature of the >"System folder" represents under MacOS? True... But: a) The organization in the System Folder was put in mainly for the *user's* benefit. I remember when it was reorganized, with System 7.0 in 1991. Previously, all OS-related items were simply dumped into the System Folder; System 7 created subfolders to organize those items, designed to be logical and understandable *from the user's standpoint*, with names like "Control Panels", "Preferences", "Startup Items," and so forth. b) These 'conventions' are limited to the OS itself; users are free to organize the rest of the computer as they please. Travis Butler (The Professor, formerly of Myth and Magick!, Lawrence, KS; tbutler@tfs.net, now from the Wandering Powerbook; <http://www.tfs.net/personal/tbutler/>; Mac page <http://www.tfs.net/business/tbutler/>) ...Cats are the proof of a higher purpose to the universe.
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Date: 31 Jan 1997 22:02:08 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5ctq50$s7v@geraldo.cc.utexas.edu> References: <5ami95$ol3@news.tuwien.ac.at> <jamesl-0601971352260001@jamesl.sirs.com> <nervous-0701970033100001@ascend6.netrover.com> <bononno-ya023680000701972252440001@news.nyu.edu> <maury-0801971641590001@199.166.204.230> <5b1p4k$8sf@news1.ucsd.edu> <maury-0901971045180001@199.166.204.230> <5b4kbm$642@csugrad.cs.vt.edu> <maury-1001971421040001@199.166.204.230> <5b9d73$p3u@csugrad.cs.vt.edu> <maury-1501971811400001@199.166.204.230> <5bloik$aqu@crl.crl.com> <5bm1pa$i8u@geraldo.cc.utexas.edu> <5bn49f$bev@cs <5cnu5o$eus@geraldo.cc.utexas.edu> <32EFF92A.526D@subsequent.com> Jonathan W. Hendry (jon@subsequent.com) wrote: : William Raphael Hix wrote: : > Unfortunately, the number of users who want a Unix OS and productivity : > apps is small (even though it includes me 8-)). Apple would be better : > served concentrating on larger markets, like content development, : > publishing, and the like, where the Apple name on a robust, stable and : > fast OS will quickly gain favor. Hopefully, we Unix users will get what : > we want, but I'm not holding my breath. : : You're assuming that the only way to market a Unix OS is as a : Unix OS. This is not a good assumption. Rhapsody will have copious : features which will allow it to be marketed to people who don't : care one whit about Unix. Apple need only mention the Unix : feature as one among dozens. The best bet would be to : emphasize it in some marketing campaigns, and de-emphasize : it in others. When trying to sell to techies, sell the Unix, : along with everything else. When selling to artists, sell the : power, ease of use, Display Postscript, and software - sell : it as a Macintosh. : There is nothing to preclude Apple from releasing Rhapsody with full BSD compliance, provided all user and system administration functions are fully GUI'd. However with the small interest in Unix in the target communities, non-compliance with BSD also wouldn't hurt much. They've said they'll build on the OpenStep API and that they'll have a modern kernal, though which kernal is still up for grabs. They'll need to interface the API with the kernal, a function now performed largely by the BSD libs. Thus Rhapsody will probably include the BSD libs, unless Apple decides they have a reason to replace them which is good enough to justify the time and effort it will take. The choice of kernal might play a role in this decision, since a kernal change will require porting the BSD libs. The case for the /bin parts of BSD is weaker. If the BSD libs are present, then adding the BSD /bin parts is easy, though it might be a separate product Apple or a third party sells. If the kernal change results in the BSD libs being dropped, full BSD compliance is a lot of work. However if the new kernal is Sun's Solaris, then SysV Unix compatibility is easy. Based on these factors, my opinion is that full BSD compliance will be possible, though I'm expecting that I'll need to pay for an additional product. Perhaps by the WWDC we'll get a better idea of how Apple feels on this issue. Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Followup-To: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Date: 31 Jan 1997 22:31:43 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5ctrsf$j2@geraldo.cc.utexas.edu> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450001@mckinnon.tezcat.com> <jinx6568-1601971303370001@news.sover.net> <5bshs8$e5n@csugrad.cs.vt.edu> <maury-2001971522480001@199.166.204.230> <Emt1MN_00iV0052vBl@andrew.cmu.edu> <maury-2101971155550001@199.166.204.230> <gmtamKS00iV_I6IBY8@andrew.cmu.edu> <maury-2701971404290001@199.166.204.230> <AmvImse00iWT4I_dgv@andrew.cmu.edu> <maury-2801971238060001@199.166.204.230> <Mmvg=Kq00iWXMGcLYX@andrew.cmu.edu> <maury-290 Pohl Longsine (pohl@screaming.org) wrote: : Re: filesystem conventions on Mac and NeXT. : : NeXTstep doesn't care that I do this, as long as I do it intentionally. : Fortunately, if I'm logged on as a mortal, it won't allow me to : accidentally drop any of my stuff into the application folders : that all of my family members share. It also doesn't allow the : toddler to drag my files out of my folders, or to damage the system : at all, short of yanking the cord out of the wall. : : Note that anybody who wants their NeXTstep system to simulate : the free-form nature of the Macintosh can just always be logged : on as root. [...but don't come cryin' to me... ;-] : It will be interesting to see how Apple integrates the single user Mac paradigm with the multi-user nature inherent in OpenStep's Unix roots. For Copland, Apple was going to include the ability to have separate preferences for multiple users and perhaps protected filespace, so I'm sure they'll go at least that far. If Rhapsody sticks to the BSD nature of OpenStep, then one would expect there to be Unix style file permissions (though not visible to the unexperienced eye) and root login for system functions. But how about remote users telneting into a Rhapsody Mac? Much of the ease of Unix system administration comes from remote logins and the ability to be root independant of the console. Will Rhapsody maintain this? If I remember correctly OpenStep allows this, though by default it's turned off. I guess these issues come under ease of use, so perhaps Apple will change these dramatically in their effort to de-Unixize Rhapsody. Will the existance of a separate system account be deemed too Byzantine for the Mac? I dread the thought of a system where everyone is root, especially in a lab or corporate system. Are we going to have to wait to WWDC before we here about such issues as these? Raph ---------------------------------------------------------------------------- William Raphael Hix Department of Astronomy raph@astro.as.utexas.edu University of Texas Voice: (512) 471-3412 R.L. Moore Hall FAX: (512) 471-6016 Austin TX 78712 WWW: http://tycho.as.utexas.edu/~raph Room 17.210 ----------------------------------------------------------------------------
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.