This is Prog-02.gz in view mode; [Up]
From: "Mark Jenkins" <markj@inwave.com> Newsgroups: comp.sys.next.programmer Subject: New User/Developer Date: 1 Feb 97 00:08:20 -0600 Message-ID: <AF1839F8-5E8A0@206.101.238.36> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Wow! As a long time and very fanatical Mac user/developer/evangelist, all I have to say is that I wish I had checked out Next sooner. :-( I am very impressed after only 1 day of setting-up and getting to know OPENSTEP 4.1 for Mach/Pentium. I have not been this excited about an OS since the original Macintosh hit the scene in 84! Pentium P-90 16meg/2gig SCSI II Fast PCI, S3 PCI video, Soundblaster AWE/32 Installation was very smooth and easy (had the mouse on com2 and this was a point of confusion at first, plugged into com 1 and all was well). How much faster will I be if I upgrade my ram to 32/64 megs? I dug right into the Developer tutorial and have come across an anomaly that is probably very easy to remedy and I look for your advise. In the Currency Exchange tutorial on page 27 they direct me to drag the NSReturnSign icon from the nib file window onto the Convert button, but there is no NSReturnSign icon in the nib file! What did I do wrong, or better yet, how can I get that icon to show up? TIA Mark Jenkins markj@inwave.com MIME, Cyberdog mail OK (Soon to be NeXT Mail compatible! :-)
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: New User/Developer Date: 1 Feb 1997 07:08:49 GMT Organization: Digital Fix Development Message-ID: <5cuq61$3nn@news.digifix.com> References: <AF1839F8-5E8A0@206.101.238.36> In-Reply-To: <AF1839F8-5E8A0@206.101.238.36> On 01/31/97, "Mark Jenkins" wrote: >Wow! > >As a long time and very fanatical Mac user/developer/evangelist, all I have >to say is that I wish I had checked out Next sooner. :-( > >I am very impressed after only 1 day of setting-up and getting to know >OPENSTEP 4.1 for Mach/Pentium. > >I have not been this excited about an OS since the original Macintosh hit >the scene in 84! > >Pentium P-90 16meg/2gig SCSI II Fast PCI, S3 PCI video, Soundblaster AWE/32 > >Installation was very smooth and easy (had the mouse on com2 and this was a >point of confusion at first, plugged into com 1 and all was well). > >How much faster will I be if I upgrade my ram to 32/64 megs? > I'm not sure if it would feel faster, but it would feel smoother. :-) With the price of RAM now adays, its pretty cheap. 64M can be had to $300. >I dug right into the Developer tutorial and have come across an anomaly >that is probably very easy to remedy and I look for your advise. > >In the Currency Exchange tutorial on page 27 they direct me to drag the >NSReturnSign icon from the nib file window onto the Convert button, but >there is no NSReturnSign icon in the nib file! > >What did I do wrong, or better yet, how can I get that icon to show up? > >TIA > >Mark Jenkins >markj@inwave.com >MIME, Cyberdog mail OK (Soon to be NeXT Mail compatible! :-) > > > > > -- 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.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 1 Feb 1997 03:05:51 GMT Organization: Netcom Distribution: world Message-ID: <5cubuf$ibm@sjx-ixn6.ix.netcom.com> References: <5cqh6k$bt5$1@news1.xs4all.nl> <32F1BD3B.25CB@microcomp.de> Petr Novak <novak@microcomp.de> wrote: > 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. You are making an assumption that Rhapsody == OS 4.1 which I'm certain will be false. NeXT made huge numbers of changes in moving from NS to OS. They did it essentially in one step (OS existed in a minor way in NS 3.3). The rate of change from 4.0 to 4.1 suggests that 4.2 will be quite good. Rhapsody will follow even later so should benefit even more. -- 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: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 1 Feb 1997 09:44:39 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5cv3a7$n1f$1@brachio.zrz.TU-Berlin.DE> References: <5cubuf$ibm@sjx-ixn6.ix.netcom.com> In article <5cubuf$ibm@sjx-ixn6.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) writes: > Petr Novak <novak@microcomp.de> wrote: [..OS 4.x is terrible, Rhapsody will be as well..] > You are making an assumption that Rhapsody == OS 4.1 which I'm certain > will be false. NeXT made huge numbers of changes in moving from NS to OS. > They did it essentially in one step (OS existed in a minor way in NS 3.3). > The rate of change from 4.0 to 4.1 suggests that 4.2 will be quite good. > Rhapsody will follow even later so should benefit even more. In addition, OS had been de-emphasized significantly, with focus shifting to WebObjects. Now the focus of not just NeXT but Apple as well is on getting the best possible OS out the door. Marcel
From: jsamson@istar.ca (Jean-Paul C. Samson) Newsgroups: comp.sys.next.programmer Subject: Re: New User/Developer Date: 1 Feb 1997 08:42:49 GMT Organization: iSTAR Internet Incorporated Message-ID: <5cuvm9$lb4@news.istar.ca> References: <AF1839F8-5E8A0@206.101.238.36> <5cuq61$3nn@news.digifix.com> In-Reply-To: <5cuq61$3nn@news.digifix.com> >>I dug right into the Developer tutorial and have come across an >>anomaly that is probably very easy to remedy and I look for your >>advise. In the Currency Exchange tutorial on page 27 they direct me >>to drag the NSReturnSign icon from the nib file window onto the >>Convert button, but there is no NSReturnSign icon in the nib file! >>What did I do wrong, or better yet, how can I get that icon to show >>up? They took out the return sign icon. Instead, the default button now has a thick black bezel, like Windows. Sadly, the Developer Tutorial book is filled with inaccuracies. They didn't do a very good job proofreading and testing the book. Maybe NeXT just ran out of time in preparing for the OPENSTEP 4.0 release. The book will give you a good idea of how to go about programming OPENSTEP applications, but don't expect the resulting programs to work very well. -- -===================================================================- Jean-Paul C. Samson -=- jsamson@istar.ca -=- NeXTmail & MIME welcome -============- http://www.cs.ualberta.ca/~jeanpaul/ -=============- -===================================================================-
From: EDV@lfa.hal.eunet.de (Thomas Richter) Newsgroups: comp.sys.next.programmer Subject: Master-Detail-Relationship problems Date: Sat, 01 Feb 1997 10:43:24 GMT Organization: Landesamt fuer archaeologische Denkmalpflege Sachsen-Anhalt) Message-ID: <5cva49$oao@news.Dortmund.Germany.EU.net> Hi all, i am using NEXTSTEP 3.3 and Developer and EOF 1.1 with installed Patches on Intel Hardware and Sybase Databases. With EOF 1.1 I cannot use Master-Detail-Relationships (no fetchs of detail records when selecting a record in the master table). Master-Peer-Configurations work fine. On my home maschine (equivalent software but msql- and Postgres95- Databases) i have no problems with Master-Detail-Relationships. Thanks for any help Thomas Richter Landesamt fuer archaeologische Denkmalpflege Sachsen-Anhalt, Gemany EDV@lfa.hal.eunet.de
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: Fri, 31 Jan 1997 18:43:01 -0800 Organization: Another Netscape News Server User Message-ID: <32F2ADB0.41DD@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> <32EFDC32.3ADC@netscape.com> <32F0D73B.F18@nowhere.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Michael Hudson wrote: > > 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. Of course. Does object C support references? > > 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. Agreed. If you are overloading the mathematical operators for any non math purposed then your code is going to be a lot tougher to read. If it isn't clear what the operation does than you shouldn't overload the operator. An example is vector multiplication. Are you talking about the dot product or the cross product? I have seen decent arguments for both which means whenever I see a vector multiplicatoin I have to think about whats going on. Bad. > 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. David
From: tiggr@es.ele.tue.nl (Pieter Schoenmakers) 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: 01 Feb 1997 16:20:57 +0100 Organization: Eindhoven University of Technology Sender: tiggr@tom.ics.ele.tue.nl Message-ID: <x7g1zgk0x2.fsf@tom.ics.ele.tue.nl> 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> <SHESS.97Jan27095044@howard.one.net> In-reply-to: shess@one.net's message of 27 Jan 97 09:50:44 to: shess@one.net In article <SHESS.97Jan27095044@howard.one.net> shess@one.net (Scott Hess) writes: I know this will get me in trouble, but ... you shouldn't be switching on the class/type of an object in any case. I could not agree more. That's the reason you use message dispatch (so the runtime does the switch for you). As an example of how this actually needs cleaner and faster code, the TOM (http://tom.ics.ele.tue.nl:8080) string classes can serve very well. Basically, there is a more-or-less abstract String class, with CharString and ByteString subclasses (for storing Unicode strings and byte-encoded versions of them, respectively), each with UniqueCharString and UniqueByteString subclasses. Now all these classes know how to compare each other, by implementing the equal method appropriately. For instance, the unique strings will simply invoke `[other equalUniqueString self]', where the receiving string, if a unique string, can simply do a `return self == other'; to normal (non-unique) strings being equal to a unique string is like being equal to a normal string. The ByteString will send `[other equalByteString self]' to test for equality. The ByteString implementation of this method can be really fast, using a simple memcmp (provided that the encodings are the same of course). The CharString implementation of `equalByteString' will do conversion between the canonical unicode and the byte encoding, etc. Why this is faster? Easy. It needs one or two extra method invocations, depending on what you compare with what, whereas the class switching needs a lot more: if ([other isKindOf: [ByteString class]]) ... In Objective-C, this is two method invocations, a class lookup (which means finding a string in a hashtable) and a class hierarchy test, which can be expensive. And after this excercise all you know is that it is a ByteString or not. And if it isn't, you have to do another expensive test. There are other advantages of not using isKindOf or conformsTo, like code locality, maintainability, and extensibility since each decision is in a seperate method, which is easily implemented by another class or overridden in a category... --Tiggr
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: New User/Developer Date: 1 Feb 1997 17:28:20 GMT Organization: Netcom Distribution: world Message-ID: <5cvufk$92p@dfw-ixnews3.ix.netcom.com> References: <AF1839F8-5E8A0@206.101.238.36> <5cuq61$3nn@news.digifix.com> <5cuvm9$lb4@news.istar.ca> jsamson@istar.ca (Jean-Paul C. Samson) wrote: > >>I dug right into the Developer tutorial and have come across an > >>anomaly that is probably very easy to remedy and I look for your > >>advise. In the Currency Exchange tutorial on page 27 they direct me > >>to drag the NSReturnSign icon from the nib file window onto the > >>Convert button, but there is no NSReturnSign icon in the nib file! > >>What did I do wrong, or better yet, how can I get that icon to show > >>up? > > They took out the return sign icon. Instead, the default button now > has a thick black bezel, like Windows. So to configure a default button in a nib, instead of dragging a NSReturnSign icon to the button, set the button's Key property to "\r" which is a common Unix representation of the carriage return character. -- 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: Joseph Panico <jpanico@online.disney.com> Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: Sat, 01 Feb 1997 13:25:59 -0500 Organization: Disney Online Message-ID: <32F38AB7.27ED@online.disney.com> References: <5cqh6k$bt5$1@news1.xs4all.nl> <5crrde$19s@dfw-ixnews8.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Art Isbell wrote: > > jwdb@fygir.nl (Jan-Willem de Bruijn) wrote: > > > Please tell me that we're not the only ones experiencing problems with > Most of your listed bugs have been fixed in 4.1/Mach, but 4.1/NT isn't as 4.1 Mach PB has many, many problems. - It's very easy to crash. Go to classes in the project file browser, double click on a .m, then double click on a .h-- splat! - I cannot find a place to set the tab-stops and the number of spaces per tab - The integrated editor does not reflect changes made to a file outside of PB. So it is impossible to use most of the features of PB with an outside editor. - Find does not search into all of the Frameworks included in a project. - It's too integrated-- The 3.3 PB had a better, more open design. It feels as though NeXT is moving backwards, not forwards. ...I could rant on... > -- > 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 -- Joe Panico Disney Online jpanico@online.disney.com
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: IB wierdess: saving .nib file alters it=>DPS errors Date: 1 Feb 1997 03:31:18 GMT Organization: MHPCC Message-ID: <5cude6$1cn@kaopala.mhpcc.edu> I've been having problems with Interface Builder in NEXTSTEP 3.3/Intel. The symptom is that when I launch my application, the app icon at the bottom of the screen stays whited out, and I get these console errors: Jan 31 17:17:58 pueo GA_VIEW[7381]: DPS client library error: PostScript program error, DPSContext f47a0 Jan 31 17:17:58 pueo GA_VIEW[7381]: %%[ Error: typecheck; OffendingCommand: ustroke ]%% Jan 31 17:17:58 pueo GA_VIEW[7381]: DPS client library error: Invalid tag in returned object, DPSContext f47a0, data 1009636 Jan 31 17:17:58 pueo GA_VIEW[7381]: DPS client library error: Invalid tag in returned object, DPSContext f47a0, data 1009652 Now, the strange thing is, all I have to do to get these errors is to open the nib file, save it without any changes, and recompile the program. I discovered that opening and saving the .nib file DOES change it! I get this diff in the data.classes file: 1c1 < BarView = {SUPERCLASS = View; }; --- > SortView = {ACTIONS = {"sortPlot:" = "sortPlot:"; }; OUTLETS = {}; SUPERCLASS = View; }; 4c4 < SortView = {ACTIONS = {"sortPlot:" = "sortPlot:"; }; OUTLETS = {}; SUPERCLASS = View; }; --- > BarView = {SUPERCLASS = View; }; For some reason, it reverses the order of these lines. There are also large differences in the data.nib files. And these differences cause the white icon and console errors. So what on earth is going on? Why should openning and saving a .nib file alter it, and cause DPS errors upon recompilation? Any tips 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: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.lang.objective-c Subject: Re: "static inline" methods would be nice ... Date: 31 Jan 97 19:38:52 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Jan31193852@howard.one.net> References: <SHESS.97Jan30142225@howard.one.net> <E4uF2G.3IK@flop.schwaben.de> In-reply-to: hhoff@schwaben.de.NOSPAM's message of Thu, 30 Jan 1997 22:42:16 GMT In article <E4uF2G.3IK@flop.schwaben.de>, hhoff@schwaben.de.NOSPAM (Holger Hoffstaette) writes: 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. This is similar to what I've done with a pretty large project that did a _lot_ of messaging. It works very well for those cases where you're tending to do something small repeatedly (for instance, doing the same simple operation to an entire set of objects in a collection. You even get bonus points if the operation is literally the same due to all of the objects being the same!). On the other hand, this is exactly the type of thing I'd really like the compiler to do for me. The route described above does usually require you to make a bunch of small changes all over the place. I'd like to make one change (putting the method in the @interface file) in one place, and then just rebuild ... 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: 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: Sat, 1 Feb 1997 16:08:23 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <smwv37e00iWp07Gn80@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> <AF17D80E96687E79C@node23.tfs.net> In-Reply-To: <AF17D80E96687E79C@node23.tfs.net> Excerpts from netnews.comp.sys.next.advocacy: 31-Jan-97 Re: MacWorld Exclusive: App.. by Travis Butler@tfs.net >> 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> That sounds perfectly reasonable to me. Under NEXTSTEP, you'd put that folder structure under /LocalApps and everything would work fine. Or you could put it whereever you liked and make links into /LocalApps. Or, assuming you can change the default searchpath for apps under Rhapsody, you could tell the WorkSpace to look whereever your tree is. > 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? They can if they want to under NEXTSTEP, too...depending on what permissions the system has been set up with. (Obviously, on a single-user machine, you can configure the permissions however you like-- but a multi-user machine normally has controls for who can do what where.) > Bottom line: Different strokes for different folks, and there is *no* One > True Way to Organize. Period. Surely. But operating systems generally have useful conventions to guide the way you organize things, and this can be very useful. [ ... ] >>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? Probably not, no-- although it's a hypothesis that could be tested if you want to spend the effort setting up experiments. I happen to think that having good filesystem conventions makes machines easier to use for all users, but that's just my opinion, not a fact. I do know that I've never seen a NEXTSTEP user complain about the filesystem conventions under NS-- it's not as if there are legions of people who are dissatisfied by having their apps under /LocalApps and their fonts under /LocalLibrary/Fonts. > Lab situations are IMHO an isolated situation that have, and *should* have, > little influence on the way other people run their systems. And corperate users in the business world are also an isolated situation? And networked users are yet another isolated situation? So much for that theory.... [ ... ] >> 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. Your opinion is noted. Of course, Apple already tried that route with the MacOC, and they finally realized that multiuser machines with security have major advantages in terms of stability, immunity to virus infection, protection that keeps one user from damaging another user's files or processes or the operating system itself, protection from network attacks like someone cracking your machine, etc. Fortunately, NEXTSTEP is a multiuser OS with security and so forth, which also is very easy for people to use as their personal computer. That's why Apple bought NeXT in order to gain their technologies, once Apple realized that Copland was a failure. > 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. Great-- stick with MacOS 7 instead of Rhapsody, then. That's your choice. > 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 Gee-- I still own an Apple ][+ with 48K on the motherboard and a 16K language card from 1979, and I remember Apple's early advertising before the Mac even existed. I think NEXTSTEP and NeXT's black hardware, with multiuser and security, was generally the most user-friendly personal computer system ever invented. [ ... ] -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.next.advocacy,comp.sys.mac.advocacy Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: Sat, 1 Feb 1997 16:49:18 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <ImwvdSe00iWp07Gpc0@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> <Amvtefa00iV6M288Ja@andrew.cmu.edu> <jinx6568-2901972309330001@news.sover.net> In-Reply-To: <jinx6568-2901972309330001@news.sover.net> Excerpts from netnews.comp.sys.next.advocacy: 30-Jan-97 Re: MacWorld Exclusive: App.. by Chris Johnson@sover.net. [ ... ] > 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. Exactly. NeXT already did a good job of hiding Unix, but Apple undoubtedly will go even further along those lines, which is great for normal users. Furthermore, Rhapsody will appeal to people who want or need to look at the low-level tools that make the OS go, which overcomes one of the primary limitations of the MacOS.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 2 Feb 1997 01:58:44 GMT Organization: Netcom Distribution: world Message-ID: <5d0sck$q9g@sjx-ixn7.ix.netcom.com> References: <5cqh6k$bt5$1@news1.xs4all.nl> <5crrde$19s@dfw-ixnews8.ix.netcom.com> <32F38AB7.27ED@online.disney.com> Joseph Panico <jpanico@online.disney.com> wrote: > 4.1 Mach PB has many, many problems. > - It's very easy to crash. Go to classes in the project file browser, > double > click on a .m, then double click on a .h-- splat! I guess the way one works determines the PB stability experienced. I rarely see PB crash and I spend all day every day using 4.1 PB on Mach and NT. But I never do the above. > - I cannot find a place to set the tab-stops and the number of spaces > per tab I have PB's preferences set to indent when tab is pressed, so I don't insert tabs in my source. But this enhancement would be nice for those who do. > - The integrated editor does not reflect changes made to a file outside > of PB. So it is impossible to use most of the features of PB with an > outside editor. I frequently use emacs to make external changes to source files. By merely entering Command-u (Revert to Saved) with the externally-edited file displayed in PB, the external changes will be displayed in PB. If you don't revert to saved, any attempt to modify the file in PB will open an Alert panel that provides an opportunity to reload the changed file, overwrite the changes, or cancel the modification. This seems like pretty good behavior. > - Find does not search into all of the Frameworks included in a project. That might be nice, but I'd want that to be optional behavior. As it stands, just having the framework projects open in PB in addition to the main project will allow the search string to be shared among all projects. So simultaneous searches of all desired projects can be run. This is pretty powerful. > - It's too integrated-- The 3.3 PB had a better, more open design. > It feels as though NeXT is moving backwards, not forwards. Different strokes for different folks, I guess. I like the tighter integration, but several important features are still missing. The former gdb browse panel is missing. This was a very nice feature. Too many gdb commands must be manually entered in the current PB. -- 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: Tom Reminga <webmaster@q-net.pair.com> Newsgroups: comp.sys.next.marketplace,comp.sys.next.programmer,comp.sys.next.software,comp.soft-sys.nextstep Subject: I Need some NeXT Hardware Date: Sat, 01 Feb 1997 22:24:17 -0600 Organization: Q-Net Internet Services Message-ID: <32F416F1.6576@q-net.pair.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Please help, I am in desperate need of hardware and software for my NeXT Station. Bellow is the list of items I need... 1 Monoter Cord- Monocrome- I am unsure since I can not even turn on the computer 2 Power Cords- One for Printer and One for computer itself 1 Printer Cords- To connect the printer to the computer 1 CD-Rom Drive- That can be connected to the SCSI port 1 Hard Drive (500 or so megs)- That can be connected to the SCSI port 1 Latest version of the operating system- Developer and user version for a Motorola processer 1 Set of Software- Browser, E-Mail Client, Word Processer, Spread Sheet, any other useful software. 1 A later version of their web development suiet for Motorola I have a Motorola NeXT Station with a Mega Pixel monoter. I also have a NeXT printer(laser). I am unsure of the RAM or Hard Disk space since I am unable to turn the computer on. Also if anyone could direct me to a few good books on NeXT. Thanks Tom Reminga E-Mail me at: mailto: webmaster@q-net.pair.com Q-Net Internet Services http://www.q-net.pair.com
From: buckley4@mail.idt.net Newsgroups: comp.sys.next.programmer Subject: RTF colors? Date: 2 Feb 1997 01:50:51 GMT Organization: IDT Message-ID: <5d0rtr$l0m@nnrp2.farm.idt.net> Edit.app (and it's derivatives like Mail.app) will display RTF with a background color if specified. Unfortunately, selected contents are not highlighted in the presence of a background color (making cut & paste a guessing game) I found some specs for RTF 1.3 but no mention of a highlight color tag. OmniWeb does manage to allow visible selection of their generated RTF (converted from sgml for rendering). Interesting, Edit's "Save Selection" service drops all background color info from an HTML doc, but TickleServices "Save RTF" manages at least the greyscale alternative. Is it possible to have Edit/Mail behave like OmniWeb and display selected text in a different color? -- _________________________________________ Paul Buckley 515 W 59th St., Apt. 22K New York, NY 10019 E-mail: buckley4@mail.idt.net Tel/Fax: 212-333-3382 _________________________________________ Nuclear weapons are inherently dangerous, highly expensive, militarily inefficient, and morally indefensible General Lee Butler, who would not be quoted in The Times
From: andrew_abernathy@omnigroup.com Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 2 Feb 1997 08:26:32 GMT Organization: Omni Development, Inc. Message-ID: <5d1j3o$blq@gaea.titan.org> References: <5cqh6k$bt5$1@news1.xs4all.nl> <5crrde$19s@dfw-ixnews8.ix.netcom.com> <32F38AB7.27ED@online.disney.com> <5d0sck$q9g@sjx-ixn7.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) wrote: > Joseph Panico <jpanico@online.disney.com> wrote: > > > 4.1 Mach PB has many, many problems. > > - It's very easy to crash. Go to classes in the project file browser, > > double > > click on a .m, then double click on a .h-- splat! > > I guess the way one works determines the PB stability experienced. I > rarely see PB crash and I spend all day every day using 4.1 PB on Mach and > NT. But I never do the above. I'm unable to duplicate this problem. > > > - I cannot find a place to set the tab-stops and the number of spaces > > per tab > > I have PB's preferences set to indent when tab is pressed, so I don't > insert tabs in my source. But this enhancement would be nice for those who > do. Check the PB release notes for the tabStopChars default; it allows what is being asked for here. > > - Find does not search into all of the Frameworks included in a project. > > That might be nice, but I'd want that to be optional behavior. As it > stands, just having the framework projects open in PB in addition to the main > project will allow the search string to be shared among all projects. So > simultaneous searches of all desired projects can be run. This is pretty > powerful. Actually (assuming you have indexing turned on), it does search all included frameworks, though it's occasionally buggy about this. I would certainly like a preference for "search these frameworks even if I don't have them included." This would let me always search Foundation, AppKit and the EOF frameworks whether I've included them in the project or not. > > - It's too integrated-- The 3.3 PB had a better, more open design. > > It feels as though NeXT is moving backwards, not forwards. > > Different strokes for different folks, I guess. I like the tighter > integration, but several important features are still missing. The former > gdb browse panel is missing. This was a very nice feature. Too many gdb > commands must be manually entered in the current PB. I too much prefer the new PB, though it does still have room for improvement. -- andrew_abernathy@omnigroup.com - NeXTmail & MIME ok
From: oure@cmfadljf.com Newsgroups: comp.sys.next.programmer Subject: CD-R Media for Sale Date: 2 Feb 1997 13:19:13 GMT Organization: Copy.Cat Shop. Message-ID: <5d248h$jct@mtinsc04.worldnet.att.net> We have the following CD-R media for sale. Brand: Pioneer Type: Printable Media (Surface is blank for printing or labels) Type: Gold on Green Size: 74 min (650 mb) Price: 6.99 Minimum Order: 10 Brand: Maxell Type: Gold on Gold Size: 74 min (650 mb) Price: 6.55 Minimum Order: 10 Brand: TDK Type: Gold on Green Size: 74 min (650 mb) Price: 6.55 Minimum Order: 10 Brand: Hewlett Packard Type Gold on Gold Size: 74 min (650 mb) Price: 7.15 Minimum Order: 10 Lifetime Warranty The Copy Cat Shop has all your CD duplication, replication, recorders, software, and media needs. If you have any questions or comments feel free to call. Cordially, The Copy Cat Shop 213-650-1680 213-650-9110 Fax
From: rbraver@ohww.norman.ok.us (Robert Braver) Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5d248h$jct@mtinsc04.worldnet.att.net> Date: 2 Feb 1997 13:24:10 GMT Control: cancel <5d248h$jct@mtinsc04.worldnet.att.net> Message-ID: <cancel.5d248h$jct@mtinsc04.worldnet.att.net> Sender: oure@cmfadljf.com Spam cancelled. Autocancel spam type: CDRMEDIA Original Subject: CD-R Media for Sale
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: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Sun, 2 Feb 1997 15:02:30 GMT Organization: Primitive Software Ltd. Message-ID: <1997Feb2.150230.1427@prim.demon.co.uk> References: <5c0ivv$ <32E64EF7.3D6A@nowhere.com> <5c7vug$4s4@csugrad.cs.vt.edu> In article <5c7vug$4s4@csugrad.cs.vt.edu> nurban@vt.edu writes: >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:)]; That's cheating. :) That only works if you've paid $5000 for the library routines to help you. My machine has "classic" Obj-C but your code snippet would produce a link failure. 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: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: Sun, 2 Feb 1997 14:50:38 GMT Organization: Primitive Software Ltd. Message-ID: <1997Feb2.145038.1341@prim.demon.co.uk> References: <32E78DAF.433F@srsys.com> <5c8j8b$10sg@flood.weeg.uiowa.edu> <5c93h6$3ur@darla.visi.com> In article <5c93h6$3ur@darla.visi.com> dwy@ace.net (David Young) writes: > >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. You must like typing. One of the worst things about OpenStep is all those horrible long method names. And whereas "drawImage" is easy to remember, how many times have you forgotten one of those long method names and typed (say) "withScaleFactor" instead of "withFloatingPointScaleFactor"? But don't tell me - there's a tool to help you. :) Dave
From: cnyap@next (Chih Nam Yap) Newsgroups: comp.sys.next.programmer Subject: How to free subviews ? Date: 2 Feb 1997 17:51:27 GMT Organization: University of Sheffield, UK Message-ID: <5d2k6v$6a@bignews.shef.ac.uk> Hi there, Can anyone tell me what is the correct way to free a hierarchy of subviews ? I have looked at view.rtf, the free method says free - free Releases the storage for the View and all its subviews. This method also invalidates the cursor rectangles for the View's window, frees the View's graphics state object (if any), and removes the View from the view hierarchy; the View will no longer be registered as a subview of any other View. I tried to free a hierarchy of subviews by using the following way [subviews free]; But my program always terminated. Do I need to perform some preparation works such as issue the "removeFromSuperview" method to each subviews before I can actually free them ? Your help is very much appreciated. Thank you. cheers, c.yap
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: 2 Feb 1997 18:29:32 GMT Organization: ace dot net internet technologies Message-ID: <5d2mec$431@darla.visi.com> References: <32E78DAF.433F@srsys.com> <5c8j8b$10sg@flood.weeg.uiowa.edu> <5c93h6$3ur@darla.visi.com> <1997Feb2.145038.1341@prim.demon.co.uk> Dave Griffiths (dave@prim.demon.co.uk) wrote: : You must like typing. One of the worst things about OpenStep is all those : horrible long method names. And whereas "drawImage" is easy to remember, : how many times have you forgotten one of those long method names and typed : (say) "withScaleFactor" instead of "withFloatingPointScaleFactor"? Five seconds of typing is better than a minute of looking stuff up. "drawImage" may be easy to remeber, but what parameters it takes sometimes is not. Draw image that's a bitmap? That's a JPEG? That's a sequence of drawing commands? With an integer scale factor? Even the class libraries that make the best use of method overloading don't accept everything as a parameter, and you wind up looking at the .h (or .java) file anyway to see what you can send it. : But don't tell me - there's a tool to help you. :) Well, of course ;) -- # 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: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: drawing bitmap to screen quickly Date: 2 Feb 97 02:40:26 GMT Organization: University of Massachusetts, Amherst Message-ID: <32f3fe9a.0@192.33.12.30> Hey there... I'm trying to get some reasonably fast animation going on a 68040 turbo color -- needless to say this will be a bit of work. The only way I know to get bitmaps to the screen is using the NXBitmapImageRep class, so I do something like the following: bitmap = [[NXBitmapImageRep alloc] initData: pixels ]; while(1) { (rearrange byte values in pixels[]) [bitmap draw]; [myWindow flushWindow]; } This setup however, only gives me about 3 frames per second in a 200 x 200 view. Along with my own code to rearrange the bytes in pixels[], I get 2 frames per second. This is simply not enough. 10 fps would be okay, but of course, the more the better. Can anybody tell me of a faster method of drawing a bitmap to the screen? -- -jon klein jklein@freon.artificial.com Caper will do it for me.
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: Re: drawing bitmap to screen quickly Date: 2 Feb 97 04:43:13 GMT Organization: University of Massachusetts, Amherst Message-ID: <32f41b61.0@192.33.12.30> References: <32f3fe9a.0@192.33.12.30> jon klein (jklein@freon.artificial.com) wrote: : bitmap = [[NXBitmapImageRep alloc] initData: pixels ]; : This setup however, only gives me about 3 frames per second in a : 200 x 200 view. Along with my own code to rearrange the bytes in : pixels[], I get 2 frames per second. This is simply not enough. : 10 fps would be okay, but of course, the more the better. Sorry to follow up to my own post, but the first example was with planer data. I get about 12 fps with meshed. Why is this, and are there any more hints to get faster animation? -- -jon klein jklein@freon.artificial.com Caper will do it for me.
From: Dru Nelson <dnelson@slip.net> Newsgroups: comp.sys.next.programmer Subject: Re: Help... [CD ROM on next]... Date: 3 Feb 1997 00:26:13 GMT Organization: Slip.Net Message-ID: <5d3bb5$rsq$1@news1.slip.net> References: <5crhap$a58$3@news.cc.umr.edu> Hi, Please post to the proper newsgroup. Thanks. Sanjeev Agarwal <sanjeev@ee.umr.edu> wrote: > 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: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer Subject: Re: MacWorld Exculsive: Apple's OS Plan Unveiled!!! Date: 2 Feb 1997 17:43:04 -0800 Organization: Electronics Service Unit No. 16 Sender: mpaque@mpaque Distribution: world Message-ID: <5d3fr8$bp@mpaque.mpaque> References: <32EE9DD1.4A9B@netscape.com> In article <32EE9DD1.4A9B@netscape.com> David Matiskella <davidm@netscape.com> writes: > 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. Done. NeXTSTEP and OPENSTEP/Mach are set up to do this by default (No login window by default). > Why don't we debate the really important questions like "How many > buttons is the mouse going to have?" One. (Two on NeXT hardware, but they do the same thing by default.) > or "How many CLI programs will > barf upon seeing mac file names with / and space in them?" None, if they're properly written and invoked. NeXTSTEP and OPENSTEP/Mach permit spaces in names. The filesystem code for foriegn filesystems performs an idempotent mapping of the path partitioning character, so ':' versus '/' (Mac vs. Unix) isn't a problem in real life. -- I don't speak for my employer, whoevere it is, and they don't speak for me. mpaque@next.com Official business only NeXT Mail OK mpaque@wco.com Non-business or personal mail NeXT mail OK
From: bbum@friday.com (Bill Bumgarner) 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) Message-ID: <32EB969C.72DA@friday.com> Date: 26 Jan 97 17:38:36 GMT 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> Organization: Demiurge Development Group 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
Newsgroups: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system From: hans@vuur (Hans Mulder) Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Message-ID: <E50s35.48x@icgned.nl> Followup-To: comp.sys.next.programmer,comp.sys.next.advocacy,comp.sys.mac.advocacy,comp.sys.mac.system Sender: news@icgned.nl Organization: IC Group 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> Date: Mon, 3 Feb 1997 09:09:05 GMT In <5bonbb$6r4@news.internetmci.com> Rajnish Dogra (rdogra@mailserv.metro.mci.com) 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. No. With OPENSTEP for NT, NeXT ships some Unix utilities, not all of them. Terminal.app is not part of the package. You can run a slightly souped-up Bourne shell in a command.com window; csh and zsh are not included. -- HansM
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: Mon, 03 Feb 1997 10:30:22 +0100 Organization: Microcomp GmbH , Cologne, Germany Message-ID: <32F5B02E.3EB1@microcomp.de> References: <5cqh6k$bt5$1@news1.xs4all.nl> <32F1BD3B.25CB@microcomp.de> <5cubuf$ibm@sjx-ixn6.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > You are making an assumption that Rhapsody == OS 4.1 which I'm certain > will be false. NeXT made huge numbers of changes in moving from NS to OS. > They did it essentially in one step (OS existed in a minor way in NS 3.3). > The rate of change from 4.0 to 4.1 suggests that 4.2 will be quite good. > Rhapsody will follow even later so should benefit even more. > -- > Art Isbell No, I don't make assumption that Rhapsody will be bad. But I don't like dream's about nice future with Rhapsody when NOW you must develop with Openstep. Rhapsody will be completely new chapter - new and bigger project resources but also new technological problems. It is dificult to say when STABLE and USABLE Rhapsody will be available. Sorry , I dont want start new discussion about Rhapsody. I would like discuss in this newsgroup concrete problems with Openstep or Nextstep programming. Petr Novak
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer Subject: Re: Broken Pipe? Date: 3 Feb 1997 11:25:10 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5d4hum$np@netty.york.ac.uk> References: <5co1u2$kpn$1@inet-prime.comshare.com> On 29 Jan 1997 17:38:10 GMT, alanf@izzy.net <alanf@izzy.net> wrote: > 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: there are all sorts of potential problems with this approach; the processes could be deadlocking, something might be writing down a pipe to a dead process (broken pipe), DPSWatchFD might not be called when you expect it to be... without a more complete sample of your code, there's very little way of finding out which is the actual problem, however. cheers, rog.
Date: Mon, 03 Feb 1997 06:41:03 -0600 From: amas@lhr-sys.dhl.com Subject: Library Headers Newsgroups: comp.sys.next.programmer Message-ID: <854973058.17599@dejanews.com> Organization: Deja News Usenet Posting Service I would like to get hold of the header files for programming OpenStep. More specifically does anybody have a list of the Display Postscript routines and data types? Is there a place at NeXT where I can find this stuff? Thanks (Please email me a copy of your reply) Andre-John -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Re: Master-Detail-Relationship problems Date: Mon, 03 Feb 1997 10:40:33 +0100 Organization: Microcomp GmbH , Cologne, Germany Message-ID: <32F5B291.196E@microcomp.de> References: <5cva49$oao@news.Dortmund.Germany.EU.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thomas Richter wrote: > > Hi all, > i am using NEXTSTEP 3.3 and Developer and EOF 1.1 with installed > Patches on Intel Hardware and Sybase Databases. With EOF 1.1 I cannot > use Master-Detail-Relationships (no fetchs of detail records when > selecting a record in the master table). Master-Peer-Configurations > work fine. I had the same problem on 4.0 and EOF 1.1. EOF automatically set some false delegate, which caused this problem. I cannot exact remember, but it was something like EOAssociation was set to delegate of TableView. Petr Novak
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: Mon, 3 Feb 1997 08:19:45 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Distribution: comp Message-ID: <4mxSLlq00iWUI108t7@andrew.cmu.edu> References: <SHESS.97Jan30142225@howard.one.net> In-Reply-To: <SHESS.97Jan30142225@howard.one.net> Excerpts from netnews.comp.sys.next.programmer: 30-Jan-97 "static inline" methods wou.. by Scott Hess@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: What you are asking for, "static inline functions", means that the compiler has to make all decisions at compile time, and that you therefore cannot rely on any dynamic properties of the runtime, like dynamic method invocation, or subclassing, etc-- but that's what you want, to avoid the overhead of objC_msgSend. This is what Java does when it sees the "final" keyword. Given that this is the case, why not simply use C macros to inline -elementAt: directly and let the compiler optimize from there? In fact, this allows you to also provide a real method implementation which could be used dynamicly by subclasses if needed, but you could use the macro version whenever you know that it's okay.... -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, 03 Feb 1997 11:42:02 -0500 Organization: SoftArc Inc. Message-ID: <maury-0302971142030001@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-290 <5ctrsf$j2@geraldo.cc.utexas.edu> In article <5ctrsf$j2@geraldo.cc.utexas.edu>, raph@porter.as.utexas.edu (William Raphael Hix) wrote: > 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. Copeland's method for this was to simply return different fid's for the Preferences folder. As long as no one hard wired the folder locations (and that should not be an issue) it would have worked great. > 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. The problem I have with this is that Unix file permissions, like Mac ones, are terribly behind the times. I'd prefer a ACL based system on ALL objects, not just file system ones, and the disappearance of the current user/group/world permissions. I'd also like to see true central authority for this, Kerberos being the obvious one, perhaps even NT's Domains could be an option. This would make the new OS slip into a LOT more corporate networks. Say what you will about it's administration, but NT's network concepts do help the average admin quite a bit. Maury
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: cancel <32f41b61.0@192.33.12.30> Control: cancel <32f41b61.0@192.33.12.30> Date: 2 Feb 97 13:34:15 GMT Organization: University of Massachusetts, Amherst Message-ID: <32f497d7.0@192.33.12.30> Article cancelled from within tin [v1.2 PL2]
From: jklein@freon.artificial.com (jon klein) Newsgroups: comp.sys.next.programmer Subject: cancel <32f3fe9a.0@192.33.12.30> Control: cancel <32f3fe9a.0@192.33.12.30> Date: 2 Feb 97 13:34:19 GMT Organization: University of Massachusetts, Amherst Message-ID: <32f497db.0@192.33.12.30> Article cancelled from within tin [v1.2 PL2]
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Date: 3 Feb 1997 15:17:49 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5d4vit$np@netty.york.ac.uk> References: <5ami95$ol3@news.tuwien.ac.at> <32D5DFF0.2FB4@surf.net.au> <mckinnon-1001970053450 <maury-3001971147180001@199.166.204.230> On Thu, 30 Jan 1997 11:47:18 -0500, Maury Markowitz <maury@softarc.com> wrote: > 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. your logic doesn't necessarily hold true here, i'm afraid. an OS that places more limitations on the user in terms of document and file placement might easily be a more flexible OS in general terms. consider the road system, for instance. drivers are restricted from driving in the wrong side of the road. does this make the road system a less flexible system in general ? no, because this very restriction allows drivers to assume that people going in the opposite direction will not be heading for a head-on collision, thus making the system *more* flexible in general, as drivers can concentrate on the task of driving from A to B, without worrying about dodging oncoming traffic. in the same way, some restrictions on the user can be useful and warranted if they aid users in accomplishing their tasks unencumbered by unexpected contingencies. this isn't to say that the unix file system is perfect by any means. there is no real reason why *all* the system related files can't be moved into (say) /system and subdirectories thereof, leaving the rest of the filesystem open to user havoc. arguments of "unix standardness" are spurious, because any portable unix program will not make assumptions about pathnames, as they are not a truly standard part of unix. for instance, /usr once contained only user accounts. /usr/etc (where the net daemons reside) and /usr/bin are relics of decades old hacks by Sun et al, and could easily be abolished in a new operating system from Apple, with only very minor changes to unix system programs. cheers, rog.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: drawing bitmap to screen quickly Date: 3 Feb 1997 19:09:15 GMT Organization: Global Objects Inc. Message-ID: <5d5d4r$t2l@news.xmission.com> References: <32f3fe9a.0@192.33.12.30> <32f41b61.0@192.33.12.30> jklein@freon.artificial.com (jon klein) wrote: > jon klein (jklein@freon.artificial.com) wrote: > > : bitmap = [[NXBitmapImageRep alloc] initData: pixels ]; > > : This setup however, only gives me about 3 frames per second in a > : 200 x 200 view. Along with my own code to rearrange the bytes in > : pixels[], I get 2 frames per second. This is simply not enough. > : 10 fps would be okay, but of course, the more the better. > > Sorry to follow up to my own post, but the first example was with planer > data. I get about 12 fps with meshed. Why is this, and are there any more > hints to get faster animation? Because the screen RAM on a Color slab is meshed. If you start with planar data, the DPS interpreter has to convert it to meshed before copying it to the screen. You want to render such that DPS will have to do as little work as possible to get the data to the screen. For the best speed, read the DPS release notes and performance notes that come with the NEXTSTEP documentation. What you want to do is to *exactly* match the buffer's layout to the screen RAM's layout (meshed vs. planar, bits per pixel, etc.) and then, on slabs, if your buffer is the right *width* (there's a complex formula in one of the performance notes) you'll get an extra boost. This is all very hardware dependent, but it is the same thing you'd have to do with Interceptor. (So you may want to make different drawing routines to deal with various buffer geometries to match different hardware platforms, for example.) In fact, because of the width thing (DPS notices an "optimal" width and does a special machine instruction for a wider copy when it sees it) it is harder to beat DPS when using Interceptor on color slabs without dropping into asm code yourself... I'd elaborate more on details, but I'm short on time right now-- at least the above should point you in the right direction. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.next.programmer Subject: Accessing Serial Ports under OpenStep Date: Mon, 03 Feb 1997 12:01:18 -0500 Organization: TofuSoft Message-ID: <jchan-ya023580000302971201180001@news.apk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Is it possible to access serial ports under OpenStep? I've got OpenStep/NT and I can't seem to find anything that allows me to talk to a serial port. --- The Evil Tofu (Only Human)
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: How to free subviews ? Date: 3 Feb 1997 20:56:00 GMT Organization: Rockwell Avionics - Collins Message-ID: <5d5jd0$nur@castor.cca.rockwell.com> References: <5d2k6v$6a@bignews.shef.ac.uk> Cc: cnyap@next I> > [subviews free]; This line of code frees the View's List of subviews...not the subviews themselves!
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Re: New User/Developer Date: 3 Feb 1997 01:29:38 GMT Organization: MHPCC Message-ID: <5d3f22$e1s@kaopala.mhpcc.edu> References: <AF1839F8-5E8A0@206.101.238.36> <5cuq61$3nn@news.digifix.com> <5cuvm9$lb4@news.istar.ca> Cc: jsamson@istar.ca In <5cuvm9$lb4@news.istar.ca> Jean-Paul C. Samson wrote: > >>I dug right into the Developer tutorial and have come across an > >>anomaly that is probably very easy to remedy and I look for your > >>advise. In the Currency Exchange tutorial on page 27 they direct me > >>to drag the NSReturnSign icon from the nib file window onto the > >>Convert button, but there is no NSReturnSign icon in the nib file! > >>What did I do wrong, or better yet, how can I get that icon to show > >>up? > > They took out the return sign icon. Instead, the default button now > has a thick black bezel, like Windows. > > Sadly, the Developer Tutorial book is filled with inaccuracies. They > didn't do a very good job proofreading and testing the book. Maybe > NeXT just ran out of time in preparing for the OPENSTEP 4.0 release. > The book will give you a good idea of how to go about programming > OPENSTEP applications, but don't expect the resulting programs to work > very well. > > It sure looked like NeXT had developed a bad case of Windows Envy before losing interest in OpenStep and focusing on WebObjects. The 4.0 beta borrowed a number of things from Windows95---blue window bars, window open/close buttons on the right, the fat button meaning carriage return, instead of the right angle arrow symbol. It was very dismaying to see. A loss of nerve. I'd like to see a Return of the Return! -- ======================================================================= 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: gvandyk@icon.co.za Newsgroups: comp.sys.next.programmer Subject: LU6.2 Interface Date: 4 Feb 1997 09:39:57 GMT Organization: E.S. Systems cc (Financial Systems Development) Message-ID: <5d705d$27b@hermes.is.co.za> We need to communicate to MVS using LU6.2. Has anyone done this before and what is involved in doing this? Any help would be greatly appreciated -- Regards, Gerrit van Dyk email: gvandyk@icon.co.za (NeXTMail welcome) E.S. Systems cc The OBJECT is the ADVANTAGE
From: boudra@cimac-res.univ-lyon1.fr (Abdel BOUDRAA) Newsgroups: comp.sys.next.programmer Subject: How to Display an image on NeXT station???? Date: 4 Feb 1997 11:39:07 GMT Organization: UCBL Message-ID: <5d774r$75j@tempo.univ-lyon1.fr> Mime-Version: 1.0 Content-Type: Text/Plain; charset=ISO-8859-1 Hello, Can anyone tell me where I can find a sample code to display an image(8Bits, 256x256) using NXImage classe. Thanks in advace, ----------------------------- A. BOUDRAA Faculte RTH Laennec Lyon France E-mail:boudra@cimac-res.univ-lyon1.fr
From: "Mark Jenkins" <markj@inwave.com> Newsgroups: comp.sys.next.programmer Subject: Re: Tutorial Question Date: 5 Feb 97 01:12:02 -0600 Message-ID: <AF1D8EEB-14415B@206.101.238.21> References: <5d8j5q$he2@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> On Tue, Feb 4, 1997 6:10 PM, mmalcolm crawford <mailto:m.crawford@shef.ac.uk> wrote: >Difficult to know exactly without seeing the code... I presume you're doing >something like sending a setFloatValue: message to your text field? Are you >sure the parameter is correct? Could you post (or email) the relevant code >snippet? > >Best wishes, > >mmalc. I appreciate your help immensely! :-) Well, as usual I decided to start from scratch. What do they say? Repetition? Anyway The NaN is gone and now I am not receiving anything. gdb tell's me: Feb 5 00:27:46 CurrencyConverter[23068] *** -[Converter convertAmount:byRate:]: selector not recognized When I click the convert button I get the above twice in gdb. The following code was type in directly from the tutorial .... Is spacing critical? They do not say anything about it in the manual. -----------------------------------------------Converter.h------------------------------------------ #import <AppKit/AppKit.h> #import <Foundation/Foundation.h> @interface Converter : NSObject { } - (float)convertAmount:(float)rate byRate:(float)amt; @end -----------------------------------------------Converter.m------------------------------------------ #import "Converter.h" @implementation Converter - (float)convertAmount:(float)amt: byRate: (float)rate { return (amt * rate); } @end ----------------------------------------------- ConverterController.h------------------------------------------ #import <AppKit/AppKit.h> @interface ConverterController : NSObject { id converter; id dollarField; id rateField; id totalField; } - (void)convert:(id)sender; @end -----------------------------------------------ConverterController.m------------------------------------------ #import "ConverterController.h" #import "Converter.h" @implementation ConverterController - (void)convert: (id)sender { float rate, amt, total; amt = [dollarField floatValue]; rate = [rateField floatValue]; total = [converter convertAmount:amt byRate:rate]; [totalField setFloatValue:total]; [rateField selectText:self]; } - (void)awakeFromNib { [rateField selectText:self]; [[rateField window] makeKeyAndOrderFront:self]; } @end
From: woody@alumni.caltech.edu (William Edward Woody) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 04 Feb 1997 23:13:41 -0800 Organization: In Phase Consulting Message-ID: <woody-0402972313420001@192.0.2.1> References: <5d8qta$6np@news.bu.edu> In article <5d8qta$6np@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > Let me say it more simply: as much as you and I find perverse > joy in the nooks and crannies of a Unix world: > > *** MAC USERS WILL NEVER ACCEPT UNIX *** > > and that's all there is to it. And guess what, there are about > 19 million more "Mac users" than there are "techies who like > Macs but secretly wish they could grep sometimes." First, take a deep breath, and relax. The sky isn't really falling, as much as it seems like it. Second, let me note that I was also concerned with the idea of having a Unix kernel underlying the MacOS--as soon as such a thing hit the shelves it wouldn't be long before someone did 'tsh', at which point, we may as well have simply exposed people to the shell. See, to me the beauty of the Mac experience was to force us tech-heads out of the CLI-driven obscure filter applications and find a new computing paradigm and program interface which was suitable to the idea of a computer as an appliance (as opposed to a computer as a souped-up card batch processing engine). Don't get me wrong: NeXT's Interface builder, the object oriented mechanism for building complex and intuitive user interfaces, was also a godsend--it assisted in getting the much more user-centric applications off the ground. But it was the Macintosh which first forced us into that mold--by being the first mass-produced computer system which was WYSIWYG and windowing-driven. But get this: Mach is *NOT* Unix. Mach has been used to build a Unix compatable OS, and most people tend to build off of a Unix client built on top of the Mach kernel because that's what most of us programmers are familiar with. But ultimately, using the Mach kernel does not mean the Macintosh will operate as a layer on top of Unix. Instead, it means Apple will more likely create various OS "servers" which service operating system calls in the same way the Unix server operates. In fact, I suspect both the "yellow box" and the "blue box" are really just Mach servers providing different operating system personalities. And it means that the yellow box containing the NeXTStep API could contain the unix servers which make many elements of NeXTStep work, yet not force the personality of Unix system-wide. (Sort of like the Posix personality module you were talking about--just because it exists doesn't mean the file system mounts disks a'la Unix, or the boot process requires a /etc/rc script to be executed.) Heck, I would even *welcome* such a personality module: sometimes it would be nice to be able to compress or decompress files behind the scenes in my application by simply calling 'system("uncompress file.Z")', instead of having to deal a bunch of AppleEvents to do the same thing. - Bill -- William Edward Woody - In Phase Consulting - woody@alumni.caltech.edu http://www.alumni.caltech.edu/~woody
From: scottm@nic.com (Scott) 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, 05 Feb 1997 04:09:26 -0500 Organization: PETA (People for the Eating of Tasty Animals) Message-ID: <scottm-ya02408000R0502970409260001@news.erols.com> 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 <5ctrsf$j2@geraldo.cc.utexas.edu> <maury-0302971142030001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <maury-0302971142030001@199.166.204.230>, maury@softarc.com (Maury Markowitz) wrote: >> 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. > > Copeland's method for this was to simply return different fid's for the >Preferences folder. As long as no one hard wired the folder locations >(and that should not be an issue) it would have worked great. > Well there go the M$ applications. :-) -- -------------------------------------------------------------------------- Scott Maxwell - scottm (at) nic (dot) com "The Mac is plug and play, Windows is plug and pray." David Forte Technology Manager (TIME Magazine) "Reports of my death have been greatly exaggerated" - Mac Twain
From: shess@one.net (Scott Hess) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 4 Feb 97 11:21:12 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb4112112@slave.one.net> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> In-reply-to: Charles William Swiger's message of Mon, 3 Feb 1997 08:19:45 -0500 In article <4mxSLlq00iWUI108t7@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> writes: Excerpts from netnews.comp.sys.next.programmer: 30-Jan-97 "static inline" methods wou.. by Scott Hess@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: What you are asking for, "static inline functions", means that the compiler has to make all decisions at compile time, and that you therefore cannot rely on any dynamic properties of the runtime, like dynamic method invocation, or subclassing, etc-- but that's what you want, to avoid the overhead of objC_msgSend. This is what Java does when it sees the "final" keyword. Given that this is the case, why not simply use C macros to inline -elementAt: directly and let the compiler optimize from there? In fact, this allows you to also provide a real method implementation which could be used dynamicly by subclasses if needed, but you could use the macro version whenever you know that it's okay.... I've certainly done that in the past. First problem is simply aesthetic - method calls should look like method calls. It's sort of like using a macro to act like a static inline function - if you had to change the interface to do it, it becomes much less attractive. Perhaps a bigger problem, though, is that changing to a macro (or static inline function) requires you to change the usage sites, rather than the definition. This requires significantly more work, and you want to be pretty sure of the benefits before doing it. [If you immediately want to back out, it's easy, but as you layer other code on top of that, you start working yourself into a corner.] Besides, quite frankly, I'd want the compiler handling this in order to help warn me about errors. With the compiler handling the inlining, it can easily warn me about a subclass which overrides the inlined method - using a macro or static inline function will give me no warning if I'm using it on a subclass. Admittedly, it can't give complete coverage, but it should be able to give warning when compiling a subclass that overrides such a method, or when dispatching the method to such a subclass. 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: "Mark Jenkins" <markj@inwave.com> Newsgroups: comp.sys.next.programmer Subject: Tutorial Question Date: 4 Feb 97 13:16:36 -0600 Message-ID: <AF1CE740-3F5BCF@206.101.238.18> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit As I stated in earlier posts, I am brand new to Unix, C and OPENSTEP. So far I love it! I am starting to learn the Project Builder and Interface Builder and have come accross a problem that is probably a very simple (ie. stupid mistake?) fix. In the first app Currency Converter I get a successfull build and compile. However, when I click the Convert Button the result that is placed in the "Amount in Other Currency" field displays :NaN (What does this indicate?) What did I do wrong? TIA Mark markj@inwave.com
Newsgroups: comp.sys.next.programmer From: "Scott W. Bradley" <scottwb@cs.washington.edu> Subject: NeXT Semaphores? help... Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: news@beaver.cs.washington.edu (USENET News System) Organization: Computer Science & Engineering, U of Washington, Seattle Message-ID: <Pine.ULT.3.91.970204142535.17504A-100000@grizzly.cs.washington.edu> Mime-Version: 1.0 Date: Tue, 4 Feb 1997 22:28:35 GMT I have a program that compiles on various other flavores of unix that uses system semaphores. It does not compile on nextstep though. I get things like "key_t" undefined. Alos, I can't even locate a header file that I usually use called <sys/sem.h>. I can't seem to find procedures like semget(). Can anybody please give any advice on how to get this to work? Help greatly appreciated -scott +-----------------------+-----------------------------------------+ | Scott W. Bradley | Home: 206.485.4142 | | 14128 NE 181st PL | Work: 206.685.2167 | | Apt. # K205 | mailto:scottwb@cs.washington.edu | | Woodinville, WA 98072 | http://weber.u.washington.edu/~scottwb/ | +-----------------------------------------------------------------+
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 19:11:15 GMT Organization: Cygnus Solutions Message-ID: <5dam0j$bd1$4@majipoor.cygnus.com> References: <5d8qta$6np@news.bu.edu> Cc: macintsh@bu.edu In <5d8qta$6np@news.bu.edu> John Siracusa wrote: > You want Unix? Buy MkLinux! Just one last little comment.. Your assertion here seems to equate Nextstep with any other flavor of Unix, such that there is even a meaningful comparison of Mklinux to Nextstep for those who want unix functionality. The ignorance contained in just those 2 sentances (not to mention the entire rest of your post) is dumbfounding. It is as logical to advocate this sort of attitude as it would be for someone to tell you that you should switch from your Mac to Dos/Win3.0. The scale of difference between Dos + Windows 3 and the Mac is the same scale of difference between any other flavor of Unix (with or without Mach) + X and Nextstep. -- 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: "Jonathan W. Hendry" <jon@subsequent.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, 05 Feb 1997 14:49:22 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32F8E442.118B@subsequent.com> 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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim Streater wrote: > > In article <AF17D80E96687E79C@node23.tfs.net>, tbutler@tfs.net (Travis > Butler) wrote: > >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. > > Sad, isn't it, that some people still don't get this. Nerds are frightened > by this philosophy, though. And yet, Apple themselves realized that some order was in order, and added some structure to the System folder. Evidently, they figured out that some structure is a good thing. Whaddya guys want, Windows-style file chaos? Bleah. -- jon@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: 4 Feb 1997 22:59:49 GMT Organization: University of Sheffield, UK Message-ID: <5d8f15$fvt@bignews.shef.ac.uk> 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> <5co5ja$lv8@geraldo.cc.utexas.edu> In-Reply-To: <5co5ja$lv8@geraldo.cc.utexas.edu> [followups trimmed] Sorry this is a bit old now, however I'm just starting to read news again and couldn't see that this had been addressed: On 01/29/97, William Raphael Hix wrote: > 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). > Umm, hang on a moment... ls ~/Apps 3DReality.app OmniPDF.app Astraloids.app OmniWeb.app Babble OpenWrite.app BeYap.app Opener.app C2Converter.app PageChoice.app CATculator.app Palette.app CedarWord.app ParaSheet.app ComponentEditor.app PasteUp.app Concurrence.app PencilMeIn.app Quantrix.app ConvertSelection.app RBrowser.app Create.app RZToDoList.app Diagram.app SplitBuilder EditSound.app SuperDraw.app Eloquent.app TIFFany2.app Encipher.app Tailor.app FrameMaker.app TaskMaster.app GifOmatic.app Thinner.app HNNews.app ToyViewer.app Jargon.app Twister.app LatinByrd.app VarioBuilder.app LaunchBar.app VarioData.app Mail.app WebMapper.app Mesa.app WebUp.app WetPaint.app Workbench.app Morph.app WriteUp.app MusicBuilder-1.0-Prerelease eXTRAPDF_Beta2.rtfd NewsFlash.app soundCheck.app OmniImage.app and there are a number of other apps I'd like to buy if I could afford it, and some I have bought but don't use at the moment and don't have disk space for (I'm almost up to my 1GB quota... <sigh>). When you say "relatively few", I think I know what you're getting at -- there are not thousands of NEXTSTEP applications all competing in the same market sector as there are with, say Windows (i.e. the remainder of the market not swamped by Micro$oft), however there are still plenty of good quality shrinkwrap productivity apps available (I've got about 6 word-processor-type apps) -- I most certainly do *not* "depend heavily on the core set of utilites which are part of the OS and their Unix derived apps". This next point has rather been overtaken by events, however with full 20/20 hindsight I'd say: > 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?" > I think -- given AppLE's current need to get the system out of the door and on developers' desks -- the question is more like "How much will Rhapsody be like OpenStep/Mach, given how much it'll cost to make it *not* so?" Best wishes, mmalc. --
Newsgroups: comp.sys.next.programmer From: fgalot@x-lan.alienor.fr Subject: How positionning tab stops? Message-ID: <E5525C.84s@x-lan.alienor.fr> Sender: news@x-lan.alienor.fr Organization: x&lan Date: Wed, 5 Feb 1997 16:36:48 GMT I've tried : int i; NXTextStyle *deftStyle; NXTabStop *tabList; deftStyle=[self defaultParaStyle]; tabList=deftStyle->tabs; nbTab=deftStyle->numTabs; for(i=0;i<nbTab;i++) { [self changeTabStopAt:(tabList+i)->x to:longMax*(i+1)]; } AND : int i; NXTextStyle *deftStyle; NXTabStop *tabList; deftStyle=[self defaultParaStyle]; tabList=deftStyle->tabs; nbTab=deftStyle->numTabs; for(i=0;i<nbTab;i++) { (tabList+i)->x=longMax*(i+1); } [self setParaStyle:deftStyle]; But no way......... -- --------------------------------------- ź ź | ź O_O ź ź | O_O -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fred Galot fgalot@x-lan.alienor.fr
From: robert@visgen.com (Robert Osborne) Newsgroups: comp.sys.next.programmer Subject: Re: Loads of bugs in Developer 4.0/Mach Date: 5 Feb 1997 11:21:58 -0500 Organization: Visible Genetics Inc. Message-ID: <5dac36$bps@knuth.visgen.com> References: <5cqh6k$bt5$1@news1.xs4all.nl> <5crrde$19s@dfw-ixnews8.ix.netcom.com> <32F38AB7.27ED@online.disney.com> Joseph Panico <jpanico@online.disney.com> wrote: >4.1 Mach PB has many, many problems. Tell me about it! Has anybody heard back from NeXT? I've submitted half a dozen or more bugs so far ... >- It's very easy to crash. Go to classes in the project file browser, >double click on a .m, then double click on a .h-- splat! Interesting. What happens to me is that suddenly there is no key window. Almost like it wants to open a new window but can't ... My favourite bug is that if I go to a block of code and type: /* and hit return PB crashes! Not always - seems to be dependant upon the code above that line (I think the autoformater is bailing ...) >- I cannot find a place to set the tab-stops and the number of spaces > per tab You have to set the preference "ProjectBuilder TabStopChars 4" outside of PB and rerun. Rob. -- Robert A. Osborne, robert@visgen.com "It's now safe to turn off your computer."
From: "Bill Keller" <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer Subject: Printing under Openstep Date: 4 Feb 1997 23:44:38 GMT Organization: Oklahoma State University, Stillwater OK Message-ID: <01bc12c3$95adcf90$06254e8b@carcosa> I've got Openstep 4.1 for NT, and have written several small utilities for work. When I got to the report printing section, I discover that Openstep won't work with non-postscript printers. Wha?! I had assumed Openstep for NT would just go through the NT printmanager. Does anyone have any experience with this, or a workaround? Under Nextstep 3.3, I used JetPilot to print to my inkjet. It was awfully slow, but it worked. Is there a similar emulation driver for NT, or am I stuck buying a postscript printer? BTW, anyone use JetPilot under Openstep for Mach? Does it still work? -- Bill Keller (kellerw@okstate.edu)
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer Subject: Re: WM Inspector Question... Date: 5 Feb 1997 00:02:52 GMT Organization: University of Sheffield, UK Message-ID: <5d8inc$hcp@bignews.shef.ac.uk> References: <5cgjaq$9g7@news.iastate.edu> <5cihg4$fsr@castor.cca.rockwell.com> <5ck5so$lor@news.iastate.edu> In-Reply-To: <5ck5so$lor@news.iastate.edu> On 01/28/97, ??? wrote: > On 01/27/97, Erik M. Buck wrote: > >In <5cgjaq$9g7@news.iastate.edu> ??? wrote: > >> 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. > > > 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? > Shouldn't be... What version of NEXTSTEP are you using? Do you have any code you could send? Best wishes, mmalc. --
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer Subject: Re: Tutorial Question Date: 5 Feb 1997 00:10:34 GMT Organization: University of Sheffield, UK Message-ID: <5d8j5q$he2@bignews.shef.ac.uk> References: <AF1CE740-3F5BCF@206.101.238.18> In-Reply-To: <AF1CE740-3F5BCF@206.101.238.18> On 02/04/97, "Mark Jenkins" wrote: > As I stated in earlier posts, I am brand new to Unix, C and OPENSTEP. > > So far I love it! > Good-oh! :-) > However, when I click the Convert Button the result that is placed in the > "Amount in Other Currency" field displays :NaN (What does this indicate?) > "Not a Number" > What did I do wrong? > Difficult to know exactly without seeing the code... I presume you're doing something like sending a setFloatValue: message to your text field? Are you sure the parameter is correct? Could you post (or email) the relevant code snippet? Best wishes, mmalc. --
Newsgroups: comp.sys.next.programmer,comp.sys.mac.system From: cdouty@netcom.com (Chris Douty) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Message-ID: <cdoutyE55ILD.KvJ@netcom.com> Summary: Hardly! Organization: Netcom On-Line Services References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> Date: Wed, 5 Feb 1997 22:32:01 GMT Sender: cdouty@netcom4.netcom.com In article <rang-0502971231490001@margaret.trillium.adaptec.com>, Anton Rang <rang@trillium.adaptec.com> wrote: > Well, yes and no. While I agree that it's possible to build a decent >GUI for *file management* on a UNIX system, there are a lot of operations >a user can do on MacOS today which couldn't easily be done in a UNIX >environment without major changes. > > Consider double-clicking a document. How do you know which program to >launch? HFS provides the type and creator, which together with the >desktop database define both the default application as well as a list of >other applications which know how to open the file. Typical UNIX file >systems don't have this information available to them, [snip] You've NEVER used a NeXT, have you? NeXTstep and OpenStep for Mach (the current incarnation) and NOT typical Unix systems. Stop the FUD frenzy! When I double-click on an icon in the Workspace Manager, the prefered application for that file-type opens the file. If I want to use a different application, I open an inspector which presents me a list of all installed applications which can open that file-type. Drag-and-drop "just works," too. Relax, Rhapsody will be better than you can imagine. -Chris -- Christopher Douty - Rogue Engineer trapped in a land of software cdouty@netcom.com "Frequently the messages have meaning; that is they refer to or are correlated according to some system with physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem." -Shannon
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 02:22:34 GMT Organization: Boston University Message-ID: <5d8qta$6np@news.bu.edu> Jeez, I just read that 200+ post thread in c.s.next.programmer about "ripping Unix out" of NeXTSTEP. I really don't think that Apple is going to end up with "Unix with a GUI on top" at the end of their Rhapsody development. Now I know most NeXT users love Unix. I know it's fun to tar -cf - Papers | rsh pooh tar -xf - instead of using Apple file sharing, but the plain fact is: that has never been a part of the Mac OS experience. There are millions of Macs out ther, and the common thread among them is that they don't require that type of thing! They run Photoshop, Electric Image, PageMaker, and WordPerfect. They *don't* run xdmcp, biod, rcp, emacs, vi, gcc, ld, troff, and mv. Further, you CANNOT hope to get the current millions of Mac users to replace their OS with an OS that acts like Unix! And believe me, no matter how much you "hide" the unix, it'll never be "like a Mac" to those millions of users. On a Mac, icons do not "represent" or "point to" or "indicate" your files. They *ARE* your files. That icon *IS* your disk drive. That just isn't going to happen in the world of Unix. And why *should* Apple keep *any* vestiges of Unix? All they have to do is use a modern kernel with a modern API. Everything else is an implemntation. Add a POSIX sublayer, if you want. But there will be none of this /usr/bin foolishness. A huge Unix tree of libraries and executables is simply not revelant in an operating system that uses a MetroWerks development environment and a Finder-like program for file manipulation. Hell, even most modern Unix users and admins forego the soup of two-letter shell-script-invoked untilities for a more full-featured and reliable tool: perl You want Unix? Buy MkLinux! You want Unix in Rhapsody? Write your own mini-Unix on top of the POSIX subsystem. Recompile tcsh, mv, rm, cp, and friends, and away you go! Hell, I've got a full Unix user environment on my SE/30 via MacMint, an implementation of an Atari Unix, of all things. Filename completion, command-line magic, perl, the works. There's no reason a suitably insane person couldn't add this to his Mac. But there's no reason a SANE Apple would compromise it's 12 year old operating system and UI philosophy to keep it in its next- generation OS! Yes, it may be in there initially. But you can bet your booty that they'll remove it as soon asn they get the chance. Don't get me wrong. Although I've owned a Mac since the 128k, I'm an avid Unix user. Unix was the first platform I programmed for, and I use it every day. But my Mac is my Mac. If I wanted an OS on my desk at home in which I could cp my .cshrc to ~blee I would be running Linux. Let me say it more simply: as much as you and I find perverse joy in the nooks and crannies of a Unix world: *** MAC USERS WILL NEVER ACCEPT UNIX *** and that's all there is to it. And guess what, there are about 19 million more "Mac users" than there are "techies who like Macs but secretly wish they could grep sometimes." -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: jude@smellycat.com (Jude Giampaolo) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.advocacy Date: Tue, 04 Feb 1997 23:01:48 -0500 Organization: CyberDrugs Message-ID: <jude-0402972301480001@jcg161.rh.psu.edu> References: <5d8qta$6np@news.bu.edu> In article <5d8qta$6np@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > > *** MAC USERS WILL NEVER ACCEPT UNIX *** Yes they will. As long as it is an "extra feature" rather than a primary part of the user experience. I hate to say it, but sort of like the way Win95 sits on top of DOS. (But better of course....) -- Jude Giampaolo -- Penn State University -- Electrical Engineering jcg161@psu.edu - jude@smellycat.com - http://prozac.cwru.edu/jude/
From: bbennett@unixg.ubc.ca (Bruce Bennett) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 4 Feb 1997 20:30:10 -0800 Organization: University of British Columbia Message-ID: <19970204203010615609@port09.annex3.net.ubc.ca> References: <5d8qta$6np@news.bu.edu> John Siracusa <macintsh@bu.edu> wrote: > On a Mac, icons do not "represent" or "point to" or "indicate" > your files. They *ARE* your files. That icon *IS* your disk > drive. I hadn't realized this. Hell, who needs Plug-and-Play when we Mac folk can replace a disk drive with a mere Cut-and-Paste operation? :^) > You want Unix? Buy MkLinux! You want Unix in Rhapsody? Write > your own mini-Unix on top of the POSIX subsystem. Recompile > tcsh, mv, rm, cp, and friends, and away you go! Hell, I've got > a full Unix user environment on my SE/30 via MacMint Eek. MacMiNT's a nifty doodad indeed, but it's very far from a full unix user environment. > *** MAC USERS WILL NEVER ACCEPT UNIX *** This one certainly will, provided it materializes only when summoned. What I don't see can't hurt me -- so long as it works. Magnificent rant, though, and you may well be correct in guessing that Apple intends to completely rid Rhapsody of unix so as not to frighten the the mass market with "incomprehensible", "old" unix -- call it The Revenge of the Herds. -- Bruce Bennett <bbennett@unixg.ubc.ca>
From: dawson@utpapa.ph.utexas.edu (Doug Dawson) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 05:00:21 GMT Organization: Physics Department, University of Texas at Austin Message-ID: <5d9455$jkt@geraldo.cc.utexas.edu> References: <5d8qta$6np@news.bu.edu> John Siracusa <macintsh@bu.edu> wrote: >Jeez, I just read that 200+ post thread in c.s.next.programmer >about "ripping Unix out" of NeXTSTEP. I really don't think that >Apple is going to end up with "Unix with a GUI on top" at the >end of their Rhapsody development. > >Now I know most NeXT users love Unix. I know it's fun to tar >-cf - Papers | rsh pooh tar -xf - instead of using Apple file >sharing, but the plain fact is: that has never been a part of >the Mac OS experience. [ tamp ] UNIX as an optional environment on top of the Mac GUI is an act of genius the likes of which the world has seldom seen. Make of that what you will ( and I mean _will_, not do. ) Doug Dawson dawson@physics.utexas.edu
From: Ian Russell Ollmann <iano@scripps.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 4 Feb 1997 21:26:15 -0800 Organization: The Scripps Research Institute, La Jolla, CA Message-ID: <Pine.SGI.3.95.970204212318.17657A-100000@wong> References: <5d8qta$6np@news.bu.edu> <19970204203010615609@port09.annex3.net.ubc.ca> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <19970204203010615609@port09.annex3.net.ubc.ca> Those of you Unix nuts out there who actually want to see unix appear on Mac hardware might strongly consider voicing your support for continued Linux development at http://www.mklinux.apple.com/forms/register.html Even if you are like me and was planning to get around to installing Linux some time Real Soon Now, you might wish to voice your intent before the product vaporizes. Ian Ollmann
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: Printing under Openstep Date: 5 Feb 1997 06:09:19 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5d986f$pag$1@brachio.zrz.TU-Berlin.DE> References: <01bc12c3$95adcf90$06254e8b@carcosa> In article <01bc12c3$95adcf90$06254e8b@carcosa> "Bill Keller" <kellerw@okstate.edu> writes: [OpenStep/NT needs PS printer] > Under Nextstep 3.3, I used JetPilot to print to my inkjet. It was awfully > slow, but it worked. Is there a similar emulation driver for NT, or am I > stuck buying a postscript printer? I am currently upgrading my printer software (the technology eXTRAPRINT and Color-X were based on) to be fully OpenStep compliant. This software is almost always faster than the ink-jet being driven. Marcel
From: "Andrew Kim" <akim@pop.cogsoft.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.hardware,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: PPP Help!!! Anyone? Date: 4 Feb 97 21:52:05 -0800 Organization: Cogent Software Message-ID: <AF1D600C-2BE8A@207.13.170.22> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="Cyberdog-AltBoundary-0002BCFC" Content-Transfer-Encoding: 7bit nntp://news.cogent.net/comp.sys.next.hardware, nntp://news.cogent.net/comp.sys.next.misc, nntp://news.cogent.net/comp.sys.next.programmer, nntp://news.cogent.net/comp.sys.next.software, nntp://news.cogent.net/comp.sys.next.sysadmin --Cyberdog-AltBoundary-0002BCFC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Is there any one can tell me how to set up PPP for OpenStep 4.0 (040 Black) by step by step instruction? Online help does not gives me a bit helpful. I have Supra Sonic and NeXTstation Color. I am very confused and I have a no idea what to do. Thank you for any suggestion. PS. I tried Gatekeeper, & Kermit. but never worked. What did I do wrong??? --Cyberdog-AltBoundary-0002BCFC Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-0002BCFC" Content-Transfer-Encoding: 7bit --Cyberdog-MixedBoundary-0002BCFC Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <X-FONTSIZE><PARAM>12</PARAM><FONTFAMILY><PARAM>Palatino</PARAM>Is there any one can tell me how to set up PPP for OpenStep 4.0 (040 Black) by step by step instruction? Online help does not gives me a bit helpful. I have Supra Sonic and NeXTstation Color. I am very confused and I have a no idea what to do. Thank you for any suggestion. PS. I tried Gatekeeper, & Kermit. but never worked. What did I do wrong???</FONTFAMILY></X-FONTSIZE> --Cyberdog-MixedBoundary-0002BCFC-- --Cyberdog-AltBoundary-0002BCFC--
From: "Chris" <C.Erker@worldnet.att.net> Newsgroups: comp.sys.next.programmer Subject: Help a new OpenStep 4.1 NT Developer! Date: 6 Feb 1997 06:02:48 GMT Organization: x Message-ID: <01bc13f3$39944410$992274cf@openstep-nt> Hi everyone, Let me say that I am very excited about the NeXT/Apple deal. I have been interested in NeXT for a couple of years now, but I honestly believed that NeXT would go bankrupt soon. But with news of the merger I went out and bought OpenStep 4.1 developer for NT. My Problem: My friend and I wrote a few dummy programs under NeXT 3.3 in a standard text editor and compiled them from the command line, without problem. When I tried to run the same program at home under NT, I get the following error message: Jethro.m:5: "Cannot find interface declaration for 'Object', superclass of 'JethroClass' Here is the complete source: <---------------------------------------------------snip-------------------- -------------------------------> #import <appkit/appkit.h> @interface JethroClass: Object { } @end @interface SallieMae: Object { } @end @implementation JethroClass { } @end @implementation SallieMae: Object { } @end void main() { //-- Declarations id oJethro; int x; SEL MySelector; oJethro = [[JethroClass alloc] init]; x = [oJethro isKindOf: [JethroClass class]]; if (x) { printf("Yes, oJethro is a kind of JethroClass!\n"); } else { printf("No way man!\n"); } MySelector = sel_getUid("isKindOf:"); x = (int) [oJethro perform: MySelector with: [SallieMae class]]; if (x) { printf("Yes, oJethro is a kind of SalllieMae!\n"); } else { printf("Are you fucking with me, or are you just stupid?\n"); } exit(0); } <---------------------------------------------------snip-------------------- -------------------------------> I suspect that this is a simple problem to fix, but I've been at it for 2 days now, and I am getting just a little frustrated. Any comments and help would definately be appreciated. Thank you for your time. -- Chris BTW: My e-mail address is CErker@rnt.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: 6 Feb 1997 06:36:32 GMT Organization: ace dot net internet technologies Message-ID: <5dbu5g$6i5@darla.visi.com> References: <32E78DAF.433F@srsys.com> <5c8j8b$10sg@flood.weeg.uiowa.edu> <5c93h6$3ur@darla.vis <5d2mec$431@darla.visi.com> <5da5dv$hld@netty.york.ac.uk> Roger Peppe (rog@ohm.york.ac.uk) wrote: : since it's an OO language, the parameter types should be evident from : the type of the object. if objective C provided decent type checking, : and separate namespaces for different objects/protocols, then : the compiler could check that the parameters were in fact of the : required type. Well, they could have done: - drawImage:image { // switch on the class of passed objcet } But why go to that effort? It'd involve raising an error if the passed parameter wasn't an acceptable type, and would generally be unclean. However, none of this would matter if you had an image protocol which all image-ish objects conformed to. Personally, I'd prefer OpenStep over a framework that took the static approach, say, MFC, or OpenClass. But that's just me. : long method names are a hack to get around the criminal lack of : namespace control in objective C. Maybe I'm missing something, but what does a long method name have to do with the framework's namespace control? Namespace control goes as far as class collision, and that's it. Having said that, I do like Java's hierarchical namespaces, but they're still not without their problems. : and i don't know about anyone else, but i find myself looking up : those long method names almost every time i use them (to check : on exact phrasing and capitalisation), whereas i usually know : what parameters they take. itsQuiteSimpleAllOpenStepMethodsHaveCapitalizationLikeThis. : if objects are well designed, then a method name that reflects the : action to be taken and not the types that the method takes : should be perfectly adequate for self documenting code : (and much more robust in the event that the argument type changes) Types are as much a part of objects as anything else. There's no reason why method names shouldn't include them. There's every reason why they should include them in a dynamically typed language. Nonetheless, I see where you're going. Instead of drawImage, drawRect, and drawString, we could just have draw, and have long *variable* names instead. Then we'd get to change them from object to object, method to method, and have no change of remember anything. -- # 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: brundage@ipac.caltech.edu (Michael Brundage) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 05 Feb 1997 22:34:39 -0800 Organization: Infrared Processing Analysis Center, Caltech Message-ID: <brundage-ya023180000502972234400001@nntp-server.caltech.edu> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <32F89AA4.1DC4@iquest.net>, sdmeyers <smee@iquest.net> wrote: > You know it would be extreamly easy to map a GUI on top of UNIX in such a way > that the User will work with it in the same way that they work with the MacOS > today [...] Yeah, and Apple has already done it once (MAE). The thing that amazes me is that UNIX is literally older than I am, and it seems to be alive and kicking well (and what is it's market share, hmm?). I think the idea of a Macintosh presenting different kinds of (inter)faces to different types of users is totally excellent (at least, in theory). michael brundage@ipac.caltech.edu
From: connelly@dawnstar.darc.org (Paul Connelly) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 06 Feb 1997 01:46:41 -0500 Organization: Dawnstar Advanced Research Collaborative Message-ID: <connelly-ya023680000602970146410001@news.ziplink.net> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5dbfr3$g10@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > Don't confuse the operating system with the shells. The shell is the best part of UNIX though. The tools that come with the shell are great. Just get rid of that horrid directory structure. (Let's see, is that program in /bin, or was it /usr/bin, or /usr/local/bin, or....?) - paul -- Ut ibi arduum cursum angelorum perficiam
From: "Thomas E. Zak" <tzak@earthlink.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: Wed, 05 Feb 1997 16:58:52 -0500 Organization: Ford Motor Company Message-ID: <32F9029C.FF6@earthlink.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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> <32F8E47B.1FCFFD97@screaming.org> <maury-0502971523160001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > In article <32F8E47B.1FCFFD97@screaming.org>, Pohl Longsine > <pohl@screaming.org> wrote: > > > Wouldn't it be easier to teach the computer about how people > > program than to teach the programmer how to jump through quirky > > hoops in the toolbox? > > Point taken and all, but the user community outnumbers the developer > community a bit (like 100 to 1). That has to be taken into consideration. > As a Mac user for 8 years, and a Unix/PC developer for 4 years, I disagree with the 100:1 justification. If Apple had made their programming interface easier, I would probably be a Mac developer right now, and the code base for the Macintosh would be expanded. Also, the programmer base would be expanded, making it easier for companies wanting to support the platform to get competent programmers. Thomas E. Zak tzak@earthlink.net
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, 05 Feb 1997 18:01:00 -0500 Organization: SoftArc Inc. Message-ID: <maury-0502971801000001@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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> <32F8E47B.1FCFFD97@screaming.org> <maury-0502971523160001@199.166.204.230> <32F9029C.FF6@earthlink.net> In article <32F9029C.FF6@earthlink.net>, "Thomas E. Zak" <tzak@earthlink.net> wrote: > As a Mac user for 8 years, and a Unix/PC developer for 4 years, > I disagree with the 100:1 justification. If Apple had made > their programming interface easier, I would probably be a > Mac developer right now, and the code base for the Macintosh > would be expanded. Also, the programmer base would be expanded, > making it easier for companies wanting to support the platform > to get competent programmers. The point in question though is about where the OS let's you place applications (if I'm reading the thread correctly). The reply to this being a problem (and I certainly think it is) is that this is no worse than forcing the developer to do odd things. Well like I said, that's definitely true, but while few of us are programmers, ALL of us are users. Maury
From: sef@kithrup.com Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <4092552e.17046336@news.zippo.com> Date: 6 Feb 1997 09:31:38 GMT Control: cancel <4092552e.17046336@news.zippo.com> Message-ID: <cancel.4092552e.17046336@news.zippo.com> Sender: cjtech@inreach.com Spam cancelled by sef@kithrup.com
From: TimT@asiatlanta.com (Tim Triemstra) Newsgroups: comp.sys.next.programmer Subject: Porting: NS 3.3 to OpenStep NT 4.1? Do I need Mach 4.1 too? Date: Wed, 05 Feb 97 21:59:27 GMT Organization: Alpha Star International Message-ID: <5db07d$26r@client3.news.psi.net> Ok, this is going to be a big project but I HAVE to port a NS 3.3 application to run under OpenStep NT v4.1... A subproject of the code will need to be re-written and compiled to link with Windows NT code (I do have Visual C++ v4.2). I do now have NeXT 3.3 (for Intel) running so I can make changes to the old .nib files and such. Unfortunately, one of the palettes used in the NeXT version is no longer available (no OpenStep port) so I need to remove it with more standard text fields. This also is probably not that hard. I have taken my project to a friend's place who is running the academic bundle of OpenStep 4.1 for NT. She didn't get much of a set of docs or tools with it. There is mention in a little .hlp file of running some OpenStep scripts on the OpenStep for Mach 4.0 distribution to convert old apps to OpenStep. I can't seem to find those scripts under the NT Academic bundle. Am I: A) Missing the conversion tools because it is an academic bundle and I don't get full docs or tools? B) Missing the conversion tools because it is an NT distribution? C) Not missing the tools but am too dumb to find them? :) If so, where are the docs for using them (the 700+ K file on porting only has like 4 pages of text!?!?) Do I need to buy BOTH the Mach and NT distributions of OpenStep? That would be cute, 3 computers to port the damn thing... I *AM* able to open the old project in the OpenStep NT 4.1 Project Builder but I can't build because it says it can't find the build tool (the inspector shows /bin/gnumake which obviously isn't a legitimate NT path.) If it *IS* possible to go directly from NS 3.3 to OpenStep NT 4.1 could someone please give me some advice? Before I ship off thousands (many) of dollars to NeXT I want to know that this is going to work and what I have to buy. What manuals will I get as opposed to the academic etc... Thanks a ton people! :) (if you're reader can respond to both mail and news that would be GREAT cause I have a hard time getting all the articles from my site.) Tim Triemstra ....... TimT@ASIAtlanta.com Alpha Star International, Atlanta GA USA
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 6 Feb 1997 02:32:03 GMT Organization: Indiana University, Bloomington Message-ID: <5dbfr3$g10@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> NNTP-Posting-User: glhansen In article <5d8qta$6np@news.bu.edu>, John Siracusa <macintsh@bu.edu> wrote: > *** MAC USERS WILL NEVER ACCEPT UNIX *** Don't confuse the operating system with the shells. If Apple put a nice GUI on any Unix, and provided control panels and menus to manipulate and administrate the system, you'd never know. The system disk could have an "Easy Install" option that automatically logs on as root when the system boots, and you'd never have to deal with usernames or passwords. Don't worry, it will still look and act like a Mac. But I hope they don't try to rip out the Unix. I hope they keep a bash or something laying around in Rhapsody. With NeXT, they're getting an industrial-strength multi-user remote-accessible operating system. That would let them expand into jobs where those qualities are needed, and attract the Unix geeks in computer science departments across America. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
Newsgroups: comp.sys.next.programmer From: Nitezki@NiDat.sub.org (Peter Nitezki) Subject: Re: LU6.2 Interface Message-ID: <E55Fp7.16J@nidat.sub.org> Sender: nitezki@nidat.sub.org (Peter Nitezki) Organization: private site of Peter Nitezki, Kraichtal, Germany References: <5d705d$27b@hermes.is.co.za> Date: Wed, 5 Feb 1997 21:29:31 GMT In article <5d705d$27b@hermes.is.co.za> gvandyk@icon.co.za writes: > We need to communicate to MVS using LU6.2. > > Has anyone done this before and what is involved in doing this? > A CICS gateway, of course. On Unix they usually come with a Unix transaction monitor package. CICS (for Unix formerly aka. as Encina by Transarc) by itself is available for AIX and HP-UX. The connection to MVS/CICS by itself also assumes a SNA network stack and hardware (like token ring adapter or a channel adapter). I haven't seen these for NEXTSTEP. Most shops I know have some HP-UX for this trick. You then either use some adapter for LU6.2 to socket interface or a XA compliant transaction monitor like Tuxedo on the platform of choice. My choice of middleware would be different but this way has been followed by more than one herd :-) -- Peter Nitezki | Nitezki@NiDat.sub.org # Blessed art thou who knoweth Staarenbergstr. 44 | Tel.: +49 7251 62495 # not about the pleasure and D-76703 Kraichtal | Fax : +49 7251 69215 # delight of being hooked GERMANY | E-mail defunct, sorry # up to the Net. Peter 1,3-5
From: amando@gcomm.com Newsgroups: comp.sys.next.programmer Subject: HASH Usage? Date: Thu, 06 Feb 1997 12:29:16 +0200 Organization: CompuServe Incorporated Message-ID: <32F9B27C.CC6@gcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Could anybody please tell me what is a hash function? I am trying to get a function that allways gives me a different serial number giving it a seed. I haven't found any FAQ of this or how to implement serial and activation codes for registered shareware. Any help will be appreciated! Thanks in advance! Amando Blasco
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: Wed, 05 Feb 1997 21:14:29 -0600 Organization: mementech, inc. Message-ID: <32F94C95.156369DA@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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> <32F8E47B.1FCFFD97@screaming.org> <maury-0502971523160001@199.166.204.230> <32F9029C.FF6@earthlink.net> <maury-0502971801000001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > "Thomas E. Zak" <tzak@earthlink.net> wrote: > > > As a Mac user for 8 years, and a Unix/PC developer for 4 years, > > I disagree with the 100:1 justification. If Apple had made > > their programming interface easier, I would probably be a > > Mac developer right now, and the code base for the Macintosh > > would be expanded. Also, the programmer base would be expanded, > > making it easier for companies wanting to support the platform > > to get competent programmers. > > The point in question though is about where the OS let's you place > applications (if I'm reading the thread correctly). That may have been the origin of this sub-thread, but the immediate context was Apple's design philosophy about how users are supreme and how geeks don't understand this. My response was to say that NeXT took this philosophy to heart and extended it to programmers. I claimed that this philosophy is superior to Apple's single-minded focus on the user, as it treats everybody with respect. This was a tangent shooting off from the free-form-filesystem discussion, but wasn't meant to say anything about it directly. I think the original topic of discussion was that Apple unveiled their OS plans at Macworld. ;) -- 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,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer From: roland@onevision.de (Roland Schwingel) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Message-ID: <E56KLo.9An@onevision.de> Sender: news@onevision.de Organization: OneVision GmbH, Regensburg, Germany References: <rang-0502971231490001@margaret.trillium.adaptec.com> Date: Thu, 6 Feb 1997 12:13:00 GMT In article <rang-0502971231490001@margaret.trillium.adaptec.com> rang@trillium.adaptec.com (Anton Rang) writes: > In article <32F89AA4.1DC4@iquest.net>, sdmeyers <smee@iquest.net> wrote: > > You know it would be extreamly easy to map a GUI on top of UNIX in such a way > > that the User will work with it in the same way that they work with the MacOS > > today (of course in turn this OS would respond in a much better fashion to the > > user). > > Well, yes and no. While I agree that it's possible to build a decent > GUI for *file management* on a UNIX system, there are a lot of operations > a user can do on MacOS today which couldn't easily be done in a UNIX > environment without major changes. > > Consider double-clicking a document. How do you know which program to > launch? HFS provides the type and creator, which together with the > desktop database define both the default application as well as a list of > other applications which know how to open the file. Typical UNIX file > systems don't have this information available to them, though there are > approaches to make it work most of the time (or all the time, if you can > enforce a file format with a fixed header). > > [... some stuff deleted for shortening ...] > -- Anton It seems to me, that you never ever have used Nextstep. You should first try it out, before shouting about something not being possible. Double click loading of documents, document loading with dragging, all that is the daily business of a Nextstep user since years. So, please cool down. And take a look. And in my opinion the File Viewer of Nextstep is far ahead of the MAC's Finder. The finder has one or two features which are currently lacking in the File Viewer of Nextstep, but File Viewer has in my opinion much more capabilities than finder, which makes him one of the very best aroung. But all this is another discussion. Bye, Roland -- ============================================================================ Roland Schwingel OneVision GmbH Developer Zeissstrasse 9 Email:roland@onevision.de 93053 Regensburg (NextMail,MIME welcome) Germany ============================================================================
From: Timothy B. Stiles <tbstiles@ix.netcom.com> Newsgroups: comp.sys.next.programmer Subject: Windows 95 Date: Thu, 06 Feb 1997 05:39:12 GMT Organization: Netcom Message-ID: <5dbqf2$nnh@dfw-ixnews6.ix.netcom.com> Can someone please answer this question? If I have a program written for Windows 95 that won't allow you to do anything to the window except "restore" or "close" where can I change those properties? IS it in the registry? I'd like to re-enable minimize, maximize, and size functionality. Please respond ASAP and cc: to tstiles@ptp.hp.com. Your help with this is very appreciated! : ) Tim Stiles
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: Thu, 6 Feb 1997 08:30:12 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <kmyRnYi00iWSQ15mII@andrew.cmu.edu> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <5dadaq$c86$1@carrera.intergate.bc.ca> In-Reply-To: <5dadaq$c86$1@carrera.intergate.bc.ca> Excerpts from netnews.comp.sys.next.programmer: 5-Feb-97 Re: "static inline" methods.. by Ian Main@Slow.kite.ml.or > Umm.. You'll have to forgive my ignorance cause I just started with objC a > couple weeks ago, but isn't it only the method calls that use the runtime > system? Pretty much, yes. You can query the runtime via pure function calls, too, but that's not common. > I just compiled a little test program using a normal inline C > function, and the compiler never said a word with -Wall (this is the GNU > compiler 2.7.2.1). Now... whether it _really_ inlined it I don't know, but > it seemed to work. It probably did inline it, because you were using normal C. Scott wants a way of inlining code through the syntax of dispatching a ObjC method invocation. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Joseph Panico <jpanico@online.disney.com> Newsgroups: comp.sys.next.programmer Subject: Re: Documentation in PB 4.1 Date: Thu, 06 Feb 1997 10:56:25 -0500 Organization: Disney Online Message-ID: <32F9FF29.4337@online.disney.com> References: <5datht$547@q.seanet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Misha M. Melikov wrote: > > For some reason I can only see AppKit and Foundation documentation in > ProjectBuilder 4.1. All other frameworks do not get indexed and > documentation can not be seen. You are not alone. Strangely enough, after a couple days of use, *some* of the EOF documentation started showing, though I didn't change any settings at all. Perhaps it just has to "warm up" a bit ;). > -m -- Joe Panico Disney Online jpanico@online.disney.com
From: Pascal Forget <pascal@wsc.com> Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 6 Feb 1997 17:14:56 GMT Organization: WSC Investment Services, Inc. Distribution: world Message-ID: <5dd3ig$asr@cerberus.wsc.com> References: <5d8qta$6np@news.bu.edu> In Mac/NeXT & Unix: You're all NUTS! comp.sys.next.programmer macintsh@bu.edu (John Siracusa) writes, > There are millions of Macs out ther, and the common thread > among them is that they don't require that type of thing! They > run Photoshop, Electric Image, PageMaker, and WordPerfect. > They *don't* run xdmcp, biod, rcp, emacs, vi, gcc, ld, troff, > and mv. Not having a command line interface doesn't affect normal users' lives, but it makes software development/maintenance harder. I would like to make an analogy with the McDonald F-101B "Voodoo" Jet fighter airplane. http://aeroweb.brooklyn.cuny.edu/aircraft/f101a.html On the Voodoo, the mechanics had to remove the engine from the engine bay to perform basic maintenance! Likewise, I believe the MacOS is low on applications serviceability, i.e it makes the life of software developers/maintainers harder than it should be. Pascal Forget -- Spammers will be hunted down and shot at.
From: woo@opus.bloomco.ornl.gov (John W. Wooten) Newsgroups: comp.sys.next.programmer Subject: Starter App? Date: 6 Feb 1997 18:17:30 GMT Organization: Oak Ridge National Lab, Oak Ridge, TN Distribution: world Message-ID: <5dd77q$4ee@stc06.ctd.ornl.gov> I've built several apps based on the Starter app from the archives. I've just built one that has a strange behavior I've not been able to track down. I alter "only" the DocumentWindow.[h-m] so that there are text fields in the Window displayed and cause the window to read the data from a file for those fields and then mark the window "isEdited". When I close the window, things work fine, but if I then click on any part of the menu, the application crashes with a "objc: FREED(id): message free sent to freed object=0x9b11c8 or objc: FREED(id): message resetCursorRect:inView: sent to freed object=0x9ac084 I'm not freeing any objects myself. Does anyone know what the Starter application might be doing that would cause this behavior? If you don't implement anything in the DocumentWindow object, then things work fine. -- J. W. Wooten <jwooten@korrnet.org> http://sacam.oren.ortn.edu/~wooten Internet Consultant NeXTmail preferred, MIME is welcome Please finger woo@160.91.216.2 for PGP public key
From: tnelson@voicenet.com ("Tracy Nelson") Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Date: 6 Feb 1997 19:12:29 GMT Organization: Voicenet - Internet Access - (215)674-9290 Message-ID: <5ddaet$36k@news1.voicenet.com> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> Anton Rang (rang@trillium.adaptec.com) wrote: : Well, yes and no. While I agree that it's possible to build a decent : GUI for *file management* on a UNIX system, there are a lot of operations : a user can do on MacOS today which couldn't easily be done in a UNIX : environment without major changes. Why not? It's all just ones and zeroes... : Consider double-clicking a document. How do you know which program to : launch? HFS provides the type and creator, which together with the : desktop database define both the default application as well as a list of : other applications which know how to open the file. Typical UNIX file : systems don't have this information available to them, though there are : approaches to make it work most of the time (or all the time, if you can : enforce a file format with a fixed header). But UNIX files don't *have* headers! That's one of the nice bits! Both the creator/type problem and the resource fork can be handled through a couple of changes to the inode structure. Why do you assume these things are carved in stone? : But there are harder cases. Consider dropping a document onto the icon : for a currently running application. This should generally open it within : the app; but there is no standard way (in a generic UNIX) to communicate : this -- there is no equivalent to the AppleEvents which MacOS uses. (The : situation is worse when you think about full scriptability.) Why are we discussing "generic" UNIX? If Apple's going to go to the work of creating a major new OS, why would it just glue together some off-the-net components? Get with it people, there are NO LIMITS. Saying something is "based on" something can be the same as saying "we stole all the best ideas from" something. Admittedly, there won't be *that* much opportunity for innovation this time around, with the release schedule they've got, but there's no reason that the core UNIX concepts (NOT the shells, and NOT two- letter command names) can't be forged into the heart of a new MacOS. : The Chooser (through its use of NBP) also provides functionality which : typical UNIX TCP/IP implementations don't. There's a lot of work to be : done to make any modern UNIX as user-friendly as the Mac. (I'm not saying : it's impossible; just hard.) So why not support NBP alongside TCP/IP? Who's going to know? They pull up a Chooser, and it works like the Chooser is supposed to work, who cares if it's tunneling NBP in an IP wrapper? Or do you think that TCP/IP = lpadmin?
From: shess@one.net (Scott Hess) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 6 Feb 97 14:01:59 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb6140159@slave.one.net> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> In-reply-to: Charles William Swiger's message of Mon, 3 Feb 1997 08:19:45 -0500 In article <4mxSLlq00iWUI108t7@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> writes: Excerpts from netnews.comp.sys.next.programmer: 30-Jan-97 "static inline" methods wou.. by Scott Hess@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: What you are asking for, "static inline functions", means that the compiler has to make all decisions at compile time, and that you therefore cannot rely on any dynamic properties of the runtime, like dynamic method invocation, or subclassing, etc-- but that's what you want, to avoid the overhead of objC_msgSend. This is what Java does when it sees the "final" keyword. 'Nother bit of thought ... to make a static inline method safer, you could potentially have the compiler modify things to verify that "self" is actually an instance of the class which defined the method (-isMemberOf:, _not_ -isKindOf:). Such a test could potentially be coded using pointer comparisons (something like self->isa==Storage, though that isn't quite right because Storage is not something you can refer directly to). If isa doesn't match, the normal method dispatch could be called. If things can be done as pointer comparisons, then the inline version could still be substantially faster than method dispatch. Of course, this would also restrict subclass use of the inline method. That's not so much of a problem in many cases (things like Storage are generally not subclassed). All of this makes me wonder if someone has been working on a method dispatch facility like those described in Karel Driesen's papers. [Sorry, no URL on-hand, look in DejaNews perhaps.] Basically put, the fastest method dispatch would be to use an matrix of pointers to method implementations, indexed by class and selector. Then method dispatch becomes "index, index, jump". Of course, such a matrix would be much too large for normal use, so you figure out ways to compress it, while still retaining the speed. Driesen describes means of packing rows or columns together to make a single array that's smaller than the matrix was. Then method dispatch becomes something like: id objc_msgSend( id self, SEL _cmd, ...) { IMP imp; imp=impTable[ selectorTable[ _cmd]+self->isa->classNumber]; return builtin_apply( imp, self, _cmd, ...); } [Sorry, I can't recall how you do builtin_apply offhand.] Basically, you index a global selector-to-offset table by the selector (which must now be a small integer rather than a static string), adjust by a per-class classNumber, and that gives you your index into impTable. In addition, within the implementation you check that it is really the implementation for _cmd, which is easy to do because at that time you _know_ what you're implementing. [Why check _cmd? Because you pack the impTable by taking advantage of the fact that most selectors aren't implemented in most classes, and use the "holes" to pack other implementations into. So you _could_ call the wrong implementation. But the check within the implementation is fast, so it's still a net gain to do the check.] I know it wouldn't work that well in the face of NXBundle, but that can probably be worked around (probably by making non-bundle code faster while leaving bundle code with the current dispatch speed). 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: imain@Slow.kite.ml.org (Ian Main) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 5 Feb 1997 16:43:06 GMT Organization: Internet Gateway Corporation Message-ID: <5dadaq$c86$1@carrera.intergate.bc.ca> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> In article <4mxSLlq00iWUI108t7@andrew.cmu.edu>, Charles William Swiger wrote: >Excerpts from netnews.comp.sys.next.programmer: 30-Jan-97 "static >inline" methods wou.. by Scott Hess@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: > >What you are asking for, "static inline functions", means that the >compiler has to make all decisions at compile time, and that you >therefore cannot rely on any dynamic properties of the runtime, like >dynamic method invocation, or subclassing, etc-- but that's what you >want, to avoid the overhead of objC_msgSend. This is what Java does >when it sees the "final" keyword. Umm.. You'll have to forgive my ignorance cause I just started with objC a couple weeks ago, but isn't it only the method calls that use the runtime system? I just compiled a little test program using a normal inline C function, and the compiler never said a word with -Wall (this is the GNU compiler 2.7.2.1). Now... whether it _really_ inlined it I don't know, but it seemed to work. Ian
From: Pascal Forget <pascal@wsc.com> Newsgroups: comp.sys.next.programmer Subject: Problem with Categories, Anyone? Date: 6 Feb 1997 20:18:28 GMT Organization: WSC Investment Services, Inc. Distribution: world Message-ID: <5ddeak$5f8@cerberus.wsc.com> I have a class implemented in a library. I have a category implemented in another library which adds an extra instance method to the class. While this code has been working flawlessly on NS 3.x, for over two years, on OS 4.1 Mach I get an exception telling me that the class does not respond to the selector for the method implemented in the category. Are categories broken in OpenStep 4.x? Any information would be appreciated. Best Regards, - Pascal Forget
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Upgrading Source from 2.0 Date: 6 Feb 1997 22:04:16 GMT Organization: The Ohio State University Message-ID: <5ddkh0$g8u@charm.magnus.acs.ohio-state.edu> I have a very old program, written for NS2.0, I think. I have Developer 3.3, and am just starting to learn it and Developer 4.1, and am curious what it would take to update a simple 2.0 app? I tried (silly me) to just rebuild it with the new PB, and of course that failed. When I wrote the app, I knew just enough to get it done, and haven't really done any GUI programming since. Comments and advice welcome. 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: Pascal Forget <pascal@wsc.com> Newsgroups: comp.sys.next.programmer Subject: Re: Problem with Categories, Anyone? Date: 6 Feb 1997 20:43:03 GMT Organization: WSC Investment Services, Inc. Distribution: world Message-ID: <5ddfon$606@cerberus.wsc.com> References: <5ddeak$5f8@cerberus.wsc.com> > Are categories broken in OpenStep 4.x? linking with -all_load fixed the problem.
From: geordie@chapman.com (Geordie Korper) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 06 Feb 1997 15:16:28 -0600 Organization: Chapman and Cutler Message-ID: <geordie-ya02408000R0602971516280001@kyrie> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <rang-0502971231490001@margaret.trillium.adaptec.com>, rang@trillium.adaptec.com (Anton Rang) wrote: : But there are harder cases. Consider dropping a document onto the icon :for a currently running application. This should generally open it within :the app; but there is no standard way (in a generic UNIX) to communicate :this -- there is no equivalent to the AppleEvents which MacOS uses. (The :situation is worse when you think about full scriptability.) Actually I think Apple copied drag and drop from NeXT. It was certainly implemented in NEXTSTEP first. Macintosh applications are only now getting the interapplication level of drag and drop that NeXT has had since day one. -- Geordie Korper geordie@chapman.com ********************************************************************* * The text above should in no way be construed to represent the * * opinions of my employer, even if specifically stated to do so. * *********************************************************************
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.lang.objective-c Subject: Re: "static inline" methods would be nice ... Date: Thu, 6 Feb 1997 08:27:31 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Distribution: comp Message-ID: <wmyRl3K00iWS015loJ@andrew.cmu.edu> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb4112112@slave.one.net> In-Reply-To: <SHESS.97Feb4112112@slave.one.net> Excerpts from netnews.comp.sys.next.programmer: 4-Feb-97 Re: "static inline" methods.. by Scott Hess@one.net > Given that this is the case, why not simply use C macros to inline > -elementAt: directly and let the compiler optimize from there? In > fact, this allows you to also provide a real method implementation > which could be used dynamicly by subclasses if needed, but you > could use the macro version whenever you know that it's okay.... > > I've certainly done that in the past. First problem is simply > aesthetic - method calls should look like method calls. It's sort of > like using a macro to act like a static inline function - if you had > to change the interface to do it, it becomes much less attractive. > > Perhaps a bigger problem, though, is that changing to a macro (or > static inline function) requires you to change the usage sites, rather > than the definition. [ ... ] Okay-- I agree that macros aren't ideal, but I did want to point out that they would do what you wanted in terms of code performance. Your point was that you want the compiler to automate this work. If there was a syntax that meant "evaluate this method call inline at compile time", that would seem to suit what you want. Maybe if you created a '#pragma' directive to indicate this, or if you created a new syntax for method invocation, something like: <anObject method:args> instead of [anObject method:args] While I'm reasonably familiar with GCC's source, I never paid any special attention to the area where Obj-C method dispatching is implemented, so I can't suggest how you'd change the compiler except in general terms. Instead of converting the [ ... ] syntax into objC_msgSend(anObject, method, arg1, arg2, ....), you'd want to expand the function corresponding to the method call inline using the same optimization mechanism that already exists to inline small functions into their callers. -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.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 6 Feb 1997 16:05:28 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ddh2o$fh1@csugrad.cs.vt.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> In article <connelly-ya023680000602970146410001@news.ziplink.net>, connelly@dawnstar.darc.org (Paul Connelly) wrote: > The shell is the best part of UNIX though. The tools that come > with the shell are great. Just get rid of that horrid directory > structure. (Let's see, is that program in /bin, or was it /usr/bin, > or /usr/local/bin, or....?) Ah, who cares, as long as they're all in the path? Though the GNU Hurd is doing something interesting with filesystem translators.. they can be used to conceptually merge the contents of /bin, /usr/bin, etc., into one directory (/bin) even when the files are stored all over the place.. everything is in /bin. That lets you keep the old Unix organizational structure (I personally don't want 1000 files in my /bin directory) yet always have everything "be in /bin". -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.mac.oop.macapp3,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Multiple Inheritance (Re: NextStep & Mac Frameworks) Date: 5 Feb 1997 14:28:15 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5da5dv$hld@netty.york.ac.uk> References: <32E78DAF.433F@srsys.com> <5c8j8b$10sg@flood.weeg.uiowa.edu> <5c93h6$3ur@darla.vis <5d2mec$431@darla.visi.com> On 2 Feb 1997 18:29:32 GMT, David Young <dwy@ace.net> wrote: > Dave Griffiths (dave@prim.demon.co.uk) wrote: > : You must like typing. One of the worst things about OpenStep is all those > : horrible long method names. And whereas "drawImage" is easy to remember, > : how many times have you forgotten one of those long method names and typed > : (say) "withScaleFactor" instead of "withFloatingPointScaleFactor"? > > Five seconds of typing is better than a minute of looking stuff up. > > "drawImage" may be easy to remeber, but what parameters it takes sometimes > is not. Draw image that's a bitmap? That's a JPEG? That's a sequence of > drawing commands? With an integer scale factor? Even the class libraries > that make the best use of method overloading don't accept everything as > a parameter, and you wind up looking at the .h (or .java) file anyway > to see what you can send it. since it's an OO language, the parameter types should be evident from the type of the object. if objective C provided decent type checking, and separate namespaces for different objects/protocols, then the compiler could check that the parameters were in fact of the required type. long method names are a hack to get around the criminal lack of namespace control in objective C. and i don't know about anyone else, but i find myself looking up those long method names almost every time i use them (to check on exact phrasing and capitalisation), whereas i usually know what parameters they take. if objects are well designed, then a method name that reflects the action to be taken and not the types that the method takes should be perfectly adequate for self documenting code (and much more robust in the event that the argument type changes) rog.
From: rang@trillium.adaptec.com (Anton Rang) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 05 Feb 1997 12:31:49 -0600 Organization: Trillium Research, an Adaptec company Message-ID: <rang-0502971231490001@margaret.trillium.adaptec.com> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> In article <32F89AA4.1DC4@iquest.net>, sdmeyers <smee@iquest.net> wrote: > You know it would be extreamly easy to map a GUI on top of UNIX in such a way > that the User will work with it in the same way that they work with the MacOS > today (of course in turn this OS would respond in a much better fashion to the > user). Well, yes and no. While I agree that it's possible to build a decent GUI for *file management* on a UNIX system, there are a lot of operations a user can do on MacOS today which couldn't easily be done in a UNIX environment without major changes. Consider double-clicking a document. How do you know which program to launch? HFS provides the type and creator, which together with the desktop database define both the default application as well as a list of other applications which know how to open the file. Typical UNIX file systems don't have this information available to them, though there are approaches to make it work most of the time (or all the time, if you can enforce a file format with a fixed header). But there are harder cases. Consider dropping a document onto the icon for a currently running application. This should generally open it within the app; but there is no standard way (in a generic UNIX) to communicate this -- there is no equivalent to the AppleEvents which MacOS uses. (The situation is worse when you think about full scriptability.) The Chooser (through its use of NBP) also provides functionality which typical UNIX TCP/IP implementations don't. There's a lot of work to be done to make any modern UNIX as user-friendly as the Mac. (I'm not saying it's impossible; just hard.) As for what Apple may do ... who knows? The Mach kernel certainly provides mechanisms which could be used for AppleEvents and the like; I doubt they would try to promote a new system which didn't include at least as much functionality as the current one (though it may take different approaches). -- Anton
From: misha@berlioz.osd.com (Misha M. Melikov) Newsgroups: comp.sys.next.programmer Subject: Re: Documentation in PB 4.1 Date: 6 Feb 1997 22:00:21 GMT Organization: Seanet Online Services, Seattle WA Distribution: world Message-ID: <5ddk9l$j08@q.seanet.com> References: <32F9FF29.4337@online.disney.com> After I added things like: #import <EOControl/EOControl.h> #import <EOAccess/EOAccess.h> #import <EOInterface/EOInterface.h> to /NextLibrary/Frameworks/AppKit.framework/Versions/B/Headers/AppKit.h everything started to work, strangely enough... What could be wrong? -m In article <32F9FF29.4337@online.disney.com> Joseph Panico <jpanico@online.disney.com> writes: > Misha M. Melikov wrote: > > > > For some reason I can only see AppKit and Foundation documentation in > > ProjectBuilder 4.1. All other frameworks do not get indexed and > > documentation can not be seen. > > You are not alone. Strangely enough, after a couple days of use, *some* > of the EOF documentation started showing, though I didn't change any > settings at all. Perhaps it just has to "warm up" a bit ;). > > > -m > > -- > Joe Panico > Disney Online > jpanico@online.disney.com -- ___________________________________________________________ Misha M. Melikov Seanet Corporation Columbia Seafirst Center 701 Fifth Ave., Suite 6801
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Mac/NeXT & Unix: File System Date: 6 Feb 1997 23:23:50 GMT Organization: Boston University Message-ID: <5ddp66$jpc@news.bu.edu> Here's an excerpt from one UseNet reader's response to a post of mine about Unix and the NeXT-generation Mac OS: > John, there's always something to be hidden. Always. The reason you > like dealing with, say, the Mac filesystem is because it hides forks > to the extent that most users don't know they're there. If users had > to know that there's a section of every file holding things like the > creator application, then they'd scream. Instead, it's made (mostly) > transparent. What makes an environment good or bad is based in the > choices of what is hidden and what isn't. > Keep in mind [...] that there's nothing about forks that can't > be handled through structured directories/folders. Forks are little > more than a backend file system detail, which can be hidden from the > user as easily as, say, inodes. This brings up what I think is one of the most important aspects of the Mac/NeXT transition, and OS design in general: the file system. What I think is at the root of Unix's unsuitability for duty as a Mac OS underpinning is the nature of it's "stream of data" file system. A large percentage of the Mac's past and present ease of use advantage is a result of its somewhat strange multi-forked file system. The reply above seems to imply that there is no conceptual difference between having a resource fork and having a folder full of separate files for each application. I challenge that implication, going so far as to claim that it is the Mac's multi-forked file system that has separated it from other OSes. I'll look at this issue in three parts: 1. Hiding directories isn't the same as "hidden" resource forks. Let me make this point as succinctly as I can: files and directories are things that the user deals with. File forks are not. Any mechanism, no matter how pervasive and consistent, that hides whole directory trees is less desirable than a file structure that makes large directory trees unnecessary because files and directories are by their nature things that the user expects to have control over. Yes, I know the Mac has a few invisible files and folders. These are exceptions that prove the rule. This point is open to personal preference, but it is my opinion that vast majority of Mac users (most of whom aren't reading and posting to comp.sys.xxx.programmer, BTW) want things to work the way they do now, only faster and more stable. Again, this is just my opinion. 2. File count! I don't think there's anyone who would want *more* files related to their OS littering their hard drive. <Old man voice ON> Back in the olden days, the Mac OS ("System", dammit! ;) consisted of a System file, a Finder application file, some DAs, and a smattering of printer drivers. <Old man voice OFF> As Mac developers started to discover the world of INITs, the System Folder became more crowded. System 7 and later 7.1 separated the System Folder into a single level of sub- folders, alleviating most of the clutter. Of course, there are exceptions. (The soup of "OpenTsprtAppleTalkLib" files spring to mind, although they reflects more on the 68k/PPC duality of the platform than any OS constraints.) To gain some perspective, however, let's contrast the Mac System Folder with the horror of the \WINDOWS and \SYSTEM directories of Windows 95 or 3.1. And then, of course, there's Unix, the king of the many-tentacled directory structure. But why is this a bad, thing? After all, if the directory structure is standardized, who cares how complex it is? Well, as I see it, there are many problems with even the most standardized and structured maze of directories. First, there's the problem of locating relevant information. If, as a user *or* a programmer, I want to, say, swap my file browser with another, newer version, on a Mac I'd simply replace the Finder application with a new one (this is a somewhat fictional example given how 7.x now works, but this type of thing may happen in a future Mac OS release. Humor me.) Doing the same thing in windows or Unix would not be a task for the faint of heart, simply because you'd first have to locate and remove every file associated with your file browser and replace them with the new versions. Yes, installers could attempt to handle this, but we all know how reliable they are. The reason for this disparity stems from the Mac's ability to shove all related resources into one executable. Due to both historic practices and their respective OS philosophies, Unix, Windows, and friends instead scatter related resources all over the file system (they'd *like* you to think all their files are in a single folder), thus making it nearly impossible to "wrap your mind around" every file associated with a single application, let alone the whole OS or your whole hard drive. This is something I personally consider a *huge* advantage of the Mac OS philosophy (if not the current implementation of it): the file system allows me to have a pretty accurate picture in my mind of *every* file on my hard drive, even though there are over 7000 files on my gigabyte hard drive. This piece of mind is nearly impossible on any other system. The counter-argument that remote administration of a large group of machines is only possible with a standardized directory structure has been dealt with before, and I won't go into it again. Suffice it to say that there are plenty of examples of successfully administered networks of "non-standard" Macs out there, possibly because of the advantages described above. As a final addition to the "application replacement" example, let me point out that in all likelihood, your non-Mac application has modified files that don't belong to it, adding to the difficulty of removing it completely from your system. Which brings me to... 2. Text configuration files Also known as: the bane of "modern" OS design. There is absolutely *no* excuse for text-based configuration files in a modern GUI operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, they're readable by every lowly text editor. But cripes! When you start providing API calls to add and delete lines from a text file (GetProfileString(), etc.) you *know* you're barking up the wrong tree! I don't think there's anyone who would deny that messing with lines of text is more error prone even in the best conditions (i.e. no user modification of the file with a text editor to munge it up) simply because each text files are so free-form. There are no constraints of design to keep a badly behaved application from munging up a shared configuration file. In this scenario, it's easy to see why there'd be API calls! It minimizes the possibility of programmer error. But that's just treating the symptoms! An example relevant to Rhapsody (see, there *is* a connection buried here ;) is how TCP/IP will be handled in the new OS. Ignoring the ancient and ugly roots of the current Mac OS on which it runs, I'd take the Open Transport control panels (Modem, TCP/IP, AppleTalk, PPP) over a slew of .conf text files any day! I routinely switch between FreePPP, OT/PPP, and direct ethernet connection with a few flips of switches in control panels on my Mac. Try that with a Unix box. If you decide you want to change from a direct connection to PPP, you'd better hope you have the config files all set up, and hopefully some shell scripts to moves everything around for you. Oh, and you'd better not have changed the location of any of the files that the scripts refer to. And speaking of moving files, another disadvantage of text configuration files is the hard-coding of file paths. Even Unix symlinks are an example of the limitations of this scheme, although not directly related to text config files. Say what you want about the performance trade-offs of keeping track of aliases, but it's certainly a better system than the "I'm scared to move anything because everything might break" world of .INI files, et al. As far as I'm concerned, a *modern* OS should be the best of both worlds: the superb functionality of a preemptive memory-protected kernel and the interface of the Mac (along with a file system that allows it, of course!) Conclusion: Even the much-vaunted BeOS seems to suffer from file proliferation a la Unix (/dev/modem anyone?) Perhaps this is unavoidable and I'm being naive. After all, the *only* example of an OS that doesn't work this way is the now-ancient Mac OS. But I don't thing there's any reason to resign ourselves to the "me-too" world of evil OSes that require "Uninstallers" and that keep us captive of a bazillion fragile text files. There's a better way, and I only hope that in the coming years the people behind the Mac/NeXT OS aren't afraid to break from the past and give us an OS we can be proud to call "Mac." -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Date: 6 Feb 1997 23:32:49 GMT Organization: Boston University Message-ID: <5ddpn1$jpc@news.bu.edu> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> William Edward Woody (woody@alumni.caltech.edu) wrote: : In article <5d8qta$6np@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: : > Let me say it more simply: as much as you and I find perverse : > joy in the nooks and crannies of a Unix world: : > : > *** MAC USERS WILL NEVER ACCEPT UNIX *** : > : > and that's all there is to it. And guess what, there are about : > 19 million more "Mac users" than there are "techies who like : > Macs but secretly wish they could grep sometimes." : First, take a deep breath, and relax. The sky isn't really falling, : as much as it seems like it. Yeah, I was a bit riled up after reading that huge thread. I'm more calm now ;) (see my new post about the whole file system issue) : Second, let me note that I was also concerned with the idea of having : a Unix kernel underlying the MacOS--as soon as such a thing hit the : shelves it wouldn't be long before someone did 'tsh', at which point, : we may as well have simply exposed people to the shell. It's not the kernel that bothers me. The Mach kernel is certainly suitable, although the Apple-striped part of me wishes I could see NuKernel with it's plug-in extensibility. : But get this: Mach is *NOT* Unix. Mach has been used to build a Unix : compatable OS, and most people tend to build off of a Unix client : built on top of the Mach kernel because that's what most of us : programmers are familiar with. Granted, kernel and system calls are fine. What I'm concerned about most is the support even simple Unix-isms like shell scripts require in order to work. IMO, this support system is not worth the small advantages that a few advanced users will receive because it constrains the rest of the OS too much. : But ultimately, using the Mach kernel does not mean the Macintosh will : operate as a layer on top of Unix. Instead, it means Apple will more : likely create various OS "servers" which service operating system calls : in the same way the Unix server operates. In fact, I suspect both : the "yellow box" and the "blue box" are really just Mach servers : providing different operating system personalities. As I stated in my original post, a POSIX subsystem is fine. A Unix directory tree appearing on my hard drive after a standard install is not. -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 5 Feb 1997 13:29:02 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0myB5iy00iWY461F04@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> In-Reply-To: <5d8qta$6np@news.bu.edu> Excerpts from netnews.comp.sys.next.programmer: 5-Feb-97 Mac/NeXT & Unix: You're all.. by John Siracusa@bu.edu > Jeez, I just read that 200+ post thread in c.s.next.programmer > about "ripping Unix out" of NeXTSTEP. I really don't think that > Apple is going to end up with "Unix with a GUI on top" at the > end of their Rhapsody development. Care to make a bet on this? A gentlemen's bet for Usenet brownie points would be fine, but I'd be happy to put my money where my mouth is. (Email me privately if that is the case.) > Now I know most NeXT users love Unix. The majority of NeXT users don't know any Unix at all, and are often surprised to learn that NEXTSTEP is based on top of BSD Unix. > I know it's fun to tar -cf - Papers | rsh pooh tar -xf - instead of > using Apple file sharing, but the plain fact is: that has never been > a part of the Mac OS experience. You're absolutely right. MacOS has been based solely around GUI solutions for every task, and the lack of a CLI is one of the major weaknesses of the MacOS because it prevents knowledgable users from using the CLI as an alternative which is sometimes superior for some tasks. Regardless of whether Apple recognized their weak points, or whether they were simply lucky, they did purchase NeXT and NeXT's technology. And Apple is in the midst of discovering just what that means and just how fortunate their choice was. Rhapsody will provide a replacement operating system for the MacOS which should be better for both traditional Mac users and for new categories of users. > There are millions of Macs out ther, and the common thread > among them is that they don't require that type of thing! They > run Photoshop, Electric Image, PageMaker, and WordPerfect. > They *don't* run xdmcp, biod, rcp, emacs, vi, gcc, ld, troff, > and mv. You're absolutely right. The typical NEXTSTEP user never runs the CLI utilities you've listed, either. If you don't want to, you will never, ever have to use the CLI under NEXTSTEP for the tasks that normal users perform. > Further, you CANNOT hope to get the current millions of Mac > users to replace their OS with an OS that acts like Unix! You're absolutely right. Fortunately, NEXTSTEP doesn't act like any other Unix I've used. > And believe me, no matter how much you "hide" the unix, it'll > never be "like a Mac" to those millions of users. You've obviously never used NEXTSTEP, or else you would have seen for yourself that you really can hide the Unix. Most people who have used both NEXTSTEP and MacOS think that NEXTSTEP has a Mac-like interface that's actually better than the Mac's. > On a Mac, icons do not "represent" or "point to" or "indicate" > your files. They *ARE* your files. That icon *IS* your disk > drive. That just isn't going to happen in the world of Unix. Try using NEXTSTEP-- it already happened years ago. > And why *should* Apple keep *any* vestiges of Unix? This has already been extensively debated. Go look up some of my previous articles via http://www.dejanews.com. [ ... ] -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.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 13:49:25 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5daknl$4j7@csugrad.cs.vt.edu> References: <5d8qta$6np@news.bu.edu> In article <5d8qta$6np@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > Further, you CANNOT hope to get the current millions of Mac > users to replace their OS with an OS that acts like Unix! No one is going to try. NEXTSTEP doesn't act like Unix. > And believe me, no matter how much you "hide" the unix, it'll > never be "like a Mac" to those millions of users. Wrong. The NEXTSTEP UI could be modified to behave just like a Mac from a user's point of view. (Of course, the API's would be different.) Let a Mac user use a NEXTSTEP system for an extended period of time. Don't tell them it's Unix. I bet they never figure it out, unless they go hunting through the documentation or run Terminal.app. > On a Mac, icons do not "represent" or "point to" or "indicate" > your files. They *ARE* your files. That icon *IS* your disk > drive. The icon "points" to the file in exactly the same way that a file icon in NEXTSTEP does. It's a bitmap which the OS knows about, and if you have a double-click event within that region, the OS looks gets a pointer/inode/file ID/whatever to the file, and opens it. > That just isn't going to happen in the world of Unix. Already been done. > And why *should* Apple keep *any* vestiges of Unix? Because Unix is an asset to a lot of people, and because they would have to spend time _removing_ Unix. There's nothing to gain from removing all the Unix utilities (except a little disk space), and something to lose. > All they > have to do is use a modern kernel with a modern API. Everything > else is an implemntation. Add a POSIX sublayer, if you want. > But there will be none of this /usr/bin foolishness. A huge > Unix tree of libraries and executables is simply not revelant in > an operating system that uses a MetroWerks development > environment and a Finder-like program for file manipulation. A lot of NEXTSTEP admin tools use Unix utilities. They would all have to be rewritten, often reproducing nontrivial functionality. There really is little reason to blow away /usr/bin, when the whole thing is 9 megs, and there are a number of users who might actually want to use something in it. Maybe if Apple is really concerned about disk space they'll make /usr/bin an optional install, but I doubt they'd nuke it completely. Heck, a lot of NeXT's developers use the utilities in there. > You want Unix? Buy MkLinux! You want Unix in Rhapsody? Write > your own mini-Unix on top of the POSIX subsystem. That's ludicrous. We already _have_ Unix in Rhapsody. There's no reason to take it out and annoy the people who want it, when leaving it in makes no difference to the people who don't. > Recompile tcsh, mv, rm, cp, and friends, and away you go! Well, I'm suspecting that Apple may remove gcc from Rhapsody.. > But there's no reason a SANE Apple would compromise it's 12 year > old operating system and UI philosophy to keep it in its next- > generation OS! "Compromise"?? Tell me exactly how NEXTSTEP compromises the Mac operating system and UI philosophy. Have you actually used NEXTSTEP? > Yes, it may be in there initially. But you can bet your > booty that they'll remove it as soon asn they get the chance. I'm not betting my booty. > Let me say it more simply: as much as you and I find perverse > joy in the nooks and crannies of a Unix world: > *** MAC USERS WILL NEVER ACCEPT UNIX *** Boy, it's really amusing then that that's what they'll be getting. 99% of them will never even know it's Unix. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: OpenStep: Some questions Date: Thu, 06 Feb 1997 17:54:21 -0500 Organization: SoftArc Inc. Message-ID: <maury-0602971754210001@199.166.204.230> I've been reading over the (sadly poorly formatted on my machine) OpenStep docs for a couple of hours now. While I won't pretend to understand a lot of it yet, I do have a few prelim questions: a) How big can text be? It doesn't really say. The Mac has a 32k limit (grumble) and all the OOPS libs out there are based on it. I hope there's no limit in OS? Having the picture embedding system in the standard text method will be helpful too. The implementation strikes me as being either hackish or brilliant, but either way it's good to see. b) How about making a spreadsheet view? Does NSMatrix support large "sheets" with arbitrary data types? The documents seem to imply that it doesn't. Does it support line-by-line or row-by-row selections? Again I don't see this. c) Is it just me or will the colour picking protocols make ColorSync a farily natural extension to the system? d) Is there _no_ document subsystem at all? I don't see anything obvious and this is rather scarry! How do you do document like things? Is it all up to you? For instance, I noticed that the text stuff has it's own read and write code, is it like this for everything? e) How does one implement custom text filters? For instance, what if I want to trap out TABs or something like that? The stuff in the FoundationKit looks moderately complete, although I haven't compared it to PowerPlant yet. Maury
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: OpenStep: Some questions Date: 06 Feb 1997 17:58:48 -0800 Organization: Cygnus Solutions Message-ID: <qdafphxtpj.fsf@blues.cygnus.com> References: <maury-0602971754210001@199.166.204.230> <5ddv6g$81v@news.xmission.com> don@globalobjects.com (Don Yacktman) writes: > > c) Is it just me or will the colour picking protocols make ColorSync a > > farily natural extension to the system? > > I would say you're right. The addition of Pantone a while back, > for the user, was a "minor" change and didn't impact the interface > much at all--other than making every app on the machine understand > Pantone, that is--and there's no reason any other color model or > system couldn't be added just as easily. :-) Also, doesn't the OpenStep API already try to make a division between device and calibrated color spaces? I'd imagine that ColorSync could help with that immensely... -- 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: 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, 05 Feb 1997 15:23:16 -0500 Organization: SoftArc Inc. Message-ID: <maury-0502971523160001@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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> <32F8E47B.1FCFFD97@screaming.org> In article <32F8E47B.1FCFFD97@screaming.org>, Pohl Longsine <pohl@screaming.org> wrote: > Wouldn't it be easier to teach the computer about how people > program than to teach the programmer how to jump through quirky > hoops in the toolbox? Point taken and all, but the user community outnumbers the developer community a bit (like 100 to 1). That has to be taken into consideration. Maury
From: mpinkert@cc.gatech.edu (Mike Pinkerton) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 06 Feb 1997 18:26:30 -0500 Organization: Georgia Tech Message-ID: <mpinkert-0602971826300001@fire.cc.gatech.edu> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> <geordie-ya02408000R0602971516280001@kyrie> In article <geordie-ya02408000R0602971516280001@kyrie>, geordie@chapman.com (Geordie Korper) wrote: >Actually I think Apple copied drag and drop from NeXT. It was certainly >implemented in NEXTSTEP first. Macintosh applications are only now getting >the interapplication level of drag and drop that NeXT has had since day >one. Very true. When I first saw a Next box waaaaay back, I saw the drag and drop integration and flexibility and I said, "Now THIS is what the Mac needs." When Apple finally gave it to us in System 7.5, I was overjoyed and it was the first thing I showed to all my PeeCee and UNIX friends. -- Mike Pinkerton mpinkert@cc.gatech.edu http://www.cc.gatech.edu/~mpinkert Cyberdog: On the Internet, no one knows you're an OpenDoc part
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: Wed, 05 Feb 1997 13:50:19 -0600 Organization: mementech, inc. Message-ID: <32F8E47B.1FCFFD97@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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tim Streater wrote: > (Travis Butler) wrote: > > > 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, > > Sad, isn't it, that some people still don't get this. Nerds are > frightened by this philosophy, though. Somebody has to stand up for the geeks, here. Apple's philosophy here was correct, but they dropped the ball and forgot to apply the same philosophy to the parts of the computer that are exposed to the programmer. Wouldn't it be easier to teach the computer about how people program than to teach the programmer how to jump through quirky hoops in the toolbox? NeXT took this philosophy from Apple and extended it so that it was not singularly focused on making life easier for the user. They decided that life should be better for the programmer, too, so that there could be better & more software (per unit programmer hour) for the users to buy. Make life better for *everybody* that has to interact with the machine, not just the user! (duh.) That philosophy is one of the things that's kept me loyal to NeXT. -- 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: phetsy@earthlink.net (Phetsy Calderon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 06 Feb 1997 18:00:41 -0800 Organization: NightStar Macintosh Consulting Message-ID: <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> In article <5ddvvd$lha@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > In article <connelly-ya023680000602970146410001@news.ziplink.net>, > Speaking of which, is there anything like a find/grep combination for Mac? Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you guessed it, lets you GREP Mac files. I believe it's in the Utilities folder, but if you haven't already, just download the <all-files.text> file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to find MacGREP's location. Phetsy Calderon phetsy@earthlink.net =========================================== The NightStar Company Macintosh consulting * Internet tutoring * Mac troubleshooting Voice/fax: 510/371-0445 Post: 4043 Guilford Ave., Livermore, CA 94550-5007 ===========================================
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 7 Feb 1997 02:36:59 GMT Organization: Boston University Message-ID: <5de4gb$np2@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> As a follow up to my own post, let me just add this: File name extensions as the OS-wide method of file type recognition: JUST SAY NO I could post a whole other rant on why the file extension concept should be thrown in the same bin as punch cards, but I'll leave it at that for now... -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 00:50:15 GMT Organization: Cygnus Solutions Message-ID: <5ddu87$oba$2@majipoor.cygnus.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddh2o$fh1@csugrad.cs.vt.edu> Cc: nurban@csugrad.cs.vt.edu In <5ddh2o$fh1@csugrad.cs.vt.edu> Nathan M. Urban wrote: > In article <connelly-ya023680000602970146410001@news.ziplink.net>, connelly@dawnstar.darc.org (Paul Connelly) wrote: > > > The shell is the best part of UNIX though. The tools that come > > with the shell are great. Just get rid of that horrid directory > > structure. (Let's see, is that program in /bin, or was it /usr/bin, > > or /usr/local/bin, or....?) > > Ah, who cares, as long as they're all in the path? > > Though the GNU Hurd is doing something interesting with filesystem > translators.. they can be used to conceptually merge the contents of > /bin, /usr/bin, etc., into one directory (/bin) even when the files are > stored all over the place.. everything is in /bin. That lets you keep > the old Unix organizational structure (I personally don't want 1000 > files in my /bin directory) yet always have everything "be in /bin". > Sounds similar to the Plan 9 solution.. which is to put mounts into user space. You don't have a path, you just mount what you want to in to /bin ;-) -- 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: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 18:58:52 GMT Organization: Cygnus Solutions Message-ID: <5dal9c$bd1$3@majipoor.cygnus.com> References: <5d8qta$6np@news.bu.edu> Cc: macintsh@bu.edu In <5d8qta$6np@news.bu.edu> John Siracusa wrote: > Jeez, I just read that 200+ post thread in c.s.next.programmer > about "ripping Unix out" of NeXTSTEP. I really don't think that > Apple is going to end up with "Unix with a GUI on top" at the > end of their Rhapsody development. > > Now I know most NeXT users love Unix. I know it's fun to tar > -cf - Papers | rsh pooh tar -xf - instead of using Apple file > sharing, but the plain fact is: that has never been a part of > the Mac OS experience. Nor is it generally part of the NeXT experience. As _MANY_ people have been telling you here on the groups, you can (and many people have) use Nextstep for years and never ever see anything related to Unix. > There are millions of Macs out ther, and the common thread > among them is that they don't require that type of thing! They > run Photoshop, Electric Image, PageMaker, and WordPerfect. > They *don't* run xdmcp, biod, rcp, emacs, vi, gcc, ld, troff, > and mv. And Nextstepers don't either. (hell, I'm a Unix sys admin, have been for years, and I don't even know what xdmcp IS) They don' t need mv, ld, troff, or a CLI editor to do everyday things. They can drag and drop files to move them, they can use the developers tools for compiling and linking, they can double click a file to load and run it, and they can use the GUI NFSManager.app to export and import file systems (and don't tell me mac users can do this without firing up an appleshare manager). And they can run WordPerfect, Tiffany, and a whole slew of top notch GUI apps that will give any same market Mac app a run for their money ANY DAY. This isn't the X world. > Further, you CANNOT hope to get the current millions of Mac > users to replace their OS with an OS that acts like Unix! > And believe me, no matter how much you "hide" the unix, it'll > never be "like a Mac" to those millions of users. You're right, Nextstep isn't "like a Mac". It's better. The people who brought you the Mac left Apple because Apple wasn't willing to take another risk and make something better.. and those people created NeXT, and created something better. A better polished GUI, with better integration and flexability. A more dynamic environment that is as friendly to developers AND users (novice and advanced) AND administrators as the Mac is to novice users. An environment that scales all the way from a single user standalone box to a distributed server on a hetergenous network. If the Mac could do that, why does Apple sell AIX for it's big end servers? > On a Mac, icons do not "represent" or "point to" or "indicate" > your files. They *ARE* your files. That icon *IS* your disk > drive. That just isn't going to happen in the world of Unix. This isn't windows 3.1 where deleting an icon means you still have the file on the drive and you have to delete it sperately. This isn't Win 95 or OS/2 where there are things on your desktop that have no relation to things in your filesystem. That icon is as tightly bound to a file or disk as your icon on a mac is. And just like on a Mac, not all icons are stored INSIDE the file's dataspace. The Mac does that _more_ than Nextstep, but the fact is the Mac doesn't do that for all files, and Nextstep does have files that store their icons inside one of their data segments. Not only can this happen in the world of Unix, it has been for the last 8 years. > And why *should* Apple keep *any* vestiges of Unix? All they > have to do is use a modern kernel with a modern API. Everything > else is an implemntation. Add a POSIX sublayer, if you want. > But there will be none of this /usr/bin foolishness. A huge > Unix tree of libraries and executables is simply not revelant in > an operating system that uses a MetroWerks development > environment and a Finder-like program for file manipulation. > Hell, even most modern Unix users and admins forego the soup of > two-letter shell-script-invoked untilities for a more > full-featured and reliable tool: perl Or they could rip out the core of Mac OS and run it on top of Unix. YOU would never know the difference. But I bet you'd sit here whining and sniveling about how annoying it would be to you to lose things you wouldn't even know were gone. Which contrasts with the Unix core of Nextstep where the things you want ripped out ARE useful and usable, and ARE important, and are already being sold by Apple on their high end servers (which run AIX, because Mac OS isn't up to the task). And while we're on the subject, compared to NeXT's development tools, Metroworks Codewarrior sucks. It's a static GUI builder (*hurl*) based around static languages and flimsy object wrappers around basically function oriented toolbox calls. The only way to get uglier is to use "Visual *". If Metroworks wants to jump in to the Rhapsody development environment that's great.. but if Apple drops Interface Builder and Project Builder, they're idiots. > You want Unix? Buy MkLinux! You want Unix in Rhapsody? Write > your own mini-Unix on top of the POSIX subsystem. Recompile > tcsh, mv, rm, cp, and friends, and away you go! Hell, I've got > a full Unix user environment on my SE/30 via MacMint, an > implementation of an Atari Unix, of all things. Filename > completion, command-line magic, perl, the works. There's no > reason a suitably insane person couldn't add this to his Mac. You're right.. And they did. It's called Mach Ten. And it's horribly slow, has no security to anyone at the console, and while usable, is barely acceptable, and your precious Mac OS is at fault for all of Mach Ten's short comings.. because as an _OS_, Mac OS sucks (Great GUI, crappy OS). Nextstep, on what has become a standard level of desktop computing power, is fast for both the CLI and GUI user, because it has a better infrastructure (which is guess what -- UNIX) and a better design that scales well. > But there's no reason a SANE Apple would compromise it's 12 year > old operating system and UI philosophy to keep it in its next- > generation OS! There's no reason a SANE Apple would continue on its current trend of clinging to a 12 year old OS that while it is only a few years more archaic than Win95, has no capacity for growth, nor their lack of growth and innovation philosophy that has become the Apple stagnation for the last several years. A Unix and Mach core at least has capability and infrastructure for a dynamic and growing environment. > Yes, it may be in there initially. But you can bet your > booty that they'll remove it as soon asn they get the chance. I'm willing to bet that by the time most people have a year of experience with something like Nextstep, they'll look at people like you for the ludite weirdos you are. > Don't get me wrong. Although I've owned a Mac since the 128k, > I'm an avid Unix user. Unix was the first platform I programmed > for, and I use it every day. But my Mac is my Mac. If I wanted > an OS on my desk at home in which I could cp my .cshrc to ~blee > I would be running Linux. > > Let me say it more simply: as much as you and I find perverse > joy in the nooks and crannies of a Unix world: > > *** MAC USERS WILL NEVER ACCEPT UNIX *** Tell that to the thousands of Nextstepers who came here from the Mac world. > and that's all there is to it. And guess what, there are about > 19 million more "Mac users" than there are "techies who like > Macs but secretly wish they could grep sometimes." Yeah, and how fast is your 19 million user Mac community shrinking because the OS is now behind the competition, and the GUI isn't that far ahead anymore? -- 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: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 05 Feb 1997 14:45:21 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32F8E351.24E0@subsequent.com> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Anton Rang wrote: > > In article <32F89AA4.1DC4@iquest.net>, sdmeyers <smee@iquest.net> wrote: > > You know it would be extreamly easy to map a GUI on top of UNIX in such a way > > that the User will work with it in the same way that they work with the MacOS > > today (of course in turn this OS would respond in a much better fashion to the > > user). > > Well, yes and no. While I agree that it's possible to build a decent > GUI for *file management* on a UNIX system, there are a lot of operations > a user can do on MacOS today which couldn't easily be done in a UNIX > environment without major changes. Nope. > Consider double-clicking a document. How do you know which program to > launch? HFS provides the type and creator, which together with the > desktop database define both the default application as well as a list of > other applications which know how to open the file. Typical UNIX file > systems don't have this information available to them, though there are > approaches to make it work most of the time (or all the time, if you can > enforce a file format with a fixed header). NeXTSTEP supports this, but using extensions. Before you panic, it's not brain-dead DOS extensions. For instance, a typical NeXTSTEP filename is something like "oracle database.eomodel" or "project schema.diagram2" Files under NeXTSTEP don't carry creator information. This wouldn't make sense in a multi-user environment like NeXTSTEP. Instead, each user selects a preferred application for opening files with a certain extension. Alternate applications can be set as the default very easily. Drag & drop also works - you can drop a file on another app to open it with that app. If you have no application that opens a file, it opens in a text editor (Edit.app). > But there are harder cases. Consider dropping a document onto the icon > for a currently running application. This should generally open it within > the app; but there is no standard way (in a generic UNIX) to communicate > this -- there is no equivalent to the AppleEvents which MacOS uses. (The > situation is worse when you think about full scriptability.) NeXTSTEP uses Distributed Objects to do this. The Workspace sends a DO message to the Application object in the application, passing the name of the document. Applications can publish objects with which you can communicate. > The Chooser (through its use of NBP) also provides functionality which > typical UNIX TCP/IP implementations don't. There's a lot of work to be > done to make any modern UNIX as user-friendly as the Mac. (I'm not saying > it's impossible; just hard.) It's been done. I used to work at a company with offices around the world. When you print a document under NeXTSTEP, the print panel lets you choose a printer. I could have printed the document on the other side of the planet. With a nice, friendly GUI. > As for what Apple may do ... who knows? The Mach kernel certainly > provides mechanisms which could be used for AppleEvents and the like; I > doubt they would try to promote a new system which didn't include at least > as much functionality as the current one (though it may take different > approaches). You should try to find a NeXTSTEP machine. Real estate agents say that 'buyers have no imagination'. The same appears true of computer users. -- jon@steeldriving.com
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: OpenStep: Some questions Date: Thu, 06 Feb 1997 19:43:22 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FA7AAA.4263@subsequent.com> References: <maury-0602971754210001@199.166.204.230> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Maury Markowitz wrote: > > I've been reading over the (sadly poorly formatted on my machine) > OpenStep docs for a couple of hours now. While I won't pretend to > understand a lot of it yet, I do have a few prelim questions: > > a) How big can text be? It doesn't really say. The Mac has a 32k limit > (grumble) and all the OOPS libs out there are based on it. I hope there's > no limit in OS? No limit that I know of, except perhaps RAM & disk space. > Having the picture embedding system in the standard text method will be > helpful too. The implementation strikes me as being either hackish or > brilliant, but either way it's good to see. > > b) How about making a spreadsheet view? Does NSMatrix support large > "sheets" with arbitrary data types? The documents seem to imply that it > doesn't. Does it support line-by-line or row-by-row selections? Again I > don't see this. I don't know if it's in the OpenStep spec, or included with OpenStep, but in EOF NeXT has a class called NXTableView which does this sort of thing. > c) Is it just me or will the colour picking protocols make ColorSync a > farily natural extension to the system? Should, yes. > d) Is there _no_ document subsystem at all? I don't see anything obvious > and this is rather scarry! How do you do document like things? Is it all > up to you? For instance, I noticed that the text stuff has it's own read > and write code, is it like this for everything? I'm not entirely sure what you mean here. Do you mean reading and writing data? There's no OpenStep document class, but there might be one in MiscKit. A lot of NeXT-application documents are saved as archived objects. Under OpenStep, you'd use NSArchiver to do this. You end up with an NSData object which can be written to disk. The reverse process is handled too, of course. > e) How does one implement custom text filters? For instance, what if I > want to trap out TABs or something like that? Take a look at NSString, NSScanner, and NSCharacterSet in FoundationKit. -- jon@steeldriving.com
From: sdmeyers <smee@iquest.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 05 Feb 1997 09:35:16 -0500 Organization: IQuest Internet, Inc. Message-ID: <32F89AA4.1DC4@iquest.net> References: <5d8qta$6np@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: <a bunch of anti-Unix drivel leading to the conclusion that...> > Let me say it more simply: as much as you and I find perverse > joy in the nooks and crannies of a Unix world: > > *** MAC USERS WILL NEVER ACCEPT UNIX *** > > and that's all there is to it. And guess what, there are about > 19 million more "Mac users" than there are "techies who like > Macs but secretly wish they could grep sometimes." > > -----------------+---------------------------------------- > John Siracusa | If you only have a hammer, you tend to > macintsh@bu.edu | see every problem as a nail. -- Maslow John... You know it would be extreamly easy to map a GUI on top of UNIX in such a way that the User will work with it in the same way that they work with the MacOS today (of course in turn this OS would respond in a much better fashion to the user). I would compare it somewhat to Win 95, but that would understate the fact that a scalable Unix based OS would best Win 95/NT in almost every catagory. ON the other hand removing this capability from this OS would be like removing the carmel nuggut from a Snickers(tm) bar, and that would not only be stupid, but it would suck too. -sdmeyers
From: Raul Sobon <a.sobon@pharmacology.unimelb.edu.au> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 15:40:01 +1100 Organization: BMU Message-ID: <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> References: <5ddp66$jpc@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: [rm -rf lotsofstuff] > 2. Text configuration files > I don't think there's anyone who would deny that messing with lines of > text is more error prone even in the best conditions (i.e. no user > modification of the file with a text editor to munge it up) simply > because each text files are so free-form. There are no constraints of > design to keep a badly behaved application from munging up a shared > configuration file. In this scenario, it's easy to see why there'd be > API calls! It minimizes the possibility of programmer error. But > that's just treating the symptoms! And ohh how wonderfull the Win95/NT solution of registry is... its NOT TEXT, but its binary.. and only regedit can edit it.. and IF IT GETS CURRUPTED as it often gets.. BOOM YOUR WIN95 is dead!!! and NOTHING but a clean install will fix it. How great non text config files work...NOT! text or not.. its all data to a program. Humans can read text and not binary like below... struct data { long *val; long flags; char filename[255]; }; -RAul
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 6 Feb 1997 19:42:42 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ddtq2$ier@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> In article <5ddp66$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > I challenge that implication, going so far as to claim that it is > the Mac's multi-forked file system that has separated it from other > OSes. One wonders if that's a good thing. One of the largest problems with the Mac filesystem is that it's a huge pain trying to transfer files to other platforms in a meaningful way. > 1. Hiding directories isn't the same as "hidden" resource forks. > Let me make this point as succinctly as I can: files and directories > are things that the user deals with. File forks are not. Any > mechanism, no matter how pervasive and consistent, that hides whole > directory trees is less desirable than a file structure that makes > large directory trees unnecessary because files and directories are by > their nature things that the user expects to have control over. NEXTSTEP uses document wrappers instead of file forks, which are directories which are treated like files. If the directory acts exactly like a file when the user manipulates it, then for all intents and purposes, it IS a file. (It still looks like a directory from the Unix CLI, though, which is also a good thing.. if you're working on the command-line, then you want a non-graphical way of getting at the contents of a document. Most Mac users will never touch the CLI, anyway.) > 2. File count! > I don't think there's anyone who would want *more* files related to > their OS littering their hard drive. I would -- if they're useful, of course! (I'm not sure what you're aiming at here, though.. directories like /bin, /usr/bin, etc. which would be "hidden" in the File Viewer, or the wrappers which replace file forks in documents and applications.) > <Old man voice ON> Back in the > olden days, the Mac OS ("System", dammit! ;) consisted of a System > file, a Finder application file, some DAs, and a smattering of printer > drivers. <Old man voice OFF> As Mac developers started to discover the > world of INITs, the System Folder became more crowded. System 7 and > later 7.1 separated the System Folder into a single level of sub- > folders, alleviating most of the clutter. Of course, there are > exceptions. NEXTSTEP's filesystem is rather well-organized.. except for the native Unix stuff, but that's hardly important to worry about as it will be hidden. None of the "dump everything in C:\WINDOWS" nightmare.. > But why is this a bad, thing? After all, if the directory structure is > standardized, who cares how complex it is? Well, as I see it, there are > many problems with even the most standardized and structured maze of > directories. > First, there's the problem of locating relevant information. Umm, face it. Things have to be stored on hard disks. They need to go somewhere. You can dump everything in one big file, or have lots of little files. > If, as a > user *or* a programmer, I want to, say, swap my file browser with > another, newer version, on a Mac I'd simply replace the Finder > application with a new one (this is a somewhat fictional example given > how 7.x now works, but this type of thing may happen in a future Mac OS > release. Humor me.) Doing the same thing in windows or Unix would not > be a task for the faint of heart, simply because you'd first have to > locate and remove every file associated with your file browser and > replace them with the new versions. You apparently have no idea how NEXTSTEP works. All the files that are associated with an application live inside the app wrapper bundle. If you move that, everything goes along for the ride. (Except your Preferences and any personal extension bundles you have installed.. those go in your home directory since they only apply to you, not to every user who users the application.) > Yes, installers could attempt to > handle this, but we all know how reliable they are. Quite reliable under NEXTSTEP, actually. There is a standardized package format which stores the location of everything installed in a Receipt file. > The reason for this disparity stems from the Mac's ability to shove all > related resources into one executable. Due to both historic practices > and their respective OS philosophies, Unix, Windows, and friends > instead scatter related resources all over the file system (they'd > *like* you to think all their files are in a single folder), NEXTSTEP does not. All the related resources ARE in a single folder, the app wrapper, which actually looks like a file to the user. > 2. Text configuration files > Also known as: the bane of "modern" OS design. I like them. > There is absolutely > *no* excuse for text-based configuration files in a modern GUI > operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, > they're readable by every lowly text editor. But cripes! When you > start providing API calls to add and delete lines from a text file > (GetProfileString(), etc.) you *know* you're barking up the wrong > tree! It's not too bad. Anyway, NEXTSTEP uses the NetInfo database for most configuration stuff.. though it also tends to manipulate config files to make the Unix people happy. > I don't think there's anyone who would deny that messing with lines of > text is more error prone even in the best conditions (i.e. no user > modification of the file with a text editor to munge it up) simply > because each text files are so free-form. There are no constraints of > design to keep a badly behaved application from munging up a shared > configuration file. Agreed. I've always thought it would be neat to use the GNU Hurd's filesystem translators to fix this.. keep everything in a database, and have a file translator sitting on top of the config file, so that when you read the file it really queries the database and then prints out the text file in the appropriate format from the result.. then things that expect the text config files can still use them, but you can start transitioning configuration over towards a cleaner database design. > An example relevant to Rhapsody (see, there *is* a connection buried > here ;) is how TCP/IP will be handled in the new OS. Ignoring the > ancient and ugly roots of the current Mac OS on which it runs, I'd > take the Open Transport control panels (Modem, TCP/IP, AppleTalk, > PPP) over a slew of .conf text files any day! I routinely switch > between FreePPP, OT/PPP, and direct ethernet connection with a few > flips of switches in control panels on my Mac. Try that with a Unix > box. If you decide you want to change from a direct connection to > PPP, you'd better hope you have the config files all set up, and > hopefully some shell scripts to moves everything around for you. Oh, > and you'd better not have changed the location of any of the files > that the scripts refer to. NeXT's admin tools do a good job of manipulating the config files. You never have to touch most of them yourselves. (Apple is working on changing that "most" to "all".) As for changing the location of the configuration files, I have no idea why you would do that. > And speaking of moving files, another disadvantage of text > configuration files is the hard-coding of file paths. Even Unix > symlinks are an example of the limitations of this scheme, although > not directly related to text config files. Say what you want about > the performance trade-offs of keeping track of aliases, Okay, I will. The performance trade-offs are awful. > but it's > certainly a better system than the "I'm scared to move anything > because everything might break" world of .INI files, et al. That's why NEXTSTEP tends to keep associated files in wrappers. I really think you ought to learn more about how NEXTSTEP (_NOT_ your plain vanilla Unix) does things before you go around spreading FUD. -- 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.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 6 Feb 1997 19:45:30 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ddtva$u31@csugrad.cs.vt.edu> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> In article <5ddpn1$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > What I'm concerned about > most is the support even simple Unix-isms like shell scripts require > in order to work. What do you mean by "support ... require[d] to work"? > IMO, this support system is not worth the small > advantages that a few advanced users will receive because it constrains > the rest of the OS too much. How does that "constrain the rest of the OS"??? > As I stated in my original post, a POSIX subsystem is fine. A Unix > directory tree appearing on my hard drive after a standard install is > not. I don't understand why not, considering that it doesn't take up that much more disk space, allows you to run any Unix programs you may wish to run in the future, is required by the OS to boot and do other administrative things, and doesn't even need to be seen by you. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.next.advocacy,comp.sys.next.hardware,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: Re: PPP Help!!! Anyone? Followup-To: comp.sys.next.sysadmin Date: Wed, 05 Feb 1997 10:19:05 -0600 Organization: mementech, inc. Message-ID: <32F8B2F9.54E682D1@screaming.org> References: <AF1D600C-2BE8A@207.13.170.22> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Andrew Kim wrote: > Is there any one can tell me how to set up PPP for OpenStep 4.0 > (040 Black) by step by step instruction? I'd like to point out here that it's really bad form to crosspost support questions to all of the comp.sys.next.* groups. Be more selective, please. -- 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.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy Subject: cancel <32F8F46E.634219C7@screaming.org> Control: cancel <32F8F46E.634219C7@screaming.org> Date: Wed, 05 Feb 1997 15:32:21 -0600 Organization: WaveFront Communications, Inc. Message-ID: <32F8FC65.78DD2258@screaming.org> References: <32F8F46E.634219C7@screaming.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message was cancelled from within Mozilla.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: OpenStep: Some questions Date: 7 Feb 1997 01:06:24 GMT Organization: Global Objects Inc. Message-ID: <5ddv6g$81v@news.xmission.com> References: <maury-0602971754210001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > a) How big can text be? It doesn't really say. The Mac has a 32k limit > (grumble) and all the OOPS libs out there are based on it. I hope there's > no limit in OS? You mean the NSText object I presume; both it and the NSString will dynamically grow to be as big as you need them to be. I've loaded multi-megabyte files into the text object and it seems to handle them quite well. (And the only performance degradation for loading a large file is the time it takes to load it; scrolling and editing are the same speed as for small files.) > Having the picture embedding system in the standard text method will be > helpful too. The implementation strikes me as being either hackish or > brilliant, but either way it's good to see. The idea of your Text object being extensible by composition is really quite elegant--and very powerful. This is one of the many patterns detailed in the GOF patterns book. > b) How about making a spreadsheet view? This is a "hole" iun the environment and should be added. The matrix is just a widget to hole a bunch of cells, but doesn't really work with multiple cells together. The NSTableView is a closer approximation to that, but still isn't quite what you want, I suspect. The answer is to write your own and donate it to the MiscKit or wait until somebody else does. (Or wait for the MiscKit idea to be assimilate by the core environment, which it usually will--eventually. :-) ) > c) Is it just me or will the colour picking protocols make ColorSync a > farily natural extension to the system? I would say you're right. The addition of Pantone a while back, for the user, was a "minor" change and didn't impact the interface much at all--other than making every app on the machine understand Pantone, that is--and there's no reason any other color model or system couldn't be added just as easily. :-) > d) Is there _no_ document subsystem at all? I don't see anything obvious > and this is rather scarry! How do you do document like things? Is it all > up to you? For instance, I noticed that the text stuff has it's own read > and write code, is it like this for everything? Here is a definite case for "use the MiscKit". We've built a flexible architecture for handling multiple documents. It still needs a lot of work (IMHO) but it is usable. This has long been a flaw in NEXTSTEP/OPENSTEP--but my answer to that is to plug the hole and then give everyone else access to my "stopper" via the MiscKit...so far that's worked pretty well. :-) > e) How does one implement custom text filters? For instance, what if I > want to trap out TABs or something like that? That's beyond the scope of a USENET posting. It can be done--I recommend looking at example code on the ftp archives or on an OPENSTEP system (what you're missing with web docs is all the megs of example code that comes with the developer release. It is an invaluable tool to see how to put things together to get something you can actually use. The general ref is helpful, but it really doesn't give the "big picture"--the best way to get that is still via looking at source code, IMHO. A good opportunity for a book, as I see it. (There are several books out there that do this with varying degress of success, but I still think there's room for more books on the topic. :-) ) > The stuff in the FoundationKit looks moderately complete, although I > haven't compared it to PowerPlant yet. Yeah, there's a lot there. But there are some things missing from the OPENSTEP spec like files, etc. (some of which are in NeXT's OPENSTEP, but not in Sun's--let's hope they get added to the spec!). -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
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: Wed, 05 Feb 1997 15:38:36 -0600 Organization: mementech, inc. Message-ID: <32F8FDDC.27EDF2C9@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> <AF17D80E96687E79C@node23.tfs.net> <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> <32F8E47B.1FCFFD97@screaming.org> <maury-0502971523160001@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: > > > Wouldn't it be easier to teach the computer about how people > > program than to teach the programmer how to jump through quirky > > hoops in the toolbox? > > Point taken and all, but the user community outnumbers the > developer community a bit (like 100 to 1). That has to be taken > into consideration. It should be taken into consideration in the following way: the minority produces every application that the majority uses. Apple, apparently, didn't see this in time or they wouldn't have felt the need to acquire NeXT. Apple's philosophy was myopically focused on the 100, and their religion was intentionally disrespectful to the one: The Evil Hacker Priesthood. NeXT chose a non-divisive philosophy that respected both, and Apple seems to appreciate the results. -- 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: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 06 Feb 1997 22:23:19 -0800 Organization: Esperance Communications Message-ID: <jk-0602972223190001@ip-salem3-30.teleport.com> References: <5d8qta$6np@news.bu.edu> <5dal9c$bd1$3@majipoor.cygnus.com> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <5dal9c$bd1$3@majipoor.cygnus.com>, jrudd@cygnus.com wrote: >You're right, Nextstep isn't "like a Mac". It's better. The people who >brought you the Mac left Apple because Apple wasn't willing to take another >risk and make something better.. and those people created NeXT, and created >something better. Hmm, I wasn't aware that "Reality Distortion Field.app" shipped with NEXTSTEP. :-) -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. Microsoft is not the answer. Microsoft is the question, the answer is no.
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 01:19:41 GMT Organization: Indiana University, Bloomington Message-ID: <5ddvvd$lha@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> NNTP-Posting-User: 1073745024 In article <connelly-ya023680000602970146410001@news.ziplink.net>, Paul Connelly <connelly@dawnstar.darc.org> wrote: >In article <5dbfr3$g10@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> Don't confuse the operating system with the shells. > >The shell is the best part of UNIX though. The tools that come >with the shell are great. Just get rid of that horrid directory >structure. (Let's see, is that program in /bin, or was it /usr/bin, >or /usr/local/bin, or....?) Speaking of which, is there anything like a find/grep combination for Mac? I may or may not have a document about Schrödinger that I'd like to look up. But I have no idea where it might be, and I'm sure it would be buried in file with a bunch of other stuff, and the name would have no relation to the subject. And I don't know where to get it from an outside source. I've made a few requests but got no response. I know, bad filing system. It wasn't designed, it evolved haphazardly whenever I found something new I wanted to keep. And I haven't had the gumption to start reading through everything on my hard drive. With a nice Unix command line, I could find out once and for all in about ten seconds' worth of typing. find and grep make information searches fun and easy. The search time is immaterial since I'd let it run while I read the Usenet. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 7 Feb 1997 00:44:00 GMT Organization: Cygnus Solutions Message-ID: <5ddtsg$oba$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> Cc: macintsh@bu.edu In <5ddp66$jpc@news.bu.edu> John Siracusa wrote: > This brings up what I think is one of the most important aspects of > the Mac/NeXT transition, and OS design in general: the file system. > > What I think is at the root of Unix's unsuitability for duty as a Mac > OS underpinning is the nature of it's "stream of data" file system. A > large percentage of the Mac's past and present ease of use advantage is > a result of its somewhat strange multi-forked file system. The reply > above seems to imply that there is no conceptual difference between > having a resource fork and having a folder full of separate files for > each application. > > I challenge that implication, going so far as to claim that it is > the Mac's multi-forked file system that has separated it from other > OSes. I'll look at this issue in three parts: > > 1. Hiding directories isn't the same as "hidden" resource forks. > > Let me make this point as succinctly as I can: files and directories > are things that the user deals with. File forks are not. Any > mechanism, no matter how pervasive and consistent, that hides whole > directory trees is less desirable than a file structure that makes > large directory trees unnecessary because files and directories are by > their nature things that the user expects to have control over. Yes, I > know the Mac has a few invisible files and folders. These are > exceptions that prove the rule. This point is open to personal > preference, but it is my opinion that vast majority of Mac users (most > of whom aren't reading and posting to comp.sys.xxx.programmer, BTW) > want things to work the way they do now, only faster and more stable. > Again, this is just my opinion. > Ohgod.. do we have to go through this AGAIN!? We already hashed this one out with Maury. NeXT used to have a 1 file mechanism for multi-segment binaries. The Mach-o file format was conceptually like resource forks, but with more forks. There was the Icon segment, a segment for each architecture's executable (all in one file), etc etc etc. More flexible than Resource Forks. But NeXT moved on from that becuase it is less flexible than Wrappers. By opening the file into multiple files that _can_ be accessed by advanced users, you can change sections of the code without any fancy tools. Things like UI elements, and optional Language localization features (which Gil Amelio has already said he wants to take advantage of). To the GUI user, a Wrapper looks EXACTLY like a file, except that it's executable. The only difference is to the CLI user (which you probably wont be anyway). The fact that folders and Wrappers are both implimented with the same file system element is just that.. an IMPLIMENTATION DETAIL. It does not change the user experience ONE BIT, unless you become advanced enough to appreciate the dynamic configurability and extensability of Wrappers (you could, for example, make a business of just adding multi-language support to apps that don't have it.. and you wouldn't need to have access to any special code from teh application vendor.. just the normal installed application -- because the wrapper is extensible, dynamic and HIERARCHICAL). > > 2. Text configuration files > > Also known as: the bane of "modern" OS design. There is absolutely > *no* excuse for text-based configuration files in a modern GUI > operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, > they're readable by every lowly text editor. But cripes! When you > start providing API calls to add and delete lines from a text file > (GetProfileString(), etc.) you *know* you're barking up the wrong > tree! > > I don't think there's anyone who would deny that messing with lines of > text is more error prone even in the best conditions (i.e. no user > modification of the file with a text editor to munge it up) simply > because each text files are so free-form. There are no constraints of > design to keep a badly behaved application from munging up a shared > configuration file. In this scenario, it's easy to see why there'd be > API calls! It minimizes the possibility of programmer error. But > that's just treating the symptoms! > I will be the first to deny this. Any application can trash any unprotected config file no matter what format it is in. And binary config files are no less error prone to novice users. In fact, they may be more so, as the person fires up a text editor to edit the binary one the first time, and accidently trashes it. API calls can be just as easily implimented to do text based config files as binary ones. There are advantages to binary config files, and to text config files. You have touched on none of the real advantages nor disadvantages of either. Try again. And, by the way, NeXT's system administration model, NetInfo, uses a binary database. Stop your whining and go use a NeXT system before you keep going on and on about how bad its' going to be. > An example relevant to Rhapsody (see, there *is* a connection buried > here ;) is how TCP/IP will be handled in the new OS. Ignoring the > ancient and ugly roots of the current Mac OS on which it runs, I'd > take the Open Transport control panels (Modem, TCP/IP, AppleTalk, > PPP) over a slew of .conf text files any day! I routinely switch > between FreePPP, OT/PPP, and direct ethernet connection with a few > flips of switches in control panels on my Mac. Try that with a Unix > box. If you decide you want to change from a direct connection to > PPP, you'd better hope you have the config files all set up, and > hopefully some shell scripts to moves everything around for you. Oh, > and you'd better not have changed the location of any of the files > that the scripts refer to. > I don't need to switch anything to do that on my Unix box. And it wouldnt' matter if it was NeXtstep or not. In fact, unlike you and your Mac, I can have PPP and ethernet going at the same time. But, generally, I can fire up PPP or close it down with one double click. That's it. I don't need to flip any control switches, change between system configurations, etc.. Unix is smart enough to know what aspects of your system are dialup networking configs and which are local networking configs. Without special add ons, Mac's can only use one network interface at a time. > And speaking of moving files, another disadvantage of text > configuration files is the hard-coding of file paths. Even Unix > symlinks are an example of the limitations of this scheme, although > not directly related to text config files. Say what you want about > the performance trade-offs of keeping track of aliases, but it's > certainly a better system than the "I'm scared to move anything > because everything might break" world of .INI files, et al. > Which is another reason to use Wrappers. Everything the application needs is in the wrapper or the system libraries. > As far as I'm concerned, a *modern* OS should be the best of both > worlds: the superb functionality of a preemptive memory-protected > kernel and the interface of the Mac (along with a file system that > allows it, of course!) > Correct.. the best of both worlds, the most solid OS core and foundations, the most usable UI, the most flexable and capable programming model. In otherwords, Nextstep. > Conclusion: > > Even the much-vaunted BeOS seems to suffer from file proliferation a la > Unix (/dev/modem anyone?) Perhaps this is unavoidable and I'm being > naive. After all, the *only* example of an OS that doesn't work this > way is the now-ancient Mac OS. But I don't thing there's any reason to > resign ourselves to the "me-too" world of evil OSes that require > "Uninstallers" and that keep us captive of a bazillion fragile text > files. There's a better way, and I only hope that in the coming years > the people behind the Mac/NeXT OS aren't afraid to break from the past > and give us an OS we can be proud to call "Mac." > Or proud to move on to the next generation of the Mac, invented by the same major visionaries of the Mac project.. called "The NeXT Computer". Obviously Apple finnaly realized that Jobs was right with the changes he wanted to make the Mac, and are now going to incorporate them. Now, before you go though these rants again, go out and use the damn thing. Stop arguing from a stance of total ignorance. -- 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: dirk@object-factory.com (Dirk Olmes) Newsgroups: comp.sys.next.programmer Subject: Re: NeXT Semaphores? help... Date: 5 Feb 1997 11:26:38 GMT Organization: Object Factory GmbH (Germany) Message-ID: <5d9qpe$mam@leonie.object-factory.com> References: <Pine.ULT.3.91.970204142535.17504A-100000@grizzly.cs.washington.edu> "Scott W. Bradley" <scottwb@cs.washington.edu> wrote: > I have a program that compiles on various other flavores of unix > that uses system semaphores. It does not compile on nextstep though. > I get things like "key_t" undefined. Alos, I can't even locate a header > file that I usually use called <sys/sem.h>. I can't seem to find > procedures like semget(). Can anybody please give any advice on how > to get this to work? > Help greatly appreciated > -scott Hi Scott, natively, NeXT does not have semaphores, shared memory etc. What you are looking for could be: ftp://ftp.cs.tu-berlin.de/pub/NeXT/misc/unix/commercial/SysVIPC-3.4.N IHS.b.tar.gz which is a commercial implementation of shared memory. Although it is a commercial product you should be able to produce binaries (which underly certain restrictions, then) -dirk --- ______________________________________________________________________ Dirk Olmes OBJECT FACTORY Gesellschaft fuer Informatik und Datenverarbeitung mbH Otto-Hahn Str. 18, 44227 Dortmund, Germany Telephon +49 (0) 231 975 137 0 Telefax +49 (0) 231 975 137 99 dirk@object-factory.com http://www.object-factory.com/ Hiroshima 45, Tschernobyl 86, Windows 95
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 06 Feb 1997 17:43:51 -0800 Organization: Cygnus Solutions Message-ID: <qdbu9xxueg.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > Here's an excerpt from one UseNet reader's response to a post of mine > about Unix and the NeXT-generation Mac OS: Note: This was a mail note that I sent to John. There, I've taken credit for it. :-) I also apologize in advance to everyone who's already gone through this with Maury. It's not clear that this is going to break any new ground, so you may just want to add this thread to the killfile now... That said, on with the show... [...] > 1. Hiding directories isn't the same as "hidden" resource forks. > > Let me make this point as succinctly as I can: files and directories > are things that the user deals with. File forks are not. John appears to have completely missed my point. Files and directories are *not* things the user deals with. They are things that exist on the file system. The user may play with representations of them, but the user doesn't have to deal with them any more than he has to know what an inode is. If I'm working on a NeXT box, I can see an application in the directory tree. In the GUI, I can move it into another folder, drag it to another drive, drop it in the recycler, or double-click it to fire it up. In all these actions, it works exactly the same as a similar application would on a Mac. I have no knowledge that the application is a single file on the Mac and a directory tree on the NeXT. It doesn't matter. It's an implementation detail, nothing more. > [...] it is my opinion that vast majority of Mac users [...] want > things to work the way they do now, only faster and more stable. I agree completely. That doesn't mean that they want to know everything about the file system, or that they want forks in their files. It means that they want to see files, and folders, and their trash can, and have the GUI actions that they're used to do the same thing as always. Try to separate how things are implemented at the file system level from how the user will deal with them. > 2. File count! [...] > The reason for this disparity stems from the Mac's ability to shove all > related resources into one executable. Due to both historic practices > and their respective OS philosophies, Unix, Windows, and friends > instead scatter related resources all over the file system (they'd > *like* you to think all their files are in a single folder), thus > making it nearly impossible to "wrap your mind around" every file > associated with a single application, let alone the whole OS or your > whole hard drive. The entire point of NeXT-style app wrappers is that you collect all the files associated with the application into one directory. Everything that you put under `related resources' goes right into the app wrapper. Your unsupported straw man arguments aside, if you can't drag the application into your recycler and have it *all* go away, it's not a well-designed NeXT-style application. You're not saying that the NeXT way is bad because of what NeXT is like, you're saying it's bad because of the way applications work in every other brand of Unix. I'll grant you that they're vastly different, but let's argue about the real situation rather than 1970s technology. > 2. Text configuration files (2? I thought we were on 3 :-) > Also known as: the bane of "modern" OS design. There is absolutely > *no* excuse for text-based configuration files in a modern GUI > operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, > they're readable by every lowly text editor. But cripes! When you > start providing API calls to add and delete lines from a text file > (GetProfileString(), etc.) you *know* you're barking up the wrong > tree! How so? If you stored all the information in a binary file, and provided the same API calls, would that somehow magically be better? Have you thought this argument out before committing it to the ether? If the information you're configuring is text-based, I don't see where it makes much difference. What you seem to want to argue is that config files should be forced to be under application control rather than user control, especially since your next argument... > [...] There are no constraints of design to keep a badly behaved > application from munging up a shared configuration file. ...is completely off the wall. If the application is badly behaved, it can screw up the file no matter how it's organized. Plus, just because it's text-based doesn't mean it can't have design constraints. > [...] I routinely switch between FreePPP, OT/PPP, and direct > ethernet connection with a few flips of switches in control panels > on my Mac. Try that with a Unix box. If you decide you want to > change from a direct connection to PPP, you'd better hope you have > the config files all set up, and hopefully some shell scripts to > moves everything around for you. That's odd, I thought I had that ability already on my NeXT at home. I didn't even have to worry about switching off my TCP/IP connection, either -- I can just click PPP and it adds in the network interface on the fly. > And speaking of moving files, another disadvantage of text > configuration files is the hard-coding of file paths. I can embed a file path just as easily in a binary config file. Again, what you want is for the configuration file to be under the control of the application, and ideally designed so that it stays with the application at all times. Hence, the app wrapper. > As far as I'm concerned, a *modern* OS should be the best of both > worlds: the superb functionality of a preemptive memory-protected > kernel and the interface of the Mac (along with a file system that > allows it, of course!) I have that on my NeXT. You have yet to say what it is about the *NeXT* way of doing things that is so horrendous. Since that way of doing things is probably what we're going to end up with, it would be good to hear about the problems with it. I haven't seen you talk about that yet, though. You told me in email that you'd used a NeXT, but you haven't given any examples. -- 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: misha@berlioz.osd.com (Misha M. Melikov) Newsgroups: comp.sys.next.programmer Subject: Documentation in PB 4.1 Date: 5 Feb 1997 21:19:57 GMT Organization: Seanet Online Services, Seattle WA Distribution: world Message-ID: <5datht$547@q.seanet.com> For some reason I can only see AppKit and Foundation documentation in ProjectBuilder 4.1. All other frameworks do not get indexed and documentation can not be seen. Any thoughts? Should I be able to see any other documentation or is it too much to ask? -m
From: Jim Gagnon <jimg@abacus.com> Newsgroups: comp.sys.next.programmer Subject: PDO and hooking in an ORB Date: Thu, 06 Feb 1997 15:09:11 -0800 Organization: Abacus Concepts, Inc. Message-ID: <32FA645B.2C4A@abacus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm in the process of learning OpenStep and am having problems in finding documentation on how to take an existing ORB and tie it into PDO so that it can successfully interoperate with other ORBs. If I can tie our application's object engine in with PDO, I can port all non-GUI code over in one fell swoop and focus on creating a new user interface for it. Any advice would be welcome. Thanks!
Newsgroups: comp.lang.objective-c,comp.sys.next.programmer From: stes@cwi.nl (David Stes) Subject: Re: "static inline" methods would be nice ... Message-ID: <E57pyw.D2C@cwi.nl> Sender: news@cwi.nl (The Daily Dross) Organization: CWI, Amsterdam References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> Distribution: comp Date: Fri, 7 Feb 1997 03:06:31 GMT In article <SHESS.97Feb6140159@slave.one.net> shess@one.net (Scott Hess) writes: >it, while still retaining the speed. Driesen describes means of >packing rows or columns together to make a single array that's smaller >than the matrix was. Note that all the exisiting OC runtimes use some form of hashtable to do the look-up. I suspect that's the "packed matrix". >Then method dispatch becomes something like: > > id objc_msgSend( id self, SEL _cmd, ...) { > IMP imp; > imp=impTable[ selectorTable[ _cmd]+self->isa->classNumber]; > return builtin_apply( imp, self, _cmd, ...); In the Portable Object Compiler, there's a single hashtable which basically gets an "imp" with a formula such as you describe. See the "objcrt" file, it's really just 60 lines of code for the entire Objective C runtime... (other runtimes sometimes have a table / class). The builtin-apply is actually something that C provides. If "imp" is a function pointer, (*imp)(...) will be application on the arguments. However, the compiler can emit a _cast_ before dereferencing the function pointer. This ability to cast before dereferencing, allows you to pass structs, or return structs etc. For example, the implementation of |perform:with:| goes like, - perform:(SEL)aSelector with:anObject { IMP imp = _imp(self,aSelector); return (*(id(*)(id,SEL,id))imp)(self,aSelector,anObject); } So it's first casting from function taking only two arguments (IMP) to function with three arguments and returning "id", and then it's dereferencing _that_ function pointer, and applying it on the 3 args. David.
From: Ian Russell Ollmann <iano@scripps.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 7 Feb 1997 00:46:31 -0800 Organization: The Scripps Research Institute, La Jolla, CA Message-ID: <Pine.SGI.3.95.970207003142.10697A-100000@wong> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: connelly@news.ziplink.net, glhansen@copper.ucs.indiana.edu In-Reply-To: <5de9k2$q13@dismay.ucs.indiana.edu> On 7 Feb 1997, Gregory Loren Hansen wrote: > In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, > Phetsy Calderon <phetsy@earthlink.net> wrote: > >In article <5ddvvd$lha@dismay.ucs.indiana.edu>, > >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > >> In article <connelly-ya023680000602970146410001@news.ziplink.net>, > > > >> Speaking of which, is there anything like a find/grep combination for Mac? > > > >Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you > >guessed it, lets you GREP Mac files. I believe it's in the Utilities > >folder, but if you haven't already, just download the <all-files.text> > >file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to > >find MacGREP's location. > > That sounds great. Except I'm not really sure what to do with that path. > I tried putting an "ftp:" in front of it, but Netscape says the connection > was refused. There are a whole series of info-mac mirror sites. The parent site is at sumex-aim.stanford.edu. Easier ones to get into are mirrors.aol.com and mirrors.apple.com. (e.g. ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/_Info-Mac_Help/) However, there are probably at least 20 such sites and maybe 50 or more. Unfortunately, (at the Apple site at least) MacGrep is either gone or called something else. There are two potentially grep related files, whose URL's are shown below. Hope that helps. ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/dev/card/grep-replace-xfcn.hqx ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/text/egrep.hqx Frankly, on the Apple, I find that if it is a specific text file, MS word or any of a half dozen word processors and text editors work fine enough for me. If you need to find a file with a particular word in it, but don't know which file it is, you can either wait for a Vtwin enabled finder under Rhapsody, if not Tempo or Allegro, or you could download TurboFind (http://www.moreinfo.com.au/access/TurboFind.html) today. Ian Ollmann
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: OpenStep: Some questions Date: 7 Feb 1997 04:22:01 GMT Organization: Digital Fix Development Message-ID: <5deal9$1uc@news.digifix.com> References: <maury-0602971754210001@199.166.204.230> In-Reply-To: <maury-0602971754210001@199.166.204.230> On 02/06/97, Maury Markowitz wrote: > I've been reading over the (sadly poorly formatted on my machine) >OpenStep docs for a couple of hours now. While I won't pretend to >understand a lot of it yet, I do have a few prelim questions: > >a) How big can text be? It doesn't really say. The Mac has a 32k limit >(grumble) and all the OOPS libs out there are based on it. I hope there's >no limit in OS? > I've loaded huge 5Mb files into the OpenStep TextEdit example. No problem. > Having the picture embedding system in the standard text method will be >helpful too. The implementation strikes me as being either hackish or >brilliant, but either way it's good to see. > >b) How about making a spreadsheet view? Does NSMatrix support large >"sheets" with arbitrary data types? The documents seem to imply that it >doesn't. Does it support line-by-line or row-by-row selections? Again I >don't see this. > Don't look at NSMatrix. Look at NSTableView. >c) Is it just me or will the colour picking protocols make ColorSync a >farily natural extension to the system? > Yep. Someone at Next has already mentioned this. >d) Is there _no_ document subsystem at all? I don't see anything obvious >and this is rather scarry! How do you do document like things? Is it all >up to you? For instance, I noticed that the text stuff has it's own read >and write code, is it like this for everything? There is no Document handling stuff in the Frameworks. There are several examples with OpenStep that implement documents, but nothing that is formally accepted as the 'way to do it'. Having said that, once you have a good working Documents.framework, its easy to re-use it where you need to. > >e) How does one implement custom text filters? For instance, what if I >want to trap out TABs or something like that? The new Text object is pretty complete, and a huge improvement on what the old Text object was. I've not had a chance to work with it at any length yet though... :-( > > The stuff in the FoundationKit looks moderately complete, although I >haven't compared it to PowerPlant yet. > -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 02:25:46 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FAD8FA.2C40@subsequent.com> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > > William Edward Woody (woody@alumni.caltech.edu) wrote: > : But get this: Mach is *NOT* Unix. Mach has been used to build a Unix > : compatable OS, and most people tend to build off of a Unix client > : built on top of the Mach kernel because that's what most of us > : programmers are familiar with. > > Granted, kernel and system calls are fine. What I'm concerned about > most is the support even simple Unix-isms like shell scripts require > in order to work. IMO, this support system is not worth the small > advantages that a few advanced users will receive because it constrains > the rest of the OS too much. How, exactly, does it 'constrain the rest of the OS too much'? How, exactly, has it constrained NeXTSTEP? -- jon@steeldriving.com
From: rdogra@mailserv.metro.mci.com (Rajnish Dogra) Newsgroups: comp.sys.next.programmer Subject: Re: Tutorial Question Date: 5 Feb 1997 12:42:38 GMT Organization: Internet MCI Message-ID: <5d9v7u$bb8$1@news-le0.internetmci.com> References: <5d8j5q$he2@bignews.shef.ac.uk> <AF1D8EEB-14415B@206.101.238.21> "Mark Jenkins" <markj@inwave.com> wrote: > >-----------------------------------------------Converter.m---------- -------------------------------- >#import "Converter.h" > >@implementation Converter > >- (float)convertAmount:(float)amt: byRate: (float)rate You put a colon after amt which is not correct in the above method. It should be like the following: - (float)convertAmount:(float)amt byRate: (float)rate Rajnish Dogra NeXTStep Developer
From: tiggr@es.ele.tue.nl (Pieter Schoenmakers) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 07 Feb 1997 10:05:11 +0100 Organization: Eindhoven University of Technology Sender: tiggr@tom.ics.ele.tue.nl Distribution: comp Message-ID: <x7ohdxf0l4.fsf@tom.ics.ele.tue.nl> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> <E57pyw.D2C@cwi.nl> In-reply-to: stes@cwi.nl's message of Fri, 7 Feb 1997 03:06:31 GMT CC: stes@cwi.nl In article <E57pyw.D2C@cwi.nl> stes@cwi.nl (David Stes) writes: Note that all the exisiting OC runtimes use some form of hashtable to do the look-up. I suspect that's the "packed matrix". The GNU Objective-C runtime uses per-class sparse arrays, indexed on selector id. The builtin-apply is actually something that C provides. If "imp" is a function pointer, (*imp)(...) will be application on the arguments. The __builtin_apply Scott refers to is GNU's. Though extremely low-level and machine dependent, it allows one to invoke any function with any number of arguments. For a good example on the use of __builtin_apply and __builtin_return, look at the implementation of the perform method in TOM (http://tom.ics.ele.tue.nl:8080), which is declared such: dynamic perform selector sel with dynamic arguments; It allows one to say things like: a = [obj perform some_sel with (1, 3.14, "a string")]; (a, b) = [obj perform sel2 with void]; (with a, b, obj, some_sel, and sel2 of an appropriate type). --Tiggr
From: Ian Russell Ollmann <iano@scripps.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 7 Feb 1997 01:16:42 -0800 Organization: The Scripps Research Institute, La Jolla, CA Message-ID: <Pine.SGI.3.95.970207004811.10697B-100000@wong> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Paul Connelly <connelly@dawnstar.darc.org> In-Reply-To: <connelly-ya023680000602970146410001@news.ziplink.net> On Thu, 6 Feb 1997, Paul Connelly wrote: > In article <5dbfr3$g10@dismay.ucs.indiana.edu>, > glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > Don't confuse the operating system with the shells. > > The shell is the best part of UNIX though. The tools that come > with the shell are great. Just get rid of that horrid directory > structure. (Let's see, is that program in /bin, or was it /usr/bin, > or /usr/local/bin, or....?) Ah, but why not just include them all in your path? Why, just look at the one I use .... . /usr/sbin /usr/bsd /sbin /usr/bin /bin /usr/bin/X11 /usr/biosym/950/biosym_bin /usr/biosym/950/irix5r3/biosym_exe /usr/pub /home/iano/bin/sgi /usr/etc /usr/lib /etc /usr/ucb /tsri/mb/net/news/sgi/bin /tsri/mb/gnu/sgi/bin /tsri/mb/soft/bin/sgi /tsri/mb/misc/bin/bin.sgi /tsri/mb/grafx/bin/bin.sgi /home/iano/bin/sgitest /tsri/gnu/sgi4DIRIX5/lib That gets just about everything. Of course, it changes if I log into another flavor of unix box. How about sun... . /usr/ucb /bin /usr/bin . /bin /usr/bin /usr/pub /home/iano/bin/sun4 /usr/etc /usr/lib /etc /usr/ucb /usr/openwin/bin /usr/openwin/bin/xview /usr/openwin/demo . /usr/ucb /bin /usr/bin . /bin /usr/bin /usr/pub /home/iano/bin/sun4 /usr/etc /usr/lib /etc /usr/ucb /nfs/crystal/export/asd/prog/XtalView/xtalmgr /nfs/crystal/export/asd/prog/XtalView/xfit /nfs/crystal/export/asd/prog/XtalView/xtty /nfs/crystal/export/asd/prog/sun4 /usr/tran/sun4/bin /usr/lang /usr/local/news/bin /home/iano/bin/sun4test /tsri/mb/net/news/sun4/bin /nfs/mbhost/mb/text/Xframe/bin /nfs/mbhost/mb/text/Xframe/bin/bin.sun4 /tsri/mb/misc/bin/bin.sun4 /tsri/mb/soft/bin/sun4 /tsri/mb/gnu/sun4/bin /tsri/mb/grafx/bin/bin.sun4 well, OK that was just sunOS 4, for sunOS 5 there is another one, and one for the HP's and another for the Convex and one for IRIX 6... Anyway, it is so simple a child could do it. Find out the name of your local sysadmin. If his loginID is ralph, then take the following steps: chmod 755 ~/.cshrc mv ~/.cshrc ~/.cshrc.bak cp ~ralph/.cshrc ~/. That ought to fix your path and if it doesn't, take it up with ralph. In fact, you should probably ask ralph if it causes any other confusing changes, too. Most sysadmins are very capable with questions such as that one in particular. At least, let's hope so. :-) Ian Ollmann
From: Patrick Schulz <schulz@freia.inf.tu-dresden.de> Newsgroups: comp.sys.sun.misc,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: OpenStep/Sparc Date: Fri, 07 Feb 1997 12:43:47 +0100 Organization: Institute of Computer Engineering, CS department, University of Technology Dresden, Germany Message-ID: <32FB1573.6445@freia.inf.tu-dresden.de> References: <32F19278.453B@erols.com> <5d5c30$8uq@mozo.cc.purdue.edu> <32FA5C21.3080@cyrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi OpenSteppers, > Openstep on Solaris is VERY slow. You're right. Sun could slightly increase performance in the current beta version, but it's IMHO not enough (compared to my NeXTstation). The bugs you mentioned are solved or in progress, just be a little bit more patient ;-) > There aren't many apps for Openstep solaris. I am sad that OW 2.0 isn't > available as I'm not too happy with some things of netscape. Agree, and IMHO the reason for that is OpenStep itself. Here's what I mean (taken from a letter to the MiscKit people): #OpenStep is promoted as a platform independend standard for a variety of #operating systems. The question is what platform independency means. #For me it's the ability to port a project in a very short time on a different #OS (much less than porting a X11-App). From my understanding an OpenStep #compliant program should be compilable on each OpenStep implementation without #major changes (I'm not talking about OS [processor] dependend code) . # #Since NeXT offers OPENSTEP I see a lot of problems for writing OpenStep #compliant Apps and Libraries. In detail they are: # #- proprietary format for InterfaceBuilder's .nib files (i.e. Sun's IB cannot handle # NeXT .nibs, you have to rebuild the complete interface) #- ClassClusters are not defined in the OpenStep standard, and do not work for # non-NeXT implementations #- all extensions to the OpenStep standard make programs not OpenStep compliant # (almost none of NeXT's AppKit examples can be ported to Solaris OpenStep, because # they're heavily using extensions like the new text system) #- there are still classes in use that remain from the old NeXTSTEP API (even the MiscKit # uses objects like Storage, NXZone, ...) #- the Framework concept and the new projectbuilder options (makefiles) require a # complete reorganization of the project on a different platform # #My results after 2 days hacking: # #- it's almost unprofitable to use the MiscKit2.x for a OpenStep implementation other # than NeXT's OPENSTEP #- the MiscKit is NOT OpenStep compliant including every application that's build upon #- the MiscKit would need significant changes to be portable (i.e. to Sun's OpenStep) #- there is no obvious benefit of the OpenStep standard # #To make OpenStep a really open standard I'd like to see: # #- keep all implementations in sync about extensions to the standard, provide upgrade # packages (free!) to close the gap (since there's a GNU implementation in the works # it's not done with a Sun<->NeXT license agreement) [NeXT's task] #- make the .nib format public and a standard [NeXT's task] #- remove all code using the NeXTSTEP API from your project [all programmers task] #- use STRICT_OPENSTEP as long as extensions are not public [all programmers task] #- separate compliant and non compliant code [all programmers task] # #I'm an OpenStep enthusiast, but I think the situation described above has #to change to be able to compete with other solutions like the Java SDK. > Everyone who sees it says that's neat. Definetely, I've never used a better UI on a Sun (I like to use a mouse :-) > It's OpenStep (looks like NeXTStep, feels like NeXTStep, but slower, > I have a NeXTStep machine...) hope for better times, the NeXT-Apple merger will make OpenStep more public and accepted, a good chance to clean up the portability problems mentioned above. Patrick. -- Patrick Schulz; Alaunstrasse 21a D-01099 Dresden; Germany email: schulz@freia.inf.tu-dresden.de (MIME & NeXTmail welcome) http://www.inf.tu-dresden.de/~ps3/ - vmunix: panic - no coffee detected, user halted.
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 7 Feb 1997 11:51:44 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E58EA9.53p@cam-ani.co.uk> References: <5ddp66$jpc@news.bu.edu> In article <5ddp66$jpc@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > An example relevant to Rhapsody (see, there *is* a connection buried > here ;) is how TCP/IP will be handled in the new OS. Ignoring the > ancient and ugly roots of the current Mac OS on which it runs, I'd > take the Open Transport control panels (Modem, TCP/IP, AppleTalk, > PPP) over a slew of .conf text files any day! I routinely switch > between FreePPP, OT/PPP, and direct ethernet connection with a few > flips of switches in control panels on my Mac. Try that with a Unix > box. Except that ANY unix will be smart enough to handle multiple interfaces. It will be quite happy to have one or more PPP links installed at teh same time as ether. It tests if the interfaces are valid, and uses them if they're working (including routing bewteen them if approriate). I therefore wouldn't have to do any config switching - it would just work. Not only is it easier to use than your so called easy switching system, its far more powerfull. Try setting up a mixed network of tcpip/appletalk and ether/localtalk/PPP and see how you get on useing your switching mechanism. $an
From: eb@con.de (Ernst Braun) Newsgroups: comp.sys.next.programmer Subject: Test only Date: 7 Feb 1997 14:11:06 GMT Organization: NetConsult Communications Message-ID: <5dfd5q$5qv@linux1.netconx.de> sorry, posted only for test
From: Gregory Loren Hansen <glhansen@indiana.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 7 Feb 1997 09:57:04 -0500 Organization: Indiana University, Bloomington Message-ID: <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> <Pine.SGI.3.95.970207003142.10697A-100000@wong> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII NNTP-Posting-User: 1073745024 In-Reply-To: <Pine.SGI.3.95.970207003142.10697A-100000@wong> On Fri, 7 Feb 1997, Ian Russell Ollmann wrote: > > > On 7 Feb 1997, Gregory Loren Hansen wrote: > > > In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, > > Phetsy Calderon <phetsy@earthlink.net> wrote: > > >In article <5ddvvd$lha@dismay.ucs.indiana.edu>, > > >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > > > >> In article <connelly-ya023680000602970146410001@news.ziplink.net>, > > > > > >> Speaking of which, is there anything like a find/grep combination for Mac? > > > > > >Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you > > >guessed it, lets you GREP Mac files. I believe it's in the Utilities > > >folder, but if you haven't already, just download the <all-files.text> > > >file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to > > >find MacGREP's location. > > > > That sounds great. Except I'm not really sure what to do with that path. > > I tried putting an "ftp:" in front of it, but Netscape says the connection > > was refused. > > There are a whole series of info-mac mirror sites. The parent site is at > sumex-aim.stanford.edu. Easier ones to get into are mirrors.aol.com and > mirrors.apple.com. (e.g. ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/_Info-Mac_Help/) > However, there are probably at least 20 such sites and maybe 50 or more. > > Unfortunately, (at the Apple site at least) MacGrep is either gone or > called something else. There are two potentially grep related files, whose > URL's are shown below. Hope that helps. > > ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/dev/card/grep-replace-xfcn.hqx > ftp://mirrors.apple.com/mirrors/Info-Mac.Archive/text/egrep.hqx Okay. I got a bunch of C source code. I'll have to try to make that work. Okay, I got TurboFind. I'm trying it out as I type do you. Looks like exactly the file/string search I wanted. Except I'm searching for "Erwin", and it keeps giving me "insidesendERWINdow) /*" in drag.c. I didn't know I had 30 copies of drag.c, but it went on to puzzleDrag.c and others, so it must be making forward progress. Looks like this one is worth the $10 the author is asking. You know, this seems like just the kind of thing OpenDoc would be good at. I realize OpenDoc has more flexibility than Unix-style streams, but each of the utilities could be a part, and a container app could be just a text command line and text output (with scrolling and printing and things, like SIOUX). That would be very nice. And those parts would also be available for any other OpenDocable app. And maybe a system() call that invokes the CLI container? GNU utilities for OpenDoc? It would all be very nice. AppleEvents scare me away, but I could handle system(). But I suppose there won't be much motivation to work on that kind of project until we see what comes with Rhapsody. Thanks!
From: syy@ecmwf.int (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 15:30:56 GMT Organization: ECMWF (European Weather Centre) Message-ID: <5dfhrg$73v@horus.ecmwf.int> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> In article <5dbfr3$g10@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) writes: |> In article <5d8qta$6np@news.bu.edu>, John Siracusa <macintsh@bu.edu> wrote: |> |> > *** MAC USERS WILL NEVER ACCEPT UNIX *** |> |> Don't confuse the operating system with the shells. |> |> If Apple put a nice GUI on any Unix, and provided control panels and menus |> to manipulate and administrate the system, you'd never know. You're forgetting the second (or maybe the first) major advantage of MacOS over UNIX: the filesystem. A pretty face can be painted on UNIX, in theory (if not yet in practice), but injecting a robust object-oriented filesystem is another matter entirely. UNIX filesystems typically provide no metadata structures analogous to the MacOS resource forks. BeOS attempts to provide something like this, but I believe it's done with a bolt-on database, not as a native part of the filesystem structure. NeXT may do something similar (I don't know) but again, it's likely to be a bolt-on. Rhapsody must provide all of the human interface correctness of MacOS along with at least as good a filesystem architecture before I'll be interested. -- Mike Connally Consultant, Data Handling Project European Centre for Medium-Range Weather Forecasts (ECMWF) Shinfield Park, Reading, Berks RG2 9AX England Tel: +44-1734-499253 Email: Mike.Connally@ecmwf.int
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 16:22:52 GMT Organization: Indiana University, Bloomington Message-ID: <5dfkss$cl1@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <5de9k2$q13@dismay.ucs.indiana.edu> <Pine.SGI.3.95.970207003142.10697A-100000@wong> <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu> NNTP-Posting-User: glhansen In article <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu>, Gregory Loren Hansen <glhansen@indiana.edu> wrote: >Okay, I got TurboFind. I'm trying it out as I type do you. Looks like >exactly the file/string search I wanted. Except I'm searching for >"Erwin", and it keeps giving me "insidesendERWINdow) /*" in drag.c. I >didn't know I had 30 copies of drag.c, but it went on to puzzleDrag.c and Okay, now I get it. There were 30 occurences in the file drag.c. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: rflattin@cornut.fr (Roger Flattin) Newsgroups: comp.sys.next.programmer Distribution: world Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 07 Feb 1997 17:05:06 GMT Message-ID: <2252931071.5809221@cornut.fr> Organization: Cornut Informatique SA Ian Ollmann wrote: >for me. If you need to find a file with a particular word in it, but don't >know which file it is, you can either wait for a Vtwin enabled finder >under Rhapsody, if not Tempo or Allegro, or you could download TurboFind >(http://www.moreinfo.com.au/access/TurboFind.html) today. To find a file with a particular word you can simply use the Find (Command-F) utility supply with MacOS 7. You just have to click on the popup that contains "name", "size" while the option key is pressed. At this point, some new items appears in the popup. Among them, a "content" item allows you to find by content. This method works fine but the search engine is slow. Roger FLATTIN e-mail: rflattin@cornut.fr ---->> On our site a SHAREWARE SQL Query Tool <<-------- --->> Don't forget to Try also our C/S Dev tool <<------- CORNUT Informatique SA Client/Server & SQL RDBMS BP 702 - 42950 St Etienne cedex 9 http://www.cornut.fr/ France email: info@cornut.fr
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: OpenStep: Some questions Date: Fri, 07 Feb 1997 11:31:23 -0500 Organization: SoftArc Inc. Message-ID: <maury-0702971131230001@199.166.204.230> References: <maury-0602971754210001@199.166.204.230> <5ddv6g$81v@news.xmission.com> In article <5ddv6g$81v@news.xmission.com>, don@globalobjects.com wrote: > You mean the NSText object I presume; both it and the NSString > will dynamically grow to be as big as you need them to be. I've > loaded multi-megabyte files into the text object and it seems to > handle them quite well. Phew. > (And the only performance degradation for > loading a large file is the time it takes to load it; scrolling > and editing are the same speed as for small files.) Double phew. Is it VM'ed or memory mapped files? > The idea of your Text object being extensible by composition is > really quite elegant--and very powerful. This is one of the many > patterns detailed in the GOF patterns book. Yeah, but it's pictures only and via a "fake char". A robust embedding system like the one from OpenDoc would be a boon. > This is a "hole" iun the environment and should be added. The > matrix is just a widget to hole a bunch of cells, but doesn't > really work with multiple cells together. The NSTableView is > a closer approximation to that, but still isn't quite what you > want, I suspect. The answer is to write your own and donate it > to the MiscKit or wait until somebody else does. (Or wait for > the MiscKit idea to be assimilate by the core environment, which > it usually will--eventually. :-) ) Well I don't think I'm nearly ready to write a production spreadsheet view as of yet, I'm still having trouble with Borland installs... To be more accurate I've seen the growing pains that PowerPlant has gone through in this regard and I'd rather let the dust of more experienced people settle and learn from their mistakes. However, you may wish to consider dropping Andy Dent a note. He was working on a massive extension to the PP Table system, integrating it with documents and his _superb_ OOFile persistant object/database system (now THERE'S some code that should come with Rhapsody!) and some cross fertilization might prove useful. > I would say you're right. The addition of Pantone a while back, > for the user, was a "minor" change and didn't impact the interface > much at all--other than making every app on the machine understand > Pantone, that is--and there's no reason any other color model or > system couldn't be added just as easily. :-) Yeah, that's what I was thinking. The issue appears to be limited entirely to making DPS understand colour correction, because ColorSync actually modified the colour tables of the monitors for correct display, as well as providing a natural "selector". > Here is a definite case for "use the MiscKit". We've built a > flexible architecture for handling multiple documents. It still > needs a lot of work (IMHO) but it is usable. This has long been > a flaw in NEXTSTEP/OPENSTEP--but my answer to that is to plug > the hole and then give everyone else access to my "stopper" via > the MiscKit...so far that's worked pretty well. :-) Fair enough. > That's beyond the scope of a USENET posting. It can be done--I > recommend looking at example code on the ftp archives or on an > OPENSTEP system I'd need one first. :-) Maury
Newsgroups: comp.lang.objective-c,comp.sys.next.programmer From: stes@cwi.nl (David Stes) Subject: Re: "static inline" methods would be nice ... Message-ID: <E58uuu.Hsp@cwi.nl> Sender: news@cwi.nl (The Daily Dross) Organization: CWI, Amsterdam References: <SHESS.97Feb6140159@slave.one.net> <E57pyw.D2C@cwi.nl> <x7ohdxf0l4.fsf@tom.ics.ele.tue.nl> Distribution: comp Date: Fri, 7 Feb 1997 17:49:42 GMT In article <x7ohdxf0l4.fsf@tom.ics.ele.tue.nl> tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes: >In article <E57pyw.D2C@cwi.nl> stes@cwi.nl (David Stes) writes: > > Note that all the exisiting OC runtimes use some form of hashtable to do > the look-up. I suspect that's the "packed matrix". > >The GNU Objective-C runtime uses per-class sparse arrays, indexed on >selector id. And the Portable Object Compiler "objcrt" uses a single "cache", where the "lookup code" is like index = ((aSel^shr) % CACHESIZE); if (clsCache[index] == (id)shr && selCache[index] == aSel && !no_cache) return impCache[index]; > The builtin-apply is actually something that C provides. If "imp" is > a function pointer, (*imp)(...) will be application on the arguments. Note that you have omitted the essential part of the posting, about the function pointer cast, which shows that it is possible to do OC messaging in "pure C" without something like a builtin function to build stackframes. This is an idea of Ken Lerman's (as far as I know), but also discussed in the 2nd edition of Brad Cox' book. The original Stepstone objc's, including the 4.0 from which NeXT's is derived, and hence by extension also GNU's, translates something like [a message:b] into _msg(a,sel,b) /* sel == @selector(message:) */ and the prototype of _msg (or objcMsgSend or whatever) is _msg(id,SEL,...) Key point : the messenger takes the argumnets of the message as arguments (the ... in the prototype) The Portable Object Compiler messenger does NOT take the message arguments, as arguments. [a message:b] translates into 2 statements (actually 1 "comma" statement) (imp=_imp(a,sel), (*(id(*)(id,SEL,id))imp)(a,sel,b)) David.
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: NeXT Semaphores? help... Date: Fri, 7 Feb 97 01:21:15 +0100 Organization: Warty Wolfs Message-ID: <9702070021.AA04930@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) -----BEGIN PGP SIGNED MESSAGE----- In article <5d9qpe$mam@leonie.object-factory.com>, dirk@object-factory.com (Dirk Olmes) wrote: > "Scott W. Bradley" <scottwb@cs.washington.edu> wrote: > > I have a program that compiles on various other flavores of > > unix that uses system semaphores. It does not compile on nextstep > > though. I get things like "key_t" undefined. Alos, I can't > > even locate a header file that I usually use called <sys/sem.h>. > > I can't seem to find procedures like semget(). Can anybody > > please give any advice on how to get this to work? > > Help greatly appreciated > > natively, NeXT does not have semaphores, shared memory etc. What > you are looking for could be: [URL snipped, see below for the "canonical" location.] > > which is a commercial implementation of shared memory. Although > it is a commercial product you should be able to produce binaries > (which underly certain restrictions, then) [...Here speaketh the author of SysVIPC...] Actually, there are no employment restrictions on binaries linked against SysVIPC, and there never has been. Note that we've changed the licensing terms of SysVIPC about a year ago. Here is the revised announcement: - -------- R&A SysVIPC v3.4 FREE FOR EDUCATIONAL USE AND DISTRIBUTED VIA THE NET R&A CHANGES LICENSING CONDITIONS AND DISTRIBUTION SCHEME FOR SysVIPC v3.4 Contact: Info@RnA.nl R&A today announces a change in the licensing conditions of SysVIPC v3.4. In short, these changes are: 1. SysVIPC is from now on distributed via the Internet. The fully functional binary distribution can be found in the directory: ftp://ftp.nl.net/pub/comp/next/SysVIPC/ 2. Use for educational purposes is free. Note that it is 'educational use' and not 'educational users'. If you want to use SysVIPC for commercial activities, you still need a license. Original version 3.4 announcement (with adapted prices) follows: R&A SHIPS Quad-fat SysVIPC V3.4 SHARED MEMORY & SEMPAHORE EMULATION FOR NEXTSTEP FREE UPGRADE FOR EXISTING CUSTOMERS *) Version 3.4, second release A new version due to shipping quad-fat (m68k, i486, hppa, sparc). Prices have changed to Dfl instead of US $. Two bugs have been fixed since pre-3.4 releases. *) Contact Info@RnA.NL for details Version 3.2 Version 3.2 differs from version 3 only with respect to POSIX support. The POSIX implementation and the BSD implementation of the directory functions and structures of NEXTSTEP 3.2 are not binary compatible. Version 3.2 of SysVIPC supports both. Follows: the text of the original Version 3 release with adapted prices R&A announces the shipping of the second release of SysVIPC: version 3. This version maximises the emulation completeness of the implementation within the constraints of security and speed. System V style IPC is used widely on SunOS, Ultrix and most System V Unix implementations for interprocess synchronisation and is not part of the NEXTSTEP developer libraries. Product description: SysVIPC offers NEXTSTEP programmers the possibility to use Unix System V style shared memory and semaphores in their code, thus enhancing portability on one side and easier porting of existing applications that use the Unix System V shared memory and semaphore API. Operating systems that include that API are (besides System V Unix implementations) for instance Digital Corporation's Ultrix 4.x and Sun Microsystem's SunOS 4.x BSD-style Unix implementations. R&A, for instance, used SysVIPC internally for the shared memory and semaphores when porting the University Postgres RDBMS (which is available as a separate product). The implementation does not need any change on the systems where programs created with SysVIPC are executed. Just installing on the developer system is enough. The following library calls are supported: semctl, semget, semop, shmctl, shmget, shmat, shmdt, ftok The following programs are included: ipcs, ipcrm The software license allows copies of the executables of icps and icprm to be shipped with your product. The implementation is as good as 100% complete (sometimes even more than complete). There are a few minor incompatibilities and some extra compatibilities beyond the API on the implementation level. These differences are (implementation level compatibilities are marked with '+', incompatibilities are marked with '-' and remarks are marked with 'o'): + Shmids and semids are system-wide unique -- as most System V-like implementations, including those of Ultrix and SunOS. This means that you can create, for instance, a semaphore set with semget() in one process, scribble the semid obtained by that down, and use it directly in another process to access that same semaphore set. This is important especially when porting programs that use this feature of the common implementations (which appear to be many). For a strict implementation of the API this is not necessary. Code from systems like SCO Unix (where the ids are on a per process basis) is not affected by the added functionality of system-wide id uniqueness. - - You cannot give away a semaphore- or shared-memory id to another user unless you are the super user. A semid or shmid is owned by a single user at a time, just like a file. (on System V it can be owned by the creator and another user.) Not being able to give away has to do with the general possibility on System V to give away things to other users. On System V, for instance, you can give away files. This behaviour is neither part of Mach nor of BSD. Our implementation is not loaded in the kernel, but runs in user space. Therefore, we had to choose between API compatibility and security. We chose to implement the latter, since in most situation this behaviour is not used anyway. Semaphores: - - all semop() and semctl() operations require READ + WRITE access to the semid, even those that according to the documentation only need READ access. This incompatibility is automatically lifted by our implementation for semaphores that are from the same owner. This incompatibility also has to do with our choice for security vs. completeness. In almost all cases developers will not be affected, since mostly semaphore operations are from one and the same user. Shared memory: + a single shmid can be attached multiple times by the same program (to different addresses) -- this is the behaviour of most System V implementations, including those of Ultrix and SunOS, but it is usually not clearly documented. Another beyond-the-API compatibility that is useful for porting existing code. o all shmids require at least READ access in order to be useful - this is also true of System V shmids, but again, is usually not clearly pointed out. - - shmat() and shmdt() cannot update the shmid_ds control structure if the shmid is read-only. Another security vs. API conflict for a user-space implementation. - - the emulation is not aware of processes that do not explicitly detach their shared memory segments before exiting. In short, the `shm_nattch' count may not reflect the actual number of segments attached. This would need some sort of server process, or a kernel implementation. Since we use a user-space implementation, we had to leave out the server for improved speed (and ease of use on the client side). o the shmctl() commands SHM_LOCK and SHM_UNLOCK are currently not implemented -- these are used in other implementations to lock/unlock the shared memory segment in physical memory, i.e., to avoid swapping (for performance?) The API defined behaviour is not affected by ignoring these. They are also impossible to implement in a user-space implementation. Also speed is not really affected by leaving these out. NB: We advise strongly against using the "beyond the API" parts of System V shared memory and semaphores when developing new code. The availablity of this behaviour is not guaranteed on other systems (e.g. SCO Unix), thus diminishing the portability of your code. You might wonder why we did not choose for a kernel-space implementation. Kernel loadable would have to be loaded on every machine that you run your software on. This implies heavy system administration and a big burden for anybody who wants to sell products that use our implementation. The user-space implementation does not have that disadvantage and is also inherently more safe to use. Any error in our implementation (of which we are not aware that there exists one) will not bring down the kernel, but merely a user process. The SysVIPC binary distribution is shipped as MAB (Version 3.4 for Intel 486, Motorola m68k and Hewlett-Packard PA-RISC architectures). Price and ordering information Prices as of 24/2/96 (may change without notice). Prices are in dutch guilders. License cost License Price Edu use 1st CPU binary Dfl 1000 shareware 2nd - 5th CPU binary Dfl 800 shareware 6th - 50th CPU binary Dfl 600 shareware 51th - 100th CPU binary Dfl 400 shareware All other CPU's Dfl 200 shareware Source license 10 times binary NA There is no runtime fee (so in general, just a few licenses are enough for any organisation, just on the developer side, and source licenses are for sites who require source control over as many parts of their product as possible). Note: SysVIPC is shareware for educational 'use', not for educational 'users'. This implies that you can use it for educational uses in commercial environments and you can't use it for commercial purposes in educational environments. Shareware means: we'd like to get money from you but it is not required. Send us money if you really like the package. Prices are without shipping, handling and VAT (Dutch VAT is 17.5%). Customers outside the European Union do not pay VAT. Customers inside the EU do, unless they send us their VAT registration number. Shipping and handling: Destination Shipping The Netherlands Dfl 15 Europe Dfl 20 Rest of the world Dfl 25 How to order Customers in the Netherlands may send a written order. A bill will be enclosed with the shipment. All other customers have to pre pay. No credit cards accepted. The best way to pay is to go to a bank that has access to SWIFT. Customer pays money transfer cost of both sides (which should normally lie around Dfl 15 per side). Bank to send money to: ABM-AMRO Bank Kneuterdijk 8 The Hague The Netherlands Account: 40.16.84.016 R&A Information: what you purchase and where to send it. In general: give as much info as you can. We do accept certified cheques. They should be written out in Dfl. Eurocheques are accepted and there is no payment fee involved. Make sure the Eurocheque is written in Dfl. Packaging SysVIPC comes in an installer package for NEXTSTEP 3.1 or higher on a 3.5" HD floppy disk. The package includes full documentation in the form of Unix man pages, as well as the ipcs and ipcrm programs. Both library and programs are in MAB format for all supported architectures. The source license comes with full sources for library, man pages and programs added to the mentioned binary installer package. Contact R&A Goudreinetstraat 582 2564 PX Den Haag The Netherlands Email: Info@RnA.NL We prefer e-mail. NeXTmail welcome. R&A is a small firm specialized in quality software design and implementation and consultancy. We are specialized in OO, Unix, NEXTSTEP and portability. Acknowledgements Ultrix is a trademark of Digital, SunOS is a trademark of Sun, SCO is a trademark of the Santa Cruz Operation, Unix is a trademark of USL, NEXTSTEP is a trademark of NEXT. All trademarks belong to their respective owners. - -------- end SySVIPC announce -------- Regards, - -- __/__/__/__/ Tom Hageman <tom@basil.icce.rug.nl> [NeXTmail/Mime OK] __/ __/_/ <Tom_Hageman@RnA.nl> __/__/__/ "Any magic sufficiently advanced is indistinguishable __/ _/_/ from a perl script" -- Larry Wall, mangled -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: next iQCVAwUBMvp1fDHcGwCnCAFpAQEt5wP+P8sLQqZttI8d4riWZ+1u/TaEWwhx7C6k Zbqnj6W1erdQgPkVh/1RKGq7MkVAZ2viRBJxARtLJgTe9rJ5MftrDxUaCdFY816m AlJO55jiYDJzi0V3ObI/9F5txOiPP35p3AZM8QB/HO5z4EX91QXYEqi+Kgv0c2ry sA+67VnSA/w= =P9eL -----END PGP SIGNATURE-----
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Date: 7 Feb 97 10:22:33 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb7102233@howard.one.net> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> In-reply-to: macintsh@bu.edu's message of 6 Feb 1997 23:32:49 GMT In article <5ddpn1$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) writes: Granted, kernel and system calls are fine. What I'm concerned about most is the support even simple Unix-isms like shell scripts require in order to work. IMO, this support system is not worth the small advantages that a few advanced users will receive because it constrains the rest of the OS too much. The "support issues" would be: o Support for fork()/exec(). Those have to be present in some form or another on _any_ O/S, and fork()/exec() are pretty nice. They are a bit more primitive than many people would like, but there's no reason you couldn't have library functions to hide them. But, while it's possible to build up more complex launch semantics from fork()/exec(), it's almost _impossible_ to emulate fork()/exec() reasonably over anything more complex. o The ability for the kernel to recognize #! as magic when trying to exec() a file. Hmm. How are these constraining things? Of course, there are other support issues. For instance, if you want to support a CLI environment for your power users, you'll need something like a pty driver. And if you want to let remote users telnet into your machine. And a tty driver if you want people to come in via serial ports. Personally, I'd rather these important abstractions are abstracted _once_, by the vendor, rather than 35 times by each individual vendor shipping a connectivity package. The overall thing to keep in mind, here, is that while it's usually quite easy to emulate simpler systems on more complex systems (single-user on a multi-user system, single-tasking on a multi-tasking system, no file protections on a filesystem with protections, no networking on a system with networking), it's often hard unto impossiblity to emulate more complex systems on less complex systems. I'd rather start with an overcapable system and remove/ignore things than start with an incapable system and try to graft new functionality onto it, and ending up with something _nobody_ really cares for. 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: phetsy@earthlink.net (Phetsy Calderon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 09:19:20 -0800 Organization: NightStar Macintosh Consulting Message-ID: <phetsy-0702970919210001@cust113.max3.santa-clara.ca.ms.uu.net> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> In article <5de9k2$q13@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, > Phetsy Calderon <phetsy@earthlink.net> wrote: > >In article <5ddvvd$lha@dismay.ucs.indiana.edu>, > >Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you > >guessed it, lets you GREP Mac files.... Path is /mirrors/Info-Mac_Help/all-files.text. >Search this file to > >find MacGREP's location. > > That sounds great. Except I'm not really sure what to do with that path. > I tried putting an "ftp:" in front of it, but Netscape says the connection > was refused. Sorry Greg--I have the Info-Mac path so firmly engraved in my brain I forget that normal human beings use brain space to remember dates with their spouses and what to put in their coffee ;-). You need to access an Info-Mac site: I use the mirror in Hawai'i, because it's the 2nd-closest to me, geographically speaking (the main site, Info-Mac at Stanford, is but 50 miles away, but the odds of getting into it are about the same as hitting the lottery). So the path I use is <ftp:ftp.hawaii.edu/mirrors/Info-Mac>. It looks like you're posting from an Indiana location, so you might want to hit the mirror at U of Iowa. Path is <ftp://grind.isca.uiowa.edu/mac/infomac/>. There's also a Canadian site <ftp://ftp.ucs.ubc.ca/pub/mac/info-mac/>, and one at Rice University <ftp://ricevm1.rice.edu/>. Phetsy Calderon phetsy@earthlink.net =========================================== The NightStar Company Macintosh consulting * Internet tutoring * Mac troubleshooting Voice/fax: 510/371-0445 Post: 4043 Guilford Ave., Livermore, CA 94550-5007 ===========================================
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 18:33:18 GMT Organization: Rockwell Avionics - Collins Message-ID: <5dajpe$a63@castor.cca.rockwell.com> References: <5d8qta$6np@news.bu.edu> Cc: macintsh@bu.edu In <5d8qta$6np@news.bu.edu> John Siracusa wrote: > Jeez, I just read that 200+ post thread in c.s.next.programmer > about "ripping Unix out" of NeXTSTEP. I really don't think that > Apple is going to end up with "Unix with a GUI on top" at the > end of their Rhapsody development. JEEZ... Have you ever USED NeXTStep. I employ many artists who have been using NeXTstep and Macs happily for years and are not yet aware that NeXT has anything to do with UNIX. Most do not even know that a terminal emulator exists or for what it might be used. These same users do appreciate NFS networking, multiuser machines that let them sit at whichever machine suits them and get work done. They also appreciate the fact that the machines almost never crash. We have several machines that have not been rebooted in almost two years. We have ONE machine that is rebooted every night because of the infamous "SWAP FILE" problem.
From: Stefano Pagiola <spagiola@worldbank.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 14:45:21 -0500 Organization: World Bank Message-ID: <32FB8651.243F@worldbank.org> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Jenks wrote: > One of the things that makes the Mac a joy to use is that I can create a > file in an application and name it anything I choose. Double click the > file and the application that created it will launch and open it. > > On Win 95 I have both Borland and MS compilers installed. After > installing the Borland compiler all my MS Visual C (*.c/cpp) created > files now insist on openning with the Borland compiler when I double > click them! I can't have some *.c/cpp files open with VC and others with > Borland and of course they must end in c/cpp to open with either one. > > What is the a type/creator mechanism on NextOS that will prevent this > step backwards in usability for Mac users in the future? The OS keeps track of all the filetypes an app can deal with. Through the Workspace's inspector, you can specify which app will, by default open a given file type. But in any given instance you can over-ride this default by either double-clicking on a different app within in the workspace inspector or command-dragging the file onto that app's icon. So, yes, all files with the same extension will by default open in a given app (you can't have some opening in one app and some opening in another) but there are easy and quick ways to over-ride the default whenever you choose to. Having said that, it seems to me that it ought to be simple to have a way to add particular extensions to the OS and tell it which app to direct files with those extensions to. That way you wouldn't be dependent on the specific extensions your app came with. In the example above, you could just customize your VC files to end with .vc instead of .c, and tell the OS to send any such files to VC rather than Borland. There is a freeware app that lets you do this under NeXTSTEP, but its not part of the OS. -- 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: robm@shore.net (Rob Mitchell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 13:25:04 -0400 Organization: Shore.Net/Eco Software, Inc; (info@shore.net) Message-ID: <robm-0702971325040001@pm20-45.bstnma.shore.net> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, phetsy@earthlink.net (Phetsy Calderon) wrote: > In article <5ddvvd$lha@dismay.ucs.indiana.edu>, > glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > > > In article <connelly-ya023680000602970146410001@news.ziplink.net>, > > > Speaking of which, is there anything like a find/grep combination for Mac? > > Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you > guessed it, lets you GREP Mac files. I believe it's in the Utilities > folder, but if you haven't already, just download the <all-files.text> > file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to > find MacGREP's location. Also, if you own BBEdit (maybe even BBEdit Lite), it has a nice little grep feature inside the Find dialog. Very nice product that BBEdit, BTW. -- Rob Mitchell (robm@shore.net) Macintosh Software Developer (PS: yes, I do Windows/MFC development and porting, too) My opinions belong to me and only me.
From: kindall@manual.com (Jerry Kindall) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 11:07:51 -0500 Organization: Manual Labor Message-ID: <kindall-0702971107520001@ppp.manual.com> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> <Pine.SGI.3.95.970207003142.10697A-100000@wong> In article <Pine.SGI.3.95.970207003142.10697A-100000@wong>, Ian Russell Ollmann <iano@scripps.edu> wrote: >Frankly, on the Apple, I find that if it is a specific text file, MS word >or any of a half dozen word processors and text editors work fine enough >for me. If you need to find a file with a particular word in it, but don't >know which file it is, you can either wait for a Vtwin enabled finder >under Rhapsody, if not Tempo or Allegro, or you could download TurboFind >(http://www.moreinfo.com.au/access/TurboFind.html) today. UltraFind is a very nice program which includes an indexer -- content searches on indexed volumes are lightning-fast. Two commercial programs which may fit your needs are On Location (discountined, but still works if you can find a copy) and Retrieve It!. On Location is another indexing-type program which is very quick (though not as flexible as UltraFind). Retrieve It! is not as fast but it doesn't require space-consuming index files and is still pretty quick. I frequently use Retrieve It! myself. > Ian Ollmann -- Jerry Kindall <kindall@manual.com> Manual Labor <http://www.manual.com/> Technical Writing; Internet & WWW Consulting Author of the Web Motion Encyclopedia The comprehensive animation and video reference for Web designers Coming Summer '97 from Waite Group Press
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 15:04:04 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FB8AB4.2A40@subsequent.com> References: <5d8qta$6np@news.bu.edu> <5dal9c$bd1$3@majipoor.cygnus.com> <jk-0602972223190001@ip-salem3-30.teleport.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joel Klecker wrote: > > In article <5dal9c$bd1$3@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > > >You're right, Nextstep isn't "like a Mac". It's better. The people who > >brought you the Mac left Apple because Apple wasn't willing to take another > >risk and make something better.. and those people created NeXT, and created > >something better. > > Hmm, I wasn't aware that "Reality Distortion Field.app" shipped with > NEXTSTEP. :-) You're just jealous. ;) -- jon@steeldriving.com
From: tonyn@tiac.net (Tony Nelson) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 16:00:22 -0500 Organization: <none> Message-ID: <tonyn-ya02408000R0702971600220001@news.tiac.net> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > Now, before you go though these rants again, go out and use the damn thing. > Stop arguing from a stance of total ignorance. I'll be brief. We like Macs. We use Macs because we can understand them. We want Macs, not techie Unix stuff. We aren't required to buy your favorite toy. If you don't like Macs, GO AWAY. ____________________________________________________________________ TonyN.:' tonyn@tiac.net '
From: shess@one.net (Scott Hess) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 7 Feb 97 14:39:14 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb7143914@slave.one.net> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> <E57pyw.D2C@cwi.nl> In-reply-to: stes@cwi.nl's message of Fri, 7 Feb 1997 03:06:31 GMT In article <E57pyw.D2C@cwi.nl> stes@cwi.nl (David Stes) writes: In article <SHESS.97Feb6140159@slave.one.net>, shess@one.net (Scott Hess) writes: >it, while still retaining the speed. Driesen describes means of >packing rows or columns together to make a single array that's >smaller than the matrix was. Note that all the exisiting OC runtimes use some form of hashtable to do the look-up. I suspect that's the "packed matrix". Unsure what your usage of "hashtable" is in the above. As I understand it, it would mean that the code to find the imp would change from: imp=impTable[ selectorTable[ _cmd]+self->isa->classNumber]; to: imp=self->isa->impTable[ hashSel( _cmd)%self->isa->impTableSize]; in a table-per-class implementation. [Sorry, this is clearly psuedo-code.] The problem is that use of hashSel(), and also that you have to handle collisions in the impTable. So obviously this is even bad psuedo-code :-). Note that the variation Driesen's paper suggests basically builds an impTable which doesn't require hashing, you index it directly. [It appears to me, looking over your code, that you optimize _imp() by using essentially a "selector look-aside buffer". First, you check a system-wide selector cache, and if the selector/class tuple is in the cache, you use the imp directly. Otherwise, you fall back to _getImp(). Driesen's version basically arranges things so that _all_ access would effectively be via the sel/class cache. Method dispatch would never use _getImp(). On the other hand, it's less dynamic.] 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: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 15:49:41 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FB9565.5193@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alan Jenks wrote: > On Win 95 I have both Borland and MS compilers installed. After > installing the Borland compiler all my MS Visual C (*.c/cpp) created > files now insist on openning with the Borland compiler when I double > click them! I can't have some *.c/cpp files open with VC and others with > Borland and of course they must end in c/cpp to open with either one. > > What is the a type/creator mechanism on NextOS that will prevent this > step backwards in usability for Mac users in the future? There is no 'creator' concept - that idea falls apart in a multiuser scenario. Filename extensions are used, but they are more flexible than Windows extensions. There's no limit on the length of the extension, for instance. The NeXTSTEP presentation app 'Concurrence' uses a '.concur' extension. Spaces are allowed in filenames. The WorkspaceManager, an application which plays the role of Apple's Finder, manages what applications open which files. Each application tells the workspace what kinds of files it can open. If you select a file, and bring up an 'Inspector' window (Command-3), you are shown a scrolling list of icons which represent the applications that can open that kind of file. One of them is treated as the default. The default application is shown as the furthest-left icon. For a file of type '.tiff', I have 5 icons: IconBuilder.app, WetPaint.app, Preview.app, WorkspaceManager.app, and Edit.app. Edit.app is always an option. This may sound odd, but it often makes sense. Files with no extension are treated as Edit files. WorkspaceManager.app provides a Contents Inspector (Command-2) in which documents are displayed (in a small window). You can create loadable bundles that will extend the Contents Inspector to handle more filetypes. If you double-click a file, the default application for that type of file is used to open it. To change the default, you bring up the inspector, select another application, and click the 'Set Default' button. You don't have to deal with all the editing garbage that Windows requires. To open the file with an application other than the default, you can either Command-drop the file on the application's icon, or you can bring up the Inspector and double-click the icon of the application you want it to open in. (Or you can use the open menu, in that application.) In one way, this may seem like a step backwards. But, in the 5 years I've been using NeXT's, I've never once had an occasion to need some utility so I could fix some file rendered useless by munged type/creator codes. That happened quite a few times in my 3 years if Mac ownership. (If it wasn't a problem, there wouldn't be several third-party tools around to work around it.) And, again, creator codes don't work well in a multi-user environment or network. If one user prefers Painter, and one user prefers Photoshop, and they both have to work on a set of files, they're continually going to have creator problems, because the files will continually have their creator code set to the other person's app. -- jon@steeldriving.com
From: Alan Jenks <jalanet@mcs.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 13:17:39 -0600 Organization: None Message-ID: <32FB7FCA.4D15@mcs.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > > As a follow up to my own post, let me just add this: > > File name extensions as the OS-wide method of > file type recognition: JUST SAY NO > I absolutely agree!! One of the things that makes the Mac a joy to use is that I can create a file in an application and name it anything I choose. Double click the file and the application that created it will launch and open it. On Win 95 I have both Borland and MS compilers installed. After installing the Borland compiler all my MS Visual C (*.c/cpp) created files now insist on openning with the Borland compiler when I double click them! I can't have some *.c/cpp files open with VC and others with Borland and of course they must end in c/cpp to open with either one. What is the a type/creator mechanism on NextOS that will prevent this step backwards in usability for Mac users in the future?
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.sun.misc,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: OpenStep/Sparc [MiscKit] Date: 7 Feb 1997 19:13:40 GMT Organization: Global Objects Inc. Message-ID: <5dfut4$k5a@news.xmission.com> References: <32F19278.453B@erols.com> <5d5c30$8uq@mozo.cc.purdue.edu> <32FA5C21.3080@cyrix.com> <32FB1573.6445@freia.inf.tu-dresden.de> As MiscKit administrator, I feel like I ought to add a few comments and explanations to Patrick Schulz's post, since it brings up some good points and raises a few issues I haven't had time to answer before. (But the public posting almost requires a response, IMHO.) On the MiscKit/OPENSTEP issues brought up here, there are a few things to note: (a) MiscKit2 as it stands is a pre-alpha and is, in my own words from the press release, "almost useless". (b) It is built on NEXT's OPENSTEP because I don't have a Solaris box to work with. (c) MiscKit is a free project and happens in people's spare time. To give more details: (a) pre-alpha; useless There's a lot of work to be done, and the OPENSTEP conversion is very incomplete. I want it to eventually be a 100% OPENSTEP compliant system and this means that there's a lot of work to do. I cannot do it all myself, and to date, not too many people have stepped in to help. Those who have: Thanks! Those who haven't: either step in and help--otherwise you have no right to complain! We _will_ get there. I'd like to do it ASAP, but as the rest of this explains, reality will cause delays in a project like this... (b) no Solaris boxes I'd be happy to make it compliant to the Solaris spec, but without a box to work with, _I_ can't do the work. If Sun cares enough about this to place a Sparc box on my desk, I'll be happy to make the MiscKit more Sparc-friendly. To date, they've expressed some interest, but not that much. What I envision is that we'll--as we always have--build off of everything NeXT gives us. Since some of that isn't in the OPENSTEP spec, what isn't in NeXT's version will have to be written for the Sparc version--ie, a non-OPENSTEP extension provided by NeXT would be recreated for the Sparc OPENSTEP. Obviously, some extensions are a bit beyond our scope to recreate, but a lot of the extensions we already almost have by virtue of the functionality of the MiscKit1 code we are porting. But without a Sun box--or someone with a Sun box stepping in to help--that situation probably won't get any better. Note that the "extra" stuff we need to run on Sun's environment is something we would probably want to either donate to GnuStep, or, if GnuStep already has it, borrow from them. :-) (c) freebie done in spare time Seems like we're all short on spare time these days given the NeXT/Apple merger and all the hoopla surrounding it; things have been somewhat slow in the submission receipt department, and I haven't had a lot of time to do the work myself. Progress is happening, but very slowly. [To keep it in perspective, here's the projects I have to keep my "spare time" busy: MiscKit1, MiscKit2, 3DKit, Indexing Kit, GameKit, several games, webmaster for several sites (www.planetary.net, www.yacktman.com, etc.) and tht's not counting family time and my regular job! So if you wait for _me_ to do all the work, it will eventually happen but not very quickly. Volunteers truly are needed!] At any rate, the problems addressed in the post that was copied from the MiscKit list are all things I plan to address over time. Right now, though, the post points out some very real flaws in the current MiscKit. My answer is: rather than complain, become part of the solution! That's the whole philosophy behind the kit itself and taking action like that will help everyone involved. :-) So, given that I acknowledge that MiscKit2 is currently almost useless for OPENSTEP development, I'd like to remind everyone that I don't plan for it to stay that way. The point point of making the kit is for it to be used, and I will do all that I can (now and in the future) to make sure that it can be used! -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Ian Russell Ollmann <iano@scripps.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 7 Feb 1997 13:07:07 -0800 Organization: The Scripps Research Institute, La Jolla, CA Message-ID: <Pine.SGI.3.95.970207125600.14380B-100000@wong> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> <Pine.SGI.3.95.970207003142.10697A-100000@wong> <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Gregory Loren Hansen <glhansen@indiana.edu> In-Reply-To: <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu> On Fri, 7 Feb 1997, Gregory Loren Hansen wrote: > Okay. I got a bunch of C source code. I'll have to try to make that work. > > Okay, I got TurboFind. I'm trying it out as I type do you. Looks like > exactly the file/string search I wanted. Except I'm searching for > "Erwin", and it keeps giving me "insidesendERWINdow) /*" in drag.c. I > didn't know I had 30 copies of drag.c, but it went on to puzzleDrag.c and > others, so it must be making forward progress. Looks like this one is > worth the $10 the author is asking. > > You know, this seems like just the kind of thing OpenDoc would be good > at. I realize OpenDoc has more flexibility than Unix-style streams, but > each of the utilities could be a part, and a container app could be just > a text command line and text output (with scrolling and printing and > things, like SIOUX). That would be very nice. And those parts would > also be available for any other OpenDocable app. And maybe a system() > call that invokes the CLI container? > > GNU utilities for OpenDoc? > > It would all be very nice. AppleEvents scare me away, but I could handle > system(). But I suppose there won't be much motivation to work on that > kind of project until we see what comes with Rhapsody. I hadn't thought about OpenDoc for that sort of use. However, if you want to use someting akin to piping in unix on the mac (e.g. something like cat /usr/mail/myboss | grep "My Name" | lpr) you might wish to a new development effort called FilterTops. It uses a graphical program interface to string together stdin and stdout of components so that you can do this sort of stuff easily on the mac. I took a look at it six months ago, and it looked promising, though not all the tools were in place. It is a mac community development effort, so if you want to write specialty tools, they would be thrilled to have you do so. In the mean time, hopefully over the last six months it has progressed fairly well and might be quite useful. It looks like it will do everything from grepping out words from a series of files to backing up/compressing files more recent than a specified date. http://topsoft.topsoft.org/ I hope that some day it finds its way into the Finder. Ian Ollmann
From: ab@purdue.edu (Allen Braunsdorf) Newsgroups: comp.sys.sun.misc,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: OpenStep/Sparc Date: 7 Feb 1997 20:20:12 GMT Organization: Purdue University Message-ID: <5dg2ps$e1h@mozo.cc.purdue.edu> References: <32F19278.453B@erols.com> <5d5c30$8uq@mozo.cc.purdue.edu> <32FA5C21.3080@cyrix.com> <32FB1573.6445@freia.inf.tu-dresden.de> Patrick Schulz <schulz@freia.inf.tu-dresden.de> wrote: >> Openstep on Solaris is VERY slow. >You're right. Sun could slightly increase performance in the current >beta version, >but it's IMHO not enough (compared to my NeXTstation). A SPARC running NEXTSTEP 3.3 is about four times as fast as a Turbo station by the usual benchmarks and feels much faster. Are you telling me that Openstep over Solaris is as slow as a station? I hope not. My machine has a CG3 in it, which NEXTSTEP doesn't support (I fixed the driver myself). I borrowed a CG6 one day and swapped it to see if there was any speed difference. It felt the same, but the graphics benchmarks said it was a little slower. My machine also runs better now that I've upgraded to 80MB of memory. OmniWeb is really the only thing that gets it swapping a lot. ab
From: dcoshel@pobox.com (Dave Oshel) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 14:49:32 -0600 Organization: Xochitl Sodality Wonders & Marvels Committee Message-ID: <dcoshel-ya02408000R0702971449320001@news.inav.net> References: <5d8qta$6np@news.bu.edu> <0myB5iy00iWY461F04@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <0myB5iy00iWY461F04@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: [ whack...] > MacOS has been based solely around GUI solutions for every task, and the > lack of a CLI is one of the major weaknesses of the MacOS because it > prevents knowledgable users from using the CLI as an alternative which > is sometimes superior for some tasks. Apple has never been loathe to throw her weakest children to the wolves, as those of us who bought Apple ]['s, ///'s and Lisas learned. Or SE's, for that matter. So MPW is a legacy of uncharacteristically old thinking at Apple -- its CLI has been around for years. With a toolbox of filters like Rez and DeRez ready to hand, its debt to Unix design philosophy has never been hard to see. Whatever the next Mac is based on, it had better know its "core business" as well as, say, the humble little Linux 1.2.13 kernel. Otherwise, some large and beautiful beasts are going to go the way of the dinosaurs. -- David C. Oshel dcoshel@pobox.com Cedar Rapids, IA http://pobox.com/~dcoshel
From: woody@alumni.caltech.edu (William Edward Woody) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 12:52:31 -0800 Organization: In Phase Consulting Message-ID: <woody-0702971252310001@192.0.2.1> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> In article <5ddpn1$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > William Edward Woody (woody@alumni.caltech.edu) wrote: > : But get this: Mach is *NOT* Unix. Mach has been used to build a Unix > : compatable OS, and most people tend to build off of a Unix client > : built on top of the Mach kernel because that's what most of us > : programmers are familiar with. > > Granted, kernel and system calls are fine. What I'm concerned about > most is the support even simple Unix-isms like shell scripts require > in order to work. IMO, this support system is not worth the small > advantages that a few advanced users will receive because it constrains > the rest of the OS too much. Hang on a second. When I said that Mach is not Unix, I think you failed to get the point. Mach itself is a microkernel, which supplies only three major services: preemptive multiprocessing and multitasking support, interprocess communications support, and the framework for low level memory management. Note that all three of these are 'support'--it is presumed that like the NuKernel or Microsoft's NT kernel, a layer of services would live on top of the Mach kernel in order to create a complete operating system. While most folks have put various flavors of Unix on top of Mach does not mean that Mach is only suitable for Unix. It would be like people only putting Unix on top of the NuKernel technology Apple was working on--just because it's first doesn't mean the NuKernel technology is only good for Unix. Mach is not Unix. It is a technology for building an operating system. Even the system calls can be redirected by the Mach technology, so that an application can request a different environment to live in. What this means is that even though the NeXTStep GUI now lives in a Unix-like environment does not mean we have to have to turn the Macintosh into a Unix box in order to run NeXTStep: it means only that at some level, the yellow box will contain a Unix emulator. > : Second, let me note that I was also concerned with the idea of having > : a Unix kernel underlying the MacOS--as soon as such a thing hit the > : shelves it wouldn't be long before someone did 'tsh', at which point, > : we may as well have simply exposed people to the shell. > > It's not the kernel that bothers me. The Mach kernel is certainly > suitable, although the Apple-striped part of me wishes I could see > NuKernel with it's plug-in extensibility. Think of Mach as CMU's version of the NuKernel. Both had the same purpose, and both have the same underlying purpose: to provide the fundamental core of services an operating system 'personality module' can use to implement a full operating system environment. > : But ultimately, using the Mach kernel does not mean the Macintosh will > : operate as a layer on top of Unix. Instead, it means Apple will more > : likely create various OS "servers" which service operating system calls > : in the same way the Unix server operates. In fact, I suspect both > : the "yellow box" and the "blue box" are really just Mach servers > : providing different operating system personalities. > > As I stated in my original post, a POSIX subsystem is fine. A Unix > directory tree appearing on my hard drive after a standard install is > not. This doesn't have to happen to support NeXTStep or the yellow box. - Bill -- William Edward Woody - In Phase Consulting - woody@alumni.caltech.edu http://www.alumni.caltech.edu/~woody
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 07 Feb 1997 15:09:46 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FB8C0A.2C92@subsequent.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <5dfhrg$73v@horus.ecmwf.int> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mike Connally wrote: > Rhapsody must provide all of the human interface correctness > of MacOS along with at least as good a filesystem architecture > before I'll be interested. HFS is not my idea of a 'good filesystem architecture'. It's a bad idea to make changes to the filesystem which make its files fundamentally incompatible with every other platform around. And don't get me started on the way HFS handles large disks. -- jon@steeldriving.com
From: Armin Tenge <Armin.Tenge@prakinf.tu-ilmenau.de> Newsgroups: comp.sys.next.programmer Subject: Problems with EOF Adaptors Date: Fri, 07 Feb 1997 22:19:28 +0100 Organization: TUI Message-ID: <32FB9C5F.462B@prakinf.tu-ilmenau.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I installed EOF 2.0 on a NT platform. I tried to make a new model and switched to the Informix Adaptor. It didn't find the ISQLI72.dll. When I switched to the other adaptor for relational databases, I got nearly the same error message that it couldn't find a dll. Thanks for immediate help, Armin
From: zander@conextions.com (Aleksey Sudakov) Newsgroups: comp.sys.next.programmer Subject: Re: Documentation in PB 4.1 Date: 7 Feb 1997 21:31:28 GMT Organization: The Internet Access Company, Inc. Message-ID: <5dg6vg$5s6@news-central.tiac.net> References: <5datht$547@q.seanet.com> misha@berlioz.osd.com (Misha M. Melikov) wrote: >For some reason I can only see AppKit and Foundation documentation in >ProjectBuilder 4.1. All other frameworks do not get indexed and >documentation can not be seen. How many other frameworks left? There is no documentation for System.framework and it's understandable. I've got References for EOF parts with OpenStep Enterprise on my machine. The problem is really that Documentation provided with OpenStep Enterprise for both Mach and NT is no longer that solid NeXT Documentation that could be found in good old days of NeXTSTEP 3.x. >Any thoughts? Should I be able to see any other documentation or is it too >much to ask? Look at $(NEXT_ROOT)/NeXTLibrary/Framework/$(FRAMEWORK_NAME).framework/Resources/Engl ish.lproj/Documentation/Reference Regards, Aleksey
From: jkeenan@next.com (Joe Keenan) Newsgroups: comp.sys.next.programmer Subject: Re: Help a new OpenStep 4.1 NT Developer! Date: 6 Feb 1997 14:01:54 GMT Organization: NeXT Software, Inc. Message-ID: <5dco8i$kmu@news.next.com> References: <01bc13f3$39944410$992274cf@openstep-nt> In article <01bc13f3$39944410$992274cf@openstep-nt> "Chris" <C.Erker@worldnet.att.net> writes: > Hi everyone, > Let me say that I am very excited about the NeXT/Apple deal. I have > been interested in NeXT for a couple of years now, but I honestly believed > that NeXT would go bankrupt soon. But with news of the merger I went out > and bought OpenStep 4.1 developer for NT. > > My Problem: > My friend and I wrote a few dummy programs under NeXT 3.3 in a > standard text editor and compiled them from the command line, without > problem. When I tried to run the same program at home under NT, I get the > following error message: > > Jethro.m:5: "Cannot find interface declaration for 'Object', superclass of > 'JethroClass' NextStep 3.3 is based on the "old" APIs, and OPENSTEP is the "new" API. All objects in OpenStep are subclasses of NSObject, not Object. You'll have to change your object definitions. joe
From: Gregory Loren Hansen <glhansen@indiana.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 7 Feb 1997 17:59:40 -0500 Organization: Indiana University, Bloomington Message-ID: <Pine.OSF.3.91.970207175212.17270B-100000@copper.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> <Pine.SGI.3.95.970207003142.10697A-100000@wong> <Pine.OSF.3.91.970207094217.31271A-100000@copper.ucs.indiana.edu> <Pine.SGI.3.95.970207125600.14380B-100000@wong> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII NNTP-Posting-User: 1073745024 In-Reply-To: <Pine.SGI.3.95.970207125600.14380B-100000@wong> On Fri, 7 Feb 1997, Ian Russell Ollmann wrote: > > GNU utilities for OpenDoc? > > > > It would all be very nice. AppleEvents scare me away, but I could handle > > system(). But I suppose there won't be much motivation to work on that > > kind of project until we see what comes with Rhapsody. > > I hadn't thought about OpenDoc for that sort of use. However, if you want > to use someting akin to piping in unix on the mac (e.g. something like > cat /usr/mail/myboss | grep "My Name" | lpr) you might wish to a new > development effort called FilterTops. It uses a graphical program > interface to string together stdin and stdout of components so that you > can do this sort of stuff easily on the mac. I took a look at it six Easy sources, filters, and sinks of information is one of the best things about Unix. It's something I'd like on the Mac, and I'll certainly take a look. > months ago, and it looked promising, though not all the tools were in > place. It is a mac community development effort, so if you want to write > specialty tools, they would be thrilled to have you do so. In the mean I'm a grad student learning the secrets of the universe, so I won't be writing specialty tools myself. I'm just looking for other people who've done all the work for me. > http://topsoft.topsoft.org/ I'll save this URL. Thanks. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: Gary Zhang <gzhang@ix.netcom.com> Newsgroups: comp.sys.next.programmer Subject: JDK Date: Fri, 07 Feb 1997 18:12:12 -0500 Organization: Bankers Trust Company Message-ID: <32FBB6CC.14FA@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there a version of JDK running on NeXTStep? Thanks.
Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer From: cdouty@netcom.com (Chris Douty) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Message-ID: <cdoutyE59AHJ.Cw1@netcom.com> Organization: Netcom On-Line Services References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> Date: Fri, 7 Feb 1997 23:27:18 GMT Sender: cdouty@netcom18.netcom.com In article <connelly-ya023680000602970146410001@news.ziplink.net>, Paul Connelly <connelly@dawnstar.darc.org> wrote: >In article <5dbfr3$g10@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> Don't confuse the operating system with the shells. > >The shell is the best part of UNIX though. The tools that come >with the shell are great. Just get rid of that horrid directory >structure. (Let's see, is that program in /bin, or was it /usr/bin, >or /usr/local/bin, or....?) What? and break every Unix package on the Net? It really has gotten a bit gangly though. Every Unix vendor has their own conventions, even in the SVR4 world. I'd like to see a nice 4.4BSD layer/filestructure. I dunno if they'll have time to do it for Rhapsody premire though. - Chris -- Christopher Douty - Rogue Engineer trapped in a land of software cdouty@netcom.com "Frequently the messages have meaning; that is they refer to or are correlated according to some system with physical or conceptual entities. These semantic aspects of communication are irrelevant to the engineering problem." -Shannon
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 07 Feb 1997 15:37:01 -0800 Organization: Cygnus Solutions Message-ID: <qdohdwi3xe.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> Alan Jenks <jalanet@mcs.com> writes: > One of the things that makes the Mac a joy to use is that I can create a > file in an application and name it anything I choose. Double click the > file and the application that created it will launch and open it. > > On Win 95 I have both Borland and MS compilers installed. After > installing the Borland compiler all my MS Visual C (*.c/cpp) created > files now insist on openning with the Borland compiler when I double > click them! I can't have some *.c/cpp files open with VC and others with > Borland and of course they must end in c/cpp to open with either one. > > What is the a type/creator mechanism on NextOS that will prevent this > step backwards in usability for Mac users in the future? These two issues (whether the types are part of the filename and the way in which file types and applications are tied together) are actually orthogonal. There are two ways in which you can tie a filename in with an application so that you can click on the filename and have the app open it nicely. The first, as seen on the Mac, is to have every file maintain a reference to the application which created it. The second, as implemented on Win95 and NeXT, is to have applications publish the file types that it knows how to handle, and give the user a way to choose a default application for that file type. The first way works very well on a single-user machine where files are usually created on the machine and left there; in this case, the creator application is (usually) always present. The second way works much better in a networked environment, where files get passed around and an attempt is made to keep the files in open standard formats. This way, the user on an individual machine can decide which application he or she likes best for opening a given file type. I prefer the second way a great deal. If I'm opening an HTML file, I don't want Netscape to open it, I want to use OmniWeb (or Mosaic, or Cyberdog...). If an Excel file is transferred onto my NeXT box, Mesa will open it without my having to do anything. And I don't care whether BBEdit, Borland, or Interface Builder created that C file, I want to open it in Emacs. Embedding type information into the filename is really a separate issue (and one which can, again, be hidden from the user if the programmers desire). -- 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: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 8 Feb 1997 02:10:35 GMT Organization: Cygnus Solutions Message-ID: <5dgnar$rm1$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> Cc: jrudd@cygnus.com In <5dgma6$rat$1@majipoor.cygnus.com> John Rudd wrote: > Oh, and by the way, unless you plan to stick wtih System 7, if you stay on > the mac, you DO have to buy my favorite toy. And if you want me to go away, > then stop posting your ignorant drivel in our nextstep newsgroups. I feel the need to applogize to the other Mac users reading the groups that this has been cross posted to. The attitude I feel toward the initial poster, and the person I was just replying to are not how I feel toward the general mac community. In fact, I welcome the merger and consider the various technologies from the "other side" to be worth looking at and evaluating for inclusion (and i feel the same sort of evaluation should be done for things from "our side" too). What irks me is that the original poster starts off with an incredibly intollerant and closed perspective not just inspite of the open discussions and attempts to explain our side of the fence in another thread, but _because_ of how much time we're taking to explain why our technology is not only "not bad" for the Mac user, but "insanely great" for the future of the Mac... and yet inspite of claiming to read all of that, his statements show an incredible level of ignorance of everything being said... and a great deal of just plain bigotry for things he clearly has no clue about. The second bozo just managed to build on the first bozo's bigotry. But I don't want anyone to think that I don't welcome constructive, calm, and mature discourse on what the future of the Mac should be, and what technologies should be present in melding our two worlds. I want to see the Mac user and the Nextstep user come out of this deal feeling like they've both been enriched and empowered. If you're a Mac user who is afraid because you keep hearing "it's got that unfriendly unix underneath it", please trust us when we say "Nextstep is the friendliest system I've ever used, and is at least in the same catagory as the Mac" -- and not all of the people saying that are techies. Speaking of which, if you're in the Bay Area, I'd be happy to try to arrange to show you my Nextstep system.. either at home or at work. I'll give you a tour, and I'll let you sit and play for a while without me protecting you from the system. I'm not only willing to sit here and talk the talk, but I'll walk the walk too, because I'm confident that when you use the system, your fears will go away. But please, before you condemn Nextstep because of that Unix word, at least _TRY_ it. Ignorance and bigotry are ugly no matter what their target is. -- 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: "Christopher Erker" <cerker@rnt.com> Newsgroups: comp.sys.next.programmer Subject: PrintForDebugger ??? Date: 7 Feb 1997 23:23:56 GMT Organization: Reich & Tang Message-ID: <01bc154a$53c4c960$8279bdce@Pilot.rnt.com> I have a few question about PrintForDebugger. All of my 3rd party books and manuals (for Next 3.3, and OpenStep 4.1) hardly mention this method, but it looks really cool! 1) Is it only used through GDB? 2) If so, then can I use it through Openstep? 3) Could someone post a short example on it's use. Thank you for your time. -- Chris
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <jim@ergotech.com> Message-ID: <199702071651.AA14596@ergotech.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 3.3 v118.2) From: Jim Redman <jim@ergotech.com> Date: Fri, 7 Feb 97 09:52:12 -0700 Subject: PDO and hooking in an ORB Cc: jimg@abacus.com Jim Gagnon <jimg@abacus.com> >I'm in the process of learning OpenStep and am having problems in >finding documentation on how to take an existing ORB and tie it into >PDO so that it can successfully interoperate with other ORBs. There are two sides to this the Microsoft OLE/COM side and CORBA (II). NeXT has given slick demos of these products and the interaction/translation between them, billing PDO as the "Universal ORB". There much more information on OLE on their web site. My understanding is that, fairly transparently, you can talk from an OLE server or client to a PDO/UNIX client. I'm willing to be corrected on that since I haven't worked with it and don't know how simple it really is. NeXT's PDO is also "CORBA II" compliant. This means absolutely nothing without an implementation of an IDL, or Interface Definition Language. Essentially an IDL allows you to present the interface to your objects in a manner that can be understood by objects in other languages. I have heard rumors of third party implementation of an IDL for Objective-C, does anyone know more? NeXT is also working on an implementation of the OMG IDL and you can find more info by searching for IDL on the NeXT website. With any implementation of an IDL it should be possible to do what you need to do and have you application successfully interoperate. Jim
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <eric@pooh.cdrom.com> Message-ID: <9702071549.AA06479@nebula.cdrom.com> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) j%q;6~]olIY<I\1zLJ.~]53@+A]/}";bKMKAoA3DJn"3Ur/iVngM_b8?1=WhD(,C\OQ`!N PGO6e04/E9[ec6sDuxxB From: Eric Tremblay <eric@cdrom.com> Date: Fri, 7 Feb 97 07:49:22 -0800 Subject: How many characters in myScrollView???? OpenStep An OpenStep question. I'm trying to figure out how many characters I have in myScrollView. I just can't seem to get it to work. Any help would be very welcomed. Here's the converted OpenStep code: - textLengthTest:sender /* The number of characters in the Text object . */ { int HowLongIsTheText; document = [MyScrollView documentView]; /* assigns the length of the text in MyScrollView */ HowLongIsTheText = [[document text] length]; /* Displays how many characters is in the text */ [theTextLength setIntValue:HowLongIsTheText]; return self; } Here's the original NEXTSTEP code: - textLengthTest:sender /* The number of characters in the Text object . */ { int HowLongIsTheText; document = [MyScrollView docView]; /* assigns the length of the text in MyScrollView */ HowLongIsTheText = [document textLength]; /* Displays how many characters is in the text */ [theTextLength setIntValue:HowLongIsTheText]; return self; } Eric "E.T." Tremblay ericet@cam.org
Newsgroups: comp.sys.next.programmer,comp.sys.mac.advocacy,comp.sys.mac.system,comp.sys.next.advocacy From: Tim.Streater@dante.org.uk (Tim Streater) Subject: Re: MacWorld Exclusive: Apple's OS Plan Unveiled!!! Message-ID: <Tim.Streater-0502971834480001@mac-tim.dante.org.uk> Sender: news@exeter.ac.uk (news admin) Organization: DANTE 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> <AF17D80E96687E79C@node23.tfs.net> Date: Wed, 5 Feb 1997 18:34:48 GMT In article <AF17D80E96687E79C@node23.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: >>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> This is the sort of thing I do too, with variations because I have different sets of applications than you. But the principle's the same. Also I have a folder with aliases to all my apps and important docs. The nice thing about the MacOS alias is that I can move an application folder to the desktop, do some fiddling with the contents, and put it back without the link from the alias being destroyed. >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. Sad, isn't it, that some people still don't get this. Nerds are frightened by this philosophy, though. -- Tim Streater, DANTE. Tim.Streater@dante.org.uk +44 1223 302992 (Fax: 303005)
From: thegoat4@airmail.net (Bryant Brandon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 19:04:21 -0600 Organization: Anti Christian Coalition Message-ID: <thegoat4-0702971904210001@news.iadfw.net> References: <5ddp66$jpc@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Damnit, shut up! You have no clue what you're whining about and you've polluted two groups that aren't related to this shit. You're concerned with what the users will experience after the merger. Programmers won't be bothered by the interface because we will always have to deal with the messy details of any system. Then you go on and on like you're the sole voice of the entire Macintosh community. You don't speak for me or anyone else. Go get a book and learn about Apple, NeXT, and programming. You obviously don't know a damn thing. In article <5ddp66$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > [...] > >Conclusion: > >Even the much-vaunted BeOS seems to suffer from file proliferation a la >Unix (/dev/modem anyone?) Perhaps this is unavoidable and I'm being >naive. After all, the *only* example of an OS that doesn't work this >way is the now-ancient Mac OS. But I don't thing there's any reason to >resign ourselves to the "me-too" world of evil OSes that require >"Uninstallers" and that keep us captive of a bazillion fragile text >files. There's a better way, and I only hope that in the coming years >the people behind the Mac/NeXT OS aren't afraid to break from the past >and give us an OS we can be proud to call "Mac." > B.B.
From: matthew@imaginator.com (Matthew Powell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Date: 8 Feb 1997 03:03:43 GMT Organization: Cygnet Internet Services Ltd Message-ID: <5dgqef$job$2@zeus.cygnet.co.uk> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> Gregory, > Speaking of which, is there anything like a find/grep combination for Mac? > I may or may not have a document about Schrödinger that I'd like to look > up. But I have no idea where it might be, and I'm sure it would be buried > in file with a bunch of other stuff, and the name would have no relation > to the subject. And I don't know where to get it from an outside source. > I've made a few requests but got no response. If time really *is* immaterial, just call up the System 7.5 Find File and hold down option whilst selecting what to search by. You'll see a number of new options there including 'contents'. It takes forever, but it works. :) Matthew. -- [this space reserved for future expansion]
From: ldesegur@911entertainment.com (LdS) Newsgroups: comp.sys.next.programmer Subject: $$$ Looking for Programmers & Graphic Artists $$$ Date: 8 Feb 1997 07:09:59 GMT Organization: 911 Message-ID: <ldesegur-0702972311320001@204.119.65.24> Hello, We are a music based entertainment company (rock, techno, heavy...) looking to establish a Web presence. We are located in the San Francisco Bay Area. * If you are an experienced Java programmer (or C++ moving to Java) and interested about on-line interactive game development, we want to hear from you now. * We are looking for experienced database programmers with a good knowledge of Oracle RDBMS and Distributed Objects Technology. * We are also looking for talented 2D and 3D graphic artists and designers with creative ideas. We offer a good environment and good money. Full time positions available. send your resume at ldesegur@911entertainment.com
From: ldesegur@911entertainment.com (LdS) Newsgroups: comp.sys.newton.programmer,comp.sys.next.programmer,comp.unix.programmer,fj.net.programming,rec.games.programmer Subject: $$$ Looking for Programmers & Graphic Artists $$$ Date: 8 Feb 1997 07:16:10 GMT Organization: 911 Message-ID: <ldesegur-0702972317430001@204.119.65.24> Hello, We are a music based entertainment company (rock, techno, heavy...) looking to establish a Web presence. We are located in the San Francisco Bay Area. * If you are an experienced Java programmer (or C++ moving to Java) and interested about on-line interactive game development, we want to hear from you now. * We are looking for experienced database programmers with a good knowledge of Oracle RDBMS and Distributed Objects Technology. * We are also looking for talented 2D and 3D graphic artists and designers with creative ideas. We offer a good environment and good money. Full time positions available. send your resume at ldesegur@911entertainment.com
From: macpd@icaen.uiowa.edu (Liquefy root user) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Date: 8 Feb 1997 03:41:44 GMT Organization: Iowa Computer Aided Engineering Network, University of Iowa Message-ID: <5dgslo$jda@server05.icaen.uiowa.edu> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> <phetsy-0702970919210001@cust113.max3.santa-clara.ca.ms.uu.net> Phetsy Calderon (phetsy@earthlink.net) wrote: : In article <5de9k2$q13@dismay.ucs.indiana.edu>, : glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: : > In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, : > Phetsy Calderon <phetsy@earthlink.net> wrote: : > >In article <5ddvvd$lha@dismay.ucs.indiana.edu>, : > >Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you : > >guessed it, lets you GREP Mac files.... Path is : /mirrors/Info-Mac_Help/all-files.text. : >Search this file to : > >find MacGREP's location. : > : > That sounds great. Except I'm not really sure what to do with that path. : > I tried putting an "ftp:" in front of it, but Netscape says the connection : > was refused. : Sorry Greg--I have the Info-Mac path so firmly engraved in my brain I : forget that normal human beings use brain space to remember dates with : their spouses and what to put in their coffee ;-). : You need to access an Info-Mac site: It looks like you're posting from : an Indiana location, so you might want to hit the mirror at U of Iowa. : Path is <ftp://grind.isca.uiowa.edu/mac/infomac/>. The U of Iowa replaced grind with liquefy a year ago, the old name still works of course. Liquefy has a HTTP interface as well as FTP, and an telnet interface for those still stuck in the dark ages. All three interfaces support file name and file date searches. Quite usefull to find things in the 4gigs of Mac files on liquefy. http://liquefy.isca.uiowa.edu/mac Brett Davis - macpd@isca.uiowa.edu
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 8 Feb 1997 01:53:09 GMT Organization: Cygnus Solutions Message-ID: <5dgma6$rat$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <tonyn-ya02408000R0702971600220001@news.tiac.net> Cc: tonyn@tiac.net In <tonyn-ya02408000R0702971600220001@news.tiac.net> Tony Nelson wrote: > In article <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > > > Now, before you go though these rants again, go out and use the damn thing. > > Stop arguing from a stance of total ignorance. > > I'll be brief. We like Macs. We use Macs because we can understand them. > We want Macs, not techie Unix stuff. We aren't required to buy your > favorite toy. If you don't like Macs, GO AWAY. You sir, are exactly why the Mac market is failing. You're holding back the Mac from moving forward by being afraid to see some innovation or rennovation that has real technical merrit because something related to that rennovation isn't what you like. You don't know jack about what Nextstep is, or how easy it is to use. I don't care if you BUY a Nextstep system or not. USE IT before you go around saying how "unix will be the end of us!".. because quite frankly I have more contacts throughout the world who find Nextstep easier to use than the Mac, than the other way around. And I'm not talking about Techie people, or people who want "techie Unix stuff". I'm talking about artists, desktop publishers, graphic artists, secretaries, business people, house wives, children, etc. It has an intuitive, dynamic, and flexible GUI that makes a Mac look like the primitive toy that it is. But unlike the Mac, that's not all.. it has a fully capable and scalable infrastructure as well. Unix doesn't get in the way of the user experience at all (not that you'd know, because rather than take my advice and USE THE DAMN THING, you and the other Mac bigot here would rather bury your head in the sand and complain about "oh no, this might have unix in it), yet the Unix core gives it all of the power necessary to work as a heterogenous network server or gateway... not something you see a lot of Macs doing. But that's STILL not all. It has a built in between these two layers (GUI and Unix) a rich, dynamic, and extensible Object layer that makes development as friendly as the NeXT UI (ie. more friendly than the Mac UI, and WAY more friendly than Mac development), as well as making it easy to develop network aware and distributable programs. Don't forget that it was the rapid development environment of Nextstep that made the originator of the Web decide it was worth his time to spend building the project. Unix doesn't limit the user one tiny bit.. instead, combined with the development and GUI layers it empowers the user in ways that the Mac only gives us a vague hint. Oh, and by the way, unless you plan to stick wtih System 7, if you stay on the mac, you DO have to buy my favorite toy. And if you want me to go away, then stop posting your ignorant drivel in our nextstep newsgroups. -- 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: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 07 Feb 1997 18:16:06 -0800 Organization: Cygnus Solutions Message-ID: <qdiv44hwk9.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> jrudd@cygnus.com (John Rudd) writes: > In <tonyn-ya02408000R0702971600220001@news.tiac.net> Tony Nelson wrote: > > I'll be brief. We like Macs. We use Macs because we can > > understand them. We want Macs, not techie Unix stuff. We aren't > > required to buy your favorite toy. If you don't like Macs, GO > > AWAY. > > You sir, are exactly why the Mac market is failing. You're holding > back the Mac from moving forward by being afraid to see some > innovation or rennovation that has real technical merrit because > something related to that rennovation isn't what you like. Hear hear. Well said, John. Apple and its marketplace are too far gone to rely on the insular, closed world they've been dealing with. They have a chance to open up and start looking at what's out there and how to make it work for them. It's time to get that act together. > [...] It has a built in between these two layers (GUI and Unix) a > rich, dynamic, and extensible Object layer that makes development as > friendly as the NeXT UI (ie. more friendly than the Mac UI, and WAY > more friendly than Mac development), as well as making it easy to > develop network aware and distributable programs. I'm often reminded that Steve Jobs, during his first visit to Xerox PARC, was shown three things: the GUI, networking, and object-oriented programming. When he came out with the Mac, it was because he only noticed the benefit of one of the trio. When he came out with the NeXT, he got all three. -- 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: robert@visgen.com (Robert Osborne) Newsgroups: comp.sys.next.programmer Subject: Re: New User/Developer Date: 5 Feb 1997 11:30:53 -0500 Organization: Visible Genetics Inc. Message-ID: <5dacjt$bqq@knuth.visgen.com> References: <AF1839F8-5E8A0@206.101.238.36> Mark Jenkins <markj@inwave.com> wrote: >How much faster will I be if I upgrade my ram to 32/64 megs? I upgraded my machine from 32 to 64 and it became much faster. It now only swaps when I run our app :-) One thing I've noticed is that the MachOS seems to have a very good swapping algorithm+ if I open an app that hasn't been "running" for a while it seems to swap the whole thing back in. So if you hear swapping when doing your regular daily work, buy memory 'cause Mach puts it to good use. Rob. + compared to other OS's I've recent experience with, like Solaris, SunOS, AIX, HP/UX, IRIX, VMS, NT, Win95 and LynxOS :-) -- Robert A. Osborne, robert@visgen.com "It's now safe to turn off your computer."
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 8 Feb 1997 06:04:41 GMT Organization: Boston University Message-ID: <5dh51p$9hn@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dgnar$rm1$1@majipoor.cygnus.com> John Rudd (jrudd@cygnus.com) wrote: : If you're a Mac user who is afraid because : you keep hearing "it's got that unfriendly unix underneath it", please trust : us when we say "Nextstep is the friendliest system I've ever used, and is at : least in the same catagory as the Mac" -- and not all of the people saying : that are techies. Contrary to what you might thing, I've always admired the NeXT system and do indeed think it has many things to offer the Mac community. What I'm afraid of is that the break from the "traditional Mac experience" will be too drastic, and that we'll be left with a sum OS that's less than either the Mac or NeXT was individually. To avoid this, obviously, the *good* from both systems must be kept. IMO, the UI and user experience are the strongest points of the Mac. The API and "plumbing" seem to me to be the best parts of NeXTSTEP (yes, there are NeXT UI tricks that the Mac could learn a thing or two from) But the central question addressed (admittedly, somewhat sensationally) in my original post to this thread was this: is the file system more part of the UI, or the "plumbing"? Put another way, if the next generation Mac OS is to keep most of the Mac user experience, can it do so while adopting the NeXT file system? My own personal conclusion was that it would be a tough road... -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: John 'kzin' Rudd <jrudd@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 08 Feb 1997 09:56:20 -0800 Organization: Cygnus Solutions Inc. Message-ID: <32FCBE44.37E5@cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dgnar$rm1$1@majipoor.cygnus.com> <5dh51p$9hn@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > > > But the central question addressed (admittedly, somewhat > sensationally) in my original post to this thread was this: is the > file system more part of the UI, or the "plumbing"? Put another way, > if the next generation Mac OS is to keep most of the Mac user > experience, can it do so while adopting the NeXT file system? > > My own personal conclusion was that it would be a tough road... > I think at first, just because of the time constraints they're under, you'll see the existing unix file system with its existing structures. It wont be exactly the same as the Mac experience, in that respect, but I don't think it will impact anyone very hard. The final solution may be something NeXT had worked on in the past.. You see, there were several evolutionary steps that were supposed to go in to the 4.0 version of the OS that they dropped (transfering resources to the Openstep/Windows project to get it out the door on time). One was a new UI (instead of a dock, a multi-folder-tabbed application shelf, a different looking Dock, and some new half size icon buttons, plus a blue gradient title bar instead of flat black), a new kernel (which is probably what the Rhapsody kernel will be), one or two misc. OS thingys (one rumor that they were going to eliminate any AT&T code, and thus eliminate that license fee, more BSD 4.4isms, etc), and last but not least (and finnaly to the point ;-) ) was a new file system that more directly supported objects. I suspect that this would probably still have hidden "complex file entities are really wrappers, which are implimented via directories", but it would probably have added things like creator information and file type information somewhere other than the file name. (note, I dont know that for a fact, I'm speculating on what features the new file system would have had). On the otherhand, maybe they ARE going to resurect this, too. Now is really the time to do it, so that people don't have to change filesystem formats later (in Rhapsody 2.0 or something). Another option is taking the features of UFS and adding in features from HFS (they already know HFS formats, as Nextstep already supports Mac disks). But that is likely to be the most expensive (in terms of both time and money) option to develop.. there's no existing framework, there's not enough time to test it along wiht all of the other changes and still keep the delivery schedule (which is, to me, the main goal). But we'll see...
From: plsuh@goodeast.com (Paul L. Suh) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 08 Feb 1997 01:30:50 -0500 Organization: Monumental Network Systems Distribution: inet Message-ID: <plsuh-ya02408000R0802970130500001@news.gslink.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <qdohdwi3xe.fsf@blues.cygnus.com>, Stephen Peters <speters@cygnus.com> wrote: > Alan Jenks <jalanet@mcs.com> writes: > > One of the things that makes the Mac a joy to use is that I can create a > > file in an application and name it anything I choose. Double click the > > file and the application that created it will launch and open it. > > > > On Win 95 I have both Borland and MS compilers installed. After > > installing the Borland compiler all my MS Visual C (*.c/cpp) created > > files now insist on openning with the Borland compiler when I double > > click them! I can't have some *.c/cpp files open with VC and others with > > Borland and of course they must end in c/cpp to open with either one. > > > > What is the a type/creator mechanism on NextOS that will prevent this > > step backwards in usability for Mac users in the future? > > These two issues (whether the types are part of the filename and > the way in which file types and applications are tied together) are > actually orthogonal. > > There are two ways in which you can tie a filename in with an > application so that you can click on the filename and have the app > open it nicely. The first, as seen on the Mac, is to have every file > maintain a reference to the application which created it. The second, > as implemented on Win95 and NeXT, is to have applications publish the > file types that it knows how to handle, and give the user a way to > choose a default application for that file type. > > The first way works very well on a single-user machine where files are > usually created on the machine and left there; in this case, the > creator application is (usually) always present. The second way works > much better in a networked environment, where files get passed around > and an attempt is made to keep the files in open standard formats. > This way, the user on an individual machine can decide which > application he or she likes best for opening a given file type. Actually, on the Mac there are _two_ 4-byte references for each file: one is the file type, the other is the file creator. Thus, it is possible to have a file of type TEXT that when double-clicked is opened by SimpleText, while another file, also of type TEXT, is opened by Netscape Navigator when double-clicked. There is a mechanism in the MacOS (Macintosh Easy Open) that allows the user to designate a default app to open a file with a creator whose app is not installed on the machine. The combination of the two works extremely well in a networked environment, IMHO much better than simple file-type defaults. Both the primary mechanism and the Macintosh Easy Open mechanism can be overridden by using drag & drop or opening from within the app. I believe that this point is moot; Aplle almost certainly will integrate a full MacOS type/creator mechanism into the file system during the development of Rhapsody. --Paul
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 08 Feb 1997 01:35:32 -0800 Organization: Esperance Communications Message-ID: <jk-0802970135320001@ip-salem2-28.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <5ddtq2$ier@csugrad.cs.vt.edu>, nurban@vt.edu wrote: >One wonders if that's a good thing. One of the largest problems with >the Mac filesystem is that it's a huge pain trying to transfer files to >other platforms in a meaningful way. No, it's not. Other platforms can't use the stuff in resource forks anyway, if the file needs the res fork stuff, then it's a mac-specific file and is useless to non-macs. If it's not a mac-specific file, say a PNG image, then just the data fork can be transferred. Or one can use a scheme such as AppleDouble, which separates the mac-specific data from the non mac-specific data. The only problem is that MacOS is not capable of decoding MacBinarized, AppleSingled, or Binhexed files on its own, which causes problems for the mac user that doesn't possess utilities to handle such files. >> not directly related to text config files. Say what you want about >> the performance trade-offs of keeping track of aliases, > >Okay, I will. The performance trade-offs are awful. Based on what evidence? I don't know of any other OS than MacOS that offers mac-like "aliases", and there's still a lot of non-native code in MacOS. I'm sure that the alias handling has gone through a bit of performance tuning, the hit, if there is one is certainly miniscule when one considers the usefulness of aliases. I'm not convinced that there /are/ any significant performance trade-offs, however. -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. Boycott Microsoft! Why? See <URL:http://www.vcnet.com/bms/>.
From: Lars Immisch <immisch@pobox.com> Newsgroups: comp.sys.next.programmer Subject: Re: NeXT Semaphores? help... Date: Thu, 06 Feb 1997 19:06:05 +0100 Organization: Immisch, Becker & Partner Message-ID: <32FA1D8D.71A5@pobox.com> References: <Pine.ULT.3.91.970204142535.17504A-100000@grizzly.cs.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Scott W. Bradley wrote: > > I have a program that compiles on various other flavores of unix > that uses system semaphores. It does not compile on nextstep though. > I get things like "key_t" undefined. Alos, I can't even locate a header > file that I usually use called <sys/sem.h>. I can't seem to find > procedures like semget(). Can anybody please give any advice on how > to get this to work? semget()... This smells like SysV to me. So I guess the semaphores your program uses are simply not available under NeXTStep. Under NeXTStep, you could use the Mach conditions and mutexes. It should not be too difficult to write a SysV emulation layer, either. Lars -- mailto:immisch@pobox.com http://pobox.com/~immisch Yesterdays yellow yoyo can make you yawn today
From: svenifer@snet.net(Sven Crouse) Newsgroups: comp.sys.next.programmer Subject: Re: Documentation in PB 4.1 Date: 8 Feb 1997 06:19:33 GMT Organization: "SNET dial access service" Message-ID: <5dh5tl$2dl@goofy.snet.net> References: <5datht$547@q.seanet.com> In-Reply-To: <5datht$547@q.seanet.com> On 02/05/97, Misha M. Melikov wrote: >For some reason I can only see AppKit and Foundation documentation in >ProjectBuilder 4.1. All other frameworks do not get indexed and >documentation can not be seen. >Any thoughts? Should I be able to see any other documentation or is it too >much to ask? >-m > Also make sure that PB->preferences->indexing->host field is not set to anything if you want the projectServer (responsible for indexing I believe) to be your local machine. Sven
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 8 Feb 1997 17:34:24 GMT Organization: Indiana University, Bloomington Message-ID: <5didf0$jre@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <5dgqef$job$2@zeus.cygnet.co.uk> NNTP-Posting-User: 1073745024 In article <5dgqef$job$2@zeus.cygnet.co.uk>, Matthew Powell <matthew@imaginator.com> wrote: >If time really *is* immaterial, just call up the System 7.5 Find File and >hold down option whilst selecting what to search by. You'll see a number >of new options there including 'contents'. It takes forever, but it >works. :) Cool! I did not I could do that. Well, I've already tried TurboFind, and I don't have the article I was looking for. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 8 Feb 1997 17:59:35 GMT Organization: Boston University Message-ID: <5dieu7$p0v@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> John Rudd (jrudd@cygnus.com) wrote: : Ohgod.. do we have to go through this AGAIN!? My nntp server only had the very tail-end of the "Mach-o" discussion... : We already hashed this one out with Maury. Well you won't have to "have it out" with me; just explain it ;) : To the GUI user, a Wrapper looks EXACTLY like a file, except that it's : executable. The only difference is to the CLI user (which you probably : wont be anyway). --which I most assuredly *will* be, if there's one to use. It's not my personal fear that's motivating the discussion, it's the traditional Mac experience that I'm concerned about. : > I don't think there's anyone who would deny that messing with lines of : > text is more error prone even in the best conditions (i.e. no user : > modification of the file with a text editor to munge it up) simply : > because each text files are so free-form. : I will be the first to deny this. Any application can trash any unprotected : config file no matter what format it is in. And binary config files are no : less error prone to novice users. In fact, they may be more so, as the : person fires up a text editor to edit the binary one the first time, and : accidently trashes it. API calls can be just as easily implimented to do : text based config files as binary ones. First, a user running a text editor on a binary config file should have no effect provided they exit the app when they realize all they see is gibberish. Second, *programming a robust API for* changing text files is much more difficult and inefficient than a structured binary format. It comes down to this: If you believe that config files should be changable by directly editing the file, then text files make sense. If you believe that config files should only be changed through a well-defined UI or GUI, then text files are not the best idea. : There are advantages to binary config files, and to text config files. You : have touched on none of the real advantages nor disadvantages of either. I think I did earlier and have again. I stated that an advantage of text config files is that they're easy for the user to edit without special tools. Disadvantages are re-stated above. The advantages of binary config files stem from the belief that config files should not be edited directly by the user, but through a UI instead. This is an OS philosophy that I support, and one that the Mac OS has traditionally supported. It is in *no way* an attack on the NeXT OS! Isn't it possible to have an open discussion of OS design without any of THIS: : And, by the way, NeXT's system administration model, NetInfo, uses a binary : database. Stop your whining and go use a NeXT system before you keep going : on and on about how bad its' going to be. Did I ever say "there are no binary config files in NeXT"? I never even *mentioned NeXT* up to this point in my post! I was clearly taking about the general idea of text config files. There's absolutely no reason to get defensive! : > An example relevant to Rhapsody (see, there *is* a connection buried : > here ;) is how TCP/IP will be handled in the new OS. Ignoring the : > ancient and ugly roots of the current Mac OS on which it runs, I'd : > take the Open Transport control panels (Modem, TCP/IP, AppleTalk, : > PPP) over a slew of .conf text files any day! I routinely switch : > between FreePPP, OT/PPP, and direct ethernet connection with a few : > flips of switches in control panels on my Mac. Try that with a Unix : > box. If you decide you want to change from a direct connection to : > PPP, you'd better hope you have the config files all set up, and : > hopefully some shell scripts to moves everything around for you. Oh, : > and you'd better not have changed the location of any of the files : > that the scripts refer to. : I don't need to switch anything to do that on my Unix box. And it wouldnt' : matter if it was NeXtstep or not. In fact, unlike you and your Mac, I can : have PPP and ethernet going at the same time. But, generally, I can fire up : PPP or close it down with one double click. That's it. Perhaps mine was a bad example, considering the Mac's limited networking ability. My point was that user interaction with OS services is less error prone when you're dealing with only one level of abstraction. My argument is that the "Mac way" of direct interaction with, say, a control panel is preferable to clicking an icon which runs an executable (or, more likely, a script on a plain Unix system) which runs a setuid exe or script that runs ifconfig which changes your network settings. : I don't need to flip : any control switches, change between system configurations, etc.. Unix is : smart enough to know what aspects of your system are dialup networking : configs and which are local networking configs. I wouldn't go so far as saying Unix is "smart enough." A few wrong CLI commands in the /dev directory and Unix would become terminally confused. That's the nature of Unix, and I really *do* like Unix. I'm just highlighting the areas where the "Unix philosophy conflicts most with the Mac philosophy. (Note: I said U-n-i-x, not N-e-X-T! :) : > And speaking of moving files, another disadvantage of text : > configuration files is the hard-coding of file paths. Even Unix : > symlinks are an example of the limitations of this scheme, although : > not directly related to text config files. Say what you want about : > the performance trade-offs of keeping track of aliases, but it's : > certainly a better system than the "I'm scared to move anything : > because everything might break" world of .INI files, et al. : Which is another reason to use Wrappers. Everything the application needs : is in the wrapper or the system libraries. Agreed. They seem like a reasonable solution, provided the practice is followed consistently (which I assume it is in the NeXT world). But what about traditional Unix apps? Are the NeXT versions .app wrappers as well? (I'm talking about things like emacs, not simple binaries like tar or gzip) : > As far as I'm concerned, a *modern* OS should be the best of both : > worlds: the superb functionality of a preemptive memory-protected : > kernel and the interface of the Mac (along with a file system that : > allows it, of course!) : Correct.. the best of both worlds, the most solid OS core and foundations, : the most usable UI, the most flexable and capable programming model. See that? We don't entirely disagree. : In otherwords, Nextstep. Err... ;) I still think there has to be some sort of compromise, here. Although the initial release of Raphsody is bound to be "straight Nextstep," I believe changes are coming and will be beneficial. : > Conclusion: : > : > Even the much-vaunted BeOS seems to suffer from file proliferation a la : > Unix (/dev/modem anyone?) Perhaps this is unavoidable and I'm being : > naive. After all, the *only* example of an OS that doesn't work this : > way is the now-ancient Mac OS. But I don't thing there's any reason to : > resign ourselves to the "me-too" world of evil OSes that require : > "Uninstallers" and that keep us captive of a bazillion fragile text : > files. There's a better way, and I only hope that in the coming years : > the people behind the Mac/NeXT OS aren't afraid to break from the past : > and give us an OS we can be proud to call "Mac." : Or proud to move on to the next generation of the Mac, invented by the same : major visionaries of the Mac project.. called "The NeXT Computer". Yes, that's another option. But why throw away what's good about 7.x? : Now, before you go though these rants again, go out and use the damn thing. : Stop arguing from a stance of total ignorance. For the umpteenth time, I *have* used Next cubes and slabs. I'm not nearly as familiar with them as I am with the Mac and Unix, however, which is why 99% of my points dealt with Mac philosophy vs. *Unix* or *Windows* philosophy (well, if Windows can be said to *have* any philosophy ;) It's posted to a NeXT group to gauge how much Unix is in NeXT! There's no reason to get defensive! I think every time an avid NeXT user reads "Unix" he or she automatically assumes that it's some dumb Mac user (also assuming that Mac users believe in computer monogomy and only use on OS ;) just assumes that "NeXT *is* Unix", and that it's the job of the NeXT user to smack some sense the poster. This is not always the case, and is certainly not the case here! -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: chsu@from.net Newsgroups: comp.sys.next.programmer Subject: Send 20 FREE Pages of Fax to any Fax machines in the World! Date: 8 Feb 1997 19:22:09 GMT Organization: Fax24 International, Inc. Message-ID: <5dijp1$nhu@netnews.hinet.net> Send Fax through the Internet. Low domestic and international rates. 20 FREE pages of Fax! Send to any Fax machines in the world! No obligation. Visit the site at: http://www.edfax.com/faxsav.htm Chris Sundres chsu@from.net
From: sef@kithrup.com Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <5dijp1$nhu@netnews.hinet.net> Date: 8 Feb 1997 20:05:52 GMT Control: cancel <5dijp1$nhu@netnews.hinet.net> Message-ID: <cancel.5dijp1$nhu@netnews.hinet.net> Sender: chsu@from.net Spam cancelled by sef@kithrup.com
From: Bob Foster <bobfoster@worldnet.att.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Sat, 08 Feb 1997 19:33:57 +0000 Organization: Symantec Corp. Message-ID: <32FCD51C.3F8@worldnet.att.net> References: <5d8qta$6np@news.bu.edu> <5dal9c$bd1$3@majipoor.cygnus.com> <jk-0602972223190001@ip-salem3-30.teleport.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joel Klecker wrote: > > Hmm, I wasn't aware that "Reality Distortion Field.app" shipped with > NEXTSTEP. :-) You kidding? That's the most important feature. Bob -- Bob Foster Symantec Internet Tools <http://www.cafe.symantec.com/>
From: sef@kithrup.com Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <32fcdb9e.0@news.cias.net> Date: 8 Feb 1997 20:43:29 GMT Control: cancel <32fcdb9e.0@news.cias.net> Message-ID: <cancel.32fcdb9e.0@news.cias.net> Sender: xxxhot@*(^$#>(noreply).com Spam cancelled by sef@kithrup.com
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer Subject: problem with filter services Date: 9 Feb 1997 04:02:11 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5dji83$g1q@nef.ens.fr> Hello, i'm trying some things with the filter services bur hace some strange problems. (I'm running NS3.3) Here is my source : --- test.m #import <appkit/Pasteboard.h> void main(int argc, char *argv[]) { id myPb; const NXAtom *list; NXStream *stream; const char *selectedType; char *data; int length; if(argc!=4) { printf("Usage: %s FILE NEWFORMAT OUTFILE\n",argv[0]); exit(0); } myPb=[Pasteboard newByFilteringFile:argv[1]]; list=[myPb types]; if(!list) { printf("No filter available"); exit(0); } printf("available types :\n"); while(*list) { printf("%s\n",*list); if(!strcmp(argv[2],*list)) { printf("--> this one"); selectedType=*list; } list++; } if(!selectedType) { printf("%s is not a goot type\n",argv[2]); exit(0); } printf("selected type : \"%s\"\n",selectedType); [myPb readType:selectedType data:&data length:&length]; if(!data) { printf("nothing read - problem...\n"); } exit(0); } --- the goal is to "translate" a file to another possible type (the "write to file" part isn't currently in the source) by typing, e.g. : ./test foo.tiff "image format gif" foo.gif I have OmniImageFilter installed and my program outputs all the pasteboard types I want ("image format gif/bmp/...") ./test foo.tiff "NeXT TIFF v4.0 pasteboard type" foo2.tiff (not very useful : translate tiff to tiff :-) gives me a good result : (here data is not NULL) but if I try : ./test foo.tiff "image format gif" foo.gif it detects that "image format gif" is a good type but data is always NULL... why ? (in fact the only working types are "NeXT TIFF v4.0 pasteboard type" and "NXTypedFilenamePboardType:tiff" which do not require any filter services) It seems that Pasteboard know the services but doesn't want to use it ! --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 09 Feb 1997 01:07:33 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FD69A5.673A@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dgnar$rm1$1@majipoor.cygnus.com> <5dh51p$9hn@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > But the central question addressed (admittedly, somewhat > sensationally) in my original post to this thread was this: is the > file system more part of the UI, or the "plumbing"? Put another way, > if the next generation Mac OS is to keep most of the Mac user > experience, can it do so while adopting the NeXT file system? The Mac approach takes a UI issue and makes it part of the filesystem, which IMHO is bad. The NeXT approach makes the UI issue part of the UI implementation. Rather than using a multi-forked filesystem to support info & resources, NeXT wrote the WorkspaceManager and the Appkit to treat bundles as files. The user experience is virtually the same: resources stay in a cohesive unit, and the user interacts with what appears to be an atomic item. Apple changed the filesystem, which resulted in persistent compatability headaches. Most of the perceived problems in reconciling the Mac and NeXT UI's and filesystems can be solved by adding some functionality into the WorkspaceManager and Appkit. Appkit changes will be adopted by all OpenStep applications and objects automatically. Even creator information could be handled this way, but on an improved, per-user basis, using some sort of database or hashtable. Each user could have their own creator code for a given file, rather than the file specifying one creator code for all users. -- jon@steeldriving.com
From: geordie@chapman.com (Geordie Korper) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 07 Feb 1997 11:52:27 -0600 Organization: Chapman and Cutler Message-ID: <geordie-ya02408000R0702971152270001@kyrie> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5ddtq2$ier@csugrad.cs.vt.edu>, nurban@vt.edu wrote: :In article <5ddp66$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: : snip :> 2. Text configuration files : :> Also known as: the bane of "modern" OS design. : :I like them. : :> There is absolutely :> *no* excuse for text-based configuration files in a modern GUI :> operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, :> they're readable by every lowly text editor. But cripes! When you :> start providing API calls to add and delete lines from a text file :> (GetProfileString(), etc.) you *know* you're barking up the wrong :> tree! : :It's not too bad. Anyway, NEXTSTEP uses the NetInfo database for most :configuration stuff.. though it also tends to manipulate config files :to make the Unix people happy. : :> I don't think there's anyone who would deny that messing with lines of :> text is more error prone even in the best conditions (i.e. no user :> modification of the file with a text editor to munge it up) simply :> because each text files are so free-form. There are no constraints of :> design to keep a badly behaved application from munging up a shared :> configuration file. : :Agreed. : :I've always thought it would be neat to use the GNU Hurd's filesystem :translators to fix this.. keep everything in a database, and have a :file translator sitting on top of the config file, so that when you read :the file it really queries the database and then prints out the text :file in the appropriate format from the result.. then things that :expect the text config files can still use them, but you can start :transitioning configuration over towards a cleaner database design. : :> An example relevant to Rhapsody (see, there *is* a connection buried :> here ;) is how TCP/IP will be handled in the new OS. Ignoring the :> ancient and ugly roots of the current Mac OS on which it runs, I'd :> take the Open Transport control panels (Modem, TCP/IP, AppleTalk, :> PPP) over a slew of .conf text files any day! I routinely switch :> between FreePPP, OT/PPP, and direct ethernet connection with a few :> flips of switches in control panels on my Mac. Try that with a Unix :> box. If you decide you want to change from a direct connection to :> PPP, you'd better hope you have the config files all set up, and :> hopefully some shell scripts to moves everything around for you. Oh, :> and you'd better not have changed the location of any of the files :> that the scripts refer to. : :NeXT's admin tools do a good job of manipulating the config files. You :never have to touch most of them yourselves. (Apple is working on :changing that "most" to "all".) As for changing the location of the :configuration files, I have no idea why you would do that. : :> And speaking of moving files, another disadvantage of text :> configuration files is the hard-coding of file paths. Even Unix :> symlinks are an example of the limitations of this scheme, although :> not directly related to text config files. Say what you want about :> the performance trade-offs of keeping track of aliases, snip Not to mention that his beloved Open/Transport PPP has configuration files for the modems that look like the following, and the only pseudo user interface to it is an alpha application that is hard to locate. begin Apple copyrighted information which is freely availible on their web site. ! USRobotics Universal ! CUSTOM SCRIPT due to "NO DIAL TONE" responce ! Author: Kris Kreutzman ! ! Copyright: © ="c" 1991-1996 Apple Computer, Inc. All Rights Reserved. ! ! revision history: ! v2.1 as shipped with the ARA 2.1 ! v2.2 update CARRIER/CONNECT parsing ! ! 'mlts' resource info for this modem: ! byte 1 == 01 -> modem HAS built-in error correction protocols ! byte 2 == 01 -> modem HAS built-in data compression protocols ! byte 3 == 33 -> max number of chars in varstr 7 ! byte 4 == 33 -> max number of chars in varstr 8 ! byte 5 == 33 -> max number of chars in varstr 9 ! @ORIGINATE @ANSWER ! ! ---- Initial modem setup ---- ! ! Set serial port speed depending upon the compression flag ! A higher rate with compression on to handle expanded data from the modem ! A lower rate closer to the DCE when compression is off ! ifstr 5 1 "0" serreset 57600, 0, 8, 1 jump 2 ! @LABEL 1 serreset 38400, 0, 8, 1 ! @LABEL 2 hsreset 0 0 0 0 0 0 settries 0 ! ! Get the modem's attention ! matchclr matchstr 1 3 "OK\13\10" write "AT\13" matchread 30 ! @LABEL 3 ! ! Setup the modem for the following: ! Reset to factory settings ! Standard compression/reliablity ! Lock serial port speed ! Serial port hardware handshaking, turn off software handshaking ! Verbose responces and compression/protocol results ! CONNECT returns DCE speed ! Turn off answering ! Reset or return to command mode on DTR toggle (optional) ! pause 5 matchclr matchstr 1 4 "OK\13\10" matchstr 2 101 "ERROR\13\10" write "AT&FE0&D2&H1&R1&B1Q0X4&A3S7=75S0=0\13" matchread 30 inctries iftries 3 101 ! ! Reset the Modem on setup failure ! DTRClear pause 5 DTRSet flush jump 3 ! ! @LABEL 4 ! Varstring 4 , reliable link protocol: ! = 0, handled by computer (ARAP) ! = 1, handled by modem (PPP) ! = 2, MNP10 protocol (Cellular protocol, no longer supported) ifstr 4 5 "1" ifstr 4 5 "2" ! ! Varstring 4 == 0, turn off reliable link protocol in modem (ARAP) matchclr matchstr 1 9 "OK\13\10" write "AT&M0\13" matchread 30 jump 101 ! ! @LABEL 5 ! Varstring 5, compression protocol: ! = 0, handled by computer ! = 1, handled by modem ifstr 5 9 "1" ! ! Varstring 5 == 0, turn off compression protocol in modem. matchclr matchstr 1 9 "OK\13\10" write "AT&K0\13" matchread 30 jump 101 ! ! @LABEL 9 ! Varstring 2, modem speaker: ! = 0, speaker off ! = 1, speaker on ifstr 2 13 "1" pause 5 matchclr matchstr 1 13 "OK\13\10" write "ATM0\13" matchread 30 jump 101 ! ! Modem ready, wait for a call or originate a call ! @LABEL 13 ifANSWER 32 ! ! ! ---- Originating a call ---- ! ! Varstring 6, dialing mode: ! = 0, normal dialing ! = 1, blind dialing ! = 2, manual dialing ifstr 6 17 "1" ifstr 6 15 "2" jump 19 ! @LABEL 15 ! Display ASK dialog with message. Goto label 107 if dialog canceled. ASK 2 "Pick up the phone & dial ^1. When the phone rings, click OK then hang up." 107 note "Manual dialing initiated" 3 ! X1 to ignore dialtone & busy, D to dial, \^ generates data tone write "ATX1D\^\13" jump 32 ! @LABEL 17 note "Dialing without tone" 3 matchclr matchstr 1 19 "OK\13\10" ! X1 to ignore dialtone & busy write "ATX1\13" matchread 30 jump 101 ! ! @LABEL 19 ! Display the full dialstring contained in Varstring 1 note "Dialing ^1" 3 ! ! Varstrings 7, 8 and 9, contain dialstring fragments ! Long phone numbers may need to be split into smaller groups ! for the modem to use ! ! Varstring 3: "p" for pulse & "t" for tone dialing ! Varstring 8 == blank (dialstring in varstring 7) ! Varstring 9 == blank (dialstring in varstrings 7 & 8) ! Otherwise (dialstring in varstrings 7, 8 & 9) ! \^ is added to the dialstring to force the modem to generate a data tone ifstr 8 27 " " ifstr 9 24 " " ! ! Write dialstring in varstrings 7, 8 & 9 matchclr matchstr 1 21 "OK\13\10" write "ATD^3^7;\13" matchread 400 jump 101 @LABEL 21 matchclr matchstr 1 22 "OK\13\10" write "ATD^3^8;\13" matchread 400 jump 101 @LABEL 22 write "ATD^3^9\13" jump 32 ! ! @LABEL 24 ! Write dialstring in varstrings 7 & 8 matchclr matchstr 1 25 "OK\13\10" write "ATD^3^7;\13" matchread 400 jump 101 @LABEL 25 write "ATD^3^8\13" jump 32 ! @LABEL 27 ! Write dialstring in varstring 7 write "ATD^3^7\13" ! ! ! ---- Connection responce ---- ! ! The following section will parse modem responces of two types: ! 1) CARRIER xxx, PROTOCOL: yyy, COMPRESSION: yyy, CONNECT xxx ! 2) CONNECT xxx/yyy ! @LABEL 32 settries 0 @LABEL 33 matchclr matchstr 1 81 "RING\13\10" matchstr 2 102 "NO DIAL TONE\13\10" matchstr 3 103 "NO CARRIER" matchstr 4 103 "ERROR\13\10" matchstr 5 104 "BUSY\13\10" matchstr 6 105 "NO ANSWER\13\10" matchstr 7 35 "CONNECT" matchstr 8 34 "CARRIER" matchstr 9 62 "PROTOCOL: LAP" matchstr 10 62 "PROTOCOL: MNP" matchstr 11 62 "PROTOCOL: ALT" matchstr 12 67 "COMPRESSION: V" matchstr 13 67 "COMPRESSION: MNP5" matchstr 14 67 "COMPRESSION: CLASS" matchread 700 ifANSWER 32 jump 105 ! ! CARRIER parsing ! @LABEL 34 jsr 38 inctries jump 33 ! ! CONNECT parsing - do not parse rate if CARRIER seen ! @LABEL 35 iftries 1 61 jsr 38 jump 61 ! ! Parse CONNECT/CARRIER rate subroutine ! 2400 and 4800 have two entries each ! to distinguish them from 24000 and 48000 ! @LABEL 38 matchclr matchstr 1 40 "2400\13" matchstr 2 40 "2400/" matchstr 3 41 "4800\13" matchstr 4 41 "4800/" matchstr 5 42 "7200" matchstr 6 43 "9600" matchstr 7 44 "12000" matchstr 8 45 "14400" matchstr 9 46 "16800" matchstr 10 47 "19200" matchstr 11 48 "21600" matchstr 12 49 "24000" matchstr 13 50 "26400" matchstr 14 51 "28800" matchstr 15 52 "31200" matchstr 16 53 "33600" matchread 10 jump 59 ! ! -- Connection rates -- ! CommunicatingAt informs ARA of the raw modem to modem ! connection speed. ! @LABEL 40 note "Communicating at 2400 bps." 2 CommunicatingAt 2400 jump 60 ! @LABEL 41 note "Communicating at 4800 bps." 2 CommunicatingAt 4800 jump 60 ! @LABEL 42 note "Communicating at 7200 bps." 2 CommunicatingAt 7200 jump 60 ! @LABEL 43 note "Communicating at 9600 bps." 2 CommunicatingAt 9600 jump 60 ! @LABEL 44 note "Communicating at 12400 bps." 2 CommunicatingAt 12400 jump 60 ! @LABEL 45 note "Communicating at 14400 bps." 2 CommunicatingAt 14400 jump 60 ! @LABEL 46 note "Communicating at 16800 bps." 2 CommunicatingAt 16800 jump 60 ! @LABEL 47 note "Communicating at 19200 bps." 2 CommunicatingAt 19200 jump 60 ! @LABEL 48 note "Communicating at 21600 bps." 2 CommunicatingAt 21600 jump 60 ! @LABEL 49 note "Communicating at 24000 bps." 2 CommunicatingAt 24000 jump 60 ! @LABEL 50 note "Communicating at 26400 bps." 2 CommunicatingAt 26400 jump 60 ! @LABEL 51 note "Communicating at 28800 bps." 2 CommunicatingAt 28800 jump 60 ! @LABEL 52 note "Communicating at 31200 bps." 2 CommunicatingAt 31200 jump 60 ! @LABEL 53 note "Communicating at 33600 bps." 2 CommunicatingAt 33600 jump 60 ! @LABEL 59 note "Communicating at an unknown rate." 2 ! @LABEL 60 return ! ! Look for reliablilty and compression results ! after the CONNECT rate. ! @LABEL 61 matchclr matchstr 1 63 "LAPM" matchstr 2 63 "REL" matchstr 3 63 "ARQ" matchstr 4 68 "COMP/" matchstr 5 68 "COMP\13" matchstr 6 63 "V42/" matchstr 7 63 "V42\13" matchstr 8 68 "V42BIS" matchstr 9 68 "V42bis" matchstr 10 63 "MNP\13" matchstr 11 68 "MNP5" matchstr 12 70 "\10" matchread 10 jump 70 ! -- Modem error correction link negotiation -- ! Userhook 2 informs ARA that a modem-to-modem error ! correcting protocol has been negotiated ! ! @LABEL 62 note "Modem Reliable Link Established." 2 userhook 2 jump 33 ! @LABEL 63 note "Modem Reliable Link Established." 2 userhook 2 jump 61 ! ! -- Compression negotiation -- ! Userhook 3 informs ARA that a modem-to-modem compression ! protocol has been negotiated ! @LABEL 67 note "Modem Compression Established." 2 userhook 3 jump 33 ! @LABEL 68 note "Modem Compression Established." 2 userhook 3 jump 61 ! ! ! -- Normal exit after "CONNECT" -- ! ! This modem has been setup to do CTS handshaking, ! and we assume that a CTS handshaking cable is being used. ! @LABEL 70 ! Turn on CTS handshaking. HSReset 0 1 0 0 0 0 ! ifANSWER 71 pause 30 @LABEL 71 exit 0 ! ! ! ---- Answer calls ---- ! ! A RING result from the modem and in ANSWERING mode ! claims the serial port and answering the phone ! @LABEL 81 ifORIGINATE 32 userhook 1 note "Answering phone..." 2 write "ATA\13" jump 32 ! ! ! ---- Hang up and reset modem ---- ! @HANGUP @LABEL 90 settries 0 HSReset 0 0 0 0 0 0 ! @LABEL 92 ! Escape from data to command mode matchclr matchstr 1 96 "OK\13\10" write "+++" matchread 20 ! @LABEL 94 ! Force a hangup matchclr matchstr 1 98 "NO CARRIER\13\10" matchstr 2 98 "OK\13\10" matchstr 3 98 "ERROR\13\10" matchstr 4 98 "0\13\10" write "ATH\13" matchread 30 ! ! Try to get control of the modem by toggling DTR DTRClear pause 5 DTRSet flush ! ! Try the hangup sequence three times otherwise declare and error inctries iftries 3 101 jump 92 ! @LABEL 96 ! Pause between data and command mode pause 50 jump 94 ! ! @LABEL 98 ! Recall the factory settings pause 15 matchclr matchstr 1 99 "OK\13\10" write "AT&F\13" matchread 30 jump 101 ! @LABEL 99 exit 0 ! ! ---- Error messages ----- ! ! Modem Not Responding @LABEL 101 exit -6019 ! ! No Dial Tone @LABEL 102 exit -6020 ! ! No Carrier or Error @LABEL 103 exit -6021 ! ! Busy @LABEL 104 exit -6022 ! ! No Answer @LABEL 105 exit -6023 ! ! User Cancellation @LABEL 107 exit -6008 -- Geordie Korper geordie@chapman.com ********************************************************************* * The text above should in no way be construed to represent the * * opinions of my employer, even if specifically stated to do so. * *********************************************************************
From: droleary@alpha.temporal.org (Doc O'Leary) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 9 Feb 1997 09:19:13 GMT Organization: University of Minnesota Message-ID: <slrn5fr5kf.93c.droleary@alpha.temporal.org> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> On 07 Feb 1997 15:37:01 -0800, Stephen Peters <speters@cygnus.com> wrote: >Embedding type information into the filename is really a separate >issue (and one which can, again, be hidden from the user if the >programmers desire). Another (more attractive, in my opinion) option is to inspect the contents of the file to determine the type. This is done all the time with the file command in Unix. Some X file managers use it to type files, and I think it would be a good thing to add to the Finder/Browser of the new Mac OS. --------- Doc -- Copyright 1997 by Doc O'Leary. Author of the wildly unsuccessful "DOS and Windows for People Who Still Have a Clue"
From: Christian Kuhtz <kuhtz@ix.netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 9 Feb 1997 10:08:20 GMT Organization: Netcom Message-ID: <5dk7mk$d2g@dfw-ixnews6.ix.netcom.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> droleary@alpha.temporal.org (Doc O'Leary) wrote: >On 07 Feb 1997 15:37:01 -0800, Stephen Peters <speters@cygnus.com> wrote: > >>Embedding type information into the filename is really a separate >>issue (and one which can, again, be hidden from the user if the >>programmers desire). > >Another (more attractive, in my opinion) option is to inspect the contents >of the file to determine the type. This is done all the time with the >file command in Unix. Some X file managers use it to type files, and I think >it would be a good thing to add to the Finder/Browser of the new Mac OS. It would be a really bad thing because it will suck rocks in networked environments, just like the current file managers that do that already. That's one feature I hope I will never see in Rhapsody. -- Christian Kuhtz <chk@gnu.ai.mit.edu> (personal) <ckuhtz@paranet.com> (work) ".com is a mistake."
From: dmgarvey@tcd.ie (Daire Garvey) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 11:49:52 GMT Organization: University of Dublin, Trinity College Message-ID: <5df4t0$mki@web3.tcd.ie> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> In <5ddpn1$jpc@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > Let me say it more simply: as much as you and I find perverse > joy in the nooks and crannies of a Unix world: > > *** MAC USERS WILL NEVER ACCEPT UNIX *** Don't be daft. There will be as much UNIX on the face of Rhapsody as there is VMS on the face of WindowsNT, now shut up! jeez.. D. -- daire@netsoc.tcd.ie ----------------+-------- http://www.netsoc.tcd.ie/~daire | "Heck! If I had 2 grand, | - 3rd Year Computer Science. I'd Be a developer too!!" | - DU NetSoc Support Officer.
From: Dave Griffiths <dave@prim.demon.co.uk> Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: Arbitary precision arithmetic? Date: Sun, 9 Feb 1997 12:03:21 GMT Organization: 3Wiz - World Wide Web Consultants Message-ID: <1997Feb9.120321.1665@prim.demon.co.uk> Hi, does anyone know of a simple maths library that will let you do arbitary precision integer arithmetic from C/Obj-C on NeXTStep? I found something called "pari" but it has a Sun3 assembler file that doesn't compile. Thanks, Dave
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.software,comp.sys.next.programmer Subject: Re: Arbitary precision arithmetic? Date: Sun, 9 Feb 1997 10:41:18 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <EmzT0Se00iWW81I3wQ@andrew.cmu.edu> References: <1997Feb9.120321.1665@prim.demon.co.uk> In-Reply-To: <1997Feb9.120321.1665@prim.demon.co.uk> Excerpts from netnews.comp.sys.next.programmer: 9-Feb-97 Arbitary precision arithmetic? by Dave Griffiths@prim.demo > Hi, does anyone know of a simple maths library that will let you do > arbitary precision integer arithmetic from C/Obj-C on NeXTStep? Sure-- libmp.a, documented in 'man mp'. However, you'd be well advised to use the GNU MP library, libgmp.a, since the GNU implementation is significantly better than the stock Unix version.. -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@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 09 Feb 1997 19:59:34 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FE72F6.4C96@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doc O'Leary wrote: > > On 07 Feb 1997 15:37:01 -0800, Stephen Peters <speters@cygnus.com> wrote: > > >Embedding type information into the filename is really a separate > >issue (and one which can, again, be hidden from the user if the > >programmers desire). > > Another (more attractive, in my opinion) option is to inspect the contents > of the file to determine the type. This is done all the time with the > file command in Unix. Some X file managers use it to type files, and I think > it would be a good thing to add to the Finder/Browser of the new Mac OS. It'd be a nice backup system for files which have had their extension munged. If used for all files, it might get a little slow. Some caching might help that, though. But what if you want to name two files the same? It's not uncommon for me to have two files in the same directory with the same name but different extensions. For instance, splash.riff and splash.bmp. Splash.riff is a working file, splash.bmp is a duplicate that is used in an application. The riff file is required since bmp's don't support Painter floaters. Take away extensions and you either have two files named splash - if duplicates are allowed. If duplicates are not allowed, you'll end up with splash_riff and splash_bmp or some such, which puts the extension back in anyway. How does the Mac handle duplicates? It's been too long since I used one. I'm thinking that you can't have two files of different types in the same directory with the same name, but I could be wrong. Anyone? Anyone? Bueller? -- jon@steeldriving.com
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Sun, 9 Feb 1997 22:26:35 -0500 Organization: phenix@interpath.com Message-ID: <199702092226354712026@roxboro-189.interpath.net> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Gregory Loren Hansen <glhansen@copper.ucs.indiana.edu> wrote: ] In article <connelly-ya023680000602970146410001@news.ziplink.net>, ] Paul Connelly <connelly@dawnstar.darc.org> wrote: ] >In article <5dbfr3$g10@dismay.ucs.indiana.edu>, ] >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: ] > ] >> Don't confuse the operating system with the shells. ] > ] >The shell is the best part of UNIX though. The tools that come ] >with the shell are great. Just get rid of that horrid directory ] >structure. (Let's see, is that program in /bin, or was it /usr/bin, ] >or /usr/local/bin, or....?) ] ] Speaking of which, is there anything like a find/grep combination for ] Mac? I may or may not have a document about Schrödinger that I'd like ] to look up. But I have no idea where it might be, and I'm sure it ] would be buried in file with a bunch of other stuff, and the name ] would have no relation to the subject. And I don't know where to get ] it from an outside source. I've made a few requests but got no ] response. Use the sys7's Find File, click on the drop down menu on the left while holding down the Option key, select contents and then set the file's probable type and creator - size to if you have a estimate. You can't have regular expressions but you SHOULD be able to find what you're looking for. -- John Moreno
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 9 Feb 1997 22:26:32 -0500 Organization: phenix@interpath.com Message-ID: <199702092226324711866@roxboro-189.interpath.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB8651.243F@worldbank.org> Stefano Pagiola <spagiola@worldbank.org> wrote: ] Alan Jenks wrote: ] > One of the things that makes the Mac a joy to use is that I can ] > create a file in an application and name it anything I choose. ] > Double click the file and the application that created it will ] > launch and open it. ] > ] > On Win 95 I have both Borland and MS compilers installed. After ] > installing the Borland compiler all my MS Visual C (*.c/cpp) created ] > files now insist on openning with the Borland compiler when I double ] > click them! I can't have some *.c/cpp files open with VC and others ] > with Borland and of course they must end in c/cpp to open with ] > either one. ] > ] > What is the a type/creator mechanism on NextOS that will prevent ] > this step backwards in usability for Mac users in the future? ] ] The OS keeps track of all the filetypes an app can deal with. Through ] the Workspace's inspector, you can specify which app will, by default ] open a given file type. But in any given instance you can over-ride ] this default by either double-clicking on a different app within in ] the workspace inspector or command-dragging the file onto that app's ] icon. ] ] So, yes, all files with the same extension will by default open in a ] given app (you can't have some opening in one app and some opening in ] another) but there are easy and quick ways to over-ride the default ] whenever you choose to. ] ] Having said that, it seems to me that it ought to be simple to have a ] way to add particular extensions to the OS and tell it which app to ] direct files with those extensions to. That way you wouldn't be ] dependent on the specific extensions your app came with. In the ] example above, you could just customize your VC files to end with .vc ] instead of .c, and tell the OS to send any such files to VC rather ] than Borland. There is a freeware app that lets you do this under ] NeXTSTEP, but its not part of the OS. The Macs way is a better way to do this, it just needs a little extension. Have a type and creator associated with each file, established by the files creator, and allow the user to override that with something similar to Macintosh Easy Open. The problem with MEO is that it doesn't allow you to do the overriding when the creating applications is available and it doesn't allow you to do something like say that *all* TEXT files are to be opened by 'My favorite text editor'. It'd be nice if you could have it open MFTE as the default for all TEXT files, all TEXT files whose creator is unavailable, or for only some TEXT files - with a list of creators to override. MEO could be modified to work properly easily enough - in fact I'm tempted to send this in as a suggestion to Apple for Sys 7, how would you do this with NeXT? -- John Moreno
From: jc@or.psychology.dal.ca (John Christie) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 10 Feb 1997 04:11:06 GMT Organization: ISINet, Nova Scotia Message-ID: <5dm74q$906@News.Dal.Ca> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <32FE72F6.4C96@subsequent.com> Jonathan W. Hendry (jon@subsequent.com) wrote: : Doc O'Leary wrote: : But what if you want to name two files the same? It's not uncommon : for me to have two files in the same directory with the same name : but different extensions. For instance, splash.riff and splash.bmp. Those aren't the same name. Why would one ever want to use EXACTLY the same name for two files on purpose. I hope no one ever comes up with a file system that allows that. I'd hate to have to follow some of the programmers I've seen in a project on such a file system. : not allowed, you'll end up with splash_riff and splash_bmp or some : such, which puts the extension back in anyway. But it does not reinstate the necessity for extensions or the limitations they engender. : How does the Mac handle duplicates? It's been too long since I : used one. I'm thinking that you can't have two files of different : types in the same directory with the same name, but I could be : wrong. Anyone? Anyone? Bueller? You could always use exactly the same name but add a blank space at the end of one of them. After that is done how are you going to easily tell them apart? (OK, the one with the space will be later in list view and HOPEFULLY they will have different icons in icon view). This was the worst argument in this thread yet. -- ------------------------------------------------------------------ John Christie "You aren't free because you CAN choose - only if you DO choose." "All you are is the decisions you make. If you let circumstances make them for you then what you are becomes very easy to estimate."
From: nspace@cts.com (Jerry Stratton) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 09 Feb 1997 19:21:07 -0800 Organization: Negative Space Message-ID: <nspace-0902971921070001@nspace2.cts.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <32FE72F6.4C96@subsequent.com> In article <32FE72F6.4C96@subsequent.com>, jon@subsequent.com wrote: >How does the Mac handle duplicates? It's been too long since I >used one. I'm thinking that you can't have two files of different >types in the same directory with the same name, but I could be >wrong. Anyone? Anyone? Bueller? Duplicate filenames in the same folder? Not allowed, type notwithstanding. While I did use to see that in DOS fairly often, it was usually considered a bug :*) The Mac stores all sorts of useful information in the header; the two that seem to be important for this discussion are the creator and the type. For example, if I save a Microsoft Word file as rich text format, the creator is MSWD, and the type is *RTF (or something like it). If a user double-clicks a file with those codes, the Mac first tries to open the creator (MSWD). If the creator doesn't exist, it then queries other applications and compiles a list of those that claim to understand *RTF. Depending on the user's settings, it will then provide the user with the list, and ask which one is most appropriate, or it will remember what the user chose the *last* time they tried to open a *RTF file and just do it. This is also how the Mac knows how to handle visual feedback on drag-and-drop. If you drag a document over an application, you'll get the darkening feedback if the application claims to understand that file type. Jerry jerry@hoboes.com http://www.hoboes.com/ e-mail help@hoboes.com What Your Children Are Doing: http://www.hoboes.com/Children/
From: anti_email_spam@real.address.in.sig (M) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 09 Feb 1997 19:03:21 -0900 Organization: UAS Message-ID: <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> In <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > In <5ddp66$jpc@news.bu.edu> John Siracusa wrote: [snip] > > 1. Hiding directories isn't the same as "hidden" resource forks. [snip] > But NeXT moved on from that becuase it is less flexible than Wrappers. By > opening the file into multiple files that _can_ be accessed by advanced > users, you can change sections of the code without any fancy tools. Things ^^^^^^^^^^^ Gee, all these years of using it, and I didn't know ResEdit was such a Fancy Tool. If you turn things 90 degrees and look at them, you could see that having to fire up a CLI to get into those wrappers is just another case of having to use a Fancy Tool. :) > like UI elements, and optional Language localization features (which Gil > Amelio has already said he wants to take advantage of). To the GUI user, a > Wrapper looks EXACTLY like a file, except that it's executable. The only > difference is to the CLI user (which you probably wont be anyway). The fact One nice thing about resource forks is that any file can have one, which is quite useful. For example, BBEdit (a popular text editor) saves some file state stuff (window size & position, location scrolled to, and document specific preferences) to resources while keeping the vanilla ascii text in the data fork. The file type is set to 'TEXT' so any app that can deal with plain ascii will open the file flawlessly, without any file conversion or any need to understand BBEdit's custom resources. When copying the text file to another platform, the resource fork is ignored. This is just one example. Many apps that deal with common file types (text, pict, jpeg, gif, tiff, eps, etc.) use the resource fork to store extra info useful for that app (or any others that recognize the same resource types), without sacrificing the portability of the file. Now, getting to my point here. . . . 1. You seem to imply that only executables are "wrappable". 2. Even if that is not the case (or it is changed for Rhapsody), I WILL be using the CLI from time to time. Having all my BBEdit files (etc.) really be directories containing several files would be, at best, cumbersome to work with. > that folders and Wrappers are both implimented with the same file system > element is just that.. an IMPLIMENTATION DETAIL. It does not change the user > experience ONE BIT, unless you become advanced enough to appreciate the > dynamic configurability and extensability of Wrappers (you could, for > example, make a business of just adding multi-language support to apps that > don't have it.. and you wouldn't need to have access to any special code from > teh application vendor.. just the normal installed application -- because the > wrapper is extensible, dynamic and HIERARCHICAL). Well, I can modify any app on my drive right now without any "special code" from the application vendor. Most Mac apps have any data that needs to be localized in standard, easily editable resource types. I expect the multi-language support in NeXTstep may be much better than the current Mac model, and if so I welcome it with open arms. But, this is really more of an issue of different API's and has nothing to do with what we are talking about here. You _seemed_ to imply that a Mac user couldn't freely modify or add new resources on their own (which is false). And yes, I do get your point with that last word in all caps -- since wrappers are really just directories the ability to create subdirectories within them is very cool. I just would hate to see the benefits of the current Mac resource model thrown out completely. Perhaps in Rhapsody Apple/NeXT will modify the current NeXT system to give us a bit of the best of both worlds. They're going to have to do something eventually to accommodate the Sys 7 "blue box", unless System 7 era files will only be able to exist on a separate partition using the old Mac file system. > > 2. Text configuration files > > > > Also known as: the bane of "modern" OS design. There is absolutely > > *no* excuse for text-based configuration files in a modern GUI > > operating system. Yes, they're oh-so-easy to edit from a CLI. Yes, > > they're readable by every lowly text editor. But cripes! When you > > start providing API calls to add and delete lines from a text file > > (GetProfileString(), etc.) you *know* you're barking up the wrong > > tree! > > > > I don't think there's anyone who would deny that messing with lines of > > text is more error prone even in the best conditions (i.e. no user > > modification of the file with a text editor to munge it up) simply > > because each text files are so free-form. There are no constraints of > > design to keep a badly behaved application from munging up a shared > > configuration file. In this scenario, it's easy to see why there'd be > > API calls! It minimizes the possibility of programmer error. But > > that's just treating the symptoms! > > I will be the first to deny this. Any application can trash any unprotected > config file no matter what format it is in. And binary config files are no > less error prone to novice users. In fact, they may be more so, as the > person fires up a text editor to edit the binary one the first time, and > accidently trashes it. This never happens on the Mac because most config files have the file type set to 'pref' with the creator code set to whatever uses them. If Joe Newbie double-clicks on the file it will try to launch the creator, but the file will not actually open in the app. Similarly, if the user is looking at the directory containing the pref file using the app's normal open dialog, the pref file won't be shown. (The same as with any other file types the app doesn't know how to open.) There are easy ways for a knowledgeable user to get into those files if they want to, but for novice users it is virtually bulletproof. > . . . . API calls can be just as easily implimented to do > text based config files as binary ones. > > There are advantages to binary config files, and to text config files. You > have touched on none of the real advantages nor disadvantages of either. Try > again. Mac users tend to prefer binary config files because: a. To protect them from the typical user the file type is usually not 'TEXT' anyway (even if it is ascii based). b. If saved in resources, settings which for one reason or another are not available to users in "control panels" or an app's dialogs can be easily edited in ResEdit. TMPL resources are templates that describe the format of a resource, allowing binary configuration resources to be edited using the GUI. Individual bits to be toggled show up as nicely labeled "radio buttons", strings & numbers have their own edit fields (again, labeled so you know what parameter you're editing). This makes them easy to edit, nearly impossible for the user to screw up the format, and smaller than ascii config files. [snip] > > As far as I'm concerned, a *modern* OS should be the best of both > > worlds: the superb functionality of a preemptive memory-protected > > kernel and the interface of the Mac (along with a file system that > > allows it, of course!) > > Correct.. the best of both worlds, the most solid OS core and foundations, > the most usable UI, the most flexable and capable programming model. In > otherwords, Nextstep. Yes, Nextstep . . . with an overhaul. > > Conclusion: > > > > Even the much-vaunted BeOS seems to suffer from file proliferation a la > > Unix (/dev/modem anyone?) Perhaps this is unavoidable and I'm being > > naive. After all, the *only* example of an OS that doesn't work this > > way is the now-ancient Mac OS. But I don't thing there's any reason to > > resign ourselves to the "me-too" world of evil OSes that require > > "Uninstallers" and that keep us captive of a bazillion fragile text > > files. There's a better way, and I only hope that in the coming years > > the people behind the Mac/NeXT OS aren't afraid to break from the past > > and give us an OS we can be proud to call "Mac." > > Or proud to move on to the next generation of the Mac, invented by the same > major visionaries of the Mac project.. called "The NeXT Computer". > Obviously Apple finnaly realized that Jobs was right with the changes he > wanted to make the Mac, and are now going to incorporate them. And there are changes that need to be made to NeXTstep. It's not a sacred cow, is it? > Now, before you go though these rants again, go out and use the damn thing. > Stop arguing from a stance of total ignorance. Now, before you go though these rants again, you need to have a better understanding of what these Mac users don't want to _lose_ in the next MacOS. ---< jsmdt@acad1.alaska.edu >------------------------------------------------
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 9 Feb 1997 22:10:32 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5dme4o$ave@crl.crl.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> In article <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu>, M <anti_email_spam@real.address.in.sig> wrote: >> But NeXT moved on from that becuase it is less flexible than Wrappers. By >> opening the file into multiple files that _can_ be accessed by advanced >> users, you can change sections of the code without any fancy tools. Things > ^^^^^^^^^^^ >Gee, all these years of using it, and I didn't know ResEdit was such a >Fancy Tool. If you turn things 90 degrees and look at them, you could see >that having to fire up a CLI to get into those wrappers is just another case >of having to use a Fancy Tool. :) 1. Compared to nothing, anything is fancy. 2. You don't need to drop down to a CLI to get into a wrapper. >This is just one example. Many apps that deal with common file types (text, >pict, jpeg, gif, tiff, eps, etc.) use the resource fork to store extra info >useful for that app (or any others that recognize the same resource types), >without sacrificing the portability of the file. You shouldn't mention forked files and portability in the same sentence without a negation in there somewhere. >1. You seem to imply that only executables are "wrappable". It's not the case. Datafiles can be wrapped as well. > >2. Even if that is not the case (or it is changed for Rhapsody), I WILL be > using the CLI from time to time. Having all my BBEdit files (etc.) really > be directories containing several files would be, at best, cumbersome to > work with. There's more than one way to skin a cat. The window location and size might be kept in a per-user defaults database. -- Don McGregor | Mistakes were made. mcgredo@crl.com |
From: glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 04:04:18 GMT Organization: Indiana University, Bloomington Message-ID: <5de9k2$q13@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> NNTP-Posting-User: glhansen In article <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net>, Phetsy Calderon <phetsy@earthlink.net> wrote: >In article <5ddvvd$lha@dismay.ucs.indiana.edu>, >glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: > >> In article <connelly-ya023680000602970146410001@news.ziplink.net>, > >> Speaking of which, is there anything like a find/grep combination for Mac? > >Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you >guessed it, lets you GREP Mac files. I believe it's in the Utilities >folder, but if you haven't already, just download the <all-files.text> >file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to >find MacGREP's location. That sounds great. Except I'm not really sure what to do with that path. I tried putting an "ftp:" in front of it, but Netscape says the connection was refused. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: "Randy Thelen" <rthelen@ix.netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 06:54:45 GMT Organization: Netcom Message-ID: <01bc171f$45774280$ceec1fcc@rthelen.ix.netcom.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> M <anti_email_spam@real.address.in.sig> wrote in article <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu>... > In <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > > In <5ddp66$jpc@news.bu.edu> John Siracusa wrote: > Gee, all these years of using it, and I didn't know ResEdit was such a > Fancy Tool. ResEdit is a lousy tool. I'm a Mac Fanatic and a developer of Mac Software. I despise having to use ResEdit. Although it's "fun" to get into a program and tiddle bits, it's not the way I want my customers to experience my software. > > like UI elements, and optional Language localization features (which Gil > > Amelio has already said he wants to take advantage of). To the GUI user, a > > Wrapper looks EXACTLY like a file, except that it's executable. The only > > difference is to the CLI user (which you probably wont be anyway). The fact > > One nice thing about resource forks is that any file can have one, which is > quite useful. Resource forks are a means to an end in some cases and an end in other. First case: The resource fork allows an application to store meta-data about the file with the file. In your example, you cited a text-editor storing window position and document preferences with the file. I think we can all agree that having file preferences on a per-file basis is pretty cool. Further, this data is automatically copied when the file is copied from place to place. That's great! In the second case, Macintosh applications have traditionally stored their M68000 executable code in the resource fork. Which is, if you really think about, a pretty unusual thing. Further, the Macintosh 'fat' applications store their PowerPC data in the data fork of the application. Which, if you remember, broke some applications which actually stored their preference data in the data fork of themselves. So, what we're seeing here are two of the many uses for multiple forks. A robust volume format that allows for multiple forks (HFS and NTFS are two good examples) is a desirable thing to have. However, FileSystems (NFS and UNIX's inode based FileSystem) which are populare in the networked world do not address multiple forks. If Apple had adopted NeXT six years ago and introduced a version of NeXT running on a multiple fork volume format, it may have encouraged UNIX implementations to adopt additional APIs which utilize multiple forks. Unfortunately that didn't happen and the UNIX centric data model of a single fork file has become the de-facto standard. It's not a bummer. It's reality. > Well, I can modify any app on my drive right now without any "special code" > from the application vendor. Most Mac apps have any data that needs to > be localized in standard, easily editable resource types. Umm, I must not have understood what you meant. I do believe ResEdit qualifies as "special code" by virtue of the fact that it is not installed when a system release is installed. Real customers don't have and should never have to have ResEdit. > I just would hate to see the benefits of the current Mac > resource model thrown out completely. Me too. I'd love to just close my eyes and wait and see what pops out in 18 months. But even blinking making me anxious about what's changed in the world around me. > Perhaps in Rhapsody Apple/NeXT will > modify the current NeXT system to give us a bit of the best of both worlds. I love my Mac as much as it sounds you love yours. But, I do not want to approach this with the "let's modify the NeXT system to do [xyz]." I'm hoping the approach taken by all involed is, "here's what customers want, here's what we have to work with, here's what can be modified to create a solution." > They're going to have to do something eventually to accommodate the Sys 7 > "blue box". Yep, they sure are. And I hope they do a good job. > This never happens on the Mac ... Careful, there is no evil that never happens on the Mac. > There are easy ways for a knowledgeable user to get into those files if they > want to, but for novice users it is virtually bulletproof. Bulletproof works. > Mac users tend to prefer binary config files because: Mmm. I think this is putting the cart before the horse. Mac users want easy control over the behavior of their system (where system may mean the O/S, their Tax software, their internet connectivity, etc.). Mac users don't really care how it gets done. In fact, if a Mac users has to know whether its a binary file or a text file, the system designer failed. > Yes, Nextstep . . . with an overhaul. Yes, Macintosh ... with an overhaul. > And there are changes that need to be made to NeXTstep. And there are changes that need to be made to Macintosh. > It's not a sacred cow, is it? Which Mac or Next? Oh! Neither. > > Now, before you go though these rants again, go out and use the > > damn thing. Stop arguing from a stance of total ignorance. > > Now, before you go though these rants again, you need to have a better > understanding of what these Mac users don't want to _lose_ in the next > MacOS. It's amazing how much alike we all sound. Friends? -- Randy Thelen
From: "Randy Thelen" <rthelen@ix.netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 07:06:13 GMT Organization: Netcom Message-ID: <01bc1720$e0f3d600$ceec1fcc@rthelen.ix.netcom.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <5dlvvo$149$1@newz.oit.unc.edu> > A horror story from NT 4.0: NT 4.0 is a horror story! Seriously, I use NT everyday on a dual-processor PowerPC machine. It's got its strengths. -- Randy Thelen
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 02:08:56 GMT Organization: The Jack Voigt Fan Club Message-ID: <5dlvvo$149$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> In article <5de4gb$np2@news.bu.edu>, John Siracusa <macintsh@bu.edu> wrote: \ As a follow up to my own post, let me just add this: \ File name extensions as the OS-wide method of \ file type recognition: JUST SAY NO \ I could post a whole other rant on why the file extension \ concept should be thrown in the same bin as punch cards, \ but I'll leave it at that for now... File name extensions are good in _some_ circumstances. I use SAS. SAS programs are TEXT files. When SAS runs, it produces a log of what it's done (a TEXT file) and a output file containing results (also a TEXT file). It helps a lot to be able to have myprogram.sas, myprogram.log, and myprogram.lst to indicated which is which, given that the fundamental underlying files are all of the same type. A horror story from NT 4.0: SAS registers .sas, .log, and .lst files when it is installed. By default, NT hides the extensions when it's showing files of known types. Thus, in the above example, I'd have three files named "myprogram" showing in the directory window, and I'd have to be able to decipher the icons to figure out which was my program, which was the log file, and which was the list file. When file names and extensions are of fixed, short length (e.g. 8.3) extensions as file-type indicators are a pain in the ass. However, with decently long filenames, I don't really care whether it's "My Latest Masterwork of Literature" or "My Latest Masterwork of Literature.Microsoft Word 5.1", especially if the last bit is hidden in icon views and hideable in list views. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 97 07:30:11 GMT Organization: Lund University Message-ID: <peterm.855559811@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> "Jonathan W. Hendry" <jon@subsequent.com> writes: [stuff deleted] >And, again, creator codes don't work well in a multi-user >environment or network. If one user prefers Painter, and >one user prefers Photoshop, and they both have to work on >a set of files, they're continually going to have creator >problems, because the files will continually have their creator >code set to the other person's app. I don't see this as a big problem. If you work on the same files and you use different programs, you either open the file from within you favourite application or you simply drag the file onto the icon of the application. (*why* do you have to command-drop on the NeXT? I don't get it). I would be seriously dissapointed at Apple if we had to start dealing with extensions, however long they may be, after having had a far superior solution for over ten years. It seems right, however, to demand that the application knows and [apparently] tells the system which files it can handle. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 97 07:43:01 GMT Organization: Lund University Message-ID: <peterm.855560581@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> Stephen Peters <speters@cygnus.com> writes: >maintain a reference to the application which created it. The second, >as implemented on Win95 and NeXT, is to have applications publish the >file types that it knows how to handle, and give the user a way to >choose a default application for that file type. One question: this "give the user a way to choose a default application...", does this mean that the user *have* to choose the default application, or does it mean that powerusers *may if they want* change the default application? I'm also suspicious against hacks of all kinds; the File Manager on Solaris is, unfortunatley, a very good example of a very, very bad hack. In that case, it is an unsolvable situation: the poverty of the filesystem (in terms of file attributes), makes a hack the only usable solution. The Real solution, a serious update of the file system, seems unthinkable to the unix community. Well, well, he who lives shall see. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 97 07:52:24 GMT Organization: Lund University Message-ID: <peterm.855561144@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> jrudd@cygnus.com (John Rudd) writes: >You don't know jack about what Nextstep is, or how easy it is to use. I >don't care if you BUY a Nextstep system or not. USE IT before you go around >saying how "unix will be the end of us!".. because quite frankly I have more I don't want to be harsh, but some three years ago I had a NeXT-machine on my desktop for a few days, just to check it out and see how it was. The first thing that happend when I booted the system was: nothing. A dialog saying "Checking System Resources" came up and then nothing. A manual told me to press ctrl-alt-q (or something) the get a shelltool and see what was happening. It was waiting for a DNS-server. And it waited and it waited. Very intuitive. Very non-unix. Once I had entered another DNS-server it booted very nicely and was ok to use, but not that much a revolution. I recently troet the NeXT-step GUI ontop of my Solaris 2.5 system. Neat, but not that neat, so I switched back to OpenWindows (in itself a disaster as a GUI, but usable). Don't get me wrong, I think this move from Apple/NeXT is a brilliant one, or at least, it has the potential to be brilliant, but please don't say that it's not unix and please don't say that it's easier for the novice to set up and maintain than the Mac OS. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 10:00:05 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5dmrj5$si2@nef.ens.fr> References: <5ddp66$jpc@news.bu.edu> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> <peterm.855561144@ulfrun> In article <peterm.855561144@ulfrun>, Peter Moller <peterm@dna.lth.se> wrote: >jrudd@cygnus.com (John Rudd) writes: [...problem with a NeXT...] >"Checking System Resources" came up and then nothing. A manual told me to >press ctrl-alt-q (or something) the get a shelltool and see what was happening. >It was waiting for a DNS-server. And it waited and it waited. Very intuitive. >Very non-unix. If this happen on a Mac (and it happens often) : the system doesn't boot and you can't do almost anything, even if you are an advanced user, and sometimes you have to reinstall the system. At least, you can almost always try something with a NeXT box (and with all modern OSes (ie not Win95 not MacOS)). > Once I had entered another DNS-server it booted very nicely and >was ok to use, but not that much a revolution. Not that much a revolution compared to OpenWindows ???? :-) > I recently troet the NeXT-step >GUI ontop of my Solaris 2.5 system. Neat, but not that neat, so I switched >back to OpenWindows (in itself a disaster as a GUI, but usable). This is not the NS GUI but the Openstep port from Sun and it seems to be very slow and not very innovative... >Don't get me wrong, I think this move from Apple/NeXT is a brilliant one, or >at least, it has the potential to be brilliant, but please don't say that >it's not unix and please don't say that it's easier for the novice to set up >and maintain than the Mac OS. It's not unix, it's Mach and it's often easier for the novice to set up and maintain (because the organisation of files (expecially those the user sees, ie Apps, "Library") is much better) than the Mac OS --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: leigh@antechinus.cs.uwa.edu.au (Leigh Smith) Newsgroups: comp.sys.next.programmer Subject: Floating point within the kernel? Date: 10 Feb 1997 17:36:17 +0800 Organization: Computer Science, University of Western Australia Message-ID: <w4gn2td80ku.fsf@antechinus> In writing a motion tracking device driver I've come across a bug with floating point operations within the kernel (NS3.3 & OS/M4.1 Intel). I can declare a variable to be a floating point constant and hand it around within the kernel ok, and even pass it back to a user level program via MiG. If I attempt a floating point operation, multiply, divide, add, subtract, cast from an int to a float etc, I get a hung kernel. Looking at the assembly code, the floating point operations produce just the expected i486 op-codes. I'm guessing the cause is from a trap occuring due to floating point operations which isn't handled within the kernel. Can anyone provide any experience or suggestions? My cup of gratitude would overfloweth :-) Leigh -- 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
Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer From: hammond_g@drkclu.meng.ucl.ac.uk (Java G) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Sender: news@ucl.ac.uk (Usenet News System) Message-ID: <1997Feb10.095803.59322@ucl.ac.uk> Date: Mon, 10 Feb 1997 09:58:03 GMT References: <5d8qta$6np@news.bu.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <5ddvvd$lha@dismay.ucs.indiana.edu> <phetsy-0602971800410001@cust71.max3.santa-clara.ca.ms.uu.net> <5de9k2$q13@dismay.ucs.indiana.edu> Organization: UCL Dept Mech Eng In article <5de9k2$q13@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) writes: |>>Yeah, somewhere on Info-Mac is a little utility called MacGREP which, you |>>guessed it, lets you GREP Mac files. I believe it's in the Utilities |>>folder, but if you haven't already, just download the <all-files.text> |>>file. Path is /mirrors/Info-Mac_Help/all-files.text. Search this file to |>>find MacGREP's location. |> |>That sounds great. Except I'm not really sure what to do with that path. |>I tried putting an "ftp:" in front of it, but Netscape says the connection |>was refused. try http://src.doc.ic.ac.uk/packages/info-mac/ -- /** Java G <hammond_g@meng.ucl.ac.uk> * Virtual Reality ROV Docking Planner * http://www.ucl.ac.uk/~zcemm23 * "it's not about money... it's about pasta..." */
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 03:19:02 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FED9F6.3D66@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit M wrote: > > In <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: > > In <5ddp66$jpc@news.bu.edu> John Siracusa wrote: > [snip] > > > 1. Hiding directories isn't the same as "hidden" resource forks. > [snip] > > But NeXT moved on from that becuase it is less flexible than Wrappers. By > > opening the file into multiple files that _can_ be accessed by advanced > > users, you can change sections of the code without any fancy tools. Things > ^^^^^^^^^^^ > Gee, all these years of using it, and I didn't know ResEdit was such a > Fancy Tool. If you turn things 90 degrees and look at them, you could see > that having to fire up a CLI to get into those wrappers is just another case > of having to use a Fancy Tool. :) You don't need a Fancy Tool or a CLI. You select the wrapper, and you select the 'Open As Folder' menu item in the 'File' menu. Or you type 'Command-O' (as opposed to Command-o for the normal open). That's in WorkspaceManager, NeXT's Finder app. -- jon@steeldriving.com
From: Rich Schroedel <richs@win.bright.net> Newsgroups: comp.sys.next.programmer Subject: Macintosh format? Date: Sat, 08 Feb 1997 12:54:42 -0600 Organization: BrightNet Wisconsin Message-ID: <32FCCBEC.93E@win.bright.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Next's document web page now claims to have down-loadable documentation in "Macintosh format". The files they have added all have a ".sit" suffix. When I try to download them using a Macintosh and Netscape, I am told that a helper application/plugin of type "application/octet-stream" is need. Netscape does not list any suggestions. I have no idea what application I need. -- Rich Schroedel "There is only one success... Ondossagon Software to live your life in your own way" richs@win.bright.net Christopher Marlowe
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 05:38:32 -0800 Organization: Esperance Communications Message-ID: <jk-1002970538320001@ip-salem1-04.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> <5dme4o$ave@crl.crl.com> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <5dme4o$ave@crl.crl.com>, mcgredo@crl.com (Donald R. McGregor) wrote: >You shouldn't mention forked files and portability in the same sentence >without a negation in there somewhere. I've never had a problem transferring files from my mac to another platform, the "portability" problem is mostly bullshit, IMHO. Files that absolutely need the resource fork are mac-specific files, and would be useless to another system anyway. A standard[1] scheme called AppleDouble exists to transfer a non mac-specific file while keeping the resource fork, meta-data, etc. to another mac intact, and allowing a non-mac to ignore the mac-specific part. The only problem is that in this multi-platform world, MacOS has no standard routines to return a specially-encoded mac file to its unencoded form (however, most mac file transfer apps have been doing this without Apple's help for years (with the exception of web browsers, irritatingly enough)). [1] RFC 1740, <URL:http://ds.internic.net/rfc/rfc1740.txt>. -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. Boycott Microsoft! Why? See <URL:http://www.vcnet.com/bms/>.
From: herren@flannet.middlebury.edu (David Herren) Newsgroups: comp.sys.next.programmer Subject: Re: Macintosh format? Date: Mon, 10 Feb 1997 08:44:09 -0500 Organization: Language Schools of Middlebury College Sender: herren@flannet.middlebury.edu Message-ID: <msg31081.thr-13e218fc.54c5638@flannet.middlebury.edu> References: <32FCCBEC.93E@win.bright.net> Mime-Version: 1.0 Content-Type: text/enriched; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: <msg31081.thr-13e218fc.54c5638.part0@flannet.middlebury.edu> <bold>richs@win.bright.net,UseNet writes:</bold> >Next's document web page now claims to have down-loadable documentation >in "Macintosh format". The files they have added all have a ".sit" >suffix. When I try to download them using a Macintosh and Netscape, I am >told that a helper application/plugin of type "application/octet-stream" >is need. Netscape does not list any suggestions. I have no idea what >application I need. Stuffit expander with the shareware enhancements can open them. -- ------------------------- David Herren ------------------------ The Language Schools herren@flannet.middlebury.edu Middlebury College http://www.middlebury.edu/~herren/ Middlebury, VT 05753 USA v: 802.443.5746 f: 802.443.2075
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: 10 Feb 97 08:22:17 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb10082217@slave.one.net> References: <32EEA76D.41C67EA6@oar.net> <SHESS.97Jan29095304@howard.one.net> <1997Feb9.105307.1337@prim.demon.co.uk> In-reply-to: dave@prim.demon.co.uk's message of Sun, 9 Feb 1997 10:53:07 GMT In article <1997Feb9.105307.1337@prim.demon.co.uk>, dave@prim.demon.co.uk (Dave Griffiths) writes: In article <SHESS.97Jan29095304@howard.one.net>, shess@one.net (Scott Hess) writes: >I've posted a copy of tcl7.6 modified to compile under NeXTSTEP3.3 >to my home page. Has anyone ported Tk to NeXTStep? I've had it running under Xnext, but no NeXTSTEP, yet. Last time I looked (tk4.1, I think), it looked like it was just too X11-based. Essentially, you'd have to write an emulator translating X11 calls into NeXTSTEP calls, and I really didn't want to get involved with that. Besides, I'd much rather have native "widgets". I don't want to see 12-pixel borders on my buttons, even if the script author wanted them! That might be a more useful port, but it would probably also take somewhat longer than an X11 emulation. 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: first@secondd.com Newsgroups: comp.sys.next.programmer Subject: CD`R Media for Sale Date: 10 Feb 1997 14:14:15 GMT Organization: thecopycatshop Message-ID: <5dnafn$1eh@dfw-ixnews5.ix.netcom.com> We have the following CD-R media for sale. Brand: Pioneer Type: Printable Media (Surface is blank for printing or labels) Type: Gold on Green Size: 74 min (650 mb) Price: 6.99 Minimum Order: 10 Brand: Maxell Type: Gold on Gold Size: 74 min (650 mb) Price: 6.55 Minimum Order: 10 Brand: TDK Type: Gold on Green Size: 74 min (650 mb) Price: 6.55 Minimum Order: 10 Brand: Hewlett Packard Type Gold on Gold Size: 74 min (650 mb) Price: 7.15 Minimum Order: 10 Lifetime Warranty The Copy Cat Shop has all your CD duplication, replication, recorders, software, and media needs. If you have any questions feel free to call. Cordially, The Copy Cat Shop 213-650-1680 213-650-9110 Fax
From: Joseph Panico <jpanico@online.disney.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: Re: Arbitary precision arithmetic? Date: Mon, 10 Feb 1997 09:48:17 -0500 Organization: Disney Online Message-ID: <32FF3531.580@online.disney.com> References: <1997Feb9.120321.1665@prim.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Griffiths wrote: > > Hi, does anyone know of a simple maths library that will let you do > arbitary precision integer arithmetic from C/Obj-C on NeXTStep? I found > something called "pari" but it has a Sun3 assembler file that doesn't > compile. > > Thanks, > > Dave Of course the Foundation's NSDecimalNumber will also allow you to do fixed point, near arbitrary (exponent of +-127) precision arithmetic. If you are so inclined, you can use a C interface into this functionality rather than access it as Obj-C classes. Look in NSDecimal.h. -- Joe Panico Disney Online jpanico@online.disney.com
From: first@secondd.com Newsgroups: comp.sys.next.programmer Date: 10 Feb 1997 14:14:15 GMT Message-ID: <cancel.5dnafn$1eh@dfw-ixnews5.ix.netcom.com> Subject: cmsg cancel <5dnafn$1eh@dfw-ixnews5.ix.netcom.com> Control: cancel <5dnafn$1eh@dfw-ixnews5.ix.netcom.com> Organization: Usenet Canal Historique ECP/EMP aka SPAM or pyramidal scheme (MMF) cancelled by bofh@keltia.freenix.fr It may also be an image too small for newsbot to be activated. See report in news.admin.net-abuse.bulletins. Date: Mon Feb 10 17:26:41 1997 Original subject was: CD`R Media for Sale
From: spamwall~mouser@zercom.net (Martiin-Gilles Lavoie) Newsgroups: comp.sys.next.marketplace,comp.sys.next.programmer,comp.sys.next.software,comp.soft-sys.nextstep Subject: Re: I Need some NeXT Hardware Date: Mon, 10 Feb 1997 13:11:01 -0500 Organization: Internet-Login Distribution: inet Message-ID: <spamwall~mouser-1002971311010001@204.191.6.123> References: <32F416F1.6576@q-net.pair.com> In article <32F416F1.6576@q-net.pair.com>, webmaster@q-net.pair.com wrote: > Please help, I am in desperate need of hardware and software for my NeXT > Station. Bellow is the list of items I need... > > 1 Monoter Cord- Monocrome- I am unsure since I can not even turn on the > computer > 2 Power Cords- One for Printer and One for computer itself > > 1 Printer Cords- To connect the printer to the computer > > 1 CD-Rom Drive- That can be connected to the SCSI port > > 1 Hard Drive (500 or so megs)- That can be connected to the SCSI port > > 1 Latest version of the operating system- Developer and user version for > a Motorola processer > 1 Set of Software- Browser, E-Mail Client, Word Processer, Spread Sheet, > any other useful software. > 1 A later version of their web development suiet for Motorola > > I have a Motorola NeXT Station with a Mega Pixel monoter. I also have a > NeXT printer(laser). I am unsure of the RAM or Hard Disk space since I > am unable to turn the computer on. Also if anyone could direct me to a > few good books on NeXT. > > Thanks > Tom Reminga > E-Mail me at: > mailto: webmaster@q-net.pair.com > > Q-Net Internet Services > http://www.q-net.pair.com Check out Spherical Solutions at www.orb.com. They have cheap NeXT hardware and components. Martin-Gilles L.
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 13:53:55 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FF6EC3.4533@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <32FE72F6.4C96@subsequent.com> <5dm74q$906@News.Dal.Ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Christie wrote: > > Jonathan W. Hendry (jon@subsequent.com) wrote: > : But what if you want to name two files the same? It's not uncommon > : for me to have two files in the same directory with the same name > : but different extensions. For instance, splash.riff and splash.bmp. > Those aren't the same name. Why would one ever want to use > EXACTLY the same name for two files on purpose. I hope no one ever comes > up with a file system that allows that. I'd hate to have to follow some > of the programmers I've seen in a project on such a file system. They are the same name, if you remove the extension. In an extensionless OS, you have 'splash' and 'splash'. There are perfectly valid reasons to name two files the same, an example of which you deleted in your response. > : not allowed, you'll end up with splash_riff and splash_bmp or some > : such, which puts the extension back in anyway. > > But it does not reinstate the necessity for extensions or the > limitations they engender. What limitations would those be? Only 3-character extensions have any limitations. > : How does the Mac handle duplicates? It's been too long since I > : used one. I'm thinking that you can't have two files of different > : types in the same directory with the same name, but I could be > : wrong. Anyone? Anyone? Bueller? > > You could always use exactly the same name but add a blank space > at the end of one of them. That's a *nice* solution. Not. >After that is done how are you going to > easily tell them apart? (OK, the one with the space will be later in list > view and HOPEFULLY they will have different icons in icon view). > This was the worst argument in this thread yet. And from a command line? Or from a telnet session? Or from an Open Panel? How do you tell them apart then? Icon's aren't any help in many situations. -- jon@steeldriving.com
From: Alan Jenks <jalanet@mcs.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 13:29:27 -0600 Organization: None Message-ID: <32FF770C.6601@mcs.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dgnar$rm1$1@majipoor.cygnus.com> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > Most of the perceived problems in reconciling the Mac > and NeXT UI's and filesystems can be solved by adding > some functionality into the WorkspaceManager and Appkit. > Appkit changes will be adopted by all OpenStep applications > and objects automatically. > > Even creator information could be handled this way, but > on an improved, per-user basis, using some sort of > database or hashtable. Each user could have their own > creator code for a given file, rather than the file > specifying one creator code for all users. It sounds like the NextOS already has a mechanism that could be enhanced to support the file type and creator concepts found on the Mac. I don't think the user will care that the implementation that supports this is multiple hidden files rather than a single file with a resource fork, as long as the user experience is the same.
From: "Mitchell Allen" <mitchell.allen@worldnet.att.net> Newsgroups: comp.sys.next.marketplace,comp.sys.next.programmer,comp.sys.next.software,comp.soft-sys.nextstep Subject: Re: I Need some NeXT Hardware Date: 10 Feb 97 19:00:06 -0500 Organization: AT&T WorldNet Services Distribution: inet Message-ID: <AF2520B9-219889@207.147.60.191> References: <spamwall~mouser-1002971311010001@204.191.6.123> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit nntp://netnews.worldnet.att.net/comp.sys.next.programmer, nntp://netnews.worldnet.att.net/comp.sys.next.software, nntp://netnews.worldnet.att.net/comp.soft-sys.nextstep On Mon, Feb 10, 1997 1:11 PM, Martiin-Gilles Lavoie <mailto:spamwall~mouser@zercom.net> wrote: > > Please help, I am in desperate need of hardware and software for my > NeXT > > Station. Bellow is the list of items I need... > > > > 1 Monoter Cord- Monocrome- I am unsure since I can not even turn on > the > > computer > > 2 Power Cords- One for Printer and One for computer itself You can get these in any computer store. > > > > 1 Printer Cords- To connect the printer to the computer > > > > 1 CD-Rom Drive- That can be connected to the SCSI port Any SCSI CD ROM drive will work. > > > > 1 Hard Drive (500 or so megs)- That can be connected to the SCSI port Any SCSI HD will work, regardless of whether it is formatted NeXT, mac or IBM. Try it, you'll see what I'm talking about. > > > > 1 Latest version of the operating system- Developer and user version for > > a Motorola processer > > 1 Set of Software- Browser, E-Mail Client, Word Processer, Spread Sheet, > > any other useful software. > > 1 A later version of their web development suiet for Motorola > > > > I have a Motorola NeXT Station with a Mega Pixel monoter. I also have a > > NeXT printer(laser). I am unsure of the RAM or Hard Disk space since I > > am unable to turn the computer on. Also if anyone could direct me to a > > few good books on NeXT. Steve Jobs and the NeXT Big Thing --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. ---------------------------------------------------------
From: Norbert Heger <bertl@hal.kph.tuwien.ac.at> Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 11 Feb 1997 00:07:42 GMT Organization: Vienna University of Technology, Austria Message-ID: <5dod8e$j3a@news.tuwien.ac.at> References: <5didf0$jre@dismay.ucs.indiana.edu> Originator: bertl@gemini Gregory Loren Hansen <glhansen@copper.ucs.indiana.edu> wrote > > [...] hold down option whilst selecting what to search by. > > You'll see a number of new options there [...] > > Cool! I did not I could do that [...] Hey guys, this is the 'NeXT PROGRAMMER' newsgroup - not a 'HOW TO OPERATE MY APPLE MACINTOSH' newsgroup. Please avoid such unnecessary crosspostings! - 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: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 23:11:49 GMT Organization: The Jack Voigt Fan Club Message-ID: <5do9vl$mp2$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> In article <32FF770C.6601@mcs.com>, Alan Jenks <jalanet@mcs.com> wrote: \ It sounds like the NextOS already has a mechanism that could be enhanced \ to support the file type and creator concepts found on the Mac. I don't \ think the user will care that the implementation that supports this is \ multiple hidden files rather than a single file with a resource fork, as \ long as the user experience is the same. Under one condition--if we're using multiple hidden files, we MUST fix the large-block problem for large hard drives. Since a hard drive has 65536 allocation blocks, and no more, small files on large hard drive are large. Right now, a text file containing a single character consumes 32K of my (2.1 GB) hard drive. Under the current system, the data fork and the resource fork each require a minimum of one allocation block. If we break down the resource fork into a bunch of little hidden files, each of which requires a minimum of one allocation block, we'll be eating up hard drive space at an amazing rate. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: philippe_Provost <phil@cnam.fr> Newsgroups: comp.sys.next.programmer Subject: WOF combined with Lotus DOmino 4.5 ? Date: 10 Feb 1997 20:58:18 GMT Message-ID: <5do25a$hn6@pauli.cnam.fr> Greetings, Forgive me if that request is not sent to the appropriate group but i found no other to send it to. I attended the Lotus conference (LotusSphere97) and found that their Domino Server looks very appealing... native HTML embedded, NNTP server embedded, SMTP/Mime server embedded, Java curently being integrated.. and administration tools for managing these... I am a NeXT fellow from the beginning and I think that WOF is still unmatched however I really think that the combination of the two would be very very interesting. (of course Domino talks with a Notes server, to maintain all Notes services). NOTE that with MQSerie (from IBM), you can extract data from the Mainframe very securely and put those in a Notes server, which also means a Domino server (ie WWW). Does anybody tried to tie them altogether ? any more info available ? please reply to phil@cnam.fr. I will make a summary in a few days. Thank you for your help Philippe
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 15:45:32 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FF88EC.6515@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <5dlvvo$149$1@newz.oit.unc.edu> <01bc1720$e0f3d600$ceec1fcc@rthelen.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Thelen wrote: > > > A horror story from NT 4.0: > NT 4.0 is a horror story! > > Seriously, I use NT everyday on a dual-processor PowerPC machine. It's got > its strengths. Support not being one of them. ;) -- jon@steeldriving.com
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 11:47:13 -0800 Organization: Cygnus Solutions Message-ID: <qdafpcigu6.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> peterm@dna.lth.se (Peter Moller) writes: > Stephen Peters <speters@cygnus.com> writes: > >maintain a reference to the application which created it. The > >second, as implemented on Win95 and NeXT, is to have applications > >publish the file types that it knows how to handle, and give the > >user a way to choose a default application for that file type. > > One question: this "give the user a way to choose a default > application...", does this mean that the user *have* to choose the > default application, or does it mean that powerusers *may if they > want* change the default application? The latter. If an application says that it can deal with a file type, then it should automatically be used. If no applications have registered that they can deal with a given file type, it should attempt to open it in some kind of default application (like a text editor). If more than one application says that it can deal with a file type, some sort of conflict resolution needs to take place. However, I note that changing something like the opener application should never be considered part of the `power user' realm. It should be easily viewable through a `file attributes' box. > I'm also suspicious against hacks of all kinds; the File Manager on > Solaris is, unfortunatley, a very good example of a very, very bad > hack. In that case, it is an unsolvable situation: the poverty of > the filesystem (in terms of file attributes), makes a hack the only > usable solution. I agree that the Solaris filemgr application is a hack. I disagree that it's the only usable solution. NeXT hasn't played with the file system to get its information; instead, it's augmented the higher-level `Workspace' to associate the file types with applications. > The Real solution, a serious update of the file system, seems > unthinkable to the unix community. The reason it seems unthinkable is because it's not necessarily the real solution. You're talking about taking what is, at its core, a high-level mapping (applications to file types), and trying to embed them into a low-level system that has historically dealt only with the organization and management of the raw bits into directories and files. The file system doesn't need to know the file types, but the `workspace' does. I think it's still an open question as to which system needs to be reconfigured to solve this. -- 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: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: Re: TCL for NeXT (HELP) Date: 10 Feb 1997 11:51:07 -0800 Organization: Cygnus Solutions Message-ID: <qd914wigno.fsf@blues.cygnus.com> References: <32EEA76D.41C67EA6@oar.net> <SHESS.97Jan29095304@howard.one.net> <1997Feb9.105307.1337@prim.demon.co.uk> <SHESS.97Feb10082217@slave.one.net> shess@one.net (Scott Hess) writes: > Has anyone ported Tk to NeXTStep? > > I've had it running under Xnext, but no NeXTSTEP, yet. Last time I > looked (tk4.1, I think), it looked like it was just too X11-based. > Essentially, you'd have to write an emulator translating X11 calls > into NeXTSTEP calls, and I really didn't want to get involved with > that. > > Besides, I'd much rather have native "widgets". I don't want to see > 12-pixel borders on my buttons, even if the script author wanted them! > That might be a more useful port, but it would probably also take > somewhat longer than an X11 emulation. The Tk8.0 release seems to be focusing a bit more on providing the ability to use native buttons, menus, scrollbars, and font designations. I've been toying with the idea of trying to do a NeXTSTEP/OpenStep port, but it's still kind of low on my to-do list :-) -- 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
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior From: rpk@world.std.com (Robert P. Krajewski) Subject: Re: Mac/NeXT & Unix: File System Sender: news@world.std.com (Mr Usenet Himself) Message-ID: <rpk-ya02408000R1002972228590001@news.std.com> Date: Tue, 11 Feb 1997 03:28:59 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB8651.243F@worldbank.org> <199702092226324711866@roxboro-189.interpath.net> Mime-Version: 1.0 Organization: The World @ Software Tool & Die So, what's really going to happen to the Mac file/document model ? I don't think it's going away. I would get that the file type/creator feature would survive into the Rhapsody APIs (even the Yellow Box) because it's such a basic feature of the way a Mac works. Otherwise, how is Rhapsody going to support existing MFS/HFS volumes without losing information ? I would expect that older Unix file systems accessible to Rhapsody would carry the extra properties in pretty much the same way that Unix implementations of AppleShare servers do, and that a new file system which is pretty much the same as what NeXTStep uses now would open up a few more slots or user properties for attributes formerly associated with MacOS. The rest can be can taken care of by a MacOS Easy Open on steroids.
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: rpk@world.std.com (Robert P. Krajewski) Subject: Re: Mac/NeXT & Unix: File System Sender: news@world.std.com (Mr Usenet Himself) Message-ID: <rpk-ya02408000R1002972232390001@news.std.com> Date: Tue, 11 Feb 1997 03:32:39 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <32FE72F6.4C96@subsequent.com> <5dm74q$906@News.Dal.Ca> Mime-Version: 1.0 Organization: The World @ Software Tool & Die > Those aren't the same name. Why would one ever want to use >EXACTLY the same name for two files on purpose. That's not what a Mac user thinks at all. The name of a file still has to be unique within a directory. It's just that the type and creator of the file are just PROPERTIES of the file, not things that change its name -- at any level. It's simple, straightforward, and unfortunately unlike what people have been led to expect from file systems on every other OS.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 20:16:28 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fhqei.ji4.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <0myB5iy00iWY461F04@andrew.cmu.edu> On Wed, 5 Feb 1997 13:29:02 -0500, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.programmer: 5-Feb-97 Mac/NeXT & >Unix: You're all.. by John Siracusa@bu.edu <snip> >> Further, you CANNOT hope to get the current millions of Mac >> users to replace their OS with an OS that acts like Unix! > >You're absolutely right. Have you guys realized that Unix's behaviour is entirely dependant upon the SHELL you are using? Look at Windoze: sure it sits on top of MS-DOG but someone unused to MS-DOG need not know any MS-LOSS commands; Most users are unaware (and uninterested) of the CLI sitting under Windoze. Windoze is a user shell, not an OS. Even Windoze-95 sits on top of a "virtual DOS" so it too qualifies as a shell. Windows NT is VMS with the serial numbers filed off. The GUI is nothing more than a user shell. Regular Unix systems w/ X windowing *can*, with the right X clients programs, hide the existence of the regular shells (though you can argue that TCL/TK is a pretty cool shell for a GUI). So the Mac handles things oddly, and, because there is no CLI available it cannot do any task that hasn't been pre- programmed. Unix (and, to a lesser extent, MS-DOG) can use small programs in a "pipeline" to handle extremely complex tasks. The advent of Perl makes this less critical, however. >Fortunately, NEXTSTEP doesn't act like any other Unix I've used. Actually, it's "shell" is unlike any previous Unix. >> And believe me, no matter how much you "hide" the unix, it'll >> never be "like a Mac" to those millions of users. > >You've obviously never used NEXTSTEP, or else you would have seen for >yourself that you really can hide the Unix. Most people who have used >both NEXTSTEP and MacOS think that NEXTSTEP has a Mac-like interface >that's actually better than the Mac's. There's nothing in Unix that keeps it from "putting on a pretty face" (which seems to be just a suite of X clients and a window manager that close the majority of gaps). Of course, Windoze is just a brown paper bag over MS-DOG's CLI. :-) >> On a Mac, icons do not "represent" or "point to" or "indicate" >> your files. They *ARE* your files. That icon *IS* your disk >> drive. That just isn't going to happen in the world of Unix. > >Try using NEXTSTEP-- it already happened years ago. Actually, have you looked at mfm and other items? Unix ain't AmigaDOS; You don't need an Icon file for any file you want to see. It really all depends upon the X client that's being used. Granted, the behavior (pre-CDE) wasn't real consistent and the "look'n'feel" was mostly dependant upon the window manager (be it Motif or OpenLook). >> And why *should* Apple keep *any* vestiges of Unix? Unix ain't a "user interface"; You can layer damn near anything on top of it without crashing the whole system. Imagine the GUI crapping out but the file system is intact, allowing more graceful behavior should an app go toes up. And that's just it- you're not arguing the same issue. Unix is a "kernel" with a sh*tload of tools around it. Much of the Mac paradigm is independant of the actual foundation it is built upon- Look at the Mac Virtual Machine(s) under BeOS; BeOS ain't Unix either, and it ain't MacOS, it has many features of Amiga's OS, but you can still do serious Mac stuff with it. Hell, if you're enough of a masochist, nothing stops anybody from grafting a MAE on top of Windoze-NT, bypassing the original M$ GUI; It's all a matter of properly interrupting the service calls. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 5 Feb 1997 20:30:07 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fhr85.ji4.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <32F89AA4.1DC4@iquest.net> <rang-0502971231490001@margaret.trillium.adaptec.com> <5dakum$ien@csugrad.cs.vt.edu> On 5 Feb 1997 13:53:10 -0500, Nathan M. Urban <nurban@csugrad.cs.vt.edu> wrote: >In article <rang-0502971231490001@margaret.trillium.adaptec.com>, rang@trillium.adaptec.com (Anton R > ang) wrote: > >> In article <32F89AA4.1DC4@iquest.net>, sdmeyers <smee@iquest.net> wrote: >> >> Consider double-clicking a document. How do you know which program to >> launch? HFS provides the type and creator, which together with the >> desktop database define both the default application as well as a list of >> other applications which know how to open the file. Typical UNIX file >> systems don't have this information available to them, though there are >> approaches to make it work most of the time (or all the time, if you can >> enforce a file format with a fixed header). > >That's probably the most difficult problem. The old "forked file" issue, again? I'm not entirely happy w/ the NeXT approach to this but I've little actual experience on NeXT itself. I'm a Unix systems generalist, so I've got some useful (and useless) things to bring in here. This is damn near trivial; Look at the "file" command in Unix. There's a file named /etc/magic that describes most file's internal "signatures"; Given this, it'd be an easy extension to allow all files w/ a particular signature to launch an application. Sure, it wouldn't allow mapping individual files with identical signatures to different applications... But then you go for filename hacking. Current versions of Linux (the ext2 filesystem) allow file names up to 256 characters long. You can (with some judicious use of "delimiting" characters) insert more information about this file into it's file name. Hell, you can even modify the filesystem to allow the Inode to support an application fork for a file (accessible via ioctl() calls?) for such information. This is *not* a biggie, especially when you have full access to the OS source code. *Everything* here is subject to trade-offs. >> But there are harder cases. Consider dropping a document onto the icon >> for a currently running application. This should generally open it within >> the app; but there is no standard way (in a generic UNIX) to communicate >> this > >It works in NEXTSTEP. It'd work damn near anywhere; It's a matter of ensuring that an application can open the file (some are too damn picky). Some of the file managers available under X allow for drag-and-drop access (though the window manager itself seldom supports this; It's a case of implementing a new window manager, really...). >> There's a lot of work to be >> done to make any modern UNIX as user-friendly as the Mac. (I'm not saying >> it's impossible; just hard.) > >Look at NEXTSTEP. I think it's friendlier than the Mac. Look carefully; Unix is an OS kernel, not a GUI. There are different GUIs layered on top of it, though, that use it's functionality (and set of tools) in entertaining ways. The advantage of Unix as a system foundation lies in it's layered nature. This allows a Unix system to take on many different personalities (consider shells; The C-Shell and Korn Shell have different personalities though they make no effort to "hide" the file system or the utitily programs...). -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 10 Feb 1997 19:54:20 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> On Fri, 7 Feb 1997 01:16:42 -0800, Ian Russell Ollmann <iano@scripps.edu> wrote: > > >On Thu, 6 Feb 1997, Paul Connelly wrote: > >> In article <5dbfr3$g10@dismay.ucs.indiana.edu>, >> glhansen@copper.ucs.indiana.edu (Gregory Loren Hansen) wrote: >> >> > Don't confuse the operating system with the shells. <snip!> >Anyway, it is so simple a child could do it. Find out the name of your >local sysadmin. If his loginID is ralph, then take the following steps: > > chmod 755 ~/.cshrc > mv ~/.cshrc ~/.cshrc.bak > cp ~ralph/.cshrc ~/. > >That ought to fix your path and if it doesn't, take it up with ralph. In >fact, you should probably ask ralph if it causes any other confusing >changes, too. Most sysadmins are very capable with questions such as that >one in particular. At least, let's hope so. You forgot that he could be re-setting his path in his .login file rather than the .cshrc file. You're also assuming he's using the C-shell (or t-c-shell) rather than (my preference) the Korn shell (which instead uses .profile and, sometimes, .kshrc files to do such setup). You can find out what his shell is, for instance, by: grep "^ralph:" /etc/passwd | awk '{print $NF}' But this is just a chance to pontificate (for me at least). The issue at hand is that most of the utilities need to be hidden from the user but we'd still need icons for various utilities to make them useful. Considering that most of the utilities are *not* suitable for use as GUI icons, we can simply have a folder with GUI'd front ends for these utilities, allowing them to be called up during drag'n'drop operations and such; The MacOS doesn't really have a way to string such things together. Alternatively, it shouldn't be all that difficult to modify TCL/TK to use the MacOS GUI gimmicks and use *that* to encapsulate the regular utilities within a shell program. A regular MacOS user will never want to launch a shell (CLI) so any utility programs the user wants access to must have the appropriate GUI wrapper; But then, this is true enough today. The "tar" utility packaged for MacOS duplicated the normal Unix tar functionality -at the back end- but needed a front-end to tie it into the GUI (which, I suspect, was the lion's share of the effort). The GUI *is* a form of a shell; It's just that you can't arrange utilities in a pipeline, so you've gotta have big, heavy utility programs. This is where the Mac differs greatly from Unix and requires a MacOS on top of Unix to implement a "command construction set" which yanks in the Unix utilities to perform a function. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: Patrick Schulz <schulz@freia.inf.tu-dresden.de> Newsgroups: comp.sys.sun.misc,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: OpenStep/Sparc [MiscKit] Date: Tue, 11 Feb 1997 11:10:28 +0100 Organization: Institute of Computer Engineering, CS department, University of Technology Dresden, Germany Message-ID: <33004594.288B@freia.inf.tu-dresden.de> References: <32F19278.453B@erols.com> <5d5c30$8uq@mozo.cc.purdue.edu> <32FA5C21.3080@cyrix.com> <32FB1573.6445@freia.inf.tu-dresden.de> <5dfut4$k5a@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, When I posted the last message, I wanted to bring up some serious portability issues about OpenStep, I didn`t like to criticize the MiscKit group. No, I think, the MiscKit and all the other free software projects are great, I wished, I`d have the time to be a volunteer. The problem I see for all OpenStep software projects is the portability problem across the different implementations. So I told you about my experiences with OpenStep Solaris, hoping that programmers and Software companies recognize the problem and start making their products more portable. IMHO it`s much easier to do that at the beginning of a project (what about a portability policy). My sorrow is, that OPENSTEP (NeXT`s thing) will become much more popular in the next time, and because of the problems I mentioned before other implementaions like Sun`s OpenStep or GNUstep will be dumped or discontinued. I`d like to see various OpenStep implementations running the same Apps no matter what platform they run on. NeXT`s OPENSTEP - aka the new MacOS won`t compete against Windows when they start doing their own thing again. My bottom line is: Stay open, don`t create/support proprietary software. OpenStep is the advantage :-) Patrick. -- Patrick Schulz; Alaunstrasse 21a D-01099 Dresden; Germany email: schulz@freia.inf.tu-dresden.de (MIME & NeXTmail welcome) http://www.inf.tu-dresden.de/~ps3/ - vmunix: panic - no coffee detected, user halted.
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 11 Feb 1997 02:01:29 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <33001949.2FD2@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dave Scocca wrote: > > In article <32FF770C.6601@mcs.com>, Alan Jenks <jalanet@mcs.com> wrote: > > \ It sounds like the NextOS already has a mechanism that could be enhanced > \ to support the file type and creator concepts found on the Mac. I don't > \ think the user will care that the implementation that supports this is > \ multiple hidden files rather than a single file with a resource fork, as > \ long as the user experience is the same. > > Under one condition--if we're using multiple hidden files, we MUST fix > the large-block problem for large hard drives. Since a hard drive has > 65536 allocation blocks, and no more, small files on large hard drive > are large. Right now, a text file containing a single character > consumes 32K of my (2.1 GB) hard drive. > > Under the current system, the data fork and the resource fork each > require a minimum of one allocation block. If we break down the > resource fork into a bunch of little hidden files, each of which > requires a minimum of one allocation block, we'll be eating up hard > drive space at an amazing rate. If Apple doesn't use resource forks, they probably won't use the Mac filesystem at all. They'd most likely use the current NeXT/bsd filesystem, which doesn't suffer from the blocksize problem. -- jon@steeldriving.com
From: "Randy Thelen" <rthelen@ix.netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 07:57:30 GMT Organization: Netcom Message-ID: <01bc17f1$350f8ce0$aaec1fcc@rthelen.ix.netcom.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> Dave Scocca <scocca@gibbs.oit.unc.edu> wrote in article > Under one condition--if we're using multiple hidden files, we MUST fix > the large-block problem for large hard drives. Who's large-block problem? The Mac's? > Since a hard drive has > 65536 allocation blocks, and no more, small files on large hard drive > are large. Right now, a text file containing a single character > consumes 32K of my (2.1 GB) hard drive. Yes, on the Macintosh and DOS-FAT16 volume formats. However, on NTSF, FAT32, and UNIX file systems there is not such limitation. All of these volume formats allow the file system to utilize blocks at the granularity of 512 bytes. The above mentioned problem is only for the Macintosh (within the context of this problem). And, it's very unlikely the Macintosh volume format (HFS - Hierarchical File System) will survive as the volume format of choice for the Rhapsody system. I have no doubt that it will be supported for both existing Hard Disks and for floppies, but it will not be the default or the preferred format. -- Randy Thelen Hoping the powers that be do the right thing wrt NeXT & Apple.
From: Norbert Heger <bertl@hal.kph.tuwien.ac.at> Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 00:07:53 GMT Organization: Vienna University of Technology, Austria Message-ID: <5dod8p$j3c@news.tuwien.ac.at> References: <32FB9565.5193@subsequent.com> Originator: bertl@gemini Jonathan Hendry <jon@subsequent.com> wrote: > And, again, creator codes don't work well in a multi-user > environment or network. If one user prefers Painter, and one user > prefers Photoshop, and they both have to work on a set of files, > they're continually going to have creator problems, because the > files will continually have their creator code set to the other > person's app. What about an extension of the file-wrapper concept? The wrapper may contain a file named ".fileCreator" to specify the creator application specific for each user e.g. using the plist-format: { john = WetPaint; bob = IconBuilder; susan = TIFFany2; } Each user may also specify wether he wants to use this information or not, using the defaults database: dwrite Workspace OpenFilesWithCreator YES (Mac like) dwrite Workspace OpenFilesWithCreator NO (NeXT like) > Filename extensions are used, but they are more flexible than > Windows extensions. There's no limit on the length of the extension, > for instance. The wrapper may also contain a file named ".fileType" to specify the type of the file-contents (e.g. "tiff"). This file may even contain A LIST OF TYPES to support multiple filetypes, e.g: "aSpecificPlistType, plist, ASCII" "m, ASCII" "h, rtf, ASCII" And it's no longer necessary to take care of the proper filetype-extension. Since the filetype information isn't part of the filename any longer, it is protected against accidental changes. Currently a folder is expected to be a wrapper if it has the proper filetype-extension and if the corresponding application is located in one of the application-search paths. Otherwise it looks like an ordinary folder which may be a bit confusing. Using the ".fileType" information instead - or in addition - to distinguish between wrappers and folders would avoid such a confusion. - 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: jason@fisher.psych.uh.edu (Jason L. Asbahr) Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.lang.python Subject: Re: TCL for NeXT (HELP) Date: 11 Feb 97 06:52:15 Organization: C.R.A.S.H. The Computers, Robotics, and Artists Society of Houston Message-ID: <JASON.97Feb11065215@fisher.psych.uh.edu> References: <32EEA76D.41C67EA6@oar.net> <SHESS.97Jan29095304@howard.one.net> <1997Feb9.105307.1337@prim.demon.co.uk> <SHESS.97Feb10082217@slave.one.net> <qd914wigno.fsf@blues.cygnus.com> In-reply-to: Stephen Peters's message of 10 Feb 1997 11:51:07 -0800 Greetings! shess@one.net (Scott Hess) writes: > Has anyone ported Tk to NeXTStep? > > I've had it running under Xnext, but no NeXTSTEP, yet. Last time I > looked (tk4.1, I think), it looked like it was just too X11-based. > Essentially, you'd have to write an emulator translating X11 calls > into NeXTSTEP calls, and I really didn't want to get involved with > that. > > Besides, I'd much rather have native "widgets". I don't want to see > 12-pixel borders on my buttons, even if the script author wanted them! > That might be a more useful port, but it would probably also take > somewhat longer than an X11 emulation. The Tk8.0 release seems to be focusing a bit more on providing the ability to use native buttons, menus, scrollbars, and font designations. I've been toying with the idea of trying to do a NeXTSTEP/OpenStep port, but it's still kind of low on my to-do list :-) That sounds very cool -- would allow for Python-based GUI development on the NeXT! Keeping in mind I haven't delved into Tk much beyond Python's tkinter, how difficult would it be to emulate Tk's worldview in native NeXTSTEP? I don't mean at the X11 call level necessarily, but just below the Tk interface, with definiting buttons, packing them, etc... Hmm... Michael B. Johnson did some excellent work with Tcl/NeXTSTEP integration at the Media Lab, I guess I should look at that again. :-) (For the curious, it also involved RenderMan-Tcl bindings, URL: http://wave.www.media.mit.edu/people/wave/ ) More later, Jason Asbahr 808 Sul Ross Suite 7 Reactive Systems Houston, Texas 77006 jason@reactive.com (713) 942-7937 voice
From: tesuji@xs4all.nl (Mark Boon) 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: Tue, 11 Feb 1997 13:54:30 +0200 Organization: Tesuji Software Message-ID: <tesuji-1102971354300001@asd16-10.dial.xs4all.nl> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> In article <MWRon-2701971033010001@aumi1-a12.ccm.tds.net>, MWRon@metrowerks.com (MW Ron) wrote: > > 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. > Does that mean with one purchase I'd get CodeWarrior for say Mac, Windows and Playstation in one package? I'm considering buying a 'Yaroze' when it becomes available in Europe this month and port our Mac-game to Playstation. -- Mark Boon --------- Tesuji Software B.V.
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 23:17:42 GMT Organization: The Jack Voigt Fan Club Message-ID: <5doaam$n5l$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> In article <5dieu7$p0v@news.bu.edu>, John Siracusa <macintsh@bu.edu> wrote: \ John Rudd (jrudd@cygnus.com) wrote: \ It comes down to this: If you believe that config files should be \ changable by directly editing the file, then text files make sense. If \ you believe that config files should only be changed through a \ well-defined UI or GUI, then text files are not the best idea. \ : There are advantages to binary config files, and to text config files. You \ : have touched on none of the real advantages nor disadvantages of either. \ I think I did earlier and have again. I stated that an advantage of \ text config files is that they're easy for the user to edit without \ special tools. Another advantage of text-based config files: troubleshooting and tech support. I work in supporting SAS, and there have been times when the best way for me to find out what's been happening on a user's system is to look at the (text-based) config.sas file. If a user needs to upload and/or email the config file for tech support reasons, it's a lot easier to use a text transfer than to worry about corrupting a binary file. And as the supporting person, it's much easier to read the text file and see what the settings are than to try to run a program which will interpret a binary file. It's also easier to deal with config.sas file options cross-platform with a text-based file than with system-dependent binary files. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 10 Feb 1997 17:14:47 -0800 Organization: Cygnus Solutions Message-ID: <qd3ev4i1o8.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > John Rudd (jrudd@cygnus.com) wrote: > : Ohgod.. do we have to go through this AGAIN!? > > My nntp server only had the very tail-end of the "Mach-o" > discussion... You might want to check DejaNews (www.dejanews.com) if you're really interested. > : To the GUI user, a Wrapper looks EXACTLY like a file, except that it's > : executable. The only difference is to the CLI user (which you probably > : wont be anyway). > > --which I most assuredly *will* be, if there's one to use. It's not > my personal fear that's motivating the discussion, it's the traditional > Mac experience that I'm concerned about. The traditional Mac user will never know the difference; he or she will be simply using the GUI to do what he or she always did. The implementation details will be (and should be) hidden. > : [...] And binary config files are no less error prone to novice > : users. In fact, they may be more so, as the person fires up a > : text editor to edit the binary one the first time, and accidently > : trashes it. API calls can be just as easily implimented to do > : text based config files as binary ones. > > First, a user running a text editor on a binary config file should > have no effect provided they exit the app when they realize all they > see is gibberish. Considering we're talking about users who randomly try to edit files when they're not sure what they are, you may be assuming too much :-) > Second, *programming a robust API for* changing text files is much more > difficult and inefficient than a structured binary format. I disagree. Completely and unequivocally. Granted, you can find some binary formats which are very hard to evaluate in text form, but in the general case this is *not* true. Especially if you're talking about most configuration files, which boil down to little more than simple mappings between keywords and values. > It comes down to this: If you believe that config files should be > changable by directly editing the file, then text files make sense. > If you believe that config files should only be changed through a > well-defined UI or GUI, then text files are not the best idea. How about if you believe that config files should be changed through a well-defined UI or GUI, but should be robust enough that if someone ftp's the file in ASCII mode (potentially changing all instances of CR to CRLF), the program should treat the file as invariant. > I think I did earlier and have again. I stated that an advantage of > text config files is that they're easy for the user to edit without > special tools. Disadvantages are re-stated above. The advantages of > binary config files stem from the belief that config files should not > be edited directly by the user, but through a UI instead. Stating whether that config files should not be edited directly by the user is a completely different question as to whether the files should be in text or binary. One is a UI philosophy issue, the other is an implementation issue. In the discussion thus far, you've been arguing that the implementation details (as exhibited by Unix) are all-important, and all horrendous, and trying to back them up with philosophical issues. Once again, I submit that the implementation details have nothing to do with the UI philosophy, and ask that if you want to argue against one you learn how to separate it from the other. > That's the nature of Unix, and I really *do* like Unix. I'm just > highlighting the areas where the "Unix philosophy conflicts most with > the Mac philosophy. (Note: I said U-n-i-x, not N-e-X-T! :) Considering that Rhapsody will be based more on N-e-X-T rather than U-n-i-x, and that you seem to be arguing that N-e-X-T is a bad basis point because of U-n-i-x, it's probably better to start by looking at N-e-X-T. > : Which is another reason to use Wrappers. Everything the > : application needs is in the wrapper or the system libraries. > > Agreed. They seem like a reasonable solution, provided the practice > is followed consistently (which I assume it is in the NeXT world). > But what about traditional Unix apps? Are the NeXT versions .app > wrappers as well? (I'm talking about things like emacs, not simple > binaries like tar or gzip) Just as a data point, the full NeXTSTEP port of emacs (Emacs.app), embeds all the library information (*.el files, etc.) in a directory structure within the app wrapper. Now, there are a number of more system-level programs (the samba daemon immediately springs to mind) which are more or less straight ports of the Unix versions, and have more of a tendency to scatter files around the hard drive. Personally, I'd rather they were better integrated, and regard those ports as interim systems until someone takes the time to clean them up. But I do appreciate that the interim systems are easily ported. :-) > I still think there has to be some sort of compromise, here. > Although the initial release of Raphsody is bound to be "straight > Nextstep," I believe changes are coming and will be beneficial. Naturally. The question is whether willy-nilly rewrites of the file system or the config file formats are at all beneficial to the system as a whole. I happen to disagree with that presumption. > : Or proud to move on to the next generation of the Mac, invented by > : the same major visionaries of the Mac project.. called "The NeXT > : Computer". > > Yes, that's another option. But why throw away what's good about > 7.x? The question is whether you think, for example, the HFS file system is what's good about 7.x, or whether you think that the functionality it gives the user is what's good. You can have one without needing the other. > For the umpteenth time, I *have* used Next cubes and slabs. I'm not > nearly as familiar with them as I am with the Mac and Unix, however, > which is why 99% of my points dealt with Mac philosophy vs. *Unix* or > *Windows* philosophy (well, if Windows can be said to *have* any > philosophy ;) It's posted to a NeXT group to gauge how much Unix is in > NeXT! There's no reason to get defensive! I'm sorry, John, but your first posts sounded a heck of a lot like you were trying to slam Unix in general, and were assuming that NeXT was the same as all the others. You have never indicated a desire to `gauge how much Unix is in NeXT'. I submit for your consideration the second paragraph you ever posted in the comp.sys.next.programmer newsgroup: Now I know most NeXT users love Unix. I know it's fun to tar -cf - Papers | rsh pooh tar -xf - instead of using Apple file sharing, but the plain fact is: that has never been a part of the Mac OS experience. The fact of the matter is that the above statement indicates an assumption that on the NeXT, sharing files to another machine is a complex CLI routine, and in addition suggests that the reason we NeXT users enjoy the Unix underpinnings is because of the CLI. Neither assumption is correct; not by a long shot. If you knew better, then I'm surprised that you would even mention the above. -- 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: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 10 Feb 1997 16:01:21 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FF8CA1.33C1@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> <01bc171f$45774280$ceec1fcc@rthelen.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Randy Thelen wrote: > First case: The resource fork allows an application to store meta-data about > the file with the file. In your example, you cited a text-editor storing > window position and document preferences with the file. I think we can all > agree that having file preferences on a per-file basis is pretty cool. > Further, this data is automatically copied when the file is copied from > place to place. That's great! This isn't so great in a multi-user environment or network, though. I want files to go where I left them, not where Bob in Accounting left them. Or where my wife left them. NeXT stores this sort of information in a per-user database. Granted, on a machine which only has one used, the issue is pretty moot. > In the second case, Macintosh applications have traditionally stored their > M68000 executable code in the resource fork. Which is, if you really think > about, a pretty unusual thing. Further, the Macintosh 'fat' applications > store their PowerPC data in the data fork of the application. Which, if you > remember, broke some applications which actually stored their preference > data in the data fork of themselves. NeXT's Mach allows a file to have multiple segments. Fat NeXT apps store each architecture's binary in a different segment. Mach knows how to execute the proper segment. Similar idea, different implementation. NeXTSTEP applications used to store app resources in segments. This was stopped for version 3.0, in favor or 'wrappers'. For resources other than the executable, the wrapper approach made more sense. One area where wrappers have an advantage over forks is in a multi-platform environment. Since NeXT applications consist of files and directories, they can 'live' on any OS, so long as there are no filename limits (8.3, etc.). A NeXTSTEP application is runnable regardless of what kind of filesystem it is stored on. It doesn't matter if the application server is a NeXT, a Sun, a Linux box, or an NT box. Conversely, it would be difficult (if not impossible) to run a Macintosh application that is stored on a non-HFS disk. Any 'special' or 'added' functionality NeXT wants is added above the filesystem layer. Which means that features such as fat binary support, application resource, etc. are not dependant upon what filesystem is used. Likewise, NeXT can add new features and functionality without modifying the filesystem. Which means that users can take advantage of the new features without reformatting their disks. And files stored on machines running other operating systems also benefit from those features. > So, what we're seeing here are two of the many uses for multiple forks. A > robust volume format that allows for multiple forks (HFS and NTFS are two > good examples) is a desirable thing to have. However, FileSystems (NFS and > UNIX's inode based FileSystem) which are populare in the networked world do > not address multiple forks. If Apple had adopted NeXT six years ago and > introduced a version of NeXT running on a multiple fork volume format, it > may have encouraged UNIX implementations to adopt additional APIs which > utilize multiple forks. Unfortunately that didn't happen and the UNIX > centric data model of a single fork file has become the de-facto standard. > It's not a bummer. It's reality. The way I look at it is this: TCP/IP is very low level. It doesn't deal with URL's, content types, or other information like that. It's pretty much concerned with sending bytes around, and that's it. This didn't prevent the development of the countless protocols that run on top of it. TCP/IP's architecture didn't prevent the development of HTTP, which provides a foundation for the media-rich content of the web. IMHO, the Unix filesystem is like TCP/IP. The NeXT Workspace is like HTTP, running on top of TCP/IP. The Workspace implements functionality that doesn't exist in the Unix filesystem, much like Netscape implements functionality that doesn't exist in TCP/IP. The Mac filesystem is like a combination of TCP/IP and HTTP. It's an interesting combination, and it adds some useful functionality, but at the cost of compatability with normal 'TCP/IP'. -- jon@steeldriving.com
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 00:50:51 GMT Organization: Cygnus Solutions Message-ID: <5dofpb$sh2$1@majipoor.cygnus.com> References: <32FB9565.5193@subsequent.com> <5dod8p$j3c@news.tuwien.ac.at> Cc: bertl@hal.kph.tuwien.ac.at In <5dod8p$j3c@news.tuwien.ac.at> Norbert Heger wrote: > Jonathan Hendry <jon@subsequent.com> wrote: > > And, again, creator codes don't work well in a multi-user > > environment or network. If one user prefers Painter, and one user > > prefers Photoshop, and they both have to work on a set of files, > > they're continually going to have creator problems, because the > > files will continually have their creator code set to the other > > person's app. > > What about an extension of the file-wrapper concept? > > The wrapper may contain a file named ".fileCreator" to specify the > creator application specific for each user e.g. using the plist-format: > [SNIP] > > The wrapper may also contain a file named ".fileType" to specify > the type of the file-contents (e.g. "tiff"). This file may even > contain A LIST OF TYPES to support multiple filetypes, e.g: > [SNIP] I think the problem with the first one is that then the file grows simply by nature of how many people access the file. I think that would be a BAD thing. I think the _best_ thing would be to add two fields to the Inode which indicate a creator and a type. Have these be an actual string (like "Create" and "gif87" or something). All files would have creators, but for things like executables you wouldn't care about the creator, just the type ("mach-o", "elf", "mac-hfs", etc). What each user would have is a preferences order for which of the two has precedence ("Do I check the creator, and if I can locate that app first, or do I check the type and if I have an app that claims to support it first?" -- "Launch by File Creator" vs "Launch by File Type"). For "launch by file type", the inspector would be exactly like NeXT's now -- you have a list of files that claim to support that file type, and you pick which one you want to launch when you do a "launch by file type". For "launch by file creator", you create a list of "when the file says it was created by app X, I want you to launch it with app Y". Each user keeps these preferences in their own environment/files. Now, it IS debatable whether it needs to be in the inode or a wrapper.. I think the inode is more appropriate, but either is do-able. For backward compatability, the workspace could take files that don't have a creator or type (null strings, which is what happens when you import from older file systems, if they're stored in the inode, or missing ".FileType" and ".FileCreator" files if they're stored in a wrapper) and use their file name extension (hence you still want to have file name extensions for portability, and simple user visual identification). The main problem with using a wrapper is that wrappers are identified by a combination of a) being a directory, and b) file-name extension. Such as "OmniWeb.app", "Mail.app", "OmniImageFilter.service", "DeveloperPatch.pkg", etc.. To make all application data files be wrappers, you'd have to have a list of every possible file extension that you want to treat as a wrapper. If someone creates a new application with a new file name extension, they wont be supported by the GUI until they get it registered with Apple, and Apple propogates that to all of the users. This is not good. One solution: if a directory contains ".Wrapper", it is a wrapper.. and instead of having ".FileType" and ".FileCreator" files, have them simply be line items in the .Wrapper file. Is anyone from the Rhapsody team reading any of this? :-) -- 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: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 09:16:03 -0800 Organization: Cygnus Solutions Message-ID: <qdwwsfgt64.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <rpk-ya02408000R1002972220520001@news.std.com> rpk@world.std.com (Robert P. Krajewski) writes: > The problem with that is it's much less linear in cost than having a > explicit property. (Especially for recipes like "starting from 8 bytes from > the end of the file...") Actually, it is still *linear* in cost, as long as the recipes are of the standard BSD /etc/magic form, which only examines the first 512 bytes, tops, of the file. Of course, linear doesn't buy you much when you're trying to build a view on a directory AFS-mounted from 3000 miles away. -- 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: Bill Keller <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer Subject: Openstep and multithreads Date: Mon, 10 Feb 1997 23:56:00 -0600 Organization: Oklahoma State University, Stillwater OK Message-ID: <330009F0.367@okstate.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----------789538EA300F0" ------------789538EA300F0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii I'm trying to find some source examples of multithreaded code for Openstep. Or, more specifically, of using NSPort to communicate between threads. I've scoured next-ftp.peak.org, and there's just not much there for openstep yet. Any pointers or examples would be very helpful. Thanks! Bill Keller (kellerw@okstate.edu) --------------------------------- ------------789538EA300F0 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <HTML><BODY> <DT>I'm trying to find some source examples of multithreaded code for Openstep. Or, more specifically, of using NSPort to communicate between threads. I've scoured next-ftp.peak.org, and there's just not much there for openstep yet. Any pointers or examples would be very helpful.</DT> <DT> </DT> <DT>Thanks!<BR> <BR> Bill Keller (kellerw@okstate.edu)<BR> ---------------------------------<BR> </DT> </BODY> </HTML> ------------789538EA300F0--
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: rpk@world.std.com (Robert P. Krajewski) Subject: Re: Mac/NeXT & Unix: File System Sender: news@world.std.com (Mr Usenet Himself) Message-ID: <rpk-ya02408000R1002972220520001@news.std.com> Date: Tue, 11 Feb 1997 03:20:52 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> Mime-Version: 1.0 Organization: The World @ Software Tool & Die In article <slrn5fr5kf.93c.droleary@alpha.temporal.org>, olearydr@freenet.msp.mn.us wrote: >Another (more attractive, in my opinion) option is to inspect the contents >of the file to determine the type. This is done all the time with the >file command in Unix. The problem with that is it's much less linear in cost than having a explicit property. (Especially for recipes like "starting from 8 bytes from the end of the file...")
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 11 Feb 1997 18:59:28 GMT Organization: Boston University Message-ID: <5dqfig$pm8@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> <qd3ev4i1o8.fsf@blues.cygnus.com> Stephen Peters (speters@cygnus.com) wrote: : macintsh@bu.edu (John Siracusa) writes: : > It comes down to this: If you believe that config files should be : > changable by directly editing the file, then text files make sense. : > If you believe that config files should only be changed through a : > well-defined UI or GUI, then text files are not the best idea. : How about if you believe that config files should be changed through a : well-defined UI or GUI, but should be robust enough that if someone : ftp's the file in ASCII mode (potentially changing all instances of CR : to CRLF), the program should treat the file as invariant. This is a poor example. Most decent admins have FTP default to binary mode to protect novice users. This is a problem with FTP and not with the file format. By this logic, why shouldn't all apps be text? After all, a user could mangle their executable file if they transfer them in ASCII mode. : Stating whether that config files should not be edited directly by the : user is a completely different question as to whether the files should : be in text or binary. One is a UI philosophy issue, the other is an : implementation issue. It would be nice if UI philosophy and implementation could be so neatly separated. But in my experience, the implementation tends dictate many aspects of the UI. For example, if config files are ASCII, although there may be well-defined interfaces for editing them, those "in the know" will inevitably advise a troubled user to "just use your text editor." Further, there'll be swaps of portions of config files, where a user will say "here's my fonts defaults for WordWanker. Just copy and paste it over the fonts section of your config file." And then, of course, the user tries this and ends up not having some font specified in the file. Just look at the instructions that come with many DOS/Windows games that reccoment adding lines to .INI files by hand simply because it was an "afterthought" to provide a better way to do it. Human nature is such that people will tend to take the easy way out. Et voila, we're back to the problem of users messing with their config files and apps having to eal with garbled settings files. The point is, if settings are made as easily accessible, they're also easily screwed up. No matter how nice the UI is, users will bypass it if they can. I know you're saying to yourself: "Well, that's their own fault. Don't cripple *my* OS to account for dumb users." Yes, I know it sounds pretty totalitarian, but that's kinda the Mac way ;) It's probably an area where most NeXT users will disagree with most "striped-in-the-wool" Mac people. Such is life. : Just as a data point, the full NeXTSTEP port of emacs (Emacs.app), : embeds all the library information (*.el files, etc.) in a directory : structure within the app wrapper. That's good news indeed :) : Now, there are a number of more system-level programs (the samba : daemon immediately springs to mind) which are more or less straight : ports of the Unix versions, and have more of a tendency to scatter : files around the hard drive. Personally, I'd rather they were better : integrated, and regard those ports as interim systems until someone : takes the time to clean them up. But I do appreciate that the interim : systems are easily ported. :-) Which makes me wonder how things like NFS are currently implemented. Although this may be a moot point, since Apple's reportedly re-doing the networking stuff. : > I still think there has to be some sort of compromise, here. : > Although the initial release of Raphsody is bound to be "straight : > Nextstep," I believe changes are coming and will be beneficial. : Naturally. The question is whether willy-nilly rewrites of the file : system or the config file formats are at all beneficial to the system : as a whole. I happen to disagree with that presumption. Actually, the question is whether or not any rewrite would be "willy- nilly." I think there is room for improvement. : The question is whether you think, for example, the HFS file system is : what's good about 7.x, or whether you think that the functionality it : gives the user is what's good. You can have one without needing the : other. As I stated above, I don't think the implementation and the UI can be separated that neatly in real life. Time will tell, I guess... -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
Newsgroups: comp.sys.next.programmer From: joerd@mail.wsu.edu Subject: templates Sender: news@serval.net.wsu.edu (News) Message-ID: <970211105633.198AAFgS.wayne@pareto> Date: Tue, 11 Feb 1997 18:56:33 GMT Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Generated by Eloquent) Organization: Washington State University According to my documentation, the C++ compiler that comes with Nextstep 3.3 does not support templates. Hopefully, I'm misinformed and someone can set me straight. If not, then does the implementation in Nextstep 4.1 support templates? Thanks in advance, Wayne Joerding Professor of Economics Ofc: 509-335-6468 Washington State University FAX: 509-335-4362 PO Box 644741 http://cbeunix.cbe.wsu.edu/~joerd/ Pullman WA 99164 email: joerd@mail.wsu.edu "Stupidity always has the chance of being a capital offense."
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 11 Feb 1997 19:38:20 GMT Organization: Boston University Message-ID: <5dqhrc$pm8@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> Raul Sobon (a.sobon@pharmacology.unimelb.edu.au) wrote: : John Siracusa wrote: : And ohh how wonderfull the Win95/NT solution of registry is... its NOT : TEXT, : but its binary.. and only regedit can edit it.. and IF IT GETS CURRUPTED : as it often : gets.. BOOM YOUR WIN95 is dead!!! and NOTHING but a clean install will : fix it. : How great non text config files work...NOT! I'd say the registry is a hack to make up for an inane filesystem that doesn't allow putting the information contained in the registry in the files themselves, where it would make more sense. -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: tpugh@oce.orst.edu (Tim Pugh) Newsgroups: comp.sys.next.programmer Subject: Re: templates Date: 11 Feb 1997 20:49:28 GMT Organization: Oregon State University Message-ID: <5dqm0o$c1a@news.orst.edu> References: <970211105633.198AAFgS.wayne@pareto> Cc: joerd@mail.wsu.edu In NS4.1 release notes: Notes Specific to Release 4.0 PR2 In this release, the compiler is based on the GNU C compiler version 2.5.8. C++ Templates. The compiler has been updated to support C++ templates or parametrized types. For example, consider the following code: #include <stream.h> #include <String.h> #include <SLList.h> typedef SLList<String> StringList; main(){ StringList listOfnames; listOfnames.append("hello world"); cout <<listOfnames.remove_front() << "\n"; } Then the above code is built and run: %> cc++ template.cc -o test -lg++ %> test hello world %> In <970211105633.198AAFgS.wayne@pareto> joerd@mail.wsu.edu wrote: > According to my documentation, the C++ compiler that comes with Nextstep 3.3 > does not support templates. Hopefully, I'm misinformed and someone can set > me straight. > > If not, then does the implementation in Nextstep 4.1 support templates? > > Thanks in advance, > > Wayne Joerding > Professor of Economics Ofc: 509-335-6468 > Washington State University FAX: 509-335-4362 -------------------------------------------------------------- Tim F. Pugh email: tpugh@oce.orst.edu Oceanic and Atmospheric Sciences voice: 541-737-2270 Oregon State University fax: 541-737-2064 104 Ocean Admin Building Corvallis, Oregon 97331-5503 NeXTmail, MIME, Sun, or Ascii mail ok! --------------------------------------------------------------
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 97 07:28:27 GMT Organization: Lund University Message-ID: <peterm.855646107@ulfrun> References: <5ddp66$jpc@news.bu.edu> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> <peterm.855561144@ulfrun> <5dmrj5$si2@nef.ens.fr> jalon@drakkar.ens.fr (Julien Jalon) writes: >If this happen on a Mac (and it happens often) : the system doesn't >boot and you can't do almost anything, even if you are an advanced user, and >sometimes you have to reinstall the system. You do? When does this happends? I consider myself a poweruser and I haven't encountered that once. Of course I reinstall my system every now and then, but that has other reasons (new system, should-have-known-better goofs etc.) >>at least, it has the potential to be brilliant, but please don't say that >>it's not unix and please don't say that it's easier for the novice to set up >>and maintain than the Mac OS. >It's not unix, it's Mach and it's often easier for the novice to set up It's not? What's the difference? When I looked at that NeXT-box (wearing a bib) using a standard shell tool, it looked almost exactly like my SunOS 4.1 system. It's not the same kernel, I know that, and it has this great Object Thing, but what else is the big difference? -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 11 Feb 1997 15:36:45 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <3300D85D.2DC9@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > I'd say the registry is a hack to make up for an inane filesystem > that doesn't allow putting the information contained in the > registry in the files themselves, where it would make more sense. It doesn't make sense when files and applications can be used by multiple users. -- jon@steeldriving.com
From: icardena@sumter.cso.uiuc.edu (Ian Patrick Cardenas) Newsgroups: comp.sys.next.programmer Subject: Re: templates Date: 11 Feb 1997 22:04:08 GMT Organization: University of Illinois at Urbana Message-ID: <5dqqco$qb6@vixen.cso.uiuc.edu> References: <970211105633.198AAFgS.wayne@pareto> joerd@mail.wsu.edu writes: > >If not, then does the implementation in Nextstep 4.1 support templates? > According to the release notes, support for C++ templates was added in 4.0. My favorite URL in NeXTanswers is: http://www.next.com/NeXTanswers/HTMLFiles/2455.htmld/2455.html "Release Notes and Installation Guides for all Products" -- Ian P. Cardenas (icardena@uiuc.edu) CCSO Sites Technical Support "I am of the opinion that pizza and beer together are far superior to either in isolation." -James E. Quick on the Apple/NeXT merger
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 13:02:55 -0800 Organization: Cygnus Solutions Message-ID: <qdraingio0.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > I'd say the registry is a hack to make up for an inane filesystem > that doesn't allow putting the information contained in the > registry in the files themselves, where it would make more sense. And in what file's resource fork would you put, say, hardware configuration information? The registry is little more than a nice little database encompassing all the configuration information for applications, hardware, user profiles, OLE, etc, so that it can be shared among all applications or all users, without the individual items hunting all over the planet. That has nothing to do with the way that it's implemented; it could just as easily be a memory-only system which pulls the information from config files and the individual resource forks in all the applications. Oops. That comes dangerously close to my argument about there being a separation between implementation and UI. You may want to ignore that heresy. :-) -- 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
Newsgroups: comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin Subject: Re: TCL for NeXT (HELP) Message-ID: <1997Feb11.142706.47358@yogi.urz.unibas.ch> From: frank@ifi.unibas.ch Date: 11 Feb 97 14:27:06 MET References: <32EEA76D.41C67EA6@oar.net> <SHESS.97Jan29095304@howard.one.net> <1997Feb9.105307.1337@prim.demon.co.uk> dave@prim.demon.co.uk (Dave Griffiths) wrote: > In article <SHESS.97Jan29095304@howard.one.net> shess@one.net (Scott Hess) writes: > > > >I've posted a copy of tcl7.6 modified to compile under NeXTSTEP3.3 to > >my home page. > > Has anyone ported Tk to NeXTStep? > > Dave > If I properly recall, yes. Some company (of which I of course don't have the name anymore) once did something like TK (ObjectTK?) and sold it commercially. Robert -- Institut fuer Informatik tel +41 (0)61 321 99 67 Universitaet Basel fax. +41 (0)61 321 99 15 Robert Frank Mittlere Strasse 142 rfc822: frank@ifi.unibas.ch (NeXT,MIME mail ok) CH-4056 Basel X400: S=frank;OU=ifi;O=unibas;P=switch;A=arcom;C=ch Switzerland
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: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: Tue, 11 Feb 1997 17:33:17 -0500 Organization: Metrowerks Message-ID: <MWRon-1102971733180001@208.137.76.136> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <tesuji-1102971354300001@asd16-10.dial.xs4all.nl> In article <tesuji-1102971354300001@asd16-10.dial.xs4all.nl>, tesuji@xs4all.nl (Mark Boon) wrote: >In article <MWRon-2701971033010001@aumi1-a12.ccm.tds.net>, >MWRon@metrowerks.com (MW Ron) wrote: > >> >> 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. >> > >Does that mean with one purchase I'd get CodeWarrior for say Mac, Windows >and Playstation in one package? I'm considering buying a 'Yaroze' when it >becomes available in Europe this month and port our Mac-game to >Playstation. I'm afraid not, The available targets referred to in the CodeWarrior Latitude are the Sun Microsystems' Solaris 2.3+, Silicon Graphics(R)' IRIX(TM) 5.2+ and Hewlett-Packard(R)'s HP-UX(R) 9.03+. Metrowerks CodeWarrior Gold will continue to support MacOS and Windows and Rhapsody. CodeWarrior for Playstation will be a standalone product but the plugins will probably work other IDE's. Ron -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
From: Eric Smalling <Eric_Smalling@amrcorp.com> Newsgroups: comp.sys.next.programmer Subject: Brief Editor Key Bindings? Date: Tue, 11 Feb 1997 16:09:34 -0600 Organization: SABRE Decision Technologies Message-ID: <3300EE1D.67C2@amrcorp.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----------EFE51C17560" ------------EFE51C17560 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Has anyone out there wrote a "StandardKeyBindings.dict" to remap OpenStep 4.1's code editor to match that of the Borland "Brief" editor? If so, please E-Mail me and let me know where I can get a hold of such a file! :OP Thanks, ____________________________________________________________________ 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 ____________________________________________________________________ ------------EFE51C17560 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii <HTML><BODY> <DT>Has anyone out there wrote a "StandardKeyBindings.dict" to remap OpenStep 4.1's code editor to match that of the Borland "Brief" editor? If so, please E-Mail me and let me know where I can get a hold of such a file! :OP</DT> <DT> </DT> <DT>Thanks,<BR> <TT> ____________________________________________________________________ <BR> Eric A. Smalling <BR> SABRE Decision Technologies - Ft Worth, Texas USA --=== <BR> ------=== The <BR> Any views expressed are mine alone and are in no ----------- SABRE<BR> way the views of AMR or any of it's subsidiaries. ------=== Group<BR> --===<BR> email:Eric_Smalling@amrcorp.com<BR> Corp Web Site: http://www.amrcorp.com/sabr_grp/sdt/sdt.htm<BR> ____________________________________________________________________<BR> </TT></DT> </BODY> </HTML> ------------EFE51C17560--
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) 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: 11 Feb 1997 18:26:46 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5dqv7m$34q@csugrad.cs.vt.edu> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <tesuji-1102971354300001@asd16-10.dial.xs4all.nl> <MWRon-1102971733180001@208.137.76.136> In article <MWRon-1102971733180001@208.137.76.136>, MWRon@metrowerks.com (MW Ron) wrote: > The available targets referred to in the CodeWarrior > Latitude are the Sun Microsystems' Solaris 2.3+, Silicon Graphics(R)' > IRIX(TM) 5.2+ and Hewlett-Packard(R)'s HP-UX(R) 9.03+. > Metrowerks CodeWarrior Gold will continue to support MacOS and Windows and > Rhapsody. Here's something I've been wondering.. will CodeWarrior on Rhapsody be able to build for OPENSTEP for Mach (any architecture, such as Intel, NeXT, etc.), or for OPENSTEP/Enterprise (i.e., OpenStep on Windows NT). Or will the only OpenStep platform it can build for be Rhapsody/PPC? (I think this Newsgroups line needs to be trimmed, but I'm not sure which groups the posters on this thread are reading...) -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: Openstep and multithreads Date: 11 Feb 1997 23:52:17 GMT Organization: Rockwell Avionics - Collins Message-ID: <5dr0nh$ugo@castor.cca.rockwell.com> References: <330009F0.367@okstate.edu> Cc: kellerw@okstate.edu There is a nice small example of multi-threads, locks, and communication in the PDO examples that come with OpenStep.
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 12 Feb 1997 12:33:15 +1100 Organization: Unisys Message-ID: <33011DDB.4B1A@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There has been an interesting discussion going on in comp.lang.eiffel which is relevant to why Apple should do much better in its efforts than just Unix. The basic problem with Unix and many other OSs is they do not notify the user of resource problems, such as disk full, file not found, memory short, etc, they just kill the program straight away. This leads to many applications having superfluous code to handle these exception conditions. This is very common code which really should be in the OS. Here is a snippet from the comp.lang.eiffel "Exceptions and Robustness" thread, as a request to Apple to not just blindly adopt Unix: --------------------------------------- Kent Tong wrote: > > Ian Joyner <i.joyner@acm.org> wrote: > > >My arguments here are the same as for files. Unfortunately, most OSs > > Actually what do you mean by this? The OS should handle a file not > found error? As shown in my previous example, this could be > inappropriate. It could be inappropriate, but mostly, it is entirely appropriate. A file is a resource that an application needs. Files are managed by the operating system, and in many environments, the fact that a file is not present does not represent a bug in the program, it represents an operations error. Thus the situation should be resolved between the operating system and the operator (which on a PC will be the end user themselves). The fact that Unix does not provide these facilities in a shared environment is even more unforgivable, and is a serious weakness of Unix. Let's consider the scenario. 1) A file is not found. 2) The OS tries alternatives to find the file, maybe on an archive. 3) If still not found, the OS notifies the operator/user of the problem (eg, via a dialog box). 4) The user responds is various ways: a) makes file available from some other source the OS can't find automatically, once the file is loaded, the program continues quite unknowingly that there was any problem; b) responds that the file is optional and should be skipped (program could contain logic to handle this situation); c) terminates the program (which could raise an exception to be handled in a number of different ways). If you are really running in an environment where the application logic depends on the availability of a file, then you should write some code before you access the file: if f.available then <access f> end (Notice I use available, not exists. Exists means a file might be present, but locked by another process, ie., it exists but is not available). Pushing these concerns into the operating system is an essential step towards providing more robust environments for programs to run. This makes no difference whether we are talking about mainframe or PC environments, it is just good OS (file manager) design. (I think we should all run down to our Unisys A Series shop to learn how a real operating system works, they have been doing this for decades, and application development and system operations is far simpler). ------------------------------------------------------------------------ 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: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 15:40:04 -0800 Organization: Cygnus Solutions Message-ID: <qdiv3yhpyj.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> <qd3ev4i1o8.fsf@blues.cygnus.com> <5dqfig$pm8@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > Stephen Peters (speters@cygnus.com) wrote: > : How about if you believe that config files should be changed through a > : well-defined UI or GUI, but should be robust enough that if someone > : ftp's the file in ASCII mode (potentially changing all instances of CR > : to CRLF), the program should treat the file as invariant. > > This is a poor example. Fair enough, I'll grant that. Although, one note on your comment: > By this logic, why shouldn't all apps be text? You're talking to someone who's been doing a *lot* of programming in interpreted languages lately, so this may not be the best example :-) > It would be nice if UI philosophy and implementation could be so > neatly separated. But in my experience, the implementation tends > dictate many aspects of the UI. Although this may be true in your experience, it's a bad thing. If the implementation is dictating the interface, you've done your design segment wrong. IMHO, of course. > For example, if config files are ASCII, although there may be > well-defined interfaces for editing them, those "in the know" will > inevitably advise a troubled user to "just use your text editor." > Further, there'll be swaps of portions of config files, where a user > will say "here's my fonts defaults for WordWanker. Just copy and > paste it over the fonts section of your config file." And then, of > course, the user tries this and ends up not having some font > specified in the file. Even if it's binary format, some user who thinks he knows more than he does may try to pull up the file and edit the strings inside of it. Bottom line: If your application can't gracefully handle arbitrary changes like the above to its config files, then it shouldn't be putting the config files somewhere where a naive user can get to them easily. If that means making them hidden files in an app wrapper, then that's what you do. If that means you put big warning messages in the file saying don't edit this except through `Preferences', then that's what you do. However, none of this has anything to do with what format the config file is in. In NT 3.x, a naive NT user could screw up his system royally simply by playing around in the registry. That's because of a problem with letting the user play with things that he probably shouldn't. In NT 4.0, they locked it down so that the user could change fewer things (so that the user can simply screw up his own account). Again, UI philosophy. Not implementation. > The point is, if settings are made as easily accessible, they're > also easily screwed up. No matter how nice the UI is, users will > bypass it if they can. Which is another UI philosophy issue. Should the users be prevented from bypassing the UI, or should they be allowed to bypass it with the realization that they're walking in unknown territory? > I know you're saying to yourself: "Well, that's their own fault. > Don't cripple *my* OS to account for dumb users." Yes, I know it > sounds pretty totalitarian, but that's kinda the Mac way ;) Which? Totalitarianism or crippling the OS? :-) > It's probably an area where most NeXT users will disagree with most > "striped-in-the-wool" Mac people. Such is life. Look, I'm not arguing that we must have Unix, and that it must be completely visible to the users. If anything, I'm arguing the opposite. Instead, I'm arguing that the line of reasoning (and this seems to be what you're trying to suggest) `users shouldn't edit config files, therefore they shouldn't be in text; a lot of Unix apps use text configs, therefore the Unix way of doing things is bad' has a number of fallacies in it. Not the least of which is the notion that config files need to be in binary in order to prevent users from playing with them. > : Naturally. The question is whether willy-nilly rewrites of the file > : system or the config file formats are at all beneficial to the system > : as a whole. I happen to disagree with that presumption. > > Actually, the question is whether or not any rewrite would be "willy- > nilly." I think there is room for improvement. No, the question is whether the cure is better than the disease. Of course there's room for improvement. But you find the improvements by looking at the problem you want to solve (which in this case is fundamentally an interface problem), and deciding where to improve it. > : The question is whether you think, for example, the HFS file system is > : what's good about 7.x, or whether you think that the functionality it > : gives the user is what's good. You can have one without needing the > : other. > > As I stated above, I don't think the implementation and the UI can > be separated that neatly in real life. John, I'd like you to close your eyes and imagine something. Suppose that someone created a Unix daemon which handled the AppleShare protocol and implemented an HFS-style system on top of NFS. Creating an `HFS file' actually made two separate files on the disk, one which was file.data and one which was, perhaps, file.rsrc. Trying to access the resource fork of the `HFS file' would pull data from the .rsrc, and vice versa. You could then mount this Unix disk on your Mac just as if it was an AppleShare'd Mac file system. Also imagine (as long as we're dreaming here) that they'd worked out most of the bugs. Honestly now, would you care that it's a Unix box that just looked like a Mac? Would you notice? Now imagine that the resource forks were instead held in a system-specific database that the system maintained and referenced, but the UI remained the same. Do you care? Will you notice? Right there, that's the difference between implementation and interface. Of course they can be separated, and in real life, too. The user doesn't care about resource forks, or file systems, or inodes; only nerds like you and I do. The user only cares about folders, documents, and double-clicking. (As a side note, I notice that there actually is something called AUFS, which works like the above, although it stores the resource fork in a hidden directory on the Unix file system. I'm unclear as to how well it works.) -- 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: jamaro@ix.netcom.com (Josue E. Amaro) Newsgroups: comp.sys.next.programmer Subject: [TEST IGNORE] Test Date: Tue, 11 Feb 1997 19:52:25 -0800 Organization: Netcom Message-ID: <jamaro-1102971952250001@hay-ca4-14.ix.netcom.com> Testing my account
From: jamaro@ix.netcom.com (Josue E. Amaro) Newsgroups: comp.sys.next.programmer Subject: [ANN] Developer proposition Date: Tue, 11 Feb 1997 20:49:45 -0800 Organization: Netcom Message-ID: <jamaro-1102972049460001@hay-ca1-13.ix.netcom.com> The Rebellion Software An Internet Based Virtual Corporation ------------------------------------------------------------------------ Vision The coming of age of the Internet has created a vast, powerful and easy to use information network that allows rapid and effective communication between geographically disperse people. It is through this medium that The Rebellion Software is possible. Bringing together all available software developers, to support a wide variety of platforms, with one common goal: Create applications that make this computer useful. ------------------------------------------------------------------------ Mission Statement To bring the software functionality available to Microsoft platforms ( DOS WINDOWS WINDOWS NT)Ș to our supported platforms through the combined efforts of independent software developers. ------------------------------------------------------------------------ The Need Millions of computer users have computers that do not run one of Microsoft's operating systems. These users sometimes are forced to give up their computers for a Windows or DOS system because the software they need is not available in other operating systems. The Products Which products do we seek to create? The Rebellion will use a radical new concept on the selection of products to create, We will ask the users! We will ask users to let us know what are their most pressing needs and form groups of programmers to provide a well engineered, robust solution. The Platforms We expect to support the following platforms. 1.Java 2.Linux\MkLinux 3.Macintosh (System 6 and System 7.x) 4.NextStep\OpenStep\Rhapsody(MacOS 8) 5.OS/2 6.Amiga 7.BeOS 8.Netware\Intranetware; 9.Any platform we can recruit developers for. Come One, Come All! Except those MS users,they have everything they need, or so I heard. Interested? GO TO <http://www2.netcom.com/~jamaro/rebellion/>
From: "Eric Stadtherr" <ericstad@netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 97 21:29:04 -0700 Organization: Dimensional Communications Message-ID: <AF26952B-12BAC3@208.206.178.20> References: <qdafpcigu6.fsf@blues.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit nntp://news.dimensional.com/comp.sys.mac.programmer.codewarrior, nntp://news.dimensional.com/comp.sys.mac.system >> The Real solution, a serious update of the file system, seems >> unthinkable to the unix community. > >The reason it seems unthinkable is because it's not necessarily the >real solution. You're talking about taking what is, at its core, a >high-level mapping (applications to file types), and trying to embed >them into a low-level system that has historically dealt only with the >organization and management of the raw bits into directories and >files. The file system doesn't need to know the file types, but the >`workspace' does. I think it's still an open question as to which >system needs to be reconfigured to solve this. > > The file system, by nature, should provide a means for the operating system to store and retrieve files, and information about those files. The Unix file system is based on the (perhaps outdated) notion that a file is a collection of bytes. The nature of the collection of bytes, and the uses to which it is put, are determined at a higher level by the application programs that access the file system through the operating system. While this blanket treatment of files has advantages in terms of portability and cross-platform interoperability, it is limited in its usefulness in a modern operating system. In a truly "modern" operating system, should the file system not be "modern" as well? The knowledge that a filesystem will contain heterogeneous types of files is instrumental in the design of a "modern" filesystem. I believe Apple, when it created HFS, pulled the concept of a filesystem from the '60s at least into the '80s. An HFS file, in addition to having a name, location, size, and extent(s), also has a type, creator, and other flags useful to the operating system that controls the file system. This concept not only makes the filesystem better suited for storage of modern files, but also allows the operating system to take advantage of the additional file information. Constructs such as the Desktop database, MacOS Easy Open, Drag-and-Drop application launching, etc., would not be nearly as elegant or intuitive if not for the support of the filesystem. HFS is not perfect. The allocation-block limitation should certainly be addressed. However, the designers of the Rhapsody filesystem would be making a mistake if they blind themselves to the intuitive knowledge that a file has more than a name and size. Therefore, I wholeheartedly disagree with your statement about the role of a filesystem. -Eric Stadtherr SingleTrac Software
From: MWRon@metrowerks.com (MW Ron) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: Wed, 12 Feb 1997 00:29:45 -0500 Organization: Metrowerks Message-ID: <MWRon-1202970029450001@aumi3-a06.ccm.tds.net> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <tesuji-1102971354300001@asd16-10.dial.xs4all.nl> <MWRon-1102971733180001@208.137.76.136> <5dqv7m$34q@csugrad.cs.vt.edu> In article <5dqv7m$34q@csugrad.cs.vt.edu>, nurban@vt.edu wrote: >Here's something I've been wondering.. will CodeWarrior on Rhapsody be >able to build for OPENSTEP for Mach (any architecture, such as Intel, >NeXT, etc.), or for OPENSTEP/Enterprise (i.e., OpenStep on Windows NT). >Or will the only OpenStep platform it can build for be Rhapsody/PPC? I don't know at this time. >(I think this Newsgroups line needs to be trimmed, but I'm not sure >which groups the posters on this thread are reading...) I trimmed it a lot :) Ron -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
Newsgroups: comp.dcom.fax,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.ms-windows.programmer.misc,comp.os.os2.programmer.misc,comp.sys.mac.programmer.misc,comp.sys.next.programmer From: linus@idirect.com (Goncalo Rodrigues) Subject: Want partner(s) in multi-platform FAX related programming project Organization: Wintermute Softworks Message-ID: <slrn5g2i68.dhm.linus@oracle.planet.com> Date: 12 Feb 97 04:35:29 UTC As the subject indicates, I'm looking for a few partners (possibly a representative from each target platform) in a fax-related programming project. Whether a specific platform is supported rests mainly on the difficulty in doing so, and whether there is a candidate experienced on that platform. Though there will ideally be someone "in charge" of each platform, everyone is able to contribute to any part of the project. Potential targets would be Linux (*nix), Win32, Mac and OS/2, etc, unless this proves too ambitious. I, personally, will be concentrating on Linux (and portable code, of course). Qualified candidates must merely think of themselves as capable C programmers ... no professional experience at all is required (but we could use some hardcore graphics manipulators, compression gurus, security officianados and a guy who can construct a good Makefile ;) Now a bit about the project itself ... A document transmission/reception system, also capable of routing faxes over the Internet, including support for SSL (using SSLeay, ftp://ftp.psy.uq.oz.au:/pub/Crypto/SSL) for secure net transmissions (be prepared to become a munitions exporter :). Support for all conventional fax standards, as well as ITU-T30E (colour fax, if the specs are easily obtainable). Integrated into each platform with an (optional) GUI front-end. Windows (Mac?) users probably have an abundance of this type of software (well, not quite _this_ type), but the other platforms seem lacking (IMO). The ideal situation would be an NFS served source tree (w/CVS?) on someone's box with a static IP that we can mount anytime. And we should set up some means of group communication maybe? The application will be made freely available. This isn't intended to be for profit, but who am I to dismiss fame and fortune. ;) Candidates should [R]eply by e-mail ... flames can be [f]ollowed up. :) -- Goncalo Rodrigues (please note the Reply-To field in case you have a broken news reader)
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: 12 Feb 1997 00:45:23 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5drldj$d5k@csugrad.cs.vt.edu> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <MWRon-1102971733180001@208.137.76.136> <5dqv7m$34q@csugrad.cs.vt.edu> <MWRon-1202970029450001@aumi3-a06.ccm.tds.net> In article <MWRon-1202970029450001@aumi3-a06.ccm.tds.net>, MWRon@metrowerks.com (MW Ron) wrote: > In article <5dqv7m$34q@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > >Here's something I've been wondering.. will CodeWarrior on Rhapsody be > >able to build for OPENSTEP for Mach (any architecture, such as Intel, > >NeXT, etc.), or for OPENSTEP/Enterprise (i.e., OpenStep on Windows NT). > >Or will the only OpenStep platform it can build for be Rhapsody/PPC? > I don't know at this time. Okay.. here's another question, then. For the developer release of Rhapsody slated for this summer, is it known yet whether the tools released at that time will include CodeWarrior, or an interim release of NeXT's ProjectBuilder until CodeWarrior is fully ported to OpenStep? (Incidentally, I hope tools eventually are produced that will migrate projects between CodeWarrior on Rhapsody and PB on OPENSTEP..) Also, has Metrowerks decided to provide something like InterfaceBuilder, or will that be provided by Apple? If it's still too early to tell, I understand.. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 97 08:07:20 GMT Organization: Lund University Message-ID: <peterm.855734840@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> Stephen Peters <speters@cygnus.com> writes: >However, I note that changing something like the opener application >should never be considered part of the `power user' realm. It should >be easily viewable through a `file attributes' box. Yes, it should be easily viewable and easily editable, but the user should by no means *have* to deal with it unless he/she want's to. >The reason it seems unthinkable is because it's not necessarily the >real solution. You're talking about taking what is, at its core, a >high-level mapping (applications to file types), and trying to embed >them into a low-level system that has historically dealt only with the >organization and management of the raw bits into directories and Well, maybee you are right, but let us at least agree that an update of the file system in which a time stamp for *when the file was created* (to complement the three time stamps that exist in the Unix file system describing when the file was last accesses, modified and referenced - if memory serves me) is added would be needed?! And while we are at it it would be very nice to have a file attribute saying if the file is in use (busy) or not, right? The UFS has it's strengths, especially when coupled with NFS over TCP/IP, but that does not mean it cannot be im- proved. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
Newsgroups: comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: Loads of bugs in Developer 4.0/Mach Message-ID: <E5HL9F.Dx@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <5cqh6k$bt5$1@news1.xs4all.nl> <5crrde$19s@dfw-ixnews8.ix.netcom.com> <32F38AB7.27ED@online.disney.com> <5dac36$bps@knuth.visgen.com> Date: Wed, 12 Feb 1997 11:00:51 GMT robert@visgen.com (Robert Osborne) wrote: > Joseph Panico <jpanico@online.disney.com> wrote: > >4.1 Mach PB has many, many problems. > > Tell me about it! Has anybody heard back from NeXT? I've submitted > half a dozen or more bugs so far ... > > >- It's very easy to crash. Go to classes in the project file browser, > >double click on a .m, then double click on a .h-- splat! > > Interesting. What happens to me is that suddenly there is no key window. > Almost like it wants to open a new window but can't ... > > My favourite bug is that if I go to a block of code and type: > > /* > > and hit return PB crashes! Not always - seems to be dependant upon > the code above that line (I think the autoformater is bailing ...) > While annoying at least the "/*" is documented in the release notes of PB 4.0. Don't know about 4.1, but at least in 4.0 you have to be careful with copying "demo" code from any RTF source (like the documentation) into your ASCII sources. This can heavily damage them if you are not careful. Turning off autoindexing and not copying RTF into sources did reduced the number of crashes on 4.0 significatly. Aloha Tomi
Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: ColorSync and DPS (was: OpenStep: Some questions) Message-ID: <E5Hn43.Ez@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <maury-0602971754210001@199.166.204.230> <5ddv6g$81v@news.xmission.com> <maury-0702971131230001@199.166.204.230> Date: Wed, 12 Feb 1997 11:40:50 GMT maury@softarc.com (Maury Markowitz) wrote: > > I would say you're right. The addition of Pantone a while back, > > for the user, was a "minor" change and didn't impact the interface > > much at all--other than making every app on the machine understand > > Pantone, that is--and there's no reason any other color model or > > system couldn't be added just as easily. :-) > > Yeah, that's what I was thinking. The issue appears to be limited > entirely to making DPS understand colour correction, because ColorSync > actually modified the colour tables of the monitors for correct display, > as well as providing a natural "selector". OPENSTEP usually works with device independant color. The NSColorPanel returns this type of values. As somebody already mentioned DPS already supports calibrated (NXCalibratedRGBColorSpace, "This color space is based on the CCIR Rec 709 phosphor set, balance to a white point of D65") and device color (NXDeviceRGBColorSpace) spaces. Now this is not only PANTONE vs RGB. But calibrated RGB vs. "raw" RGB. The flexible approach of (D)PS allowed NeXT to add a lot of hooks. So you can adjust the transfer function to the imagebuffer which gives you one level of color correction. For CMYK you can use setcmykadjust, setcmykadjustparams, setdefaultcmykadjust to control hwo CMYK gets mapped to RGB. (and 4.0 does cmykadjust by default . As I had to learn...its makes a huge difference). You can also create your own color spaces if you wish. But the calibration so far, has been made for screens only...and only for NeXT MegaPixel devices. So ColorSync does not have to add any new features into the DPS/AppKit combo but could just fill the NetInfo database with the right color correction parameters for your current devices. It might also change the definiton of the "default" calibrated color space. Btw. this is where Win95 has something OPENSTEP lacks...Configure App does not offer you a way to define the monitor which is attached to a certain graphics card. While Win95 propably might not take any reasonable benefits from defining the monitor....on a real system it could automatically ensure that only reasonalbe resolution/refresh rates can be chosen...and that the right color profiles get installed automatically. So to some degree ColorSync might get integratedin the Configure application. Only Apple or NeXT folks could elaborate, if there is some code inside ColorSync which is more efficient then the one in DPS. If there is, this might be another level of "integration". > > That's beyond the scope of a USENET posting. It can be done--I > > recommend looking at example code on the ftp archives or on an > > OPENSTEP system > > I'd need one first. :-) > Btw.. is there any legal problem with making the entire RTF(D) documentation of OPENSTEP available ? Perhaps someone (NeXT ?, Scott & stepwise ?) could link the References/Release Notes into the web somehow. Or make PS (PDF) files out of them. This could help many Mac developers who want to read the details but have no Intel to install OPENSTEP. NeXT ?...this should be an easy task and propable worth the effort. Aloha Tomi
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 12 Feb 1997 06:54:28 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0n0OxoO00iWp023GQ0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> In-Reply-To: <33011DDB.4B1A@acm.org> Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org > There has been an interesting discussion going on in comp.lang.eiffel > which is relevant to why Apple should do much better in its efforts > than just Unix. The basic problem with Unix and many other OSs is > they do not notify the user of resource problems, such as disk full, > file not found, memory short, etc, they just kill the program straight > away. Under NEXTSTEP, when you start running low on disk space, the Workspace will pop-up an alert panel warning you that disk space is low. When you run critically low on space, you'll get another warning suggesting rebooting in order to free up space by shrinking the swapfile. Under any Unix, when a processes tries to open() a file, it can receive any of about a dozen errors, including EACCESS (file not found, or bad permissions). There are not fatal errors, and the OS does _not_ kill the process when they occur. It's up to the process to implement appropriate error handling upon receiving these errors. As for "memory short" condition, what precisely does this mean under an OS which provides a good virtual memory implementation? Normally, there are two problems which can occur: running low on disk space because of swapfile size, or excessive paging due to a lack of physical memory. The former condition will cause malloc() to return NULL and set ENOMEM (again, the OS does _not_ kill the process, and it's up to the process to detect and respond to such a condition appropriately). The latter condition represents a situation where the machines' physical resources are inadequate for the workload being attempted, and Unix system pagers will try to page and/or swap out processes to reduce the phsyical memory frame requirements because they pay attention to the page fault frequency rate (ie, they use a global PFF algorithm in association with their page replacement algorithm). > This leads to many applications having superfluous code to > handle these exception conditions. This is very common code which > really should be in the OS. Above you complain that the OS 'just kill[s] the program straight away' when certain error conditions occur, and now you suggest that the OS should handle those error conditions instead of the application! These two statements are mutually contradictory. How should the OS handle these exceptional conditions? Are you saying the OS should do the same thing to every process when those errors occur, instead of passing the error condition to the process and letting the process decide for itself what should be done? [ ... ] > (I think we should all run down to our Unisys A Series shop to > learn how a real operating system works, they have been doing > this for decades, and application development and system operations > is far simpler). > ------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------ Does anyone besides me detect a common bias between the last paragraph and the .signature? -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.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 08:22:32 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5dsg6o$dtd@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> In article <peterm.855734840@ulfrun>, peterm@dna.lth.se (Peter Moller) wrote: > Well, maybee you are right, but let us at least agree that an update of > the file system in which a time stamp for *when the file was created* > (to complement the three time stamps that exist in the Unix file system > describing when the file was last accesses, modified and referenced - Accessed, modified, or changed.. "referenced" sounds the same as "accessed" to me. > if memory serves me) is added would be needed?! Yes. > And while we are at it > it would be very nice to have a file attribute saying if the file is in > use (busy) or not, right? No, I see no need to write that data out to disk ever. It's not a static attribute of a file. There should be a system call to detect that. Such an attribute may become more desirable if the filesystem is a remote mount, like AFS or something, so you can't just ask your own OS directly.. but I think AFS has its own methods of handling busy files anyway.. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: rflattin@cornut.fr (Roger Flattin) Newsgroups: comp.sys.next.programmer Distribution: world Subject: Windows Native Controls through OpenStep ? Date: 12 Feb 1997 14:26:20 GMT Message-ID: <3326541822.31250673@cornut.fr> Organization: Cornut Informatique SA Hi, I have some questions about OpenStep for Windows NT, here is some of them : 1. I'm wondering wheither the GUI objects in OpenStep NT windows are native or not ? 2. Does OpenStep NT use Display Poscript to draw buttons, text fields or does it use the native Windows objects ? 3. Can a window be drawn without a call to display postscript (a window that contains only controls)? 4. How much memory resources does display postscript need ? I'm asking these questions because we are looking at OpenStep to develop client/serveur application which doesn't make intensive use of graphics. Some we have no direct need to use DPS. Thanks in advance, Roger FLATTIN rflattin@cornut.fr ---->> On our site a SHAREWARE SQL Query Tool <<-------- --->> Don't forget to Try also our C/S Dev tool <<------- CORNUT Informatique SA Client/Server & SQL RDBMS BP 702 - 42950 St Etienne cedex 9 http://www.cornut.fr/ France email: info@cornut.fr
From: anti_email_spam@real.address.in.sig (M) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 12 Feb 1997 05:04:59 -0900 Organization: UAS Message-ID: <anti_email_spam-1202970504590001@uas-du-01-03.jun.alaska.edu> References: <5d8qta$6np@news.bu.edu> <0myB5iy00iWY461F04@andrew.cmu.edu> <slrn45fhqei.ji4.campbejr@phu989.um.us.sbphrd.com> soup@jtan.com (John R. Campbell) wrote: > So the Mac handles things oddly, and, because there is no > CLI available it cannot do any task that hasn't been pre- > programmed. Unix (and, to a lesser extent, MS-DOG) can use > small programs in a "pipeline" to handle extremely complex > tasks. I take it you've never heard of AppleScript or Frontier. . . :) No, It's not the same as unix pipes, but it can act as the glue between apps to do pipe-like operations. Plus, it can have control over GUI based apps in ways that I've never seen on any other system. ---< jsmdt@acad1.alaska.edu >------------------------------------------------
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 12 Feb 1997 09:32:39 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> In-Reply-To: <peterm.855734840@ulfrun> Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & Unix: File S.. by Peter Moller@dna.lth.se >> The reason it seems unthinkable is because it's not necessarily the >> real solution. You're talking about taking what is, at its core, a >> high-level mapping (applications to file types), and trying to embed >> them into a low-level system that has historically dealt only with the >> organization and management of the raw bits into directories and > > Well, maybee you are right, but let us at least agree that an update of > the file system in which a time stamp for *when the file was created* > (to complement the three time stamps that exist in the Unix file system > describing when the file was last accesses, modified and referenced - > if memory serves me) is added would be needed?! The "last modified" timestamp is generally used as the time when the file was created, and the two are equivalent in the case of files that have never been modified. If you care about keeping exact track of earlier revisions of a file for whatever reason, you can use a revision control system. It will keep track of all (or some) of the intermediate versions and their timestamps. Perhaps it's just me, but I don't see much value to preserving the timestamp of the creation date of the original version of a file when you don't actually have the original file-- just the modified version. Can you provide a real-world example of why you'd care about that timestamp? > And while we are at it it would be very nice to have a file attribute > saying if the file is in use (busy) or not, right? Maybe. Currently, many systems keep track of busy files by maintaining state in the kernel, and various locking mechanisms like lockf(), flock(), etc exist. These provide semantics for doing things like shared and exclusive locks, or for locking sections of files instead of locking the entire thing. Having a single file attribute to indicate a file is busy would not be adequate to replace the more complex behaviors described above, but it would still be useful in some cases. > The UFS has it's strengths, especially when coupled with NFS over TCP/IP, > but that does not mean it cannot be improved. Certainly. I don't have any objections to augmenting the UFS in order to implement the Mac's current creator and filetype attributes. I think it's likely that Apple will do something along those lines because it would simplify the transition for Mac users who expect to see those in Rhapsody. However, those Mac attributes are not adequate for handling the document-to-application mapping under a multiuser OS for reasons that we've already been through. Given that this is the case, I expect to see that there will continue to exist something at a higher level which lets users select on an individual basis which applications they would prefer to have open various document types. Such a system could rely on just the file extension if the Mac-like creator/filetype attributes are not available or are not recognized [consider a file that has been FTP'ed or is being accessed via a remote filesystem like NFS, AFS, etc], but could also pay attention to the Mac attributes if they are available and valid. That seems to combine the desirable features without changing the way either current Mac users or current NEXTSTEP users like to have things work.... -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@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 09 Feb 1997 17:47:50 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <32FE5416.59CA@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > > Second, *programming a robust API for* changing text files is much more > difficult and inefficient than a structured binary format. No it's not. NeXT's FoundationKit introduces something called a 'propertylist'. The classes in the FoundationKit (NSString, NSArray, NSDictionary) understand PropertyList format. You can write an NSDictionary to a file using PropertyList format. What you get looks like this: { Hostname = 'Foo'; IPAddress = '127.0.0.1'; Domain = 'steeldriving.com'; Users = ('tom','dick','harry'); LoginInfo = { LoginName = 'anonymous'; Password = 'guest'; }; } (An example dictionary with networking information.) The NSDictionary uses key = value formatting. The value can be a String, an Array, or another Dictionary. There's no limit to how complex the file can get, or how 'deep'. Read such a file in, and you've got a Dictionary object, which you can query ( [ipDictionary objectForKey:@"Hostname"] ). Make the changes, and save it out again. NeXT uses this to store EOModel objects. An EOModel is an object which relates database tables to Enterprise Object classes. An EOModel object can be written out to a file, and that file is an ascii propertyList format representation like that shown above. > It comes down to this: If you believe that config files should be > changable by directly editing the file, then text files make sense. If > you believe that config files should only be changed through a > well-defined UI or GUI, then text files are not the best idea. Nope. EOModel objects are stored as ascii text, but 99% of the time are edited with an excellent GUI tool, EOModeler.app. Sometimes, you've got to make global changes in an EOModel. It's much easier to open it up in a text editor and do a search & replace than to use the GUI app to do it. -- jon@steeldriving.com
From: Gary Zhang <gzhang@ix.netcom.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 12 Feb 1997 11:44:42 -0500 Organization: Bankers Trust Company Message-ID: <3301F37A.4B3@ix.netcom.com> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> <32FAD8FA.2C40@subsequent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit IMHO which file system to choose really is not that important -- that is, from a user's perspective. Ideally users (programmers being the exception) should be shielded from the underlying file system. Having the users to deal with file system directly is a major design flaw in all the OSs to date (execuse me if I'm wrong on this one). Why should a user be concerned with saving a file, creating a directory, and managing folders? If computers are really smart they should do all these for the user automatically. Ever tried to teach your mom to use a word processor? It all goes fine until you ask her to SAVE the file? No matter what you try she is not going to understand why you need to do this. The point -- information storage should be automatic and information retrieval should be intellegent. Right now the computer behaves like a dumb warehouse where YOU have to do the cleanning and organizing, while ideally it should be a SMART assistant who takes care tedious works for you -- "computer, here is my memo, don't lose it!" or "computer, I want to continue working on the unfinished article I started yesterday!" THAT's what a computer should do! ... I think Apple has a chance to create a really greate new OS. While trying to maintain compatibility, they should also build something revolutionary. An integrated, INTELLEGENT document management system should be one of those to consider... Just my 2 cents.
From: shaffer@durer.phyast.pitt.edu (C. David Shaffer) Newsgroups: comp.sys.next.programmer Subject: Re: templates Date: 12 Feb 1997 16:28:44 GMT Organization: University of Pittsburgh Message-ID: <SHAFFER.97Feb12112844@durer.phyast.pitt.edu> References: <970211105633.198AAFgS.wayne@pareto> <5dqm0o$c1a@news.orst.edu> In-reply-to: tpugh@oce.orst.edu's message of 11 Feb 1997 20:49:28 GMT Hello, I've posted about this before. My station is running 3.3 (academic bundle). My Workspace Manager reports: System Release 3.3, Workspace Version 374.6. Now if I ask for my complier version I get: ernie> cc -v Reading specs from /lib/m68k/specs NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8 That's 2.5.8! In fact, the template example that was posted previously compiles just fine on my machine. What gives? Not that I'm complaining but it seems that at least some of the 3.3 academic bundles shipped with gcc 2.5.8. David -- David Shaffer Department of Physics Wayne State College Wayne, NE 68787 shaffer@phyast.pitt.edu -- David Shaffer Department of Physics Wayne State College Wayne, NE 68787 shaffer@phyast.pitt.edu
Newsgroups: comp.sys.next.misc,comp.sys.next.software,comp.sys.next.programmer From: "Eric K. Ringger" <ringger@cs.rochester.edu> Subject: Re: TCL for NeXT (HELP) In-Reply-To: Your message of "11 Feb 1997 14:27:06 +0700." <1997Feb11.142706.47358@yogi.urz.unibas.ch> Message-ID: <199702121643.LAA03436@slate.cs.rochester.edu> Followup-To: comp.sys.next.software Sender: ringger@cs.rochester.edu (Eric K. Ringger) Cc: comp.sys.next.misc, comp.sys.next.software, comp.sys.next.programmer Organization: University of Rochester Computer Science Dept Date: Wed, 12 Feb 1997 11:43:30 -0500 frank@ifi.unibas.ch wrote: >dave@prim.demon.co.uk (Dave Griffiths) wrote: [...] >> Has anyone ported Tk to NeXTStep? [...] >If I properly recall, yes. Some company (of which I of course don't >have the name anymore) once did something like TK (ObjectTK?) and >sold it commercially. [...] I believe that you're thinking of Objective-TCL, from Pedja Bogdanovic at TipTop Software ( http://www.tiptop.com/ ). The package does not include Tk. [Follow-ups to comp.sys.next.software only.] --Eric --- Eric K. Ringger mailto:ringger@cs.rochester.edu Dept. of Computer Science Office: +1-716-275-0922; Lab: +1-716-275-1083 University of Rochester Fax: +1-716-461-2018 Rochester NY 14627-0226 http://www.cs.rochester.edu/u/ringger/ ||||| | | | | | | | | | | | | | | | | |||||
From: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 12 Feb 1997 18:53:30 GMT Organization: NeXT Software, Inc. Message-ID: <5dt3ja$nc3@news.NeXT.COM> References: <5cq1m5$6vs@elna.ethz.ch> David C. EKCHIAN writes > > Hi all, > > A question about the dynamic flag of the compiler. > 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? Actually, the release notes could have been more clear on this point. The -dynamic flag is the default if none is specified. Therefore, it no longer needs to be passed on the command line (and didn't in 4.0, either). You don't need to do anything special, unless you want to create staticly-linked executables. > And what shall I do with that DYLD_FRAMEWORK_PATH? If you set the DYLD_FRAMEWORK_PATH environment variable, any programs that you load will attempt to find the frameworks they depend on in those directories first. This allows you to easily test a new version of a framework, while keeping the old version installed in it's usual place. You really ought to read the dyld man page. There's a pretty good description of this and a few other environment variables used by dyld there. Hope this helps, -Mark -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
From: dwy@ace.net (David Young) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Followup-To: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Date: 12 Feb 1997 18:29:51 GMT Organization: ace dot net internet technologies Message-ID: <5dt26v$hkh$1@darla.visi.com> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <MWRon-1102971733180001@208.137.76.136> <5dqv7m$34q@csugrad.cs.vt.edu> <MWRon-1202970029450001@aumi3-a06.ccm.tds.net> <5drldj$d5k@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : Okay.. here's another question, then. For the developer release of : Rhapsody slated for this summer, is it known yet whether the tools : released at that time will include CodeWarrior, or an interim release : of NeXT's ProjectBuilder until CodeWarrior is fully ported to : OpenStep? (Incidentally, I hope tools eventually are produced that : will migrate projects between CodeWarrior on Rhapsody and PB on : OPENSTEP..) Also, has Metrowerks decided to provide something like : InterfaceBuilder, or will that be provided by Apple? I'd been wondering a little about this too. I'd think that Apple could either sell what we know as OpenStep Developer to a friendly third party (ie, Metrowerks), or spin off another subsidiary corporation (ie, NeXT ;) in order to market them as a separate product. They kind of need a lot of attention and somehow I think Apple might neglect them in order to bolster third party developer tool support.. -- # 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: Robert Beeman <auchstet@gate.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 12 Feb 1997 14:27:44 -0500 Organization: CyberGate, Inc. Message-ID: <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5dt1v1$j6$2@majipoor.cygnus.com> On 12 Feb 1997, John Rudd wrote: > In <AF26952B-12BAC3@208.206.178.20> "Eric Stadtherr" wrote: > > Hold on to this perspective for a minute, and think about how things are > implimented in computers in general. Generally layers of the system are > implimented seperately, each layer abstracting some low level detail to make > impimenting the next higher level easier. At some level, in ANY file system, > the file system is literally just a collection of bytes on a disk. That's > true in HFS, UFS, FAT, etc. > > The reason the NeXT advocates are saying "Don't put more of this into the > file system than you absolutely have to" is because you're trying to put a > high level construct (who created those bits on the disk, and what format > they have) into a low level construct. You can impliment that high level > construct in MANY ways, and have it appear to the user the same no matter > where you actually have implimented that mechanism. > > For example, lets say you have a HFS file that is a tiff of a dog called "My > Dog". You created it in photoshop. As a user, you don't care where the > creator and format information are stored, as long as when you click on the > file, it pulls up the right application (presumably photoshop) and loads, and > you can edit the picture of your dog. HFS puts all of this into the file > itself, in the resource fork. > > However, lets say we modify Nextstep such that if you have a directory "My > Dog" that contains the file ".wrapper", then it is treated as a single file. > Inside .wrapper is all of the meta information on the file that you need > (creator, format, etc). When you, as a user, see that "My Dog", you see a > file. It may even look like a thumbnail of the actual picture, and if you > double click on it it fires up the right application. UFS hasn't stored any > of this information in the file system mechanisms. UFS doesn't know or even > care about this. UFS is a low level construct. > > The GUI, on the otherhand, does know where to find the information, does know > what to do with it, and does the right thing. The GUI is a high level > construct. If you were to take this high level construct and force it into a > low level implimentation, more likely than not you'd create problems and slow > the system down. You would also create inconsistancies and > incompatabilities, because you could only store these data items on systems > whose low level implimentation matched those resources. > > However, by using the UFS abstraction, any file system that supports 1) > directories/folders, and 2) file names that start with a . and continue on > for at least 7 more characters, can be used to store this information. Thus, > you care less about what your file server is. If you run a high-redundancy > file server with a dedicated OS, as long as it does NFS and supports 1 and 2, > you don't care how it stores the data on the disk. But if you imbed the > information in the file blocks themselves, you can't rely on simple NFS > implimentations. You have to build some sort of translator, which then > limits your choice of platforms to those that the translator have been ported > to. To share HFS files via non-Mac systems, you either need a specialized > NFS server, CAP, or a similiar piece of specialized software. To share a > wrapper, you can use any pre-canned NFS server, including dedicated NFS > systems like those from Auspex, HP, etc. > > Thus, you have completely ignored the concept of open systems... which is why > I bet Apple wont go down this road.. They are claiming to embrace open > systems now. > > Even though the other day I thought the inode was the best place to add this, > thinking about it more (thinking about what I wrote at the time more, even), > I think a wrapper is the best way to handle this. A wrapper which is > recognized, not by name, but by containing an identifying resource (like a > file ".wrapper"). The .wrapper file can contain any meta information you > need (perhaps in pairs like "creator = photoshop", "creator_version = x.y", > "file_type = tiff", "file_type_version = a.b", etc). > > > -- > 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. > > > Yup, sounds good to me, although I'm not an expert. It does lead me to two questions that maybe you can answer: 1. Instead of a nice single file with everything in it (executables, icons, tutorial, notes, etc) you now have a collection of files, some of which are invisible. Take Disinfectant 3.6, for example. You copy one file, its all there. If you use the .wrapper extra file, doesn't this all get lost if you FTP the file from somewhere else? I suppose you could come up with something like MacBinary to handle these invisible "support" files, but its still somewhat ugly, and you could end up with files missing icons, etc. Wouldn't it be better to embed this info into the first bytes of the file itself? I think this is how OpenDoc embeds creators, etc, and wouldn't using the OpenDoc methods be a better idea anyway? It certainly would give you the same "one file holds everything" that is so convenient. 2. How does MacOS really do the resource fork? When you write a DOS format floppy there is a directory titled "resources" on the disk. Does the MacOS hide resources in separate folders with reserved names (like the Trash and desktop stuff) or where is this stuff in the file system? I guess this really shows my ignorance!! Bob Beeman, Coral Springs, FL
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: [ANN] METROWERKS TO ACQUIRE LATITUDE PORTING TECHNOLOGY Date: 12 Feb 1997 18:40:44 GMT Organization: Cygnus Solutions Message-ID: <5dt2rc$j6$3@majipoor.cygnus.com> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <MWRon-1102971733180001@208.137.76.136> <5dqv7m$34q@csugrad.cs.vt.edu> <MWRon-1202970029450001@aumi3-a06.ccm.tds.net> <5drldj$d5k@csugrad.cs.vt.edu> Cc: nurban@csugrad.cs.vt.edu In <5drldj$d5k@csugrad.cs.vt.edu> Nathan M. Urban wrote: > In article <MWRon-1202970029450001@aumi3-a06.ccm.tds.net>, MWRon@metrowerks.com (MW Ron) wrote: > > > In article <5dqv7m$34q@csugrad.cs.vt.edu>, nurban@vt.edu wrote: > > > >Here's something I've been wondering.. will CodeWarrior on Rhapsody be > > >able to build for OPENSTEP for Mach (any architecture, such as Intel, > > >NeXT, etc.), or for OPENSTEP/Enterprise (i.e., OpenStep on Windows NT). > > >Or will the only OpenStep platform it can build for be Rhapsody/PPC? > > > I don't know at this time. > > Okay.. here's another question, then. For the developer release of > Rhapsody slated for this summer, is it known yet whether the tools > released at that time will include CodeWarrior, or an interim release > of NeXT's ProjectBuilder until CodeWarrior is fully ported to > OpenStep? (Incidentally, I hope tools eventually are produced that > will migrate projects between CodeWarrior on Rhapsody and PB on > OPENSTEP..) Also, has Metrowerks decided to provide something like > InterfaceBuilder, or will that be provided by Apple? > > If it's still too early to tell, I understand.. > I'd actually like to know a lot more about the Apple/NeXT deal with Metrowerks. It sounds to me like it might be the death of IB and PB, which would REALLY suck. While I have heard good things about Metrowerks tools, I have never heard anyone say they offered the capabilities of Interface Builder. But, it doesn't really make sense for Apple to make this deal with Metrowerks if they're planning to ship a port of Openstep Developer for Rhapsody (or, rather, it doesn't make sense for Metrowerks to have jumped in there). The only way I can see that being "workable" is if IB and PB are shipped by Apple as "Objective-C only" development tools, and Metrowerks is "language independant" development tools (I seem to recall that being one of their strengths.. supporting several languages). Then your choice is the power of NeXT's tools vs the independance of Metrowerks tools. Another possability is that IB (which is really a necessary tool to any Nextstep development -- not literally so, but realistically) and PB will become seperate from the compiler choice. Apple could ship IB and PB in the base OS, without a compiler. Then Metrowerks would ship its compiler/debugger product, and both companies would be sure the two worked together. You use IB to build your .nib interface objects, PB (or metrowerks equivelant) to manage your project, and codwarrior to compile and debug. We'll have to see, though. -- 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: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 18:25:37 GMT Organization: Cygnus Solutions Message-ID: <5dt1v1$j6$2@majipoor.cygnus.com> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> Cc: ericstad@netcom.com In <AF26952B-12BAC3@208.206.178.20> "Eric Stadtherr" wrote: > >> The Real solution, a serious update of the file system, seems > >> unthinkable to the unix community. > > > >The reason it seems unthinkable is because it's not necessarily the > >real solution. You're talking about taking what is, at its core, a > >high-level mapping (applications to file types), and trying to embed > >them into a low-level system that has historically dealt only with the > >organization and management of the raw bits into directories and > >files. The file system doesn't need to know the file types, but the > >`workspace' does. I think it's still an open question as to which > >system needs to be reconfigured to solve this. > > > > > > > The file system, by nature, should provide a means for the operating system > to store and retrieve files, and information about those files. The Unix > file system is based on the (perhaps outdated) notion that a file is a > collection of bytes. The nature of the collection of bytes, and the uses > to which it is put, are determined at a higher level by the application > programs that access the file system through the operating system. While > this blanket treatment of files has advantages in terms of portability and > cross-platform interoperability, it is limited in its usefulness in a > modern operating system. > > In a truly "modern" operating system, should the file system not be > "modern" as well? The knowledge that a filesystem will contain > heterogeneous types of files is instrumental in the design of a "modern" > filesystem. I believe Apple, when it created HFS, pulled the concept of a > filesystem from the '60s at least into the '80s. An HFS file, in addition > to having a name, location, size, and extent(s), also has a type, creator, > and other flags useful to the operating system that controls the file > system. This concept not only makes the filesystem better suited for > storage of modern files, but also allows the operating system to take > advantage of the additional file information. Constructs such as the > Desktop database, MacOS Easy Open, Drag-and-Drop application launching, > etc., would not be nearly as elegant or intuitive if not for the support of > the filesystem. > > HFS is not perfect. The allocation-block limitation should certainly be > addressed. However, the designers of the Rhapsody filesystem would be > making a mistake if they blind themselves to the intuitive knowledge that a > file has more than a name and size. > > Therefore, I wholeheartedly disagree with your statement about the role of > a filesystem. > I'm sorry for keeping all of this in the post, but I think I have to... Hold on to this perspective for a minute, and think about how things are implimented in computers in general. Generally layers of the system are implimented seperately, each layer abstracting some low level detail to make impimenting the next higher level easier. At some level, in ANY file system, the file system is literally just a collection of bytes on a disk. That's true in HFS, UFS, FAT, etc. The reason the NeXT advocates are saying "Don't put more of this into the file system than you absolutely have to" is because you're trying to put a high level construct (who created those bits on the disk, and what format they have) into a low level construct. You can impliment that high level construct in MANY ways, and have it appear to the user the same no matter where you actually have implimented that mechanism. For example, lets say you have a HFS file that is a tiff of a dog called "My Dog". You created it in photoshop. As a user, you don't care where the creator and format information are stored, as long as when you click on the file, it pulls up the right application (presumably photoshop) and loads, and you can edit the picture of your dog. HFS puts all of this into the file itself, in the resource fork. However, lets say we modify Nextstep such that if you have a directory "My Dog" that contains the file ".wrapper", then it is treated as a single file. Inside .wrapper is all of the meta information on the file that you need (creator, format, etc). When you, as a user, see that "My Dog", you see a file. It may even look like a thumbnail of the actual picture, and if you double click on it it fires up the right application. UFS hasn't stored any of this information in the file system mechanisms. UFS doesn't know or even care about this. UFS is a low level construct. The GUI, on the otherhand, does know where to find the information, does know what to do with it, and does the right thing. The GUI is a high level construct. If you were to take this high level construct and force it into a low level implimentation, more likely than not you'd create problems and slow the system down. You would also create inconsistancies and incompatabilities, because you could only store these data items on systems whose low level implimentation matched those resources. However, by using the UFS abstraction, any file system that supports 1) directories/folders, and 2) file names that start with a . and continue on for at least 7 more characters, can be used to store this information. Thus, you care less about what your file server is. If you run a high-redundancy file server with a dedicated OS, as long as it does NFS and supports 1 and 2, you don't care how it stores the data on the disk. But if you imbed the information in the file blocks themselves, you can't rely on simple NFS implimentations. You have to build some sort of translator, which then limits your choice of platforms to those that the translator have been ported to. To share HFS files via non-Mac systems, you either need a specialized NFS server, CAP, or a similiar piece of specialized software. To share a wrapper, you can use any pre-canned NFS server, including dedicated NFS systems like those from Auspex, HP, etc. Thus, you have completely ignored the concept of open systems... which is why I bet Apple wont go down this road.. They are claiming to embrace open systems now. Even though the other day I thought the inode was the best place to add this, thinking about it more (thinking about what I wrote at the time more, even), I think a wrapper is the best way to handle this. A wrapper which is recognized, not by name, but by containing an identifying resource (like a file ".wrapper"). The .wrapper file can contain any meta information you need (perhaps in pairs like "creator = photoshop", "creator_version = x.y", "file_type = tiff", "file_type_version = a.b", etc). -- 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: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: Windows Native Controls through OpenStep ? Date: 12 Feb 1997 19:40:15 GMT Organization: NeXT Software, Inc. Distribution: world Message-ID: <5dt6av$nkg@news.next.com> References: <3326541822.31250673@cornut.fr> Roger Flattin writes > Hi, > > I have some questions about OpenStep for Windows NT, here is some of > them : > > 1. I'm wondering wheither the GUI objects in OpenStep NT windows are > native or not ? Not. > 2. Does OpenStep NT use Display Poscript to draw buttons, text fields or > does it use the native Windows objects ? OPENSTEP/NT uses DPS for everything except the window border and title bar. > 3. Can a window be drawn without a call to display postscript (a window > that contains only controls)? If you REALLY REALLY wanted to, you could probably do it using Windows API calls...But then you couldn't use the AppKit to interact with that window. > 4. How much memory resources does display postscript need ? > > I'm asking these questions because we are looking at OpenStep to develop > client/serveur application which doesn't make intensive use of graphics. > Some we have no direct need to use DPS. OK, now I understand. Unfortunately, OpenStep is largely an all-or-nothing kind of proposition. The AppKit is very dependent on DPS for all it's drawing. You could use just the Foundation layer, and do all the user interface with Windows API, but that would be almost as much work as not using OpenStep at all. I'd recommend using the whole OpenStep product to prototype your application, making sure that you have a clean break between application logic and user interface. Then, once it's running, determine whether DPS is really causing you any problems. Then if you have to, you can replace the DPS/Appkit front end with something a little lighter weight. -Mark -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: urban@cobra.jpl.nasa.gov (Michael P Urban) Subject: Re: Mac/NeXT & Unix: File System Message-ID: <1997Feb12.173429.29584@llyene.jpl.nasa.gov> Sender: news@llyene.jpl.nasa.gov Organization: Jet Propulsion Laboratory, Pasadena, California References: <5ddp66$jpc@news.bu.edu> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> Date: Wed, 12 Feb 1997 17:34:29 GMT In article <peterm.855734840@ulfrun>, Peter Moller <peterm@dna.lth.se> wrote: >Stephen Peters <speters@cygnus.com> writes: > >>The reason it seems unthinkable is because it's not necessarily the >>real solution. You're talking about taking what is, at its core, a >>high-level mapping (applications to file types), and trying to embed >>them into a low-level system that has historically dealt only with the >>organization and management of the raw bits into directories and > >Well, maybee you are right, but let us at least agree that an update of >the file system in which a time stamp for *when the file was created* >(to complement the three time stamps that exist in the Unix file system >describing when the file was last accesses, modified and referenced - >if memory serves me) is added would be needed?! And while we are at it >it would be very nice to have a file attribute saying if the file is in >use (busy) or not, right? The UFS has it's strengths, especially when >coupled with NFS over TCP/IP, but that does not mean it cannot be im- >proved. > Creation time information will be necessary for Mac programs, and would doubtless be helpful in some configuration management. It of course complicates Unix programs like "cp" that would need to explicitly duplicate the creation time, and operations like "cat a > b" could not preserve creation time information. "busy" information is not properly a function of the file header as it exists on disks, and complicates recovery in the event of a system crash. Out-of-band data associated with files (Finder information, resource fork, and perhaps other things) could be added in a general way to a Unix file system; for all I know, the NeXT folk may already have done this. It would certainly be a more general solution than the traditional Unix reliance on "magic numbers" and similar hackery. (two forks are theoretically sufficient; the second fork can point to another file with two forks, in a linked-list sort of way if multiple forks are desired).
From: nwc@ceto (Nick Christopher) Newsgroups: comp.sys.next.programmer Subject: NSCoder..what does encodePropertyList: do? Date: 12 Feb 1997 21:16:15 GMT Organization: WSC Investment Services, Inc. Distribution: world Message-ID: <NWC.97Feb12161615@ceto> I need to be able to move achieves between OPENSTEP and GNUSTEP and so have written an NSCoder/NSArchiver/NSUnarchiver clone that allows this to happen. But - and its a big but...I am a little confused about encodePropertyList: and its decoding mirror. What are they there for? The docs are on these can not be used as specs. Anybody from NeXT/ApPPLE out there that might give a definitive answer? I read email (nwc@wsc.com) more than news so prefer answers that way. \n -- Nicholas Christopher nwc@wsc.com
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 12 Feb 1997 22:31:04 GMT Organization: Boston University Message-ID: <5dtgb8$dh4@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <qdraingio0.fsf@blues.cygnus.com> Stephen Peters (speters@cygnus.com) wrote: : macintsh@bu.edu (John Siracusa) writes: : > I'd say the registry is a hack to make up for an inane filesystem : > that doesn't allow putting the information contained in the : > registry in the files themselves, where it would make more sense. : And in what file's resource fork would you put, say, hardware : configuration information? I'm not quite sure what you mean by "hardware configuartion values." Do you mean size and number of disk drives, video cards, and stuff like that? That seems like the type of thing that is sensed at boot time and dynamically configured by the OS as disks are mounted or whatever. As for the concept of a centralized information registry, the closest the Mac comes is the Desktop File database(s). I don't like them much either, but at least if they get screwed up you can just trash them and they'll rebuild themselves. The seem to be a decent compromise between performance and functionality, consolidating all the information in each individual file's resource fork (as pertaining to file types, creators, and icon sets, in this case) into a central database to speed access. But without the information in the apps themselves, the ability to rebuild after a database corruption or whatever is gone. I think that's the main problem with the windows registry and I think it highlights the need for, if not separate file forks, then at least a standardized file *attribute* format (see: BeOS and it's spiffy mime-based file-typing and arbitrary key/value DB system built into its file system). -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: MWRon@metrowerks.com (MW Ron) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: [ANN] Making The Ultimate Development Platform Date: Wed, 12 Feb 1997 15:08:36 -0500 Organization: Metrowerks Message-ID: <MWRon-1202971508360001@aumi5-a04.ccm.tds.net> HI, Just thought I'd point out that there is an interview in Apples online magazine Focus with Greg Galanos on the future plans of Metrowerks titled Making The Ultimate Development Platform http://www2.apple.com/home/thirddecade/ Ron -- METROWERKS Ron Liechty "Software at Work" MWRon@metrowerks.com http://www.metrowerks.com/about/people/rogues.html#mwron
Newsgroups: comp.sys.next.programmer From: hhoff@schwaben.de.NOSPAM (Holger Hoffstaette) Subject: Re: templates Sender: news@flop.schwaben.de Organization: NeXT Ghetto People feat. St.Eve Message-ID: <E5IEu3.2s8@flop.schwaben.de> References: <970211105633.198AAFgS.wayne@pareto> <5dqm0o$c1a@news.orst.edu> <SHAFFER.97Feb12112844@durer.phyast.pitt.edu> Date: Wed, 12 Feb 1997 21:39:39 GMT C. David Shaffer wrote: > Hello, > > I've posted about this before. My station is running 3.3 (academic > bundle). My Workspace Manager reports: System Release 3.3, Workspace > Version 374.6. Now if I ask for my complier version I get: > > ernie> cc -v > Reading specs from /lib/m68k/specs > NeXT Computer, Inc. version cc-437.2.6, gcc version 2.5.8 > > That's 2.5.8! In fact, the template example that was posted > previously compiles just fine on my machine. What gives? Not that I'm > complaining but it seems that at least some of the 3.3 academic > bundles shipped with gcc 2.5.8. On 4.1 it's still some transmogrified 2.5.8. I didn't really expect the posted example to compile, let alone work correctly (hey, we *are* talking about C++ here!), and needless to say I get punished for trying nevertheless: hhoff>cc++ -v Reading specs from /lib/i386/specs NeXT Computer, Inc. version cc-478, gcc version 2.5.8 hhoff>cc++ test.C -lg++ hhoff>ll total 35 -rwxr-xr-x 1 hhoff other 34192 Feb 12 22:34 a.out* -rw-r--r-- 1 hhoff other 216 Feb 12 22:31 test.C hhoff>a.out Segmentation fault hhoff> Changing from a statically allocated object to one on the heap won't help either. Looks like typical C++ behaviour to me! :-> Holger
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 14:58:29 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g122e.o78.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> On 10 Feb 1997 11:47:13 -0800, Stephen Peters <speters@cygnus.com> wrote: >peterm@dna.lth.se (Peter Moller) writes: >> I'm also suspicious against hacks of all kinds; the File Manager on >> Solaris is, unfortunatley, a very good example of a very, very bad >> hack. In that case, it is an unsolvable situation: the poverty of >> the filesystem (in terms of file attributes), makes a hack the only >> usable solution. > >I agree that the Solaris filemgr application is a hack. I disagree >that it's the only usable solution. NeXT hasn't played with the file >system to get its information; instead, it's augmented the >higher-level `Workspace' to associate the file types with >applications. Still, it isn't that hard to add attributes to a file in a reasonable way w/i the Unix paradigm (though we'd need to doink around with the "copy" utility...). Now you've given me an opening- I'm old enough that I *love* an opportunity to pontificate. In a Unix filesystem there is an object called an I-Node; each unique file has one. Directories only contain names and inode numbers; Only the directory contains names, since there's little point to attaching a name to an inode directly (especially since several names can point to the same inode). I-Nodes are filesystem-wide and not constrained to a particular directory. An inode contains the timestamps of creation, modification and access, permissions and an array of block numbers where the file resides w/i the filesystem; There is no reason that one of those blocks can't be stolen and press-ganged into storing "overhead" information about a file; The only real limitation is how to get at the extended information block. See, for a "normal" utility (even for the Mac) this information is stored "out of band"; It's invisible to a utility program unless the program itself explicitly looks that information up. In Unix, read() and write() deal with in-band information and makes access to extended file information awkward. The stat() and fstat() calls are designed to look at specific information from the inode (but not all of it) and has the disadvantage of being "fixed format" (though we *can* cheat here). Another syscall used for out-of-band information is the ioctl() (I/O control) call; Normally applied to devices it can just as easily be applied to files... >> The Real solution, a serious update of the file system, seems >> unthinkable to the unix community. > >The reason it seems unthinkable is because it's not necessarily the >real solution. You're talking about taking what is, at its core, a >high-level mapping (applications to file types), and trying to embed >them into a low-level system that has historically dealt only with the >organization and management of the raw bits into directories and >files. The file system doesn't need to know the file types, but the >`workspace' does. I think it's still an open question as to which >system needs to be reconfigured to solve this. Actually, there is a good argument that such a "fork" mechanism can be useful, especially with an attempt to migrate towards a more "object oriented" filesystem. There are times when even I'd like to hide some information out- of-band to a file's contents yet still be able to get at it (Business BASICs, like Throroughbred's, must leave a special in-band header on a file, making it extremely difficult to access the file using "normal" Unix utilities). Linux's ext2 filesystem already has hooks for ACLs and the like; There's nothing precluding adding this feature as an experimental measure and exploring it's advantages, disadvantages and other side defects within a Unix-like environment. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 16:35:59 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5dtd3v$pc2@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <1997Feb12.173429.29584@llyene.jpl.nasa.gov> In article <1997Feb12.173429.29584@llyene.jpl.nasa.gov>, urban@cobra.jpl.nasa.gov (Michael P Urban) wrote: > Out-of-band data associated with files (Finder information, resource > fork, and perhaps other things) could be added in a general way to > a Unix file system; for all I know, the NeXT folk may already have > done this. It would certainly be a more general solution than the > traditional Unix reliance on "magic numbers" and similar hackery. What NeXT needs to do is ressurect its object-oriented database filesystem project. Allows for the association of arbitrary attributes with files, or so I assume from what I remember hearing about it. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 21:28:15 GMT Organization: Cygnus Solutions Message-ID: <5dtclf$35p$1@majipoor.cygnus.com> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> Cc: auchstet@gate.net In <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> Robert Beeman wrote: > > 1. Instead of a nice single file with everything in it (executables, > icons, tutorial, notes, etc) you now have a collection of files, some of > which are invisible. Take Disinfectant 3.6, for example. You copy one > file, its all there. If you use the .wrapper extra file, doesn't this all > get lost if you FTP the file from somewhere else? I suppose you could > come up with something like MacBinary to handle these invisible "support" > files, but its still somewhat ugly, and you could end up with files > missing icons, etc. Wouldn't it be better to embed this info into the > first bytes of the file itself? I think this is how OpenDoc embeds > creators, etc, and wouldn't using the OpenDoc methods be a better idea > anyway? It certainly would give you the same "one file holds everything" > that is so convenient. > NeXT did used to use something like this for its executables. Mach-o is a binary file format with multiple segments.. for icons, langauge resource, multiple executables (for various architectures), etc. But it was decided to switch to wrappers for more modularity, flexability, and such. It also turns out to be more portable. It does add an extra level of complexity for file transfers.. if you're creating something to distribute via FTP, you generally want to create a package, and then tar and compress/gzip that. But that's not really any worse than having to BinHex mac files. For copying files to a floppy or nfs volume, there's no overhead.. you drag the wrapper to the place you want it, and the GUI knows to copy not just the directory wrapper, but everything inside it. A Gui "Make an FTP volume" tool could easiliy be created.. or making a wrapper aware ftp server and client (probably the GUI tool would be better). > 2. How does MacOS really do the resource fork? When you write a DOS > format floppy there is a directory titled "resources" on the disk. Does > the MacOS hide resources in separate folders with reserved names (like the > Trash and desktop stuff) or where is this stuff in the file system? I > guess this really shows my ignorance!! > Your guess is pretty much accurate. At the point where we were using an NFS server for serving Appletalk volumes (via some add on software), it stored the data forks in one directory tree, and the resource forks in another. Probably the "resources" directory on the Dos disk was basically that.. -- 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: bettis@inetnebr.com (Mr. Jeremy Bettis) Newsgroups: comp.sys.next.programmer Subject: Re: NSCoder..what does encodePropertyList: do? Date: 12 Feb 1997 16:36:12 -0600 Organization: Internet Nebraska Message-ID: <5dtgks$j5r@falcon.inetnebr.com> References: <NWC.97Feb12161615@ceto> NNTP-Posting-User: bettis nwc@ceto (Nick Christopher) writes: >I need to be able to move achieves between OPENSTEP and GNUSTEP and so have >written an NSCoder/NSArchiver/NSUnarchiver clone that allows this to happen. >But - and its a big but...I am a little confused about encodePropertyList: and >its decoding mirror. What are they there for? The docs are on these can not be >used as specs. -encodePropertyList encodes a property list, a property list is a graph of the following objects NSString, NSData, NSArray, and NSDictionary. encoding a property list does not preserve the mutablilty of the objects, just the structure.
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 13 Feb 1997 12:00:10 +1100 Organization: Unisys Message-ID: <33026799.D07@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@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.programmer: 12-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > > There has been an interesting discussion going on in comp.lang.eiffel > > which is relevant to why Apple should do much better in its efforts > > than just Unix. The basic problem with Unix and many other OSs is > > they do not notify the user of resource problems, such as disk full, > > file not found, memory short, etc, they just kill the program straight > > away. > > Under NEXTSTEP, when you start running low on disk space, the Workspace > will pop-up an alert panel warning you that disk space is low. When you > run critically low on space, you'll get another warning suggesting > rebooting in order to free up space by shrinking the swapfile. Rebooting!!! > Under any Unix, when a processes tries to open() a file, it can receive > any of about a dozen errors, including EACCESS (file not found, or bad > permissions). There are not fatal errors, and the OS does _not_ kill > the process when they occur. It's up to the process to implement > appropriate error handling upon receiving these errors. And this is wrong. An OS should handle many more of these common errors. > As for "memory short" condition, what precisely does this mean under an > OS which provides a good virtual memory implementation? Normally, there > are two problems which can occur: running low on disk space because of > swapfile size, or excessive paging due to a lack of physical memory. > > The former condition will cause malloc() to return NULL and set ENOMEM > (again, the OS does _not_ kill the process, and it's up to the process > to detect and respond to such a condition appropriately). The latter > condition represents a situation where the machines' physical resources > are inadequate for the workload being attempted, and Unix system pagers > will try to page and/or swap out processes to reduce the phsyical memory > frame requirements because they pay attention to the page fault > frequency rate (ie, they use a global PFF algorithm in association with > their page replacement algorithm). But in this case I expect the OS to alert the user to decide to close down certain processes. This decision is beyond the operating system to make, and it is certainly far beyond the scope of an application program. So what is the application program going to do because a malloc has failed due to environmental factors beyond its control? > > This leads to many applications having superfluous code to > > handle these exception conditions. This is very common code which > > really should be in the OS. > > Above you complain that the OS 'just kill[s] the program straight away' > when certain error conditions occur, and now you suggest that the OS > should handle those error conditions instead of the application! These > two statements are mutually contradictory. How are they contradictory? I'm saying: don't kill my program, and don't hand me an exception before the OS has a good attempt at handling it itself. Only after this, hand me an exception so I can leave things in a consistent state. > How should the OS handle these exceptional conditions? Are you saying > the OS should do the same thing to every process when those errors > occur, instead of passing the error condition to the process and letting > the process decide for itself what should be done? Yes, because many of these things are so common. Why clutter applications just to make up for deficiencies in the OS? > [ ... ] > > (I think we should all run down to our Unisys A Series shop to > > learn how a real operating system works, they have been doing > > this for decades, and application development and system operations > > is far simpler). > > ------------------------------------------------------------------------ > > 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 > > ------------------------------------------------------------------------ > > Does anyone besides me detect a common bias between the last paragraph > and the .signature? Not at all, I am giving a concrete example of where what I am talking about is put into practice, with significant simplification in systems operations, and substantially reduced applications development effort. If I was really biased, I would not share these observations with Apple, would I? If Apple wants to adopt NeXT and Mach, then it had better be fully aware of the technical deficiencies of Unix, or Apple will lose its edge of superiority. > -Chuck > > Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer > ----------------+---------------------+--------------------- > I know you're an optimist if you think I'm a pessimist. -- ------------------------------------------------------------------------ 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: shimpei@ra.patnet.caltech.edu (Shimpei Yamashita) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 14:53:53 -0800 Organization: Hummingbird Heaven Message-ID: <5dthm1$30h@ra.patnet.caltech.edu> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> In article <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net>, Robert Beeman <auchstet@gate.net> wrote: >2. How does MacOS really do the resource fork? When you write a DOS >format floppy there is a directory titled "resources" on the disk. Does >the MacOS hide resources in separate folders with reserved names (like the >Trash and desktop stuff) or where is this stuff in the file system? I >guess this really shows my ignorance!! On the lowest level of abstraction, the two forks of a Mac file is stored as two separate files. (To convince yourself of this, make a tiny data file with and without a resource fork. The one without a resource fork will take up some minimal amount of space on the hard disk; the one with a resource fork will take up twice that, even though the amount of information in each is identical.) However, the two forks belong to the same file as far as application programmers are concerned. HFS doesn't allow you to move them around separately, AFAIK. The hack of putting the resource fork in some hidden directory is also used for AUFS (an emulation of HFS on top of Unix filesystem). That works just fine until you try to look at the files from the Unix side--then all sorts of things will break because file viewing and manipulation routines in Unix will only affect the data fork. I munged more than a few files this way before I learned by lesson. -- Shimpei Yamashita <http://www.cco.caltech.edu/%7Eshimpei/> Caltech submillimeter astrophysics group shimpei@socrates.caltech.edu
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 13 Feb 1997 01:04:37 GMT Organization: Boston University Message-ID: <5dtpb5$h4t@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> Jonathan W. Hendry (jon@subsequent.com) wrote: : John Siracusa wrote: : > I'd say the registry is a hack to make up for an inane filesystem : > that doesn't allow putting the information contained in the : > registry in the files themselves, where it would make more sense. : It doesn't make sense when files and applications can be used : by multiple users. I don't see how that is. File type and creator information doesn't vary from user to user. If you're talking about the type of thing that is stored in preference files on the Mac, then the logical solution is to have separate preference folders for each user. This doesn't really apply since, abilities aside, Rhaposdy will be targeted as a single-user system from what I have read. -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 12 Feb 1997 19:18:22 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <33025DCE.2A6D@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <33001949.2FD2@subsequent.com> <slrn45g154u.o78.campbejr@phu989.um.us.sbphrd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John R. Campbell wrote: > > On Tue, 11 Feb 1997 02:01:29 -0500, "Jonathan W. Hendry" <jon@subsequent.com> wrote: > >If Apple doesn't use resource forks, they probably won't use the > >Mac filesystem at all. They'd most likely use the current > >NeXT/bsd filesystem, which doesn't suffer from the blocksize problem. > > Let's assume a mangled Unix-like filesystem that allows for out-of- > band information to be stored in a special block w/i the inode. > Under normal circumstances this block won't be allocated on the > disk unless an application needs it, so the overhead isn't too > terrible. In order to get at the information we'd either need > to extend the stat() and fstat() calls or just do I/O to the block > via ioctl() (normally used for out-of-band management of devices). That might work, but once again, non-Apple filesystems would lack that information. NFS-mounted volumes from other Unix boxes would be devoid of this information. -- jon@steeldriving.com
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 12 Feb 1997 19:06:49 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <33025B19.42A1@subsequent.com> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> <5dtclf$35p$1@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Rudd wrote: > > In <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> Robert Beeman > wrote: > > > > 1. Instead of a nice single file with everything in it (executables, > > icons, tutorial, notes, etc) you now have a collection of files, some of > > which are invisible. Take Disinfectant 3.6, for example. You copy one > > file, its all there. If you use the .wrapper extra file, doesn't this all > > get lost if you FTP the file from somewhere else? I suppose you could > > come up with something like MacBinary to handle these invisible "support" > > files, but its still somewhat ugly, and you could end up with files > > missing icons, etc. Wouldn't it be better to embed this info into the > > first bytes of the file itself? I think this is how OpenDoc embeds > > creators, etc, and wouldn't using the OpenDoc methods be a better idea > > anyway? It certainly would give you the same "one file holds everything" > > that is so convenient. > A Gui "Make an FTP volume" tool could easiliy be created.. It's already there: File->Compress (For Mac users, the NeXT Workspace includes a Compress item in the File menu. Compress tar's and compresses the selected file. Or decompresses it, if the file's already compressed. Naturally, in that case, the menu item says 'Decompress'. The resulting file has a .compressed extension. The user doesn't need to go to the CLI and use tar and compress. It also handles .tar and .tar.Z files. A .compressed file is identical to a .tar.Z file.) -- jon@steeldriving.com
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 01:53:44 GMT Organization: Cygnus Solutions Message-ID: <5dts78$bot$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> Cc: macintsh@bu.edu In <5dtpb5$h4t@news.bu.edu> John Siracusa wrote: > Jonathan W. Hendry (jon@subsequent.com) wrote: > : John Siracusa wrote: > : > I'd say the registry is a hack to make up for an inane filesystem > : > that doesn't allow putting the information contained in the > : > registry in the files themselves, where it would make more sense. > > : It doesn't make sense when files and applications can be used > : by multiple users. > > I don't see how that is. File type and creator information doesn't > vary from user to user. If you're talking about the type of thing > that is stored in preference files on the Mac, then the logical > solution is to have separate preference folders for each user. > > This doesn't really apply since, abilities aside, Rhaposdy will > be targeted as a single-user system from what I have read. It applies if they don't plan to _limit_ it to single user systems. Targeting isn't the same as saying "it wont be able to be used for applications other than this one". It simply means that is who they plan to focus on. Focusing on single user systems is all well and good, and rather appropriate to the mac market.. but again, Apple wants to come out of this with a system that scales to servers and such.. and it's not going to scale as well if they eliminate multi-user capabilities. On the otherhand, I don't see how that's relevant to Jonathan's point. The application creator is the application creator.. if that information is relevant to you, then you use that application. There is no need to overload this data. If you want the file type to determine the application you launch, instead of the creator, then the GUI should have a switch for choosing between the two. Then each user keeps a list of bindings for file types to applications. Multi-user systems aren't hindered by either of these being stored in the file (or the file wrapper, or the inode, or the resource fork). The reason this is a problem on a Mac isn't because it's stored in a central location.. it's because the Mac doesn't allow you to pick file type over file creator for its launching heuristic, and then give a seperate file-type <-> application binding for different "profiles" (even if its' just swapping a file at runtime). If it did allow this (even the crude run time swapping of the binding file), then it wouldn't be a problem. -- 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: stanj@cs.stanford.edu (Stan Jirman) Newsgroups: comp.sys.next.programmer Subject: Openstep: removing events from the queue Date: 13 Feb 1997 02:12:44 GMT Organization: Stanford University Message-ID: <5dttas$1pk@nntp.Stanford.EDU> I have an event loop which follows the mouse as it's being dragged. The things I do there are quite expensive, esp. on NT. So I would like to get rid of all in-between dragged events to avoid lag. - (void)discardEventsMatchingMask:(unsigned int)mask beforeEvent:(NSEvent *)lastEvent; won't work because I don't know the very last event. The online docs say "NSAnyEvent till the mouseUp", but how am I gonna get the mouseUp NSEvent pointer if I don't know whether / where it is? So I built something like: while (ne = [_window nextEventMatchingMask:moveMask untilDate:[NSDate distantFuture] // [NSDate date] aint it either inMode:NSEventTrackingRunLoopMode dequeue:YES]) rLoc = [ne locationInWindow]; For some strange reason, this doesn't help. Can someone clue me in? Thanks - Stan --- Nature photography: http://www-leland.stanford.edu/~stanj NeXTmail and MIME: stanj@cs.stanford.edu
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 11 Feb 1997 15:51:01 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g154u.o78.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <33001949.2FD2@subsequent.com> On Tue, 11 Feb 1997 02:01:29 -0500, "Jonathan W. Hendry" <jon@subsequent.com> wrote: >Dave Scocca wrote: >> >> In article <32FF770C.6601@mcs.com>, Alan Jenks <jalanet@mcs.com> wrote: >> >> \ It sounds like the NextOS already has a mechanism that could be enhanced >> \ to support the file type and creator concepts found on the Mac. I don't >> \ think the user will care that the implementation that supports this is >> \ multiple hidden files rather than a single file with a resource fork, as >> \ long as the user experience is the same. >> >> Under one condition--if we're using multiple hidden files, we MUST fix >> the large-block problem for large hard drives. Since a hard drive has >> 65536 allocation blocks, and no more, small files on large hard drive >> are large. Right now, a text file containing a single character >> consumes 32K of my (2.1 GB) hard drive. Sounds like MS-DOG's excuse for a filesystem to me. Using NeXT's NextStep you have a more Unix-like filesystem, so this is the logical starting point. Mind you, NeXT "fakes" the resource fork using hidden files; They apparently didn't want to modify the filesystem to allow for hidden information. A Unix-based file system (like Linux's ext2) can handle extremely large filesystems w/o having to boost the allocation granule size (sorry for using old MainFrame terminology, but I've been there); Most Unix filesystems still allocate 512byte blocks as the granule size. Even the Berkeley Fast File System resolves to these despite pre-allocating 4K per file and then allocating fragments when space starts getting tight. >> Under the current system, the data fork and the resource fork each >> require a minimum of one allocation block. If we break down the >> resource fork into a bunch of little hidden files, each of which >> requires a minimum of one allocation block, we'll be eating up hard >> drive space at an amazing rate. > >If Apple doesn't use resource forks, they probably won't use the >Mac filesystem at all. They'd most likely use the current >NeXT/bsd filesystem, which doesn't suffer from the blocksize problem. Let's assume a mangled Unix-like filesystem that allows for out-of- band information to be stored in a special block w/i the inode. Under normal circumstances this block won't be allocated on the disk unless an application needs it, so the overhead isn't too terrible. In order to get at the information we'd either need to extend the stat() and fstat() calls or just do I/O to the block via ioctl() (normally used for out-of-band management of devices). It ain't something that impossible, nor is it hard; It's merely a trick of a filesystem. I've been considering this issue and I see no reason I couldn't hack up a modification to Linux's ext2 filesystem to handle this... ...hmmm, this might make an interesting diversion... -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 97 17:08:23 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb12170823@slave.one.net> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> In-reply-to: jrudd@cygnus.com's message of 12 Feb 1997 18:25:37 GMT In article <5dt1v1$j6$2@majipoor.cygnus.com>, jrudd@cygnus.com (John Rudd) writes: In <AF26952B-12BAC3@208.206.178.20> "Eric Stadtherr" wrote: > The file system, by nature, should provide a means for the > operating system to store and retrieve files, and information > about those files. The Unix file system is based on the (perhaps > outdated) notion that a file is a collection of bytes. The > nature of the collection of bytes, and the uses to which it is > put, are determined at a higher level by the application programs > that access the file system through the operating system. <...> > I believe Apple, when it created HFS, pulled the concept of a > filesystem from the '60s at least into the '80s. An HFS file, in > addition to having a name, location, size, and extent(s), also > has a type, creator, and other flags useful to the operating > system that controls the file system. Actually, I would argue that with this information, Apple brought filesystems from the 60's to at most the 70's. Keep in mind the goals Unix had when it was young - don't build new abstractions for everything, instead try to find one abstraction which can fit most cases, with some adjustment at the boundaries. Thus we have things like sockets as a file descriptor, most everything as a device, and filesystems that turn files into bags of bytes. Hold on to this perspective for a minute, and think about how things are implimented in computers in general. Generally layers of the system are implimented seperately, each layer abstracting some low level detail to make impimenting the next higher level easier. At some level, in ANY file system, the file system is literally just a collection of bytes on a disk. That's true in HFS, UFS, FAT, etc. The reason the NeXT advocates are saying "Don't put more of this into the file system than you absolutely have to" is because you're trying to put a high level construct (who created those bits on the disk, and what format they have) into a low level construct. There is a _very_ good reason why you want to do this, one that I didn't see John mention in his post. Remember that we're no longer dealing with a glorified application launcher plus some system libraries, here. The filesystem code is either in the kernel (Unix, macrokernel Mach), or ever so slightly outside the kernel (microkernel Mach). [Honestly, the two only differ for people who like to hack on the kernel :-).] A filesystem as a bag of bytes is fundamentally easier to write and debug than a filesystem which maintains arbitrary amounts of auxiliary information. Keep in mind that each additional piece of info you stuff into the inode makes _everything_ that much slower. Right now, each block of inodes contains some number of inodes, call it N. If we make the inode twice as big, then each read only gets half as many inodes. This makes all of your directory traversal code slower, because it's waiting on the disk, and all of your inode maintenance code is likely slower, because you can't cache as many inodes in a given space (be it a disk block cache or a CPU cache). This affects _all_ files, even those which don't give a rat's ass about a file's creator, and it affects anything which "looks" at the file, including just listing the directory the file is in. Consider things like Unix pipes and devices. Under Unix, device access is mostly the same across devices (though each obviously works differently). You direct output to the console as easily as you direct output to a file as easily as you direct output to a network socket as easily as you direct output to a raw disk drive as easily as you direct one command's output to another's input. Devices, named pipes, redirected files, directories, executables, none of these need CREATOR or anything of the sort. All will pay the excise tax if it's added, though. Then there's the maintenance concern. What happens if you store various info in the inode, creator and whatnot, and ... the info you need changes? Nobody uses the "Last time a newline was written" flag, or it turns out that your "creator" indicator isn't big enough to handle all of the potential creator apps. [Perhaps someone wants to say "FuzzBall version 1.2" versus "FuzzBall version 2.1".] Or you need an entirely new bit of info which the current scheme doesn't provide. The _only_ thing I could see adding to the FFS filesystem to enhance support for additional info for files would be a single bit in the permissions for that file or directory. This bit would have no effect on anything, it would just be an advisory bit saying "I'm a document or document wrapper". This would allow the file viewer or finder to make certain assumptions about the file, such as how to display it and where to find certain information (within the file itself, or in a special file in the wrapper). Specifically, it lets you display a file as an application wrapper without requiring a registered extension. OTOH, if you just defined wrapperName/.FinderInfo as The Place To Put Finder Information, even that bit wouldn't be necessary. If the file is empty, display it as a document without any special handling. Otherwise the contents of the file might describe the creator application, the author of the file, what icon to use for the file, whether to verify before deleting, whether the file is password protected, etc, etc. And anything the application puts in which the finder doesn't understand is ignored, which could reasonably allow finder upgrades. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 00:06:27 GMT Organization: Cygnus Solutions Message-ID: <5dtlu3$93o$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <33001949.2FD2@subsequent.com> <slrn45g154u.o78.campbejr@phu989.um.us.sbphrd.com> Cc: campbejr@phu989.mms.sbphrd.com In <slrn45g154u.o78.campbejr@phu989.um.us.sbphrd.com> John R. Campbell wrote: > > > >If Apple doesn't use resource forks, they probably won't use the > >Mac filesystem at all. They'd most likely use the current > >NeXT/bsd filesystem, which doesn't suffer from the blocksize problem. > > Let's assume a mangled Unix-like filesystem that allows for out-of- > band information to be stored in a special block w/i the inode. > Under normal circumstances this block won't be allocated on the > disk unless an application needs it, so the overhead isn't too > terrible. In order to get at the information we'd either need > to extend the stat() and fstat() calls or just do I/O to the block > via ioctl() (normally used for out-of-band management of devices). > > It ain't something that impossible, nor is it hard; It's merely > a trick of a filesystem. I've been considering this issue and I > see no reason I couldn't hack up a modification to Linux's ext2 > filesystem to handle this... > > ...hmmm, this might make an interesting diversion... > > First, before I say this, I want to say I think it would be MUCH better to go with the wrapper solution.. in the same way Mach-o is an improvement over a HFS solution (N forks vs 2 forks), and Wrappers are an improvement over Mach-o (N forks + heirarchy vs N forks) for executables, I think the same will be true for wrappers as data files. However, I went and looked at the Inode structures to see if there is an unused field that can be used for storing creator information (storing type information isn't something I think you can do in the current inode.. you could store an integer that referenced a list of types, but then you can only have files be of a "blessed" type to take advantage of that.. that's too limiting, in my opinion -- so you'd probably need to stick with keeping the file type information in the file name). There are 4 "reserved for future use" long's in the inode structure (inode.i_ic.ic_spare[4]) which could be used to store a) a device (a short), and b) an inode (a u_long) for the creator's location, and c) the time_t (long) of the file's last access by that creator at that inode. You'd probably also want to use the spare c time (inode.i_ic.ic_ctspare) for the "create time" of any arbitrary file. Then, when you access the file to find its creator, you a) check the create time of your file, find the device and inode of its creator and see if the file at THAT inode was created more recently than item C above. If the creator inode is more recent, then the creator file is no longer valid (it was destroyed since you last accessed this file from that creator). Otherwise, that file is the creator. There are some limits here... in file transfer via things like ftp and such, you WILL lose this data. It is non-portable to non-Rhapsody machines (it can be stored there via NFS, but the other machine wont use it, and it may get corrupted by the other machine(s), esp if they use this "reserved for future use" field for something else). However it doesn't create a seperate pool of information (the "pointer to a block" method would also be lost.. in transfer, btw), it doesn't have things spread across multipe files even at the lowest file level. It's just a simple "here's my creator" tag. It's also a bit of a hack.. not very elegant nor extensible. But it would probably work. I just don't think we want to be implimenting these things via hacks. -- 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: David Young <dwy@ace.net> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 13 Feb 1997 04:46:57 GMT Organization: ace dot net internet technologies Message-ID: <5du6c1$19c$1@darla.visi.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> In comp.sys.next.programmer Ian Joyner <i.joyner@acm.org> wrote: : Yes, because many of these things are so common. Why clutter : applications : just to make up for deficiencies in the OS? "Out of memory" is not something an OS can dictate an action for to an application. Trust me, when a UNIX box says out of memory, it's tried absolutely everything it can. : If Apple wants to adopt NeXT and Mach, then it had better be fully : aware of the technical deficiencies of Unix, or Apple will lose its : edge of superiority. Are you *insane*? Apple's current OS has the *worst* memory management architecture of ANY operating system since the advent of the MMU. Period. Whereas UNIX (and Mach) have one of the best. -- # 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.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 13 Feb 1997 05:01:30 GMT Organization: Indiana University, Bloomington Message-ID: <5du77a$ean@dismay.ucs.indiana.edu> References: <5d8qta$6np@news.bu.edu> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5du6c1$19c$1@darla.visi.com> NNTP-Posting-User: glhansen In article <5du6c1$19c$1@darla.visi.com>, David Young <dwy@ace.net> wrote: >In comp.sys.next.programmer Ian Joyner <i.joyner@acm.org> wrote: >: Yes, because many of these things are so common. Why clutter >: applications >: just to make up for deficiencies in the OS? > >"Out of memory" is not something an OS can dictate an action for to an >application. Trust me, when a UNIX box says out of memory, it's tried >absolutely everything it can. And the response could be anything from "Out of memory: can't open file" to "Not enough memory for that operation. Try something smaller." to just opening up a smaller drawing area or sending a "Connection refused" error down the network without ever putting up a dialog box, or maybe limiting the quality of sound output in a game. Maybe even a "Calculation halted: out of memory. Try quitting some applications, then click 'RESUME' to continue." The operating system just doesn't know what you want to do with that out of memory error. And only you can decide which path the program should take, rather than charging ahead assuming you have the memory. And if you do charge ahead? If you try to store data through a null pointer, then the program is just plain broken and nothing the operating system can do will fix it. At that point the program can't even continue to run. -- "Good things come in small packages. But big things can't, unless they're inflatable or require some assembly." - The Tick
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 09:11:28 GMT Organization: Lund University Message-ID: <peterm.855825088@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> writes: >Perhaps it's just me, but I don't see much value to preserving the >timestamp of the creation date of the original version of a file when >you don't actually have the original file-- just the modified version. >Can you provide a real-world example of why you'd care about that >timestamp? Easily; quite often I try to figure out which version of a file or a program is the oldest and the created time stamp is very handy in those situations. I admit that this is often a problem when I move files around nad/or have the "same" file on several places: my hard disk at work, my file server at work, a floppy on the way home or my hard disk at home; but there are other instances. When I have a small utility program that doesn't have proper version information and I am to determine which of two versions is the oldest. I see no reason not to have a created time stamp. I have cursed the unix file system more than once for not having such a time stamp. >Maybe. Currently, many systems keep track of busy files by maintaining >state in the kernel, and various locking mechanisms like lockf(), >flock(), etc exist. These provide semantics for doing things like >shared and exclusive locks, or for locking sections of files instead of >locking the entire thing. Well, maybee there are solutions for this in the unix world, but then I must have stumbled on the bad implementations of them. An easy example is the mailtool in OpenWindows. It's not working as desired. I don't say that a simple flag would do the trick in a multi user environment (I think we need something more sophisticated here and maybee that system should be layered on top of the file system), but I believe it would be a step in the right direction. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 01:05:18 -0800 Organization: Cygnus Solutions Message-ID: <qdafp913g1.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> John 'kzin' Rudd <jrudd@cygnus.com> writes: > It may seem pendantic to point out the difference between "creator" and > what you're talking about, but it is semantically different. The > creator of a file is the creator of the file no matter whether you like > to use that application or not. If "creator" is going to be recorded, > then it really is an attribute of the file itself, and should somehow be > stored with it. Which begs the question to a die-hard Unix user like myself, if you add the notion of a `preferred application', what use is the `creator' designation other than bookkeeping? As a fallback to a known good application? Ditto on the various discussions on adding the `time created' field to augment the last modified and other time codes stored with the file. For me, once I start caring about the time the file was first created, I start caring about all the changes that were made, which seems to scream `revision control system' to me. (And if you copy a file from somewhere else, should it inherit the source file's created time?) Maybe I'm just not seeing it. Can someone help enlighten me? > However, each user should have the option to substitute some other app, > in case they don't want to use the actual applications creator.. and > that list of preferences would probably be best called "Prefered > applications" or something.. which would read something like: > > I prefer Painter for Photoshop apps. > Which would probably be mapped like "Photoshop.app -> Painter.app", > and thus when you launched a file created by Photoshop, it would > bring up Painter. :-} Ick. I really don't like this on an application basis. One person may normally look at JPEGs under Netscape, whereas I have some neat image utility like OmniImage that I use. That doesn't mean I want to set up OmniImage as a replacement for Netscape in all circumstances. -- 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: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 12 Feb 1997 23:58:01 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <33029F59.5E8D@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Siracusa wrote: > > Jonathan W. Hendry (jon@subsequent.com) wrote: > : John Siracusa wrote: > : > I'd say the registry is a hack to make up for an inane filesystem > : > that doesn't allow putting the information contained in the > : > registry in the files themselves, where it would make more sense. > > : It doesn't make sense when files and applications can be used > : by multiple users. > > I don't see how that is. File type and creator information doesn't > vary from user to user. Sure it does. If I use Photoshop to edit a tiff, it'll get a Photoshop creator code, correct? If my coworker Bob prefers to work in Painter, he won't be able to double-click files that I've opened and have them open in Painter. After he saves them, I won't be able to open them in Photoshop by double-clicking. This is a pain. Yes, you can open by drag n drop, and yes you can open from the open panel. But, consider the situation where I want to open several files at once from the Finder. Bob's edited some of them. I select the files, and open them all at once. Photoshop is opened, as is Painter. Potentially, there could be as many creator codes as there are files, and I could end up with half a dozen applications running, just by opening files in the finder. This is a pain. If I prefer to edit tiffs in Painter, that should be the application that is used when I double-click. I should only be forced to use other methods in the exceptional case - when I want to use the other application. In the typical case, I should not have to go out of my way. Under *no circumstances*, should *I* be forced to take extra steps because of *someone else's* application usage preferences. An operating system which makes me do this is broken. I'm not crazy about the idea of creator codes, but if they must be there, each user has to have their own. Let the user decide which apps to use, not their coworkers. > If you're talking about the type of thing > that is stored in preference files on the Mac, then the logical > solution is to have separate preference folders for each user. > This doesn't really apply since, abilities aside, Rhaposdy will > be targeted as a single-user system from what I have read. I've read nothing of the sort. If Rhapsody is single-user, it'll never make much headway in the enterprise. A Windows95 class single-user operating system won't do. It certainly won't be any kind of draw for corporate customers. Apple will get laughed off Nasdaq if they try that. Apple needs an NT-class product, and they know that. Crippling it as a Win95-style singleuser OS makes little sense. It would gain Apple nothing. It would simply be an extension of the status quo - the 1980's model of computing. Not exactly something to be proud of. There really is no compelling reason to sell a single user system these days. Multiuser systems aren't exactly difficult to use. Hell, AOL is a multiuser system, and non-technical people don't seem to have any real trouble using *it*. Username/password isn't beyond anyone's comprehension, and would probably seem downright sensible to most people these days. Multiuser OS's offer advantages that even dimwit consumers could understand. Privacy. Virus resistance. Better user-specific configuration. Etc. -- jon@steeldriving.com
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 00:20:24 -0500 Organization: phenix@interpath.com Message-ID: <199702130020245167110@roxboro-185.interpath.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <slrn5fr5kf.93c.droleary@alpha.temporal.org> <32FE72F6.4C96@subsequent.com> <5dm74q$906@News.Dal.Ca> John Christie <jc@or.psychology.dal.ca> wrote: ] Jonathan W. Hendry (jon@subsequent.com) wrote: ] : Doc O'Leary wrote: ] ] : But what if you want to name two files the same? It's not uncommon ] : for me to have two files in the same directory with the same name ] : but different extensions. For instance, splash.riff and splash.bmp. ] ] Those aren't the same name. Why would one ever want to use ] EXACTLY the same name for two files on purpose. I hope no one ever ] comes up with a file system that allows that. I'd hate to have to ] follow some of the programmers I've seen in a project on such a file ] system. As you say it's a silly argument and just BEGS the question of what do you do "if you want to name two files the same" including the extension? -- John Moreno
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 01:01:19 GMT Organization: Cygnus Solutions Message-ID: <5dtp4v$aqt$1@majipoor.cygnus.com> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> <5dtclf$35p$1@majipoor.cygnus.com> <33025B19.42A1@subsequent.com> Cc: jon@subsequent.com In <33025B19.42A1@subsequent.com> "Jonathan W. Hendry" wrote: > John Rudd wrote: > > A Gui "Make an FTP volume" tool could easiliy be created.. > > It's already there: > > File->Compress > er.. Duh.. I knew that. :-) -- 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.
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Message-ID: <2938717302@hoult.actrix.gen.nz> From: Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Thu, 13 Feb 1997 22:21:42 +1300 References: <5dtd3v$pc2@csugrad.cs.vt.edu> nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: > In article <1997Feb12.173429.29584@llyene.jpl.nasa.gov>, urban@cobra.jpl.nasa.gov (Michael P Urban) wrote: > > > Out-of-band data associated with files (Finder information, resource > > fork, and perhaps other things) could be added in a general way to > > a Unix file system; for all I know, the NeXT folk may already have > > done this. It would certainly be a more general solution than the > > traditional Unix reliance on "magic numbers" and similar hackery. > > What NeXT needs to do is ressurect its object-oriented database > filesystem project. Allows for the association of arbitrary attributes > with files, or so I assume from what I remember hearing about it. It might pay to look at the work done for the OS/2 file system. Each file has the ability to have out-of-band "extended attributes" (I think that's what they call them) of arbitrary number and size. It's all rather like a Mac resource fork, but I think a bit more general. -- Bruce -- ...in 1996, software marketers wore out a record 31,296 copies of Roget's Thesaurus searching for synonyms to the word "coffee" ...
From: anch@logiball.de (Andreas Christiani) Newsgroups: comp.sys.next.programmer Subject: Re: Openstep and multithreads Date: 12 Feb 1997 12:54:49 GMT Organization: Knipp Medien und Kommunikation, Dortmund, Germany Message-ID: <5dseip$jo2$2@news.knipp.de> References: <330009F0.367@okstate.edu> Bill Keller <kellerw@okstate.edu> wrote: >I'm trying to find some source examples of multithreaded code for >Openstep. Or, more specifically, of using NSPort to communicate between >threads. I've scoured next-ftp.peak.org, and there's just not much >there for openstep yet. Any pointers or examples would be very helpful. > >Thanks! > >Bill Keller (kellerw@okstate.edu) From the docs of NSPort : "An NSPort represents a communication channel to or from another NSPort, which typically resides in different thread or task. The distributed objects system uses NSPort objects to send NSPortMessages back and forth. You should implement interapplication communication using distributed objects whenever possible, and use NSPorts only when necessary." Is it necessary ? If not, using DO is very simple and it's documented quite good. There's also an example in /NextDeveloper/Examples/Foundation/MultiThreadedDO. Bye, A.C. --- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ LogiBall gGmbH * Innovationszentrum Herne * Westring 303 * 44629 Herne Andreas Christiani * christiani@logiball.de * http://www.logiball.de Tel.: 02323 / 925 577 * Fax : 02323 / 925 551 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: John 'kzin' Rudd <jrudd@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 06:28:11 -0800 Organization: Cygnus Solutions Inc. Message-ID: <330324FB.E67@cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonathan W. Hendry wrote: > > John Siracusa wrote: > > > > Jonathan W. Hendry (jon@subsequent.com) wrote: > > : John Siracusa wrote: > > : > I'd say the registry is a hack to make up for an inane filesystem > > : > that doesn't allow putting the information contained in the > > : > registry in the files themselves, where it would make more sense. > > > > : It doesn't make sense when files and applications can be used > > : by multiple users. > > > > I don't see how that is. File type and creator information doesn't > > vary from user to user. > > Sure it does. If I use Photoshop to edit a tiff, it'll > get a Photoshop creator code, correct? If my coworker > Bob prefers to work in Painter, he won't be able to > double-click files that I've opened and have them open > in Painter. After he saves them, I won't be able to > open them in Photoshop by double-clicking. > > This is a pain. Yes, you can open by drag n drop, > and yes you can open from the open panel. > except that what you're talking about is NOT "creator" information. It's more appropriately called "prefered application" or something like that. If the app somehow tracks the creator and file type (via any of the suggested mechanisms), it's trivial for the GUI to look at the creator, check to see if you have a "if app A is the creator, launch app B instead" entry in some preferences, and launch that instead. Or, have to GUI launch an app you have associated with the file type instead of an app you have substituted for the creator. However, in either case, storing and associating the document creator with/with-in the file itself has absolutely no affect on multiuser environments. It may seem pendantic to point out the difference between "creator" and what you're talking about, but it is semantically different. The creator of a file is the creator of the file no matter whether you like to use that application or not. If "creator" is going to be recorded, then it really is an attribute of the file itself, and should somehow be stored with it. However, each user should have the option to substitute some other app, in case they don't want to use the actual applications creator.. and that list of preferences would probably be best called "Prefered applications" or something.. which would read something like: I prefer Painter for Photoshop apps. Which would probably be mapped like "Photoshop.app -> Painter.app", and thus when you launched a file created by Photoshop, it would bring up Painter. :-}
From: uli@zoodle.robin.de (Ulrich Grepel) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 12 Feb 1997 22:29:06 GMT Organization: meow!!! (private site) Message-ID: <5dtg7i$29a@zoodle.robin.de> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> In-Reply-To: <33011DDB.4B1A@acm.org> On 02/12/97, Ian Joyner wrote: >There has been an interesting discussion going on in comp.lang.eiffel >which is relevant to why Apple should do much better in its efforts >than just Unix. The basic problem with Unix and many other OSs is >they do not notify the user of resource problems, such as disk full, >file not found, memory short, etc, they just kill the program straight >away. This leads to many applications having superfluous code to >handle these exception conditions. This is very common code which >really should be in the OS. Ok. Let's see how OPENSTEP handles these: - disk full: back in the days when I still had a small hard disk in my NeXTstation was the last time I had this particular problem. And behold, the system *did* inform me when the disk space began running short. Something like a message box saying "Alert, only 5 Megabytes left on device" or somesuch. Perfectly ok, except for the fact that I was in severe need of disk space back then ;-) - memory short: under normal circumstances this only happens if you run out of disk (i.e. swap) space. So it's the same as above. (Remember, we've got virtual memory in a swap file residing in the normal file system, the swap file grows (and sometimes - only sometimes though :-/ - also shrinks with usage, therefore out of memory ~= out of disk space) the non-normal circumstances would be an application (or the OS itself) that uses up all available virtual address space. That's at least close to two Gigabytes of virtual memory, allocated but - mostly - unused, per single task. I've had such a situation once with OmniWeb, showing up in the process status list as using the incredible amount of 1.99 Gigabytes of virtual memory. I checked this out when OmniWeb wasn't working properly and my disk began working hard. By the way: the rest of the system still worked perfectly, including quite good response times. Maybe (anyone in the know?) OmniWeb was doing some process-local garbage collection, for after about 20 minutes of swapping it continued to work normally. (This happened after several hours of watching pictures on the net with OmniWeb, and the swapfile was "just" about 100-200 MB, plus 96MB of real RAM.) - file not found: There's just no way to open a nonexistant file. You - obviously - can't doubleclick on it, or drag it to the application, and if you use the open panel, entering a filename that doesn't exist just causes the OK button not to function - you're still in the open panel. Of course you might not be allowed to open a file - and then you'll get the appropriate message. Similar things exist for other variations of file-system-doesn't-want-to- let-you-do-what-you-just-wanted-to-do situations. As - I hope - in any other user interface, even the so unpopular unix CLI based stuff. Generally, as described above, some of the functionality (disk-is-going-to-be-full-soon, open panel etc.) indeed *is* in the OS level. That is, at least in some shared library noone needs to take care of programming. Other stuff just can't be realized by the operating system except by telling the application (which may very well be a command line utility here) that something went wrong. If it just informs the user, but not the application, the application might do something stupid. Imagine, you want to quit an application. It tells you that there are unsaved files. You say ok, save them. The OS tells *you* (but not the app) that the disk is full, write protected or whatever else. So the app thinks the files are saved and quits. Without saving (to another disk, whatever). Unix doesn't kill applications. Applications kill themselves. Or the user does by manually killing them (GUI based of course). By the way, how do you kill a misbehaving application on MacOS? One that refuses to work? Reboot? Well... [stuff from the eiffel newsgroup deleted] Well, I still don't think this would really be useful. Normally, files needed for a system (be it the OS itself, an application, the network drivers, whatever) should be there. I think it's totally valid for the system to not function if something is ripped apart. It should of course gracefully tell you what's wrong, but it shouldn't basically pause the application until you do indeed find the file somewhere else. That's appropriate behaviour for MVS mainframes with a huge manually operated tape library, where disk storage in earlier times couldn't hold even moderately sized user files. I've never liked this behaviour all that much. In those environments you have long running jobs, needing several tapes mounted one after another. Obviously the system (which in these cases basically also handle the file I/O itself) has to prompt you to mount the next tape. And obviously, it should tell you "wrong tape, use the other one", and obviously you have to be able to respond with either "here it is", or "sorry, the cat ate it, you must die!". But that's a quite different world compared to most desktop/client/server kind of applications running today. And in those - quite rare - cases where it's still appropriate (an archive or backup tool using more than one tape or disk) this will better be handled by the application itself. But the application might be the OS itself as well, spitting out the current disk and prompting you to insert the one called "stupidlabel" if your application accesses the file "/stupidlabel/afile.txt" just after "/firstdisk/anotherfile.txt". This does work. Today. GUI-based. Even if you select the files from a shell window. Bye, Uli
From: uli@zoodle.robin.de (Ulrich Grepel) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 12 Feb 1997 22:45:47 GMT Organization: meow!!! (private site) Message-ID: <5dth6r$2c3@zoodle.robin.de> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> In-Reply-To: <0n0OxoO00iWp023GQ0@andrew.cmu.edu> On 02/12/97, Charles William Swiger wrote: >Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & >Unix: You're.. by Ian Joyner@acm.org >> This leads to many applications having superfluous code to >> handle these exception conditions. This is very common code which >> really should be in the OS. > >Above you complain that the OS 'just kill[s] the program straight away' >when certain error conditions occur, and now you suggest that the OS >should handle those error conditions instead of the application! These >two statements are mutually contradictory. > >How should the OS handle these exceptional conditions? Are you saying >the OS should do the same thing to every process when those errors >occur, instead of passing the error condition to the process and letting >the process decide for itself what should be done? Yes, exactly. The rest is more Re: Ian Joyner's posting If you've got a situation where an operator is able to provide the right tape containing the wanted file, then this is not really an error condition at all. It's just the operating system stalling the application and checking whether the user can do something to help. I don't know anything about Unisys systems, but I do know a bit about MVS and VSE. Basically, if you cannot provide the tape needed by your batch programs, most of the times the only useful option is to kill the job. Manually. Most JCLs or batch programs I've seen do not provide appropriate error checking. Imagine an MVS or VSE job for sending an email. The jcl tries to locate the equivalent of a .signature file. You don't have one, and don't want to create one. Now what could the OS do? Ask the user for the file? Well... I don't want a .signature file. Kill the job? Well... a .sig is not vitally important for an email message. Tell the application? See, that's what most OSes do in such circumstances. And don't tell me that having the following code is better than the code following the following code: --------8<-------- if (file-is-accessible) read-file else message("file not found") -------->8-------- read-file if (error) message("file not found") --------8<-------- Actually, the opposite is true. In the first example (which is what you - or rather the eiffel guys - wanted to use) no care is taken of the fact that between checking the accessability of the file and the file access itself there's nothing happening to the file - in another thread or process, on another CPU or even computer (making it "another process" - namely the NFS daemon or equivalent). So the first code example would even have to look like --------8<-------- lock-file if (file-is-accessible) read-file else message("file not found") unlock-file -------->8-------- And that doesn't include the possibility of lock/unlock going wrong. >> (I think we should all run down to our Unisys A Series shop to >> learn how a real operating system works, they have been doing >> this for decades, and application development and system operations >> is far simpler). >> ------------------------------------------------------------------------ >> 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 >> ------------------------------------------------------------------------ > >Does anyone besides me detect a common bias between the last paragraph >and the .signature? ;-) Well, seems like it should be "...we have been doing..." A colleague of mine also calls all non-mainframe operating systems "Nintendo systems". And I don't think app development and system operations is much easier on old style mainframe systems. At least not if you want to provide the same comfort for the user. Most modern systems cope *without* a system operator. They *only* have a user. That includes PCs, Macs and even NeXT boxes. It might include quite a few other Unix boxes as well. But administrating a mainframe is a full time job. Most of the times for more than one person. Bye, Uli
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 13 Feb 1997 07:55:46 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5duhe2$49a$1@brachio.zrz.TU-Berlin.DE> References: <0n0OxoO00iWp023GQ0@andrew.cmu.edu> In article <0n0OxoO00iWp023GQ0@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> writes: [...] > Above you complain that the OS 'just kill[s] the program straight away' > when certain error conditions occur, and now you suggest that the OS > should handle those error conditions instead of the application! These > two statements are mutually contradictory. > > How should the OS handle these exceptional conditions? Are you saying > the OS should do the same thing to every process when those errors > occur, instead of passing the error condition to the process and letting > the process decide for itself what should be done? Well, the OS should open an on-line connection to the nearest computer retailer, order more DRAM and put the process to sleep until the memory has been made availabel. :-) Marcel
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 13 Feb 1997 07:19:47 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <cn0kPX200iWp02=5g0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> In-Reply-To: <33026799.D07@acm.org> Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >> Under NEXTSTEP, when you start running low on disk space, the Workspace >> will pop-up an alert panel warning you that disk space is low. When you >> run critically low on space, you'll get another warning suggesting >> rebooting in order to free up space by shrinking the swapfile. > > Rebooting!!! That's what I said, yes. In general, this only happens when someone's system was very low on disk space to start with. If you make sure that you've got 100 MB free where you swap to, you're not going to have problems. >> Under any Unix, when a processes tries to open() a file, it can receive >> any of about a dozen errors, including EACCESS (file not found, or bad >> permissions). There are not fatal errors, and the OS does _not_ kill >> the process when they occur. It's up to the process to implement >> appropriate error handling upon receiving these errors. > > And this is wrong. An OS should handle many more of these common errors. Handle how? Specificly what should the OS do when open() fails instead of returning EACCESS? >> As for "memory short" condition, what precisely does this mean under an >> OS which provides a good virtual memory implementation? Normally, there >> are two problems which can occur: running low on disk space because of >> swapfile size, or excessive paging due to a lack of physical memory. >> >> The former condition will cause malloc() to return NULL and set ENOMEM >> (again, the OS does _not_ kill the process, and it's up to the process >> to detect and respond to such a condition appropriately). [ ... ] > > But in this case I expect the OS to alert the user to decide to close > down certain processes. This decision is beyond the operating system > to make, and it is certainly far beyond the scope of an application > program. So what is the application program going to do because a > malloc has failed due to environmental factors beyond its control? I assume you're just talking about the first case, where malloc() fails. Polite applications warn the user that they couldn't get the memory they needed, and they abort the operation being attempted, and return to their main event loop. Furthermore, under NEXTSTEP, running out of swapspace (which is what causes malloc() to fail) will usually cause the WorkSpace to provide a "disk space low" warning, as I described above. What else do you want the OS to do? >> Above you complain that the OS 'just kill[s] the program straight away' >> when certain error conditions occur, and now you suggest that the OS >> should handle those error conditions instead of the application! These >> two statements are mutually contradictory. > > How are they contradictory? I'm saying: don't kill my program, and don't > hand me an exception before the OS has a good attempt at handling it > itself. Killing the process is bad, agreed (although if you're deadlocked, you've basicly got no good alternatives)-- it's a poor general solution to an exceptional condition. In general, the OS shouldn't do anything when confronting an exception that's not appropriate for all processes. The OS should report exceptions and let the process decide what should be done, instead of having the OS spend time and resources attempting to handle the exception itself. You've acknowledged that the OS should not perform inappropriate actions when encountering an exception since you gave the specific example of killing processes, but you don't appear to realize that your suggestions that the OS perform some other action beyond reporting the exceptional condition means that the OS will do things which are inappropriate for some tasks-- thus, the contradiction. >> How should the OS handle these exceptional conditions? Are you saying >> the OS should do the same thing to every process when those errors >> occur, instead of passing the error condition to the process and letting >> the process decide for itself what should be done? > > Yes, because many of these things are so common. Why clutter > applications just to make up for deficiencies in the OS? You're dodging the question. It's remarkably easy to claim that the OS is deficient, but it's much harder to define alternative behavior that the OS should perform that's generally useful for all processes. >> [ ... ] >>> (I think we should all run down to our Unisys A Series shop to >>> learn how a real operating system works, they have been doing >>> this for decades, and application development and system operations >>> is far simpler). >>> ------------------------------------------------------------------------ >>> 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 >>> ------------------------------------------------------------------------ >> >> Does anyone besides me detect a common bias between the last paragraph >> and the .signature? > > Not at all, I am giving a concrete example of where what I am talking > about is put into practice, with significant simplification in > systems operations, and substantially reduced applications development > effort. If I was really biased, I would not share these observations > with Apple, would I? The two aaren't mutually exclusive by any means. Right now, we've got someone from Unisys who is extolling the virtues of Unisys as "a real OS", and slamming other operating systems as "technically deficient". If you could substantiate the claims you've made, I'll happily withdraw my claim of bias. However, so far I've seen absolutely nothing of the sort-- you've made claims that the OS should provide error handling for conditions which I consider to be better handled within the applications. > If Apple wants to adopt NeXT and Mach, then it had better be fully > aware of the technical deficiencies of Unix, or Apple will lose its > edge of superiority. What "technical deficiencies" are you talking about, and precisely what "edge of superiority" did Apple and MacOS have over the NEXTSTEP (which is a Unix) operating system? In case you've forgotten, the reason Apple purchased NeXT was to remedy the technical deficiencies of the MacOS because Apple tried and failed to create their own replacement OS (q.v. Copland and Taligent). -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: "Howard E. Hinant" <heh@beamtech.com> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: [ANN] Making The Ultimate Development Platform Date: Thu, 13 Feb 1997 09:44:20 -0500 Organization: Beam Technologies, Inc. Message-ID: <330328BB.68C3@beamtech.com> References: <MWRon-1202971508360001@aumi5-a04.ccm.tds.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This sounds great. For me, the key point was stated, but perhaps not emphasized enough: "So when they write for Rhapsody, their applications can run on Mac OS, Wintel and UNIX boxes too." This is absolutely critical; Including the gui, the networking, and the multi-threading. (else we'll all be forced into java, gag!). -Howard MW Ron wrote: > > HI, > > Just thought I'd point out that there is an interview in Apples online > magazine Focus with Greg Galanos on the future plans of Metrowerks titled > Making The Ultimate Development Platform > > http://www2.apple.com/home/thirddecade/
From: Ian Russell Ollmann <iano@scripps.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 12 Feb 1997 19:05:28 -0800 Organization: The Scripps Research Institute, La Jolla, CA Message-ID: <Pine.SGI.3.95.970212185806.11623C-100000@wong> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> <32FAD8FA.2C40@subsequent.com> <3301F37A.4B3@ix.netcom.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: Gary Zhang <gzhang@ix.netcom.com> In-Reply-To: <3301F37A.4B3@ix.netcom.com> On Wed, 12 Feb 1997, Gary Zhang wrote: > IMHO which file system to choose really is not that important -- that > is, from a user's perspective. Ideally users (programmers being the > exception) should be shielded from the underlying file system. Having > the users to deal with file system directly is a major design flaw in > all the OSs to date (execuse me if I'm wrong on this one). Why should a > user be concerned with saving a file, creating a directory, and managing > folders? If computers are really smart they should do all these for the > user automatically. Ever tried to teach your mom to use a word > processor? It all goes fine until you ask her to SAVE the file? No > matter what you try she is not going to understand why you need to do > this. The point -- information storage should be automatic and > information retrieval should be intellegent. Right now the computer > behaves like a dumb warehouse where YOU have to do the cleanning and > organizing, while ideally it should be a SMART assistant who takes care > tedious works for you -- "computer, here is my memo, don't lose it!" or > "computer, I want to continue working on the unfinished article I > started yesterday!" THAT's what a computer should do! ... I think Apple > has a chance to create a really greate new OS. While trying to maintain > compatibility, they should also build something revolutionary. An > integrated, INTELLEGENT document management system should be one of > those to consider... Just my 2 cents. I think this is generally a good idea, but what of those documents that exist so dimly in your memory that you can't decribe them in sufficient detail for a computer (or another person for that matter) to find. In these cases, you'd have to fall back on some sort of visual file system cue, so it would always have to be there in some form. Also, if you use your computer a lot, you can start to build up thousands of files. It might be difficult to communicate to your computer the fine points of difference between (for example) your Netscape bookmarks html and the backup of it that you made last week or the week before, or which of sixteen saved games for DOOMII level 30 that you wish to play. Ian Ollmann
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 12 Feb 1997 16:57:09 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g3tcv.qak.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> On 11 Feb 1997 19:38:20 GMT, John Siracusa <macintsh@bu.edu> wrote: >Raul Sobon (a.sobon@pharmacology.unimelb.edu.au) wrote: >: John Siracusa wrote: >: And ohh how wonderfull the Win95/NT solution of registry is... its NOT >: TEXT, >: but its binary.. and only regedit can edit it.. and IF IT GETS CURRUPTED >: as it often >: gets.. BOOM YOUR WIN95 is dead!!! and NOTHING but a clean install will >: fix it. > >: How great non text config files work...NOT! > >I'd say the registry is a hack to make up for an inane filesystem >that doesn't allow putting the information contained in the >registry in the files themselves, where it would make more sense. Just in case you folks really think the registry is a bizarre mechanism, it's also (kind of) used in AIX; Most of the apps and h/w configuration is maintained in a registry that is edited by smit (I _still_ think "smut" was a better name, for "System Management UTility"; It's really just a curses-based front end to a sh*tload of executables...). While a centralized registry/repository makes _some_ sense, it really should've been embedded within the filesystem - especially since the i-node table is *itself* a registry of file objects within each filesystem (namespace is at a different level). I've already thrown in some ideas for such an enhancement on the "regular" Unix filesystems to support additional forks; I'm not sure how useful anybody who does this stuff for a living will find it. It's not like this is voodoo; It's not that it can't be done in a portable fashion; It's not that it can't be done simply; It's merely a lack of will to *get* it done. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 07:30:06 GMT Organization: Lund University Message-ID: <peterm.855819006@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <slrn45g122e.o78.campbejr@phu989.um.us.sbphrd.com> campbejr@phu989.mms.sbphrd.com (John R. Campbell) writes: > An inode contains the timestamps of creation, modification > and access, permissions and an array of block numbers where Correction; there is no time stamp that says when the file is created (a *major* bummer in my opinion). There are three time stamps that tell you when a file was last: 1. modified (content) 2. mode changed (file attributes) 3. accessed -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: anch@logiball.de (Andreas Christiani) Newsgroups: comp.sys.next.programmer,comp.sys.next.software Subject: Re: Arbitary precision arithmetic? Date: 10 Feb 1997 10:02:24 GMT Organization: Knipp Medien und Kommunikation, Dortmund, Germany Message-ID: <5dmrng$5i5$1@news.knipp.de> References: <1997Feb9.120321.1665@prim.demon.co.uk> Dave Griffiths <dave@prim.demon.co.uk> wrote: >Hi, does anyone know of a simple maths library that will let you do >arbitary precision integer arithmetic from C/Obj-C on NeXTStep? I found >something called "pari" but it has a Sun3 assembler file that doesn't >compile. > >Thanks, > >Dave > Take a look at GNU MP (abbreviated gmp). A.C. --- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ LogiBall gGmbH * Innovationszentrum Herne * Westring 303 * 44629 Herne Andreas Christiani * christiani@logiball.de * http://www.logiball.de Tel.: 02323 / 925 577 * Fax : 02323 / 925 551 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: dirk@object-factory.com (Dirk Olmes) Newsgroups: comp.sys.next.programmer Subject: Re: PrintForDebugger ??? Date: 10 Feb 1997 09:48:21 GMT Organization: Object Factory GmbH (Germany) Message-ID: <5dmqt5$2nn@leonie.object-factory.com> References: <01bc154a$53c4c960$8279bdce@Pilot.rnt.com> "Christopher Erker" <cerker@rnt.com> wrote: > I have a few question about PrintForDebugger. All of my 3rd party books > and manuals (for Next 3.3, and OpenStep 4.1) hardly mention this method, > but it looks really cool! > > 1) Is it only used through GDB? > 2) If so, then can I use it through Openstep? > > 3) Could someone post a short example on it's use. Hi, it's even more simple: AFAIK the debugger tries to invoke the -description method of any object you try to po. So if you implement this method the debugger should be able to po yor custom object. hope it helps, -dirk --- ______________________________________________________________________ Dirk Olmes OBJECT FACTORY Gesellschaft fuer Informatik und Datenverarbeitung mbH Otto-Hahn Str. 18, 44227 Dortmund, Germany Telephon +49 (0) 231 975 137 0 Telefax +49 (0) 231 975 137 99 dirk@object-factory.com http://www.object-factory.com/ Hiroshima 45, Tschernobyl 86, Windows 95
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 09:16:12 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb13091612@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <1997Feb12.173429.29584@llyene.jpl.nasa.gov> In-reply-to: urban@cobra.jpl.nasa.gov's message of Wed, 12 Feb 1997 17:34:29 GMT In article <1997Feb12.173429.29584@llyene.jpl.nasa.gov>, urban@cobra.jpl.nasa.gov (Michael P Urban) writes: Creation time information will be necessary for Mac programs, Why? and would doubtless be helpful in some configuration management. Again, why? When would you want to do something to "all files created between such and such a date" as opposed to "all files modified between such and such a date"? Keep in mind that "modified" includes "replaced entirely" as a subset. If it was _really_ important that you get only files created in a certain timespan, you could easily end up with files that actually were created much later. Out-of-band data associated with files (Finder information, resource fork, and perhaps other things) could be added in a general way to a Unix file system; for all I know, the NeXT folk may already have done this. It would certainly be a more general solution than the traditional Unix reliance on "magic numbers" and similar hackery. (two forks are theoretically sufficient; the second fork can point to another file with two forks, in a linked-list sort of way if multiple forks are desired). Absolutely _not_. Beyond any gripes you're going to see from introducing some new type of links into the filesystem (yet another thing to cause hard-to-trace bugs in the filesystem code), if you're talking just theory, one fork and the ability to nest directories is sufficient. Just pretend that the directory is a linked list of nodes, there you go. Your choices really should be one fork or an undefined number of forks (directories give you the entire range, from zero to arbitrarily high). Why should Finder be a priviledged process in this context? _I_ want to be able to store out-of-band crap with my files, too! Everyone needs to keep in mind that under any future NeXTSTEP+MacOS operating system, Finder will be Just Another Executable. Yes, it will be _an_ application launcher - but it won't be _the_ executable launcher, if you see what I mean. Specifically, decisions like "who gets to open this file" need to be moved into a completely configurable user-land database of some sort, both because not all programs and files care (and thus shouldn't have to pay the toll), and because once you put something like this in the kernel, you are stuck with it _forever_. Transparent on-the-fly format upgrades are completely appropriate for applications, but completely _inappropriate_ for the kernel. [One starts to wonder if Copland and Taligent fell by the wayside because someone involved (management?) didn't understand the meaning of the word _kernel_, and the reasoning behind microkernels. "Don't forget the kernel level Tetris clone." For various reasons, you want as little as possible in the kernel, including things that might otherwise be very useful, but are just too complex. The kernel is _not_ an area where we want people trying out their pet theories - well, I don't want _you_ trying out _your_ pet theories on _my_ kernel.] [Hell, why not go with a real microkernel, put a BSD FFS filesystem server on it, and then layer an all-the-forks-you-want filesystem server on top of _that_? Then you can also layer the forked filesystem server over your NFS filesystem server. Stuff that in your pipe and smoke it :-).] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 09:53:13 GMT Organization: Lund University Message-ID: <peterm.855827593@ulfrun> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: >vary from user to user. If you're talking about the type of thing >that is stored in preference files on the Mac, then the logical >solution is to have separate preference folders for each user. Yes, definetley. >This doesn't really apply since, abilities aside, Rhaposdy will >be targeted as a single-user system from what I have read. Let's hope not! The lack of a true user concept is one of the major lacks of the Mac OS. By the time Rhapsody really ships, every other computer worth the name will have some sort of user concept. I do hope Apple will not be the last to get onto that ship. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 04:35:42 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <3302E06E.8D@subsequent.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John 'kzin' Rudd wrote: > > Jonathan W. Hendry wrote: > > Sure it does. If I use Photoshop to edit a tiff, it'll > > get a Photoshop creator code, correct? If my coworker > > Bob prefers to work in Painter, he won't be able to > > double-click files that I've opened and have them open > > in Painter. After he saves them, I won't be able to > > open them in Photoshop by double-clicking. > > > > This is a pain. Yes, you can open by drag n drop, > > and yes you can open from the open panel. > > > > except that what you're talking about is NOT "creator" information. > It's more appropriately called "prefered application" or something like > that. If the app somehow tracks the creator and file type (via any of > the suggested mechanisms), it's trivial for the GUI to look at the > creator, check to see if you have a "if app A is the creator, launch app > B instead" entry in some preferences, and launch that instead. Or, have > to GUI launch an app you have associated with the file type instead of > an app you have substituted for the creator. The Mac only uses the creator code which is what I'm bitching about. > However, in either case, storing and associating the document creator > with/with-in the file itself has absolutely no affect on multiuser > environments. If you only use an in-file creator code to determine the application, as the Mac does, then it does have an effect on multiuser environments. The way the Mac uses the creator code - to determine what app to use to open a file - is inherently poor for a multiuser environment. > It may seem pendantic to point out the difference between "creator" and > what you're talking about, but it is semantically different. The > creator of a file is the creator of the file no matter whether you like > to use that application or not. If "creator" is going to be recorded, > then it really is an attribute of the file itself, and should somehow be > stored with it. Okay. My beef is with the Macintosh's usage of the creator code, not the existence of one. > However, each user should have the option to substitute some other app, > in case they don't want to use the actual applications creator.. and > that list of preferences would probably be best called "Prefered > applications" or something.. which would read something like: > > I prefer Painter for Photoshop apps. Photoshop documents, you mean? > Which would probably be mapped like "Photoshop.app -> Painter.app", > and thus when you launched a file created by Photoshop, it would > bring up Painter. :-} The problem with this arrangement is that it creates a potentially large set of mappings, especially when you get into mapping to both creator and type. It seems more useful to just map types, and not creators. -- jon@steeldriving.com x x x x x
From: anch@logiball.de (Andreas Christiani) Newsgroups: comp.sys.next.programmer Subject: Re: problem with filter services Date: 12 Feb 1997 12:11:36 GMT Organization: Knipp Medien und Kommunikation, Dortmund, Germany Message-ID: <5dsc1o$jo2$1@news.knipp.de> References: <5dji83$g1q@nef.ens.fr> jalon@drakkar.ens.fr (Julien Jalon) wrote: >I have OmniImageFilter installed and my program outputs all the >pasteboard types I want ("image format gif/bmp/...") > >./test foo.tiff "NeXT TIFF v4.0 pasteboard type" foo2.tiff >(not very useful : translate tiff to tiff :-) >gives me a good result : (here data is not NULL) > >but if I try : >./test foo.tiff "image format gif" foo.gif >it detects that "image format gif" is a good type but >data is always NULL... > >why ? >(in fact the only working types are "NeXT TIFF v4.0 pasteboard type" >and "NXTypedFilenamePboardType:tiff" which do not require any filter >services) > >It seems that Pasteboard know the services but doesn't want to use it ! IMHO the OmniImageFilters are only input-filters. That means you can only translate the given types to NeXT-TIFF format. Read the README in OmniImagFilter.service. By the way : writing gif is only allowed by permission of COMPUSERVE :-) If you're only searching for converting tool, give me note and I tell you which you can use. Bye, A.C. --- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ LogiBall gGmbH * Innovationszentrum Herne * Westring 303 * 44629 Herne Andreas Christiani * christiani@logiball.de * http://www.logiball.de Tel.: 02323 / 925 577 * Fax : 02323 / 925 551 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
From: JYoungman@vggas.com (James Youngman) Newsgroups: comp.dcom.fax,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.ms-windows.programmer.misc,comp.os.os2.programmer.misc,comp.sys.mac.programmer.misc,comp.sys.next.programmer Subject: Re: Want partner(s) in multi-platform FAX related programming project Date: 13 Feb 1997 10:39:03 GMT Organization: VG Gas Analysis Systems Message-ID: <5dur07$eou@halon.vggas.com> References: <slrn5g2i68.dhm.linus@oracle.planet.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=US-ASCII In article <slrn5g2i68.dhm.linus@oracle.planet.com>, linus@idirect.com says... >Now a bit about the project itself ... > >A document transmission/reception system, also capable of routing faxes over the Internet, including support for SSL (using SSLeay, ftp://ft You mean, something a bit like HylaFAX? -- James Youngman VG Gas Analysis Systems |The trouble with the rat-race Before sending advertising material, read |is, even if you win, you're http://www.law.cornell.edu/uscode/47/227.html|still a rat.
From: schack@eldar.arc.ab.ca (Brian Schack) Newsgroups: comp.sys.next.programmer Subject: Referencing externs from loaded bundle on OpenStep/NT - how? Date: 13 Feb 1997 09:48:16 -0700 Organization: Alberta Research Council, Calgary Alberta, Canada Sender: schack@eldar.arc.ab.ca Message-ID: <vbd8u4mz3j.fsf@eldar.arc.ab.ca> We have an application consisting of a main program, and several bundles which are loaded at run time using [NSBundle initWithPath:]. The bundles reference several global variables in the main program. We've compiled and run the code successfully on NeXT hardware, Solaris OpenStep, and plain old gcc on a Sun. However, we cannot get it to work under OpenStep/NT - the main program and the bundle end up looking at two entirely different bits of memory. Here's a quick synopsis of the code: ---- main program ---- int global = 42; int main() { ... NSBundle* b = [[NSBundle alloc] initWithPath:@"test.bundle"]; Class bClass = [b principalClass]; [[bClass alloc] init]; ... } ---- bundle ---- extern int global; @implementation test - init { ... printf("global = %d\n", global); ... } ... @end -------- When run, it prints out something like: global = 3487248 definitely not the right answer. OPENSTEP 4.1 Release Notes (Entry Number 2473, Reference 72308) talks about exporting symbols from Frameworks (I think - it isn't very clear), but not how to import symbols into bundles. OPENSTEP/NT Developer FAQ (Entry Number 2462) also talks about exporting symbols from frameworks, but once again not how to import symbols into bundles. I've trying prefacing the 'extern int global' with a __declspec(dllimport), and the 'int global = 42' with a __declspec(dllexport), and various other combinations, all with no luck. Has anybody experienced this problem and know how to deal with it? Thanks, Brian -- ---------------------------------------------------------------------------- Brian Schack |mailto:schack@arc.ab.ca | "I don't want to achieve Alberta Research Council |http://www.arc.ab.ca | immortality through my 6815 8th St NE | | work ... I want to achieve Calgary, Alberta |ph: (403) 297-7564 | it through not dying." Canada T2E 7H7 |fax: (403) 297-2339 | - Woody Allen ----------------------------------------------------------------------------
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 10:04:47 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb13100447@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <slrn45g3tcv.qak.campbejr@phu989.um.us.sbphrd.com> In-reply-to: campbejr@phu989.mms.sbphrd.com's message of 12 Feb 1997 16:57:09 GMT In article <slrn45g3tcv.qak.campbejr@phu989.um.us.sbphrd.com>, campbejr@phu989.mms.sbphrd.com (John R. Campbell) writes: On 11 Feb 1997 19:38:20 GMT, John Siracusa <macintsh@bu.edu> wrote: >I'd say the registry is a hack to make up for an inane filesystem >that doesn't allow putting the information contained in the >registry in the files themselves, where it would make more sense. While a centralized registry/repository makes _some_ sense, it really should've been embedded within the filesystem - especially since the i-node table is *itself* a registry of file objects within each filesystem (namespace is at a different level). I'm not so certain about that. Documents are not the be-all and end-all of a GUI environment! NeXTSTEP uses two "registries", NetInfo and the defaults database. NetInfo is more of a system level registry, used for things like usernames and NFS info. defaults is an entirely user-level database, used to store things like where you want windows to appear and how you want applications to work. Some stuff is perfectly good to store with the document. For instance, where the document's windows were on the screen last time you closed it. Other stuff is not appropriate, such as where you want to store your template documents, or what document was open when you quit the application. You _can't_ store some of that stuff in an app-specific area on a multi-user system (say, the app's resource fork or forks). Either the app would have to manage multiple users (unlikely to happen, in practice), or every user would trounce every other user's preferences. Besides the obvious security hole of allowing write access to apps. On a NeXTSTEP network, you generally install apps read-only, and the apps store their preferences information in the defaults database, which is a per-user thing, with the magic handled by the system's libraries. [John, you probably knew all that - I just wanted to make the point that a registry is not necessarily something that can be replaced by information stored with files in the filesystem.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 12 Feb 1997 17:13:36 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g3ubq.qak.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <0myB5iy00iWY461F04@andrew.cmu.edu> <slrn45fhqei.ji4.campbejr@phu989.um.us.sbphrd.com> <anti_email_spam-1202970504590001@uas-du-01-03.jun.alaska.edu> On Wed, 12 Feb 1997 05:04:59 -0900, M <anti_email_spam@real.address.in.sig> wrote: >soup@jtan.com (John R. Campbell) wrote: > >> So the Mac handles things oddly, and, because there is no >> CLI available it cannot do any task that hasn't been pre- >> programmed. Unix (and, to a lesser extent, MS-DOG) can use >> small programs in a "pipeline" to handle extremely complex >> tasks. > >I take it you've never heard of AppleScript or Frontier. . . :) > >No, It's not the same as unix pipes, but it can act as the glue between >apps to do pipe-like operations. Plus, it can have control over GUI based >apps in ways that I've never seen on any other system. Sure, but remember that you're tying together high-level (GUI driving) utility programs. What I'm referring to are the "low level" CLI-based programs you find in Unix. And herein lies the rub: Unix is based upon the idea that each utility should do one (simple) thing *well* (there are obvious exceptions like awk) and encourage the user to construct a pipeline (by providing simple tools to do so) that will combine these operations into a final form. Mac applications (and utilities) are dependant upon user supervision via the GUI to perform their tasks and embed all the necessary functionality within their code to perform all possible tasks. A Mac is a primarily interactive device, requiring (normally) close human supervision of each application to perform their tasks. While there is nothing stopping a Unix kernel from underlying the MacOS, the lack of a CLI would mean that the "regular" Unix utility tree would be rendered irrelevant. Of course, if the "extended information" is embedded as a header to each file, most of the text-oriented utilities would be rendered useless anyway. So my argument isn't MacOS utility programs, it's using the "standard" Unix command set. Yes, I know that "standard Unix" is oxymoronic; I've been around. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: geordie@chapman.com (Geordie Korper) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 11:49:08 -0600 Organization: Chapman and Cutler Message-ID: <geordie-ya02408000R1302971149080001@kyrie> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <qdafp913g1.fsf@blues.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <qdafp913g1.fsf@blues.cygnus.com>, Stephen Peters <speters@cygnus.com> wrote: :Ditto on the various discussions on adding the `time created' field to :augment the last modified and other time codes stored with the file. :For me, once I start caring about the time the file was first created, :I start caring about all the changes that were made, which seems to :scream `revision control system' to me. (And if you copy a file from :somewhere else, should it inherit the source file's created time?) : :Maybe I'm just not seeing it. Can someone help enlighten me? It actually become very useful in a filesystem that is not accessed using hierarchial metaphors. Since I have ten thousand files on my drive some of which could be located in one of several places it is convenient to be able to search based upon when I made the file as well as name and file type and in the worst cases contents. -- Geordie Korper geordie@chapman.com ********************************************************************* * The text above should in no way be construed to represent the * * opinions of my employer, even if specifically stated to do so. * *********************************************************************
From: shaffer@durer.phyast.pitt.edu (C. David Shaffer) Newsgroups: comp.sys.next.programmer Subject: Re: templates Date: 13 Feb 1997 14:57:12 GMT Organization: University of Pittsburgh Message-ID: <SHAFFER.97Feb13095712@durer.phyast.pitt.edu> References: <970211105633.198AAFgS.wayne@pareto> <5dqm0o$c1a@news.orst.edu> <SHAFFER.97Feb12112844@durer.phyast.pitt.edu> <E5IEu3.2s8@flop.schwaben.de> In-reply-to: hhoff@schwaben.de.NOSPAM's message of Wed, 12 Feb 1997 21:39:39 GMT Hmm, transcript from my session included below. Compiled and ran just fine. Maybe a different version of libg++? ernie> cat test.cc #include <stream.h> #include <String.h> #include <SLList.h> typedef SLList<String> StringList; main(){ StringList listOfnames; listOfnames.append("hello world"); cout <<listOfnames.remove_front() << "\n"; } ernie> cc++ -o test test.cc -lg++ ernie> ./test hello world ernie> -- David Shaffer Department of Physics Wayne State College Wayne, NE 68787 shaffer@phyast.pitt.edu
From: msoori@genetics.bio-rad.com (msoori) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 13 Feb 1997 18:03:50 GMT Organization: Bio-Rad Laboratories Message-ID: <msoori-1302971003500001@ms.genetics.bio-rad.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> In article <33026799.D07@acm.org>, i.joyner@acm.org wrote: > > Under any Unix, when a processes tries to open() a file, it can receive > > any of about a dozen errors, including EACCESS (file not found, or bad > > permissions). There are not fatal errors, and the OS does _not_ kill > > the process when they occur. It's up to the process to implement > > appropriate error handling upon receiving these errors. > > And this is wrong. An OS should handle many more of these common errors. How should the OS know what the application intended to do with the file? What if the application implemeted a sort of virtual mem scheme or an application preferences file that the user has no idea about, and if the OS cant find/create it it should asks the user to find it??? This is application domain not the OS. What you say makes sense for some files that the user is aware of, but in genereal the OS dosent know what a file's intended purpose is. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Mahesh P. Sooriarachchi. ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ Work: msoori@genetics.bio-rad.com | ~ ~ Home: mahesh@value.net | This space for rent! ~ ~ Home Page: http://value.net/~mahesh/ | ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 08:52:41 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb13085241@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> In-reply-to: "Jonathan W. Hendry"'s message of Thu, 13 Feb 1997 04:35:42 -0500 In article <3302E06E.8D@subsequent.com>, "Jonathan W. Hendry" <jon@subsequent.com> writes: Okay. My beef is with the Macintosh's usage of the creator code, not the existence of one. OK, then, I'll beef. If some bit of information is not really necessary, then it shouldn't be added to the filesystem. If the creator code is just a nice little bit of trivia which follows a file around, but isn't necessary to figure out who to open the file with, then who cares? If it's in the information the filesystem maintains, then it's a drag on _every_ file, _every_ access, _every_ program. Put another way, if we must have it, rather than a creator code like "DRAW", I'd rather have something like "NeXT Draw demo program, version 3.14". Even better if it's got fields for creating user, date, hostname, etc, etc. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 97 09:46:15 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb13094615@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> In-reply-to: peterm@dna.lth.se's message of 13 Feb 97 09:11:28 GMT In article <peterm.855825088@ulfrun>, peterm@dna.lth.se (Peter Moller) writes: Charles William Swiger <cs4w+@andrew.cmu.edu> writes: >Perhaps it's just me, but I don't see much value to preserving the >timestamp of the creation date of the original version of a file >when you don't actually have the original file-- just the modified >version. Can you provide a real-world example of why you'd care >about that timestamp? Easily; quite often I try to figure out which version of a file or a program is the oldest and the created time stamp is very handy in those situations. I admit that this is often a problem when I move files around nad/or have the "same" file on several places: my hard disk at work, my file server at work, a floppy on the way home or my hard disk at home; but there are other instances. When I have a small utility program that doesn't have proper version information and I am to determine which of two versions is the oldest. I see no reason not to have a created time stamp. I have cursed the unix file system more than once for not having such a time stamp. But a created timestamp doesn't solve the problem you asked to be solved. In the following situation: cp file1 /a/file1 cp file1 /b/file1 edit /a/file1 Which file is created first, /a/file1 or /b/file1? /a/file1. Which file is the most recently modified version? /a/file1. Pretend that /a is actually your machine at work, and /b is actually your machine at home. You look on the proxy for your home machine (a Zip disk, say), and see that the file1 on your work disk was created before the file1 on the Zip disk, and copy the file from the Zip to your work disk, overwriting the edited version. In this case, it's the last-modified timestamp you're looking for. Does anyone have a better example of why a created timestamp is needed? Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer Subject: Re: problem with filter services Date: 13 Feb 1997 12:33:02 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5dv1lu$2rp@nef.ens.fr> References: <5dji83$g1q@nef.ens.fr> <5dsc1o$jo2$1@news.knipp.de> In article <5dsc1o$jo2$1@news.knipp.de>, Andreas Christiani <anch@logiball.de> wrote: >IMHO the OmniImageFilters are only input-filters. That means you can only >translate the given types to NeXT-TIFF format. Read the README in >OmniImagFilter.service. No, OmniImageFilter are also TIFF->other formats filters (it's in the README and in the OmniImageFilter.service/services file) My code works fine if I include it in an app structure. The solution is just to include : [Application new] at the begining of my source ant it works fine. here is my source : (it's not finished but it works) --- genericfilter.m #import <appkit/Application.h> #import <appkit/Pasteboard.h> void main(int argc, char *argv[]) { id myPb; const NXAtom *list; NXStream *stream; const char *selectedType; char *data; int length; if(argc!=4) { printf("Usage: %s FILE NEWFORMAT OUTFILE\n",argv[0]); exit(0); } [Application new]; myPb=[Pasteboard newByFilteringFile:argv[1]]; list=[myPb types]; if(!list) { printf("No filter available\n"); [myPb free]; [NXApp free]; exit(0); } printf("available types :\n"); while(*list) { printf("%s\n",*list); if(!strcmp(argv[2],*list)) { selectedType=*list; } list++; } if(!selectedType) { printf("%s is not a goot type\n",argv[2]); [myPb free]; [NXApp free]; exit(0); } printf("selected type : \"%s\"\n",selectedType); printf("opening stream...\n"); stream=[myPb readTypeToStream:selectedType]; if(!stream) { printf("nothing read on stream\n"); [myPb free]; [NXApp free]; exit(0); } printf("writing to \"%s\"\n",argv[3]); if(NXSaveToFile(stream,argv[3])) { printf("unable to save to \"%s\"\n",argv[3]); exit(0); } NXCloseMemory(stream,NX_FREEBUFFER); [myPb free]; [NXApp free]; exit(0); } --- >By the way : writing gif is only allowed by permission of COMPUSERVE :-) writing ? I thought the problem was to produce source code which writes/read gifs... my program doesn't, it's the OmniImageFilter which does ! >If you're only searching for converting tool, give me note and I tell you >which you can use. I know almost all the converting tool. My idea was to produce a "generic converter" using all the facilities of NS. I can do : ./genericfilter foo.tiff "image format gif" foo.gif ./genericfilter foo.gif "image format bmp" foo.bmp ./genericfilter foo.pic "NeXT TIFF v4.0 pasteboard type" foo.tiff and also : ./genericfilter foo.rtf "NeXT plain ascii pasteboard type" foo.txt and whatever you want if the proper filter is installed ! --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 13 Feb 1997 16:29:38 GMT Organization: Netcom Distribution: world Message-ID: <5dvfhi$s0i@sjx-ixn2.ix.netcom.com> References: <5cq1m5$6vs@elna.ethz.ch> <5dt3ja$nc3@news.NeXT.COM> MaRK_BeSSeY@NeXT.CoM (Mark Bessey) wrote: > If you set the DYLD_FRAMEWORK_PATH environment variable, any programs that > you load will attempt to find the frameworks they depend on in those > directories first. This allows you to easily test a new version of a > framework, while keeping the old version installed in it's usual place. How can DYLD_FRAMEWORK_PATH be used when launching an app from Workspace? Because Workspace isn't a shell subprocess, there doesn't seem to be an easy way to set DYLD_FRAMEWORK_PATH for Workspace-launched apps. I understand how to use DYLD_FRAMEWORK_PATH from gdb or when launching an app from a shell. But the dyld man page doesn't state that these restrictions apply. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 OPENSTEP/NT Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Bill Keller <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 00:49:48 -0600 Organization: Oklahoma State University, Stillwater OK Message-ID: <3302B98C.4590@okstate.edu> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Rudd wrote: [big snip!] > Even though the other day I thought the inode was the best place to add this, > thinking about it more (thinking about what I wrote at the time more, even), > I think a wrapper is the best way to handle this. A wrapper which is > recognized, not by name, but by containing an identifying resource (like a > file ".wrapper"). The .wrapper file can contain any meta information you > need (perhaps in pairs like "creator = photoshop", "creator_version = x.y", > "file_type = tiff", "file_type_version = a.b", etc). > Amen! Thats the best approach I've seen yet on this thread. If you've used Openstep (I've just used the NT version), it uses something called property lists. In fact, there is even a Foundation class to handle this (NSPPL). You can store any info within these lists. The system can store whatever it wants within the .plist files, and use that info at runtime. Ultimately, the current Mac community doesn't care about the mechanics of how the information is retrieved, they just want to click on the file and go. If you can implement that functionality without screwing up the filesystem, that's the route you need to go. I read that Apple is not going to use Mach 3.0 for just this reason. They want to stick with something they know works, rather than waste alot of time to implement something that might not. -- Bill Keller (kellerw@okstate.edu) ---------------------------------
From: Bill Keller <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 00:56:52 -0600 Organization: Oklahoma State University, Stillwater OK Message-ID: <3302BB34.34EB@okstate.edu> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <Pine.A32.3.93.970212141241.58886B-100000@navajo.gate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Beeman wrote: > Yup, sounds good to me, although I'm not an expert. It does lead me to > two questions that maybe you can answer: > > 1. Instead of a nice single file with everything in it (executables, > icons, tutorial, notes, etc) you now have a collection of files, some of > which are invisible. Take Disinfectant 3.6, for example. You copy one > file, its all there. If you use the .wrapper extra file, doesn't this all > get lost if you FTP the file from somewhere else? I suppose you could > come up with something like MacBinary to handle these invisible "support" > files, but its still somewhat ugly, and you could end up with files > missing icons, etc. Wouldn't it be better to embed this info into the > first bytes of the file itself? I think this is how OpenDoc embeds > creators, etc, and wouldn't using the OpenDoc methods be a better idea > anyway? It certainly would give you the same "one file holds everything" > that is so convenient. Sorry about jumping into the middle of this thread, but under Nextstep, you can declare a directory (a wrapper), to not even appear to be a directory. If I have Photoshop.app, it acts, in every respect, as a file. Its not. Its a directory of files. If I want to copy or move this, I click on the icon, and drag it where it's supposed to go. And all the files get moved together. -- Bill Keller (kellerw@okstate.edu) ---------------------------------
From: Alan Olson <alan@caucasus.eecs.umich.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 12:21:19 -0500 Organization: University of Michigan EECS Dept., Ann Arbor, MI Message-ID: <y9lybcs62r4.fsf@caucasus.eecs.umich.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> "Jonathan W. Hendry" <jon@subsequent.com> writes: > [deletions...] > Sure it does. If I use Photoshop to edit a tiff, it'll > get a Photoshop creator code, correct? If my coworker > Bob prefers to work in Painter, he won't be able to > double-click files that I've opened and have them open > in Painter. After he saves them, I won't be able to > open them in Photoshop by double-clicking. This is not a problem with multiple users, this is a problem with using multiple applications to edit the same file. A single individual would encounter this problem if he prefered the Photoshop tools for some of his work and the Painter tools for the rest. [more deletions...] > > This is a pain. If I prefer to edit tiffs in Painter, that > should be the application that is used when I double-click. > I should only be forced to use other methods in the > exceptional case - when I want to use the other application. > In the typical case, I should not have to go out of my way. > > Under *no circumstances*, should *I* be forced to take extra > steps because of *someone else's* application usage preferences. > An operating system which makes me do this is broken. Sounds like you want file type to determine which application to open. That's a valid way of doing things, and in some ways its better than using creator codes. On a Mac the problem is there is no standardization of type codes (as far as I know). You can't tell the format/contents of a file just by looking at the type. There are a few types which are widely recognized (e.g., TEXT), but I don't think Apple has issued directives saying that files of type XXXX must have such and such a format. I should also point out that using creator codes is not entirely bad. It works fine for many (most?) people who create a file with a particular program, and always use the same program when editing the file. It is also good when you want to use several programs to work with files of a particular type. For example, you often edit JPEG files with Photoshop, you also want to look at JPEG files you download from the net. Photoshop isn't a particularly good or efficient JPEG viewer, you'd rather use JPEGView instead. If you only look at fiie type you are forced to make a choice. With creator codes you can set the appropriate creator for each so that the desired application is launched. Having universally recognized types would be nice, and I hope Apple considers doing this. One solution would be to let people choose between a type-centric or a creator-centric system (i.e., a user preference). A more sophisticated system which used both type and creator information would be better: e.g., lauch Photoshop for all JPEG files unless the creator is DNLD in which case launch JPEGView. Implementing a usable interface for such a system is left as an exercise for the reader. Alan Olson alan@eecs.umich.edu
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 18:47:16 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g6o7e.qq8.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5dh51p$9hn@news.bu.edu> <5dtlu3$93o$1@majipoor.cygnus.com> On 13 Feb 1997 00:06:27 GMT, John Rudd <jrudd@cygnus.com> wrote: >In <slrn45g154u.o78.campbejr@phu989.um.us.sbphrd.com> John R. Campbell wrote: >> >> Let's assume a mangled Unix-like filesystem that allows for out-of- >> band information to be stored in a special block w/i the inode. >> Under normal circumstances this block won't be allocated on the >> disk unless an application needs it, so the overhead isn't too >> terrible. In order to get at the information we'd either need >> to extend the stat() and fstat() calls or just do I/O to the block >> via ioctl() (normally used for out-of-band management of devices). >> <snip> > >First, before I say this, I want to say I think it would be MUCH better to go >with the wrapper solution.. in the same way Mach-o is an improvement over a >HFS solution (N forks vs 2 forks), and Wrappers are an improvement over >Mach-o (N forks + heirarchy vs N forks) for executables, I think the same >will be true for wrappers as data files. Entertaining thought, but just that... My main thrust in all of this is to address the ability to use "regular" Unix utilities *in addition* to the MacOS programs. I envision that the first 512bytes block of a file (or 1K, if this is the filesystem's internal granularity) become a hidden "resource fork" to retain fork information. In effect, the file will have an lseek() offset automagically added by the filesystem unless a fcntl() flag (to be allocated?) is set, allowing read/write access to the "hidden" region. The Unix "cp" program would need to perform the fcntl() on both source and destination files to ensure a full copy is performed. This guarantees that the "resource fork" travels with the file. Granted, other parts of the system will need to know about this offset (like the exec() syscall) but this isn't that major a deal (consider how easily this can be done). If we don't provide this mode for all files we will need to add a 1bit flag to indicate whether the offset exists or not. This is actually a fallback to the "header" issue; It's just that the header isn't available to any programs but those that have a "need to know". This allows awk/grep/sed/vi/emacs to look at the contents of a file and not end up sucking in or destroying the header. Of course, cp, tar, cpio and perhaps dd will need to be privy to this region so that the backup is complete. Remember, even directories will have these headers. >However, I went and looked at the Inode structures to see if there is an >unused field that can be used for storing creator information (storing type >information isn't something I think you can do in the current inode.. you >could store an integer that referenced a list of types, but then you can only >have files be of a "blessed" type to take advantage of that.. that's too >limiting, in my opinion -- so you'd probably need to stick with keeping the >file type information in the file name). Are you talking Linux's ext2 or Mach-o? I've not been delving w/i the i-node structure of ext2 (or the others). Mind you, using an index is bogus; You might as well use /etc/magic for such signatures. >There are 4 "reserved for future use" long's in the inode structure >(inode.i_ic.ic_spare[4]) which could be used to store a) a device (a short), >and b) an inode (a u_long) for the creator's location, and c) the time_t >(long) of the file's last access by that creator at that inode. You'd >probably also want to use the spare c time (inode.i_ic.ic_ctspare) for the >"create time" of any arbitrary file. Actually, we could (if we're gonna keep it out of the regular block list) add a block number (which will require fsck to be aware of). Mind you, this adds extra complications. There are several utility programs that will need to be updated for this new filesystem. Additionally, why are you thinking that the i-node can't be changed? We're not expecting to support an existing filesystem (I guess this would become "ext3" or "cfufs" for Linux). >Then, when you access the file to find its creator, you a) check the create >time of your file, find the device and inode of its creator and see if the >file at THAT inode was created more recently than item C above. If the >creator inode is more recent, then the creator file is no longer valid (it >was destroyed since you last accessed this file from that creator). >Otherwise, that file is the creator. Sure, you can do that, but it doesn't help if the creating utility is in another filesystem or across a network. There's just too much information required. A "transparent" header make *just* enough sense (though there'd be quite a bit of debate over what the internals of this header will look like). >There are some limits here... in file transfer via things like ftp and such, >you WILL lose this data. It is non-portable to non-Rhapsody machines (it can >be stored there via NFS, but the other machine wont use it, and it may get >corrupted by the other machine(s), esp if they use this "reserved for future >use" field for something else). However it doesn't create a seperate pool of >information (the "pointer to a block" method would also be lost.. in >transfer, btw), it doesn't have things spread across multipe files even at >the lowest file level. It's just a simple "here's my creator" tag. Well, you lose this information via FTP anyway, so there's no real reason to allow FTP access to this transparent header (though it can be argued that a new flag could be added, but why bother?). NFS isn't really popular for Macs anyway, though a "MacFS" port for an enhanced MacNFS can be argued as sensible. In a "normal" NFS server running Unix these transparent headers won't be seen (remember you need to fcntl() a special flag to turn off the lseek() offset logic) unless enhancements are put in place. Also, since (IIRC) fcntl() *is* supported by NFS, we can find a way to use this. The idea isn't to make a MacOS environment a "perfect match" but to allow the Unix utilities to be used on the same files. >It's also a bit of a hack.. not very elegant nor extensible. But it would >probably work. I just don't think we want to be implimenting these things >via hacks. I think the transparent header isn't that much of a hack; It's awkward in some ways but opens up the opportunity to add more functionality to the filesystem, even for Unix. The truly great debate will center on what kind (and format) of information is placed in this "transparent" header. If this technique is really useful it is likely to find it's way into other filesystems; But it must first be seen as a truly useful enabling technology for Unix. It's something of a pity that I spent more time dealing with various device drivers rather than the filesystem code. I'll have to see what kind of cheat I can put together for Linux so I can try this out... -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: rang@trillium.adaptec.com (Anton Rang) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 11:29:26 -0600 Organization: Trillium Research, an Adaptec company Message-ID: <rang-1302971129260001@margaret.trillium.adaptec.com> References: <5ddp66$jpc@news.bu.edu> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <1997Feb12.173429.29584@llyene.jpl.nasa.gov> <SHESS.97Feb13091612@howard.one.net> In article <SHESS.97Feb13091612@howard.one.net>, shess@one.net (Scott Hess) wrote: > In article <1997Feb12.173429.29584@llyene.jpl.nasa.gov>, > urban@cobra.jpl.nasa.gov (Michael P Urban) writes: > Creation time information will be necessary for Mac programs, > > Why? Because they already have access to it, so it has to be there to preserve backwards compatibility. (Does anyone use it? Probably; but it doesn't matter.) > and would doubtless be helpful in some configuration management. > > Again, why? When would you want to do something to "all files created > between such and such a date" as opposed to "all files modified > between such and such a date"? "Let me find all of the files which were placed on my disk when I installed CyberDog and its plug-ins. I want to copy them over to my new 20GB hard disk." Or, "I know I wrote the first draft of that article in September or October, and updated it last week...let me find all the files on the server like that." Just because you can't think of a reason to do it doesn't mean there aren't valid ones. (Conversely, just because there are valid reasons to do it doesn't mean it has to be possible.) > Keep in mind that "modified" includes "replaced entirely" as a subset. Well, it depends on what you mean by "replaced entirely"...the entire contents or the entire file? > [One starts to wonder if Copland and Taligent fell by the wayside > because someone involved (management?) didn't understand the meaning > of the word _kernel_, and the reasoning behind microkernels. Have you actually read the Copland microkernel white paper? -- anton
From: schack@eldar.arc.ab.ca (Brian Schack) Newsgroups: comp.sys.next.programmer Subject: Re: Referencing externs from loaded bundle on OpenStep/NT - how? Date: 13 Feb 1997 13:23:46 -0700 Organization: Alberta Research Council, Calgary Alberta, Canada Sender: schack@eldar.arc.ab.ca Message-ID: <vbbu9omp4d.fsf@eldar.arc.ab.ca> References: <vbd8u4mz3j.fsf@eldar.arc.ab.ca> In-reply-to: schack@eldar.arc.ab.ca's message of 13 Feb 1997 09:48:16 -0700 >>>>> "Brian" == Brian Schack <schack@eldar.arc.ab.ca> writes: Brian> We have an application consisting of a main program, and Brian> several bundles which are loaded at run time using Brian> [NSBundle initWithPath:]. The bundles reference several Brian> global variables in the main program. [etc] Well, I've just discovered the answer. The answer is given by NeXT's OPENSTEP/NT Developer FAQ, Entry Number: 2462, under the question: Q: Why do I get a segmentation fault when trying to use a bundle? A: There is a problem with code in a bundle trying to access global variables in the main application. Typically, when the bundle code tries to access the global variable, you will get a segmentation fault. The solution is to put these global symbols into a framework and link both the application and the bundle against the framework. You must also implement additional declarations (given in the next question) to export symbols other than class and category names from your frameworks. That'll teach me for skimming through the docs! It's a shame that it doesn't work the same on NT as it does on other machines though. -- ---------------------------------------------------------------------------- Brian Schack |mailto:schack@arc.ab.ca | "I don't want to achieve Alberta Research Council |http://www.arc.ab.ca | immortality through my 6815 8th St NE | | work ... I want to achieve Calgary, Alberta |ph: (403) 297-7564 | it through not dying." Canada T2E 7H7 |fax: (403) 297-2339 | - Woody Allen ----------------------------------------------------------------------------
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 13 Feb 1997 19:21:10 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45g6q70.qq8.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <5dth6r$2c3@zoodle.robin.de> On 12 Feb 1997 22:45:47 GMT, Ulrich Grepel <uli@zoodle.robin.de> wrote: >On 02/12/97, Charles William Swiger wrote: >>Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & >>Unix: You're.. by Ian Joyner@acm.org >>> This leads to many applications having superfluous code to >>> handle these exception conditions. This is very common code which >>> really should be in the OS. But this is where the signal handlers belong. The operating system is *not* an application, it merely arranges for services. It's really a convenience that is has some way of asynchronously notifying a user process that it's getting seriously overweight; It must fall to the application writer to decide what the best course of action should be (like save temp files and exit, for instance). >>Above you complain that the OS 'just kill[s] the program straight away' >>when certain error conditions occur, and now you suggest that the OS >>should handle those error conditions instead of the application! These >>two statements are mutually contradictory. Yup. Either the application is actually part of the OS or not. If it ain't you've got more power. The OS ain't magic, it ain't Sparky (ObB5ref), so it has little need-to-know about the internals of an application. Remember, a computer may "simulate" certain levels of intelligence (as in expert systems) but it can't provide "judgement". An OS is not a place for an expert system, and how would you imbue it with judgement? >>How should the OS handle these exceptional conditions? Are you saying >>the OS should do the same thing to every process when those errors >>occur, instead of passing the error condition to the process and letting >>the process decide for itself what should be done? But *what* is the "right thing"? In Unix mere notification via a signal is pretty damn sufficient, giving the app the ability to choose a corrective action (and some signals are just there to notify of I/O completion, like SIGIO). >Yes, exactly. The rest is more Re: Ian Joyner's posting Well that's clear. *NOT* >If you've got a situation where an operator is able to provide the right >tape containing the wanted file, then this is not really an error condition at >all. It's just the operating system stalling the application and checking >whether the user can do something to help. > >I don't know anything about Unisys systems, but I do know a bit about MVS and >VSE. Basically, if you cannot provide the tape needed by your batch programs, >most of the times the only useful option is to kill the job. Manually. Most >JCLs or batch programs I've seen do not provide appropriate error checking. >Imagine an MVS or VSE job for sending an email. The jcl tries to locate the >equivalent of a .signature file. You don't have one, and don't want to create >one. Now what could the OS do? Ask the user for the file? Well... I don't want >a .signature file. Kill the job? Well... a .sig is not vitally important for >an email message. Tell the application? See, that's what most OSes do in such >circumstances. On the ol' Exec-8 (now OS-1100, OS-2200 I guess) all batch jobs entered a "Facilities Inventory" phase where all the assigns needed for the first job step are pending. Once these have been satisfied (by disk or tape mounts) the batch job will be released from the backlog. (The last time I dealt w/ Exec-8 it's version was 38R5- almost an eternity, ain't it?) In Unix it depends on the application. An open() call will return an error indicator (and set the errno variable) and it is up to the program to perform corrective action. >And that doesn't include the possibility of lock/unlock going wrong. Lock/Unlock have a tendency to "stall" the user's process until the syscall completes. And let's not get into "advisory" vs. "mandatory" file locking. >>> (I think we should all run down to our Unisys A Series shop to >>> learn how a real operating system works, they have been doing >>> this for decades, and application development and system operations >>> is far simpler). >>Does anyone besides me detect a common bias between the last paragraph >>and the .signature? >Well, seems like it should be "...we have been doing..." > >A colleague of mine also calls all non-mainframe operating systems "Nintendo >systems". Sounds like an odd bias. I've done years with mainframes (DEC-10, Xerox Sigma-9 w/CP-V, UNIVAC 1100s before getting into Unix. Unix is a different conceptual model optimized to provide a wide range of services to an individual user but it isn't really optimized for performance. In a mainframe system application performance (TPS, for instance) is optimized; Additionally, a mainframe provides awesome levels of I/O bandwidth (and I/O connectivity to devices) with it's CPU performance (remember that a mainframe maximizes single thread performance). Such an operating system doesn't really belong at the desktop; It funny that VMS (actually a clone named NT) is _almost_ able to be used there, but VMS has minicomputer (user centrist) roots mixed into it's architecture. Unix is written *around* the user, wrapping him(her) in a wonderfully responsive security blanket. Mainframes barely recognize a user's existence and do their best to provide services but they aren't really personalized. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: mpaque@next.com (Mike Paquette) Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 13 Feb 1997 20:52:42 GMT Organization: NeXT Software, Inc. Distribution: world Message-ID: <5dvuuq$3fs@news.next.com> References: <5dvfhi$s0i@sjx-ixn2.ix.netcom.com> In article <5dvfhi$s0i@sjx-ixn2.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) writes: > How can DYLD_FRAMEWORK_PATH be used when launching an app from > Workspace? Because Workspace isn't a shell subprocess, there doesn't seem to > be an easy way to set DYLD_FRAMEWORK_PATH for Workspace-launched apps. > > I understand how to use DYLD_FRAMEWORK_PATH from gdb or when launching an > app from a shell. But the dyld man page doesn't state that these > restrictions apply. The assorted DYLD environment variables are strictly for debugging purposes. They aren't available to apps running from the Workspace, or when running as the superuser (root) for obvious reasons. -- Mike Paquette I don't speak for my employer, and they don't speak for me. "May you live in interesting times." - Old Chinese curse
From: mtrombin@ix.netcom.com (Mark Trombino) Newsgroups: comp.sys.next.programmer Subject: Where's NSSound in OpenStep? Date: 13 Feb 1997 22:06:10 GMT Organization: Egghead Billy, Inc. Message-ID: <5e038i$s5q@sjx-ixn7.ix.netcom.com> From a casual poking around the OpenStep section of NeXT's on-line documentation archive, I haven't seen any references to the Sound object (or NSSound, I presume, in OpenStep). Has it disappeared? Is someone else maintaining it now? Just Curious, -- Mark Trombino mtrombin@ix.netcom.com (NEXTMail, MIME Mail okay)
From: shess@one.net (Scott Hess) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 13 Feb 97 13:56:26 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb13135626@slave.one.net> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> In-reply-to: shess@one.net's message of 6 Feb 97 14:01:59 In article <SHESS.97Feb6140159@slave.one.net>, shess@one.net (Scott Hess) writes: All of this makes me wonder if someone has been working on a method dispatch facility like those described in Karel Driesen's papers. Haven't had time to do this, but I'll probably try it. David Stes, http://www.can.nl/~stes/, has something out there called the Portable Object Compiler, which is an Objective-C to C preprocessor. I'll probably be experimenting which that, once I have a clearer understanding of what I'm doing ... Meanwhile, David has implemented inline caching for that runtime (v1.1.6 and later, I think). Now each dispatch site has a cache for the message previously sent from that site. Just to see what the difference is for the "hit" case, I wrote a simple program that calls [anObject self] 100 million times. The times were: NeXT runtime, 2.5.8 :29 objcrt 1.1.1 1:33 objcrt 1.1.7 :46 objcrt 1.1.8 :27 direct call to imp :11 The difference between 1.1.1 and 1.1.7 is the addition of the inline caching the dispatched method. The difference between 1.1.7 and 1.1.8 is that 1.1.8 has the inline cache hit literally inlined, not in a function. The last line is for comparison against calling the implementation of the method directly. Note that this is a completely artificial benchmark. It's testing a _single_ method dispatch on a single object with a very simple implementation, repeatedly. Real code is not so easy :-). Specifically, you'll likely have lots of cache misses (the object you're sending the message to can vary by class), and more complicated methods (in a real program, method dispatch should be less than %10 of the execution time). This does bring up a couple points for future testing. Why is NeXT's dispatch so fast? Do they cache the <isa,sel,imp> tuple between calls to objc_msgSend()? [That should be easy enough to ferret out.] [Now, toss in inline methods and an optimizing compiler, and this would take 0:00 execution time :-).] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Referencing externs from loaded bundle on OpenStep/NT - how? Date: 13 Feb 1997 19:37:55 GMT Organization: Netcom Distribution: world Message-ID: <5dvqij$pl9@dfw-ixnews12.ix.netcom.com> References: <vbd8u4mz3j.fsf@eldar.arc.ab.ca> schack@eldar.arc.ab.ca (Brian Schack) wrote: > We have an application consisting of a main program, and several > bundles which are loaded at run time using [NSBundle initWithPath:]. > The bundles reference several global variables in the main program. > OPENSTEP 4.1 Release Notes (Entry Number 2473, Reference 72308) talks > about exporting symbols from Frameworks (I think - it isn't very > clear), but not how to import symbols into bundles. > > OPENSTEP/NT Developer FAQ (Entry Number 2462) also talks about > exporting symbols from frameworks, but once again not how to import > symbols into bundles. > > I've trying prefacing the 'extern int global' with a > __declspec(dllimport), and the 'int global = 42' with a > __declspec(dllexport), and various other combinations, all with no > luck. Has anybody experienced this problem and know how to deal with > it? One approach that works for us is to avoid defining global variables in the main executable if these variables need to be exported to loadable modules (seems like a really lame limitation of the WIN32 linker or whatever is to blame). Instead, we define all exported variables in loadable modules and import them into the main executable or into other loadable modules even when doing so doesn't seem to make sense. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 OPENSTEP/NT Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 19:02:25 GMT Organization: Cygnus Solutions Message-ID: <5dvog1$2bh$4@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> Cc: jon@subsequent.com In <3302E06E.8D@subsequent.com> "Jonathan W. Hendry" wrote: > John 'kzin' Rudd wrote: > Okay. My beef is with the Macintosh's usage of the creator code, > not the existence of one. > Ok.. I agree that the implimentation used by the Mac could cause problems in a multi-user environment. But I dont' think the concept in general would necessarily cause problems. Lets hope this is one of those things they think through well. > > However, each user should have the option to substitute some other app, > > in case they don't want to use the actual applications creator.. and > > that list of preferences would probably be best called "Prefered > > applications" or something.. which would read something like: > > > > I prefer Painter for Photoshop apps. > > Photoshop documents, you mean? > Yeah, sorry :-} > > Which would probably be mapped like "Photoshop.app -> Painter.app", > > and thus when you launched a file created by Photoshop, it would > > bring up Painter. :-} > > The problem with this arrangement is that it creates a potentially > large set of mappings, especially when you get into mapping to > both creator and type. It seems more useful to just map types, > and not creators. I think I mostly agree with you. I care more about what application to use by its type and/or its name (for example, I want my icons, which are tiffs, to open with icon builder. I want all the rest of my tiffs to open with OmniImage.. I could do this by file creator.. or if I name all of my icons name.icon.tiff, I could do it by file name.. But it's impossible to do it by file type alone -- you have to resort to manually dragging to the app or opening the app first). The Mappings could get quite large, but I'm willing to force the computer to take a little more time if it saves me a little more time.. that IS the point of computing, afterall. A preferences setup like: Default to [Creator, Type, Name Extensions] for determining Application to Launch for documents. (perhaps a draggable ordered list, like the preferences choice for languages) for Creator, a list of "created by this application, use this application instead" _or_ a "defer to next heuristic" option ("If it's created by Netscape, defer to the file's type for determining what to do") for Type, like with Nextstep now you have a list of apps that handle that type, and you pick which is the primary choice. And you have an option to defer to another heuristic for a given file type. for name extension, it's exactly like file type (except you're mapping by a different datum). When the GUI or "open" cli program try to find the app to launch for a document, it counts the number of deferals -- if you get 3 deferals, you've got a loop, and a dialogue should show up saying so (perhaps with the icons for the creator, the apps that handle that file type, and the apps that handle that file name extension... so you can just pick to launch one now). That's just my idea :-} yes, it could get large.. but with a good hashing algorythm, it shouldn't take TOO much overhead... and like I said, the point of the computer is to save me time, not the otherway around. -- 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.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 14:19:31 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5dvpg3$kif@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <qdafp913g1.fsf@blues.cygnus.com> In article <qdafp913g1.fsf@blues.cygnus.com>, Stephen Peters <speters@cygnus.com> wrote: > Which begs the question to a die-hard Unix user like myself, if you > add the notion of a `preferred application', what use is the `creator' > designation other than bookkeeping? As a fallback to a known good > application? Because some users (i.e., many Mac users) _like_ opening files by creator, rather than by type. I don't see much of a problem with adding a creator field to the filesystem, other than the fact that remote mounts to non-Rhapsody hosts will likely not be able to see it, or may munge it, as has been pointed out elsewhere in this thread. (Thus, a document-opening scheme based solely on creator fails in a heterogenous networked environment.) However, if there is _also_ a type-based preferred application scheme like NeXT uses, then you can choose to use either scheme, or use the preferred-application scheme in a remote-mount situation in which creator information is not available. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Steve Barnet <"mailer-daemon"@[127.0.0.1]> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 13 Feb 1997 16:31:26 -0600 Organization: UW-Madison Space Science and Engineering Message-ID: <5e04nv$eqt@spool.cs.wisc.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit CC: barnet Ian Joyner wrote: > But in this case I expect the OS to alert the user to decide to close > down certain processes. This decision is beyond the operating system > to make, and it is certainly far beyond the scope of an application > program. Which user? Your assumption will only hold for a desktop system. Furthermore, there's no guarantee there will be a user. What about systems that sit in a closet and sling bytes (we call them servers)? Having a message pop up that says "A program can't get enough memory, which of these 500 processes should die" is not acceptable as 1) No one's at the box 2) who decides what dies? - If any Joe User can go postal because his program has asked for too much memory then we have a completely unacceptable security problem. The sysadmin will not likely be sitting in front of the box - what now? > So what is the application program going to do because a > malloc has failed due to environmental factors beyond its control? > Fail gracefully: log an error message (in a logfile or errorfile) and exit. The alternative you describe assumes (at least) two things: there's a user at the box all the time, the user at the box is able to make an acceptable decision. In multi-user environments those assumptions simply don't hold. Best, ---Steve -- Steve Barnet--System Administrator steve.barnet@ssec.wisc.edu UW-Madison Space Science and Engineering Center I'm not a rocket scientist, but I play one on TV (608)263-2268
From: Bill Keller <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 13 Feb 1997 01:18:33 -0600 Organization: Oklahoma State University, Stillwater OK Message-ID: <3302C049.15C8@okstate.edu> References: <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <5duhe2$49a$1@brachio.zrz.TU-Berlin.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit marcel@sysyem.de wrote: > > In article <0n0OxoO00iWp023GQ0@andrew.cmu.edu> Charles William Swiger > <cs4w+@andrew.cmu.edu> writes: > [...] > > Above you complain that the OS 'just kill[s] the program straight away' > > when certain error conditions occur, and now you suggest that the OS > > should handle those error conditions instead of the application! These > > two statements are mutually contradictory. > > > > How should the OS handle these exceptional conditions? Are you saying > > the OS should do the same thing to every process when those errors > > occur, instead of passing the error condition to the process and letting > > the process decide for itself what should be done? > > Well, the OS should open an on-line connection to the nearest computer > retailer, order more DRAM and put the process to sleep until the memory > has been made availabel. :-) > > Marcel That, coupled with the fact that Apple should write an operating system so that I never have to check return codes (or handle exceptions. yuck!) again. I can just code away, avoid "cluttering up" my application with an error checking at all. "File not found"? No problem, the OS will handle it! "Out of memory"? Why exit gracefully, the OS will handle it! "File is locked by another user"? Who cares, open it anyway! Even if the OS handled errors like that, it would STILL have to inform the application in some manner, that the operation failed. The app would STILL have to have code that responds to the information recieved, and you're STILL in the same position you are right now. -- Bill Keller (kellerw@okstate.edu) ---------------------------------
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 17:24:53 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mn0tGpa00iV3A4W=0F@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> In-Reply-To: <peterm.855825088@ulfrun> Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & Unix: File S.. by Peter Moller@dna.lth.se >> Perhaps it's just me, but I don't see much value to preserving the >> timestamp of the creation date of the original version of a file when >> you don't actually have the original file-- just the modified version. >> Can you provide a real-world example of why you'd care about that >> timestamp? > > Easily; quite often I try to figure out which version of a file or a > program is the oldest and the created time stamp is very handy in those > situations. The last-modified timestamp serves that purpose better than the creation timestamp does. If the file has never been editted, the last-modified timestamp is identical to the creation timestamp. If the file has been changed, the last-modified timestamp will tell you which version is oldest whereas the creation timestamp does not. Try again. > I admit that this is often a problem when I move files around > nad/or have the "same" file on several places: my hard disk at work, my > file server at work, a floppy on the way home or my hard disk at home; but > there are other instances. When I have a small utility program that doesn't > have proper version information and I am to determine which of two versions > is the oldest. Where is the problem? Simply copying, or making links to a file shouldn't change the last-modified timestamp-- just the last-accessed. > I see no reason not to have a created time stamp. I have > cursed the unix file system more than once for not having such a time stamp. Really? I've been using Unix for about a decade, and I've can't ever recall needing the creation timestamp for anything that I wasn't already going to use a RCS for, anyway. >>Maybe. Currently, many systems keep track of busy files by maintaining >>state in the kernel, and various locking mechanisms like lockf(), >>flock(), etc exist. These provide semantics for doing things like >>shared and exclusive locks, or for locking sections of files instead of >>locking the entire thing. > > Well, maybee there are solutions for this in the unix world, but then I must > have stumbled on the bad implementations of them. An easy example is the > mailtool in OpenWindows. It's not working as desired. How so? More information is needed for me to respond.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
Newsgroups: comp.sys.next.programmer From: hhoff@schwaben.de.NOSPAM (Holger Hoffstaette) Subject: Re: templates Sender: news@flop.schwaben.de Organization: NeXT Ghetto People feat. St.Eve Message-ID: <E5K3oy.2EC@flop.schwaben.de> References: <970211105633.198AAFgS.wayne@pareto> <5dqm0o$c1a@news.orst.edu> <SHAFFER.97Feb12112844@durer.phyast.pitt.edu> <E5IEu3.2s8@flop.schwaben.de> <SHAFFER.97Feb13095712@durer.phyast.pitt.edu> Date: Thu, 13 Feb 1997 19:34:10 GMT C. David Shaffer wrote: > Hmm, transcript from my session included below. Compiled and ran just > fine. Maybe a different version of libg++? Hmm.. hhoff>otool -L test test: /usr/lib/libg++.A.dylib (compatibility version 37.0.0, current version 39.0.0) /NextLibrary/Frameworks/System.framework/Versions/A/System (compatibility version 1.0.0, current version 117.13.0) hhoff> This is a 4.1 system upgraded from 3.3pl1, and all the new stuff seems to be in place - PB, gdb & Co. work fine. Anybody with more luck ? Holger
From: jalon@allege.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 13 Feb 1997 21:39:18 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5e01m6$pdq@nef.ens.fr> References: <qdafpcigu6.fsf@blues.cygnus.com> <AF26952B-12BAC3@208.206.178.20> <5dt1v1$j6$2@majipoor.cygnus.com> <3302B98C.4590@okstate.edu> In article <3302B98C.4590@okstate.edu>, Bill Keller <kellerw@okstate.edu> wrote: >I read that Apple is not going to use Mach 3.0 for just this reason. They want to stick with something they >know works, rather than waste alot of time to implement something that might not. ??? Mach 3.0 works !!... and when you see how NS (and Openstep) works, it's. maybe, one of the best choice to do Raphsody ! The real problem is that Mach is a bit "slow". --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: handleym@apple.com (Maynard Handley) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 13 Feb 1997 17:11:51 -0800 Organization: Apple Computer Message-ID: <handleym-1302971711510001@handma.apple.com> References: <5dtd3v$pc2@csugrad.cs.vt.edu> <2938717302@hoult.actrix.gen.nz> In article <2938717302@hoult.actrix.gen.nz>, Bruce@hoult.actrix.gen.nz (Bruce Hoult) wrote: > nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: > > In article <1997Feb12.173429.29584@llyene.jpl.nasa.gov>, urban@cobra.jpl.nasa.gov (Michael P Urban) wrote: > > > > > Out-of-band data associated with files (Finder information, resource > > > fork, and perhaps other things) could be added in a general way to > > > a Unix file system; for all I know, the NeXT folk may already have > > > done this. It would certainly be a more general solution than the > > > traditional Unix reliance on "magic numbers" and similar hackery. > > > > What NeXT needs to do is ressurect its object-oriented database > > filesystem project. Allows for the association of arbitrary attributes > > with files, or so I assume from what I remember hearing about it. > > It might pay to look at the work done for the OS/2 file system. Each file has the ability > to have out-of-band "extended attributes" (I think that's what they call them) of arbitrary > number and size. > > It's all rather like a Mac resource fork, but I think a bit more general. > Finally, Bruce, your restore my faith that there are some people out there looking further than their own noses. Actually, (at least in older versions of HPFS) there are rather strong size constraints on what can go into the extended attributes. However NTFS has unlimited extended attributes which could trivially be used to hold creator/type info, multiple forks etc. The one difference, not at the file system but at the higher layer, is the lack of conventions on the meanings of these attributes and a Resource Manager to deal with resources. Maynard -- My opinion only
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 14 Feb 1997 12:02:00 +1100 Organization: Unisys Message-ID: <3303B988.4E8F@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <msoori-1302971003500001@ms.genetics.bio-rad.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit msoori wrote: > > In article <33026799.D07@acm.org>, i.joyner@acm.org wrote: > > > > Under any Unix, when a processes tries to open() a file, it can receive > > > any of about a dozen errors, including EACCESS (file not found, or bad > > > permissions). There are not fatal errors, and the OS does _not_ kill > > > the process when they occur. It's up to the process to implement > > > appropriate error handling upon receiving these errors. > > > > And this is wrong. An OS should handle many more of these common errors. > > How should the OS know what the application intended to do with the file? > What if the application implemeted a sort of virtual mem scheme or an > application preferences file that the user has no idea about, and if the > OS cant find/create it it should asks the user to find it??? This is > application domain not the OS. What you say makes sense for some files > that the user is aware of, but in genereal the OS dosent know what a > file's intended purpose is. You are correct that there are several different uses for files, which need to be identified. However all uses can be designed into an OS, and a consistent treatment can be designed. For example, there is a different treatment for a file that the application expects to be there, and one that it might optionally create if it is not present. Or a file might be optional, in which case the application might continue happily without it being there, with your preferences example it just uses defaults. Yes the application will code for these cases, but my point is there is a lot more that OSs can and should do. If the file is mandatory, what can the application accomplish? The user or some other process must make the file present. In fact that is one way of synchronising processes. Now before I gave Unisys A Series as a case example of an OS where all these cases have been considered, and a very consistent means of handling such resource problems was implemented over 20 years ago. Unfortunately, I was then accused of bias in a not very polite fashion. ------------------------------------------------------------------------ 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: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 14 Feb 1997 11:32:22 +1100 Organization: Unisys Message-ID: <3303B296.6C6@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@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.programmer: 13-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >> Under NEXTSTEP, when you start running low on disk space, the Workspace > >> will pop-up an alert panel warning you that disk space is low. When you > >> run critically low on space, you'll get another warning suggesting > >> rebooting in order to free up space by shrinking the swapfile. > > > > Rebooting!!! > > That's what I said, yes. In general, this only happens when someone's > system was very low on disk space to start with. If you make sure that > you've got 100 MB free where you swap to, you're not going to have > problems. Well rebooting is an admission of failure in the OS, either by implementation but even worse by design, and in this case it sounds like it's by design. > >> Under any Unix, when a processes tries to open() a file, it can receive > >> any of about a dozen errors, including EACCESS (file not found, or bad > >> permissions). There are not fatal errors, and the OS does _not_ kill > >> the process when they occur. It's up to the process to implement > >> appropriate error handling upon receiving these errors. > > > > And this is wrong. An OS should handle many more of these common errors. > > Handle how? Specificly what should the OS do when open() fails instead > of returning EACCESS? I explained that in my original post... to explain, the OS is responsible for maintaining the environment and resources within which an application runs. If the operating system is not handling such common cases and expecting an application to handle them, it is not providing a very good environment, and so its whole raison d'etre for existence is in question. > >> As for "memory short" condition, what precisely does this mean under an > >> OS which provides a good virtual memory implementation? Normally, there > >> are two problems which can occur: running low on disk space because of > >> swapfile size, or excessive paging due to a lack of physical memory. > >> > >> The former condition will cause malloc() to return NULL and set ENOMEM > >> (again, the OS does _not_ kill the process, and it's up to the process > >> to detect and respond to such a condition appropriately). [ ... ] > > > > But in this case I expect the OS to alert the user to decide to close > > down certain processes. This decision is beyond the operating system > > to make, and it is certainly far beyond the scope of an application > > program. So what is the application program going to do because a > > malloc has failed due to environmental factors beyond its control? > > I assume you're just talking about the first case, where malloc() fails. > Polite applications warn the user that they couldn't get the memory > they needed, and they abort the operation being attempted, and return to > their main event loop. Since this is a case that should be handled by every running task, why burden the application programmer with this task: make it common to the OS. The whole reason for frameworks is to remove this kind of burden from the programmer. However, when you think about it, this should not even be in the frameworks, it should be in the OS. That way, there is a common look and feel guaranteed for all common exceptions. > Furthermore, under NEXTSTEP, running out of swapspace (which is what > causes malloc() to fail) will usually cause the WorkSpace to provide a > "disk space low" warning, as I described above. What else do you want > the OS to do? We're not disagreeing, you're on the right track! It's exactly what should happen, so that the user can change into operator mode and clean up the disk problem. Then the application should continue, quite oblivious to the fact that some problem had occurred. > >> Above you complain that the OS 'just kill[s] the program straight away' > >> when certain error conditions occur, and now you suggest that the OS > >> should handle those error conditions instead of the application! These > >> two statements are mutually contradictory. > > > > How are they contradictory? I'm saying: don't kill my program, and don't > > hand me an exception before the OS has a good attempt at handling it > > itself. > > Killing the process is bad, agreed (although if you're deadlocked, > you've basicly got no good alternatives)-- it's a poor general solution > to an exceptional condition. In general, the OS shouldn't do anything > when confronting an exception that's not appropriate for all processes. > The OS should report exceptions and let the process decide what should > be done, instead of having the OS spend time and resources attempting to > handle the exception itself. So time and resources are spent in the application to handle the exception. This makes no difference there. But it does make a difference that every application programmer must spend time and great expense developing code to handle exceptions because OSs are in general not sufficiently designed. > You've acknowledged that the OS should not perform inappropriate actions > when encountering an exception since you gave the specific example of > killing processes, but you don't appear to realize that your suggestions > that the OS perform some other action beyond reporting the exceptional > condition means that the OS will do things which are inappropriate for > some tasks-- thus, the contradiction. No, you don't make sense here: you are attempting to contrive some contradition. If the OS reports the problem, it is asking the user for some help, without having to bother the application. And the kinds of conditions I am talking about are problems with resources, the exact entity that it is the OSs job to manage. In order to prove your asserted contradiction you would have to show what is inappropriate for the OS to handle in any of the example scenarios I have given. > >> How should the OS handle these exceptional conditions? Are you saying > >> the OS should do the same thing to every process when those errors > >> occur, instead of passing the error condition to the process and letting > >> the process decide for itself what should be done? > > > > Yes, because many of these things are so common. Why clutter > > applications just to make up for deficiencies in the OS? > > You're dodging the question. It's remarkably easy to claim that the OS > is deficient, but it's much harder to define alternative behavior that > the OS should perform that's generally useful for all processes. Um, I think I answered yes... how is that "dodging the question"? I have also defined what the OS should do. What more do you want, apart from an argument and a boring Internet flame war? Please stick to the substance. > >> [ ... ] > >>> (I think we should all run down to our Unisys A Series shop to > >>> learn how a real operating system works, they have been doing > >>> this for decades, and application development and system operations > >>> is far simpler). > >>> ------------------------------------------------------------------------ > >>> 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 > >>> ------------------------------------------------------------------------ > >> > >> Does anyone besides me detect a common bias between the last paragraph > >> and the .signature? > > > > Not at all, I am giving a concrete example of where what I am talking > > about is put into practice, with significant simplification in > > systems operations, and substantially reduced applications development > > effort. If I was really biased, I would not share these observations > > with Apple, would I? > > The two aaren't mutually exclusive by any means. Right now, we've got > someone from Unisys who is extolling the virtues of Unisys as "a real > OS", and slamming other operating systems as "technically deficient". No, take out your emotionally provokative tone like "slamming". I have made some points and given examples, I can't see that who I work for disqualifies me from this. Remember, Unisys is a large Unix vendor as well, so stay off your high horse as your comments are just silly. You are being personal, please keep it to technical points. > If you could substantiate the claims you've made, I'll happily withdraw > my claim of bias. However, so far I've seen absolutely nothing of the > sort-- you've made claims that the OS should provide error handling for > conditions which I consider to be better handled within the applications. > > > If Apple wants to adopt NeXT and Mach, then it had better be fully > > aware of the technical deficiencies of Unix, or Apple will lose its > > edge of superiority. > > What "technical deficiencies" are you talking about, and precisely what > "edge of superiority" did Apple and MacOS have over the NEXTSTEP (which > is a Unix) operating system? Because MacOS made computers useable. There are good things about Nextstep, but you should be careful about inheriting all the problems of Unix. > In case you've forgotten, the reason Apple purchased NeXT was to remedy > the technical deficiencies of the MacOS because Apple tried and failed > to create their own replacement OS (q.v. Copland and Taligent). This is quite reasonable. I think using the Mach Kernel and Openstep environment could be quite good. However, they should assemble the components carefully, and not just accept that Unix is the best thing since sliced bread, because it isn't. ------------------------------------------------------------------------ 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: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 14 Feb 1997 01:25:58 GMT Organization: Boston University Message-ID: <5e0ev6$qje@news.bu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> <qd3ev4i1o8.fsf@blues.cygnus.com> <5dqfig$pm8@news.bu.edu> <qdiv3yhpyj.fsf@blues.cygnus.com> Stephen Peters (speters@cygnus.com) wrote: : macintsh@bu.edu (John Siracusa) writes: : > I know you're saying to yourself: "Well, that's their own fault. : > Don't cripple *my* OS to account for dumb users." Yes, I know it : > sounds pretty totalitarian, but that's kinda the Mac way ;) : Which? Totalitarianism or crippling the OS? :-) Err...historically, a little of both ;) : John, I'd like you to close your eyes and imagine something. Suppose : that someone created a Unix daemon which handled the AppleShare : protocol and implemented an HFS-style system on top of NFS. Creating : an `HFS file' actually made two separate files on the disk, one which : was file.data and one which was, perhaps, file.rsrc. Trying to access : the resource fork of the `HFS file' would pull data from the .rsrc, : and vice versa. You could then mount this Unix disk on your Mac just : as if it was an AppleShare'd Mac file system. Also imagine (as long : as we're dreaming here) that they'd worked out most of the bugs. : Honestly now, would you care that it's a Unix box that just looked : like a Mac? Would you notice? Now imagine that the resource forks : were instead held in a system-specific database that the system : maintained and referenced, but the UI remained the same. Do you care? : Will you notice? If I'm on a Mac mounting a Unix volume full of Mac files which are split up this way (which I do daily at work), no, I don't care. But if it's *my* computer that has all these fragmented files on it's HD, I start to worry. And if there's not just a single .rsrc file associated with each file, but a whole slew of support files, things get hairy. Actually, I think you (and many other NeXT users) have sold me on the concept of app wrappers. Just today I found myself defending them in a discussion with (of all things) a GeoWorks user (GeoWorks uses a Mac-type loadable resource structure combined with system-wide loadable libraries). So I'll concede that .app wrappers may be a perfectly viable solution. The only remaining reservation I have is about the whole process of installing apps and then moving them after they're installed. Is there any possibility of paths getting messed up? : Right there, that's the difference between implementation and : interface. Of course they can be separated, and in real life, too. But my statement that the UI and implementation can't be separated referred more to this concept: no mater what the UI is, if the implementation is such that the UI is not *necessary*, then the majority of users and software vendors will cavalierly ignore it. I'm basing this theory on the DOS, Unix, and Windows practices of requiring or asking users to edit text files themselves in certain situations just because it's easier to ask that than to provide a more GUi-ish way to do it. Perhaps it's more of a cultural issue than a technical one. I'm not sure how common that type of practice is in the NeXT culture. But a Mac user *never* expects to be asked to do anything more than point, click, and drag. And any software package that asks him to do more than this during installation, maintenence, and use will be looked upon as a poor piece of work (smart comment about word processors omitted). To get back to the "totalitarian issue," it's the traditionally heavy-handed Human Interface Guidelines that Apple demands (although they spell it "suggests") you use which have kept Macs ahead of the pack in user friendliness. Because, left to their own devices, software vendors will do what's easiest for them, and force users to train themselves to to "get used to" the hacks they slap together. An example is the very first round of Mac apps from Microsoft which, as Steve Jobs put it, "were *terrible*" (emphasis his). They had to be scolded by Apple and sent back to the workbench several times before they did it "the Mac way." And this happened *with* file formats and conventions that discouraged roaming from the straight path. Speaking of which, I think I'm off-topic at this point. A very similar discussion (file systems, formats, etc.) is going on in the Be Developer's mailing list (along with about 15 other discussions ;) It seems like a hotly debated issue for any emerging OS, Be or Rhapsody. -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 14 Feb 1997 11:44:29 +1100 Organization: Unisys Message-ID: <3303B56D.6AA0@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5du6c1$19c$1@darla.visi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I think I dropped into the wrong thread here. I was not intending to havea Next/Unix vs Mac debate, merely to point out that most OSs should do more than they do in terms of exception handling. David Young wrote: > > In comp.sys.next.programmer Ian Joyner <i.joyner@acm.org> wrote: > : Yes, because many of these things are so common. Why clutter > : applications > : just to make up for deficiencies in the OS? > > "Out of memory" is not something an OS can dictate an action for to an > application. Trust me, when a UNIX box says out of memory, it's tried > absolutely everything it can. Unquestionably, things will degrade, but it is the mode of degradation. At least on Microsoft systems, they give the user the chance to "close applications" when memory is low. That's about all you can do. Unfortunately, most people are used to teaching or development environments where "Out of memory" means a bug in some program. However, in a production environment, either large scale or PC use, out of memory means the machine has been overloaded by the users. Thus the users must clean up. There is nothing much the application can do about it at this stage. > : If Apple wants to adopt NeXT and Mach, then it had better be fully > : aware of the technical deficiencies of Unix, or Apple will lose its > : edge of superiority. > > Are you *insane*? Apple's current OS has the *worst* memory management > architecture of ANY operating system since the advent of the MMU. Period. No, I am not defending MacOS: it has problems. That is not my point. The point is not just to rush into Unix, as Unix also has deficiencies, and these deficiencies are in useability, where Mac has always showed it's strengths. The last thing Mac users want to be is Unix gurus, and to run a healthy Unix system you have to be. This is not just important for home users, but for companies as well who want to save money on their very costly operations (hence the drive to NCs). > Whereas UNIX (and Mach) have one of the best. And Apple should use the good parts of Mach, but not just blindly accept the deficiencies of Unix. ------------------------------------------------------------------------ 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: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 14 Feb 1997 12:21:54 +1100 Organization: Unisys Message-ID: <3303BE32.2D7C@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <5dth6r$2c3@zoodle.robin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ulrich Grepel wrote: > > On 02/12/97, Charles William Swiger wrote: > >Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & > >Unix: You're.. by Ian Joyner@acm.org > >> This leads to many applications having superfluous code to > >> handle these exception conditions. This is very common code which > >> really should be in the OS. > > > >Above you complain that the OS 'just kill[s] the program straight away' > >when certain error conditions occur, and now you suggest that the OS > >should handle those error conditions instead of the application! These > >two statements are mutually contradictory. > > > >How should the OS handle these exceptional conditions? Are you saying > >the OS should do the same thing to every process when those errors > >occur, instead of passing the error condition to the process and letting > >the process decide for itself what should be done? > > Yes, exactly. The rest is more Re: Ian Joyner's posting > > If you've got a situation where an operator is able to provide the right > tape containing the wanted file, then this is not really an error condition at > all. It's just the operating system stalling the application and checking > whether the user can do something to help. > > I don't know anything about Unisys systems, but I do know a bit about MVS and > VSE. Basically, if you cannot provide the tape needed by your batch programs, > most of the times the only useful option is to kill the job. Manually. Most > JCLs or batch programs I've seen do not provide appropriate error checking. > Imagine an MVS or VSE job for sending an email. The jcl tries to locate the > equivalent of a .signature file. You don't have one, and don't want to create > one. Now what could the OS do? Ask the user for the file? Well... I don't want > a .signature file. Kill the job? Well... a .sig is not vitally important for > an email message. Tell the application? See, that's what most OSes do in such > circumstances. > > And don't tell me that having the following code is better than the code > following the following code: > > --------8<-------- > if (file-is-accessible) > read-file > else > message("file not found") > -------->8-------- > read-file > if (error) > message("file not found") > --------8<-------- > > Actually, the opposite is true. In the first example (which is what you - or > rather the eiffel guys - wanted to use) no care is taken of the fact that > between checking the accessability of the file and the file access itself > there's nothing happening to the file - in another thread or process, on > another CPU or even computer (making it "another process" - namely the NFS > daemon or equivalent). So the first code example would even have to look like Considering the mail signature file, surely the code should be if signature_file.present then <read and insert it> end that's it, no file not found messages needed. In the case where the application must have the file, the file loading should be taken care of between the OS and the operator. Let's work it out contractually. The application issues a read on a file that must be read (it's a non-optional file). This contracts the OS to read the file no matter what. If the file is not there (along any of the search paths that the OS knows about), the operator/user must be informed. Since the OS has been contracted to read the file, it should contact the operator "Help I'm having problems fulfilling this contract, what should I do now". Even better still it suggests to the operator several actions: 1) Kill the program (really do raise an exception), 2) make the file present, 3) tell me an alternative file, 4) perhaps change the read status to optional, etc. > A colleague of mine also calls all non-mainframe operating systems "Nintendo > systems". I don't agree, all OSs should be well designed, but unfortunately, many OSs lack features that the mainframe people take for granted, and more than that expect of operating systems. I am saying that more of these features should be implemented in low end machines (and especially Unix!). > And I don't think app development and system operations is much easier on old > style mainframe systems. At least not if you want to provide the same comfort > for the user. Most modern systems cope *without* a system operator. They > *only* have a user. That includes PCs, Macs and even NeXT boxes. It might > include quite a few other Unix boxes as well. But administrating a mainframe > is a full time job. Most of the times for more than one person. Be careful not to characterise things as "old style mainframes" and "modern systems", you have accepted too much of the artificial lines drawn by the marketing types and journalists. As far as I am concerned all these things are converging. I'll probably get accused of bias again, but an A Series takes far less operational support than your average Unix box. Small A Series require no operators at all. Don't judge these systems by what you know about IBM, it just ain't the same. Mainframes are not necessarily big ugly old OSs. But A Series aren't necessarily mainframes, just a well designed OS. ------------------------------------------------------------------------ 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: sef@kithrup.com Newsgroups: comp.sys.next.programmer Subject: cmsg cancel <OWyRNEgG8GA.141@uptgmsnb01> Date: 14 Feb 1997 06:03:12 GMT Control: cancel <OWyRNEgG8GA.141@uptgmsnb01> Message-ID: <cancel.OWyRNEgG8GA.141@uptgmsnb01> Sender: scanning@XXX1324noreply.com (Cyber Services) Spam cancelled by sef@kithrup.com
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 1997 04:56:06 GMT Organization: The Jack Voigt Fan Club Message-ID: <5e0r96$i86$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> In article <SHESS.97Feb13094615@howard.one.net>, Scott Hess <shess@one.net> wrote: \ But a created timestamp doesn't solve the problem you asked to be \ solved. In the following situation: \ cp file1 /a/file1 \ cp file1 /b/file1 \ edit /a/file1 \ Which file is created first, /a/file1 or /b/file1? /a/file1. Which \ file is the most recently modified version? /a/file1. In the Mac world, copy operations preserve the timestamps of the original. Thus, in this case, both files would have the same creation date, and :a:file1 would have a more recent modification date. \ Does anyone have a better example of why a created timestamp is \ needed? One theory is that it helps distinguish different edits of the same file from similarly-named files with wholly different contents. Apple's File Assistant synchronization software, uses creation date to help insure that it's dealing with two different versions of the same file rather than two different files with the same name. (Actually, I wish this feature could be turned off, or at least limited. When I run a file through LaTeX, the .aux file is always "re-created" rather than modified. Thus, my .aux files have to be synched by hand or (more often) deleted to make the synch process go smoothly. But I can see situations in which it could be useful.) D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 1997 05:09:22 GMT Organization: The Jack Voigt Fan Club Message-ID: <5e0s22$iki$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <y9lybcs62r4.fsf@caucasus.eecs.umich.edu> In article <y9lybcs62r4.fsf@caucasus.eecs.umich.edu>, Alan Olson <alan@caucasus.eecs.umich.edu> wrote: \ This is not a problem with multiple users, this is a problem with \ using multiple applications to edit the same file. A single \ individual would encounter this problem if he prefered the Photoshop \ tools for some of his work and the Painter tools for the rest. [...] This strikes me as an extraordinarily common situation. Especially with files of type TEXT. \ Sounds like you want file type to determine which application to \ open. That's a valid way of doing things, and in some ways its better \ than using creator codes. On a Mac the problem is there is no \ standardization of type codes (as far as I know). You can't tell the \ format/contents of a file just by looking at the type. There are a \ few types which are widely recognized (e.g., TEXT), but I don't think \ Apple has issued directives saying that files of type XXXX must have \ such and such a format. TEXT is exactly why I like the current system. If I'm editing a web page, I want to open it in Alpha. If it's a SAS program, I may want BBEdit or SAS depending on whether I want to edit it or run it. If it's a text file I've downloaded from the Net, I probably want to open it in Word 5. But if it's a binhexed file, I want to use Stuffit Expander. My solution is drag and drop--I've got a few options (Expander, Word, and BBEdit) installed in DragThing, and most of my other options are available by dragging into the menu bar. When I can, though, I take advantage of creator codes--my web pages are Alpha documents, so the machine "knows" to open them in Alpha. If I were forced to use a system that assigned only one app per file type, TEXT files would drive me up the wall. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 1997 05:02:42 GMT Organization: The Jack Voigt Fan Club Message-ID: <5e0rli$ijn$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <1997Feb12.173429.29584@llyene.jpl.nasa.gov> <SHESS.97Feb13091612@howard.one.net> <rang-1302971129260001@margaret.trillium.adaptec.com> In article <rang-1302971129260001@margaret.trillium.adaptec.com>, Anton Rang <rang@trillium.adaptec.com> wrote: \ > Creation time information will be necessary for Mac programs, \ Because they already have access to it, so it has to be there to \ preserve backwards compatibility. (Does anyone use it? Probably; but it \ doesn't matter.) Apple's PowerBook File Assistant synchro program uses it... it uses filename, type, creator, and creation date to decide which files "match", and then uses modification date to know which version is the new one. \ > and would doubtless be helpful in some configuration management. \ "Let me find all of the files which were placed on my disk when I \ installed CyberDog and its plug-ins. I want to copy them over to my new \ 20GB hard disk." Not a great example; as with file copies, installers leave the original creation dates on the files. So unless the CyberDog programmers gave all the files the same creation dates, this wouldn't work. \ > Keep in mind that "modified" includes "replaced entirely" as a subset. \ Well, it depends on what you mean by "replaced entirely"...the entire \ contents or the entire file? Certain operations on the Mac "replace" files and thereby change the creation date of what otherwise look like identical files. If you take a file and do a "save as" using the same name and in the same folder, you will usually change the creation date. At least one LaTeX application (Textures) "recreates" .aux files when it typesets. (I know because this plays hell with PowerBook File Assistant.) D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: glenn@concentric.net.no.spam (Glenn) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 14 Feb 1997 02:34:30 -0400 Organization: Concentric Internet Services Message-ID: <glenn-1402970234300001@61020d0022ct.concentric.net> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5du6c1$19c$1@darla.visi.com> In article <5du6c1$19c$1@darla.visi.com>, David Young <dwy@ace.net> wrote: > Are you *insane*? Apple's current OS has the *worst* memory management > architecture of ANY operating system since the advent of the MMU. Period. Evidently you haven't done any 16 bit Winderz programming.... glenn@concentric.net.no.spam
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <cs@hal.kph.tuwien.ac.at> Message-ID: <9702132021.AA02677@zaphod> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) From: Christian Starkjohann <cs@hal.kph.tuwien.ac.at> Date: Thu, 13 Feb 97 21:21:48 +0100 Subject: Re: Referencing externs from loaded bundle on OpenStep/NT - how? In article <vbd8u4mz3j.fsf@eldar.arc.ab.ca> schack@eldar.arc.ab.ca (Brian Schack) writes: > We have an application consisting of a main program, and several > bundles which are loaded at run time using [NSBundle initWithPath:]. > The bundles reference several global variables in the main program. > > We've compiled and run the code successfully on NeXT hardware, Solaris > OpenStep, and plain old gcc on a Sun. However, we cannot get it to > work under OpenStep/NT - the main program and the bundle end up > looking at two entirely different bits of memory. Here's a quick > synopsis of the code: > > [code example deleted] > [...] > > I've trying prefacing the 'extern int global' with a > __declspec(dllimport), and the 'int global = 42' with a > __declspec(dllexport), and various other combinations, all with no > luck. Has anybody experienced this problem and know how to deal with > it? I had the same problem. I have tried several combinations of this dllexport/dllimport stuff, too, and I also had no luck with it. I think, exporting globals to DLLs just does not. I "solved" the problem by writing class methods to access the global variables (luckily it was just one global variable...). Bye, Christian. -- Christian Starkjohann <cs@hal.kph.tuwien.ac.at> or <cs@ds1.kph.tuwien.ac.at>, finger for PGP Public Key. PGP fingerprint: DF FD 40 60 91 6A 14 1C CD 2C E9 07 38 AE CB 4E
Newsgroups: comp.sys.next.programmer Organization: Antigone Press gateway, San Francisco Return-Path: <cs@hal.kph.tuwien.ac.at> Message-ID: <9702132035.AA02710@zaphod> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.0 v146.2) From: Christian Starkjohann <cs@hal.kph.tuwien.ac.at> Date: Thu, 13 Feb 97 21:35:54 +0100 Subject: Using NSConditionLock et al Hi, I want to use an NSConditionLock (or any other NSLocking class) to protect the instance variables of objects in a multithreaded environment. The NSConditionLock should have been an instance variable of each such object. But then I found this sentence in the documentation of each NSLocking class (quote from "NSConditionLock.rtfd"): An application can have multiple NSConditionLock objects, each protecting different sections of code. However, these objects must be created before the application becomes multithreaded. Does that mean that I have to know how many locks I will need before I fork the first thread? Should I allocate a certain amount (say 100 or 1000) instances of NSConditionLock before forking a thread just in case I need them later? And does anybody know why it should be dangerous to allocate locks in a multithreaded environment? Thanks for any insights! Bye, Christian. -- Christian Starkjohann <cs@hal.kph.tuwien.ac.at> or <cs@ds1.kph.tuwien.ac.at>, finger for PGP Public Key. PGP fingerprint: DF FD 40 60 91 6A 14 1C CD 2C E9 07 38 AE CB 4E
From: Kresten Krab Thorup <krab@california.daimi.aau.dk> Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 14 Feb 1997 10:51:04 +0100 Organization: DAIMI, Computer Science Dept. of Aarhus Univ. Distribution: comp Message-ID: <xz6d8u3zpfb.fsf@california.daimi.aau.dk> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> <SHESS.97Feb13135626@slave.one.net> shess@one.net (Scott Hess) writes: > .... Just to see what the > difference is for the "hit" case, I wrote a simple program that calls > [anObject self] 100 million times. The times were: > > NeXT runtime, 2.5.8 :29 > objcrt 1.1.1 1:33 > objcrt 1.1.7 :46 > objcrt 1.1.8 :27 > direct call to imp :11 > > This does bring up a couple points for future testing. Why is NeXT's > dispatch so fast? Do they cache the <isa,sel,imp> tuple between calls > to objc_msgSend()? [That should be easy enough to ferret out.] The NeXT messenger is so fast because someone spend *months* optimizing it for each specific hardware platform. It has a linear hash table cache in each class which contains (SEL,IMP) pairs, using "(SEL & (2^n-1))" as hash function. (You can easily reverse engineer the algorithm using the headerfiles.) This is reasonably fast because of the simple arithmetics involved, and because the hash search typically touches just one (hardware) cache line. The big speedup however, comes because the cache lookup is carefully hand-tuned assembler, which takes such things as cache line alignment and multiple issue pipeline into consideration. With NEXTSTEP 4, the runtime also implements a new multi thread support scheme which doesn't use an explicit mutex. This even speeds up the non-multi threaded case because it doensn't have to check the Mt flag. -- Kresten _ _ ___ _ _ _ _ _ | | _ _ _ __ | |_ / _ \ _| | __ (_)_ _ _(_) __ __ _ _ _| | | _ | |/ | '_|_ \| ' / _ / ` ||_ \| | ' ' | | |_ \ |_ \| | | / ` | |/ | | <| | / . | | | \__( (| / _ | | | | | |_/ _ / _ | | |( (| | < |_|\_|_| \_,_|_,_/\___/\_,_\__,_|_|_|_|_|_(_)__,_\__,_\_,_(_)_,_|_|\_|
From: rft@cg.tuwien.ac.at (Robert F Tobler) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 14 Feb 1997 10:32:21 GMT Organization: Vienna University of Technology, Austria Distribution: comp Message-ID: <5e1evl$ql@news.tuwien.ac.at> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> <SHESS.97Feb13135626@slave.one.net> Cc: shess@one.net In <SHESS.97Feb13135626@slave.one.net> Scott Hess wrote: > In article <SHESS.97Feb6140159@slave.one.net>, > This does bring up a couple points for future testing. Why is NeXT's > dispatch so fast? Do they cache the <isa,sel,imp> tuple between calls > to objc_msgSend()? [That should be easy enough to ferret out.] > > [Now, toss in inline methods and an optimizing compiler, and this > would take 0:00 execution time :-).] You could also have a look a the GNU implementation of the Objective-C dispatch. In a real-world test with an Objective-C raytracer I get 10% speedup when I run the gcc-2.7.2 compiled version when compared to Next's gcc-2.5.8 version. (Of course this might also be caused by better general optimizations in gcc-2.7.2, you might want to include gcc in you simple comparison.) Anyway, the GNU implementation is available in source code, so you do not need to dig into assembly language: If gcc-2.7.2.1 is installed, see function: static inline void* sarray_get(struct sarray* array, sidx index) in: /usr/local/lib/gcc-lib/i386-next-nextstep3/2.7.2.1/include/objc/sarray.h ------------------------------------------------------------------------ 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: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 97 11:17:00 GMT Organization: Lund University Message-ID: <peterm.855919020@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> shess@one.net (Scott Hess) writes: >But a created timestamp doesn't solve the problem you asked to be >solved. In the following situation: > cp file1 /a/file1 > cp file1 /b/file1 > edit /a/file1 >Which file is created first, /a/file1 or /b/file1? /a/file1. Which >file is the most recently modified version? /a/file1. They both have the same created timestamp! Yes, /a/file1 is the most recent changed, so? Did I ever say that I want the created time stamp to *replace* the last changed time stamp??? I honestly don't get the big problem with having a created time stamp. Let's say I have this neat unix script, and I want to see if this script is the one I wrote from scratch, or the one that is a hack on a hack on a hack, then time created is invaluable! >Pretend that /a is actually your machine at work, and /b is actually >your machine at home. You look on the proxy for your home machine (a >Zip disk, say), and see that the file1 on your work disk was created >before the file1 on the Zip disk, and copy the file from the Zip to >your work disk, overwriting the edited version. >In this case, it's the last-modified timestamp you're looking for. >Does anyone have a better example of why a created timestamp is >needed? Yes, of course I need the last-modified stamp - also!!! But that doesn't mean that I *never* need to know when I created a file! If you copy a file, you clone it, and of course you should copy all file attributes. What's the problem with that? I am aware that programmers/hackers rarely care about other things than raw (7-bit US-ASCII) text files, but there's a large amount of users (lusers) out there, and they have somewhat other interests. This is not a question of "who's right", but rather "how do we make both happy?" -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 14 Feb 97 12:20:40 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb14122040@slave.one.net> References: <5ddp66$jpc@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> In-reply-to: tfs@gravity.science.gmu.edu's message of 13 Feb 1997 22:15:21 GMT In article <5e03pp$thl@portal.gmu.edu>, tfs@gravity.science.gmu.edu ( Tim) writes: Under the current NeXT/bsd filesystem, a file with one character in it takes up 2 bytes. -rw------- 1 tfs 2 Feb 13 17:08 foo So it's feasible to have allot of small files, hell that's what losenet news is, lots and lots of small files, many smaller than the rather huge 32K that you're used to... Untrue. FFS uses blocks and fragments. Blocks are generally something like 8k or 4k, fragments are generally 512 bytes or 1024 bytes (1/8 a block or so). Any file _must_ be an integral number of fragments. Only the last partial block can be made up of adjacent fragments somewhere - a block-sized file will be stored as a block, not as a bunch of fragments. Only the last direct pointer in the inode can reference a fragment, which means that a file which is 25 blocks plus N bytes (N<block size) will always use a full block for the last piece of the file. (25 was picked out of thin air. The number of direct pointers in the inode is something like 12.) As a result, the average wastage is relative to the average fragment size, while large files are kept efficient by virtue of using larger blocks. FFS uses various layout strategies to try to keep adjacent blocks (and partial blocks) optimally located such that you don't have to do wide-ranging seeks to find them (that's where the 10% time vs space amount comes from). Generally, du will tell you the actual amount of disk space a given file is taking up, in fragments, as will ls -s. You can use something like "dd if=/etc/termcap of=aFile bs=<size> count=1" to create a file of an arbitrary size. The following table gives the <size>, what ls -l reports, and what du and ls -s report for a couple sizes on my filesystem (8k blocks, 1k fragments): <size> ls -l du/ls -s 2 2 1 1024 1024 1 1025 1025 2 88k 90112 88 88k=8k/bloc*11 blocks 88k+1 90113 89 96k 98304 96 96k=8k/block*12 blocks 96k+1 98305 112 From the above, it's clear that there are 12 direct block pointers in the inode, since it allocates a full 8k for that last one byte. That's not such a big deal, because it only affects large files (8k-1 wasted from 96k+1 is less than 8% wastage), while still keeping wastage small for small files. [BTW, 4k was the chosen blocksize initially for ffs, because with 4k blocks, you could put 1024 block numbers in an indirect node, and 1024 indirect block numbers in an doubly-indirect node, giving a filesystem size of 4*1024*1024*1024==2^32 without using triply-indirect blocks (which aren't currently implemented anyhow, though there's an inode entry for one). Unfortunately, somewhere signed integers are being used, so you can only use 2^32 (2G) in one partition on NeXTSTEP at this time. Actually you want it to be slightly smaller than that.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: sieg@informatik.uni-muenchen.de Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 1997 21:25:57 GMT Organization: Institut fuer Informatik der Universitaet Muenchen Distribution: world Message-ID: <5e2l95$902@arcadia.informatik.uni-muenchen.de> References: <5e0s22$iki$1@newz.oit.unc.edu> Keywords: drag & drop mac nextstep unix text Dave Scocca writes > In article <y9lybcs62r4.fsf@caucasus.eecs.umich.edu>, > Alan Olson <alan@caucasus.eecs.umich.edu> wrote: > > \ This is not a problem with multiple users, this is a problem with > \ using multiple applications to edit the same file. A single > \ individual would encounter this problem if he prefered the Photoshop > \ tools for some of his work and the Painter tools for the rest. > [...] > > This strikes me as an extraordinarily common situation. Especially > with files of type TEXT. > > \ Sounds like you want file type to determine which application to > \ open. That's a valid way of doing things, and in some ways its better > \ than using creator codes. On a Mac the problem is there is no > \ standardization of type codes (as far as I know). You can't tell the > \ format/contents of a file just by looking at the type. There are a > \ few types which are widely recognized (e.g., TEXT), but I don't think > \ Apple has issued directives saying that files of type XXXX must have > \ such and such a format. > > TEXT is exactly why I like the current system. If I'm editing a web > page, I want to open it in Alpha. If it's a SAS program, I may want > BBEdit or SAS depending on whether I want to edit it or run it. If > it's a text file I've downloaded from the Net, I probably want to open > it in Word 5. But if it's a binhexed file, I want to use Stuffit > Expander. > > My solution is drag and drop--I've got a few options (Expander, Word, > and BBEdit) installed in DragThing, and most of my other options are > available by dragging into the menu bar. When I can, though, I take > advantage of creator codes--my web pages are Alpha documents, so the > machine "knows" to open them in Alpha. You just do the same with Nextstep / Openstep for mach! > > If I were forced to use a system that assigned only one app per file > type, TEXT files would drive me up the wall. Just try Nextstep / Openstep for mach befor you complain, please! > > D. > -- > * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * > * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * > * "My love does not, cannot _make_ her happy. My love can only * > * release in her the capacity to be happy." --J. Barnes * -- Arne Sieg, StuMi-Sysadmin PST (E10, E3) url: http://www.pst.informatik.uni-muenchen.de/~sieg/
Newsgroups: comp.sys.next.programmer From: : Hans Mulder <hansm@icgned.nl> Subject: Re: Broken Pipe? Message-ID: <E5LI4I.IsG@icgned.nl> Sender: news@icgned.nl Organization: IC Group References: <5co1u2$kpn$1@inet-prime.comshare.com> Date: Fri, 14 Feb 1997 13:43:30 GMT alanf@izzy.net wrote: >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 shell script should (and initially does) simply echos to stdout whatever >comes in on stdin. How exactly does your shell script do that? >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. The most common problem in this type of exercise is stdio buffering in the shell script. You'd test the shell script in a Terminal window and it'll work fine (because then you get line buffering). Then you use it at the far end of a pipe and it'll fail, because then you get block buffering. A few unix utilities allow you to turn off buffering, for example cat uses the -u option to do that. But cat is in a minority here. It would be nice if there were a way to tell stdio to not buffer the stdout stream (an enviromnet variable maybe?). AFAIK, there is no such mechanism. Hope this helps, -- HansM
From: tfs@gravity.science.gmu.edu ( Tim) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 13 Feb 1997 22:15:21 GMT Organization: George Mason University, Fairfax Va. Sender: tfs-----@gravity.science.gmu.edu (remove dashes to reply) Message-ID: <5e03pp$thl@portal.gmu.edu> References: <5ddp66$jpc@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit In article <5do9vl$mp2$1@newz.oit.unc.edu>, Dave Scocca <scocca@gibbs.oit.unc.edu> wrote: > >Under one condition--if we're using multiple hidden files, we MUST fix >the large-block problem for large hard drives. Since a hard drive has >65536 allocation blocks, and no more, small files on large hard drive >are large. Right now, a text file containing a single character >consumes 32K of my (2.1 GB) hard drive. > Well, there's no way the filesystem being used should be the Mac's, (flames on this to /dev/null if you can't see that the above is a monster problem, it isn't worth discussing). Under the current NeXT/bsd filesystem, a file with one character in it takes up 2 bytes. -rw------- 1 tfs 2 Feb 13 17:08 foo So it's feasible to have allot of small files, hell that's what losenet news is, lots and lots of small files, many smaller than the rather huge 32K that you're used to... Tim -- ________________________________________________________________ tfs@vampire.science.gmu.edu (NeXTmail, MIME) Tim Scanlon tfs@epic.org (PGP key aval.) crypto is good Seal Technologies Inc. I own my own words
From: rang@trillium.adaptec.com (Anton Rang) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 14 Feb 1997 09:23:06 -0600 Organization: Trillium Research, an Adaptec company Message-ID: <rang-1402970923060001@margaret.trillium.adaptec.com> References: <5ddp66$jpc@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> In article <5e03pp$thl@portal.gmu.edu>, tfs@gravity.science.gmu.edu ( Tim) wrote: > Under the current NeXT/bsd filesystem, a file with one character > in it takes up 2 bytes. > -rw------- 1 tfs 2 Feb 13 17:08 foo Well, er, no. I'm not sure of NeXT's implementation (BSD filesystems vary from machine to machine), but no BSD-derived file systems allow a file to take less than one block on disk (512 bytes). Saving that little bit of space just isn't worth the huge impact on speed. (Well, for some applications it would be; that's one place where plug-in file systems are useful.) > So it's feasible to have allot of small files, hell that's what > losenet news is, lots and lots of small files, many smaller than > the rather huge 32K that you're used to... The current HFS *implementation* is certainly painful on modern drives, and should be replaced; but 99% of the API doesn't care about the implementation; it's reasonable to think about an HFS implementation which allocated space in a much more friendly way but still provided the current Mac functionality. On a side note, someone claimed on one thread that the support for aliases in the Mac file system was a performance hit, and thus should be dropped; I'd just like to point out that the UNIX inode number is very similar and nobody suggests that it be dropped. :) -- Anton
From: shess@one.net (Scott Hess) Newsgroups: comp.lang.objective-c,comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 14 Feb 97 08:48:03 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb14084803@slave.one.net> References: <SHESS.97Jan30142225@howard.one.net> <4mxSLlq00iWUI108t7@andrew.cmu.edu> <SHESS.97Feb6140159@slave.one.net> <SHESS.97Feb13135626@slave.one.net> <xz6d8u3zpfb.fsf@california.daimi.aau.dk> In-reply-to: Kresten Krab Thorup's message of 14 Feb 1997 10:51:04 +0100 In article <xz6d8u3zpfb.fsf@california.daimi.aau.dk>, Kresten Krab Thorup <krab@california.daimi.aau.dk> writes: shess@one.net (Scott Hess) writes: > .... Just to see what the difference is for the "hit" case, I > wrote a simple program that calls [anObject self] 100 million > times. The times were: > > NeXT runtime, 2.5.8 :29 > objcrt 1.1.1 1:33 > objcrt 1.1.7 :46 > objcrt 1.1.8 :27 > direct call to imp :11 > > This does bring up a couple points for future testing. Why is > NeXT's dispatch so fast? Do they cache the <isa,sel,imp> tuple > between calls to objc_msgSend()? [That should be easy enough to > ferret out.] The NeXT messenger is so fast because someone spend *months* optimizing it for each specific hardware platform. It has a linear hash table cache in each class which contains (SEL,IMP) pairs, using "(SEL & (2^n-1))" as hash function. Ugh. This did suddenly (for no good reason) cause me to test two other possibilities. The above were all without any optimization flags. (sorry.) A couple more numbers: NeXT runtime, -O2 :28 essentially the same objcrt 1.1.8, -O2 :18 NeXT's 2.5.8 objcrt 1.1.8, -O6 :16 gcc 2.7.2 with Pentium opts (961122) NeXT's version didn't change because it's still doing a function call, and the function call should still be the same speed. 1.1.8 inlines them, and then optimizes the inline code. With the Pentium optimized gcc, it presumably can also schedule things. Still, this isn't a very good benchmark, though now I'm wondering whether -O6 can overcome the miss penalty for a more "real" program. [Sorry, I can't test the GNU runtime using this crappy benchmark at this time without rebooting my machine to Linux.] With NEXTSTEP 4, the runtime also implements a new multi thread support scheme which doesn't use an explicit mutex. This even speeds up the non-multi threaded case because it doensn't have to check the Mt flag. I've been waiting a long time for this, as it's always seemed to me a silly distinction. Using an atomic store to update the cache should preserve the semantics without needing a flag, so long as all possible "simultaneous" stores are storing the same value. Wouldn't even need to be explicit, so long as you can't read a value that's half new, half stale. Should even work on SMP machines, unless one CPU can see a half-stale aligned word. [Brings up an interesting point. On an SMP machine running a multithreaded program on multiple CPUs, would it make more sense to have the IMP cache shared, or just let each of them maintain their own cache so they don't update each other's. I know that it would be nigh impossible to program, just thinking. Of course, after the cache is primed, it doesn't make much difference either way.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: woo@opus.bloomco.ornl.gov (John W. Wooten) Newsgroups: comp.sys.next.programmer Subject: Data from App to Improv using Services? Date: 14 Feb 1997 15:04:07 GMT Organization: Oak Ridge National Lab, Oak Ridge, TN Distribution: world Message-ID: <5e1ut7$8uo@stc06.ctd.ornl.gov> Where can I find out how to take data from an app I'm writing and put it into Improv for some calculations and formatting? I'd like to programmatically launch Improv and then paste the data parameters in. The rest of the formulas would already be in the spreadsheet if possible. -- J. W. Wooten <jwooten@korrnet.org> http://sacam.oren.ortn.edu/~wooten Internet Consultant NeXTmail preferred, MIME is welcome Please finger woo@160.91.216.2 for PGP public key
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 14 Feb 97 08:32:48 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb14083248@slave.one.net> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> <qd3ev4i1o8.fsf@blues.cygnus.com> <5dqfig$pm8@news.bu.edu> <qdiv3yhpyj.fsf@blues.cygnus.com> <5e0ev6$qje@news.bu.edu> In-reply-to: macintsh@bu.edu's message of 14 Feb 1997 01:25:58 GMT In article <5e0ev6$qje@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: But my statement that the UI and implementation can't be separated referred more to this concept: no mater what the UI is, if the implementation is such that the UI is not *necessary*, then the majority of users and software vendors will cavalierly ignore it. I'm basing this theory on the DOS, Unix, and Windows practices of requiring or asking users to edit text files themselves in certain situations just because it's easier to ask that than to provide a more GUi-ish way to do it. Perhaps it's more of a cultural issue than a technical one. I'm not sure how common that type of practice is in the NeXT culture. But a Mac user *never* expects to be asked to do anything more than point, click, and drag. I won't claim that all NeXT "applications" are good in this regard. In general, though, real apps (ie, with GUI, launched from WorkSpace) tend to have a Preferences panel which stores its values in the defaults database. It's not done so much because it's recommended, as because with InterfaceBuilder, it's just not really that hard to throw together at least a minimal panel to handle most preferences. Some Unix-level stuff naturally requires you to putz with text config files. Obviously, if you install GNU CVS, you won't have a magical GUI for it :-). OTOH, things like PPP still usually require at least some command-line work, mostly because there simply aren't enough users out there to make it worth someone's while to put a GUI interface on it. Doing so wouldn't be hard, and if you could guarantee 100 shareware registrations to someone, they'd probably be willing to throw something together. [Depending on who "someone" is, you might only need 10 or 20 registrations :-).] There are some gray-area types, though. For instance, if you have "Super Power User Feature Which Is Not Fully Tested", you might not have a Preferences panel item for it. But you might leave the defaults database handling the same, and tell select customers you trust "Just go to a command-line and type 'dwrite MyApp SuperFeature YES'" or something of the sort. I've also done this in cases where I could more easily add a feature than I could rearrange my carefully laid out preferences panel, which isn't so easy to rearrange now that it's got 30 or 40 interacting options :-). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
Newsgroups: comp.sys.next.programmer From: : Hans Mulder <hansm@icgned.nl> Subject: Re: Compiler version in newest OS? Message-ID: <E5LMpt.J7J@icgned.nl> Sender: news@icgned.nl Organization: : hardly any References: <9701282154.AA05544@basil.icce.rug.nl> Date: Fri, 14 Feb 1997 15:22:41 GMT Tom Hageman <tom@basil.icce.rug.nl> wrote: >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:-/) It was 2.7.2: $ gcc -v Reading specs from C:/NeXT/NextDeveloper/Libraries/gcc-lib/i386-nextpdo-winnt3.5\2.7.2\specs gcc version 2.7.2 for NeXT PDO Incidentally, why does the pathname separator change form '/' to '\' at or near the word "winnt" :-? -- HansM
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 97 10:39:37 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb14103937@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> In-reply-to: peterm@dna.lth.se's message of 14 Feb 97 11:17:00 GMT One thing this thread is proving, beyond a _shadow_ of a doubt, is that once you put something into the information the filesystem stores with a file, it's almost _impossible_ to remove it. That observation, in and of itself, is a strong argument for not adding things to the inode :-). In article <peterm.855919020@ulfrun>, peterm@dna.lth.se (Peter Moller) writes: shess@one.net (Scott Hess) writes: >In this case, it's the last-modified timestamp you're looking for. >Does anyone have a better example of why a created timestamp is >needed? Yes, of course I need the last-modified stamp - also!!! But that doesn't mean that I *never* need to know when I created a file! If you copy a file, you clone it, and of course you should copy all file attributes. What's the problem with that? I am aware that programmers/hackers rarely care about other things than raw (7-bit US-ASCII) text files, but there's a large amount of users (lusers) out there, and they have somewhat other interests. Unfortunately, that is _not_ a valid argument for changing things, because it's open-ended. You might also want to know which user created a file. You might want to know what machine the file was created on. You might want to know which version of a program created the file (as distinct to which program created the file). Heck, you might want a complete log of which version of which program worked with a file, and which users editted it, when they editted it, what portions they editted, and where they editted it from. That _doesn't_ justify putting that information in _the_ filesystem. This thread has had suggestions which accomplish the same things over top of the existing filesystem, rather than by modifying things at a low level. All of this might justify putting the information in _a_ filesystem, though. Distinction? _The_ filesystem is the basic abstraction that lives somewhere deep in the kernel (at least to all intents and purposes). It should only be modified in extreme need. There's no reason you couldn't allow filesystem drivers to be layered on top of each other, though, with each level modifying how the filesystem is viewed. You might have multiple root filesystems (FFS, NFS, NTFS, HPFS, HFS, etc), with arbitrary filesystem "translators" layered on them. You want to view a non-HFS filesystem as having forks? Layer in a translator on whatever you have. Stuff it all in system libraries somewhere so that in the common case you don't even make the decision. [Using MacApp, you get something looking like HFS, using unistd.h you get something looking like FFS.] This is not a question of "who's right", but rather "how do we make both happy?" Well, except that I'm trying to argue that you shouldn't be unhappy with how it's currently done (in Unix) :-). More broadly, though, the filesystem obviously cannot be changed to make everyone happy. Everyone might be happy with the fact that their pet feature is in there, but everyone will be _unhappy_ because the performance sucks, it's buggy as all get out, and it doesn't interoperate with other filesystems at all. The plain fact of the matter is that in the abstract, there is a lowest common denominator filesystem out there. It looks suspiciously like FFS, if only because NFS was built in an FFS environment. Anything Apple/NeXT come out with _must_ interoperate with NFS in an almost completely transparent fashion. _MUST_. That's not even an option. NFS is simply too prevalent. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Date: 14 Feb 1997 22:06:50 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5e2nlq$76p@geraldo.cc.utexas.edu> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> <5ddtva$u31@csugrad.cs.vt.edu> Nathan M. Urban (nurban@csugrad.cs.vt.edu) wrote: : macintsh@bu.edu (John Siracusa) wrote: : : > As I stated in my original post, a POSIX subsystem is fine. A Unix : > directory tree appearing on my hard drive after a standard install is : > not. : I don't understand why not, considering that it doesn't take up that : much more disk space, allows you to run any Unix programs you may wish : to run in the future, is required by the OS to boot and do other : administrative things, and doesn't even need to be seen by you. For good or for ill, John's comments are going to reflect those of a lot of Mac users. Which means that all vestiges of Unix must be completely hidden, not just from day to day users, but even for system managment. Clearly, of current Unix implimentations, NeXT does this the best, but Apple has said it needs to be done better. Whether this means that Apple will develop a complete set of GUI wrappers for all functions, or choose instead to replace these functions, probably hasn't been decided. I personally hope that hiding the Unixness doesn't mean removing it, but comments by Tevanian indicate that Rhapsody might not include Unix utilities. In taking a month to examine all the kernal options Apple has shown that they are being thorough in picking the pieces of the Next Mac OS. It will probably be several more months before we get a clear view of issues like the Unixness of 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: cruel@xs4all.nl (Bart) Subject: Special offer Newsgroups: comp.dcom.net-analysis,comp.dcom.net-management,comp.os.netware.connectivity,comp.os.netware.misc,comp.os.netware.security,comp.ai.neural-nets,comp.sys.newton.misc,comp.sys.newton.programmer,comp.sys.next,comp.sys.next.advocacy,comp.sys.next.bugs,comp.sys.next.hardware,comp.sys.next.marketplace,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.soft-sys.nextstep,comp.protocols.nfs,comp.networks.noctools.bugs,comp.networks.noctools.d,comp.sys.northstar Date: Fri, 14 Feb 1997 20:27:03 GMT Message-ID: <23.0072463750839@news.xs4all.nl> Organization: Pedo lovers inc. IMPORTANT MESSAGE !! Yes for 150 $ you can possibly buy a nice young tight boys ass for 1.5 hours. This is in a district close to Rotterdam in Holland The boys are 10-12 years old. They have not been used more than 1 month at the most, some are untouched. Most of them from Pakistan but they aren't 100% black, the sperm only shows better on coloured skin anyway. For 150 $ you can use one of the boys 1.5 hours, that might not be long, but a 10 year old ass doesn't hold forever. You can use their mouth and asshole as much as the boys can take, the ones that already have been rented out all managed 1-2 penetrations in both the mouth and asshole. They are all instructed before first trip so they know how to suck, swallow the sperm and lick the dick clean afterwards. The assholes are well greased with Vaseline and stretched a bit just so they can take a dick. They can also massage you with oil and lick you in your asshole. Urin stuff is not allowed, neither is SM, you must not hurt the boys, then action will be taken. What you have to do is reply fast, because we can only use the same address a day or two. On replying you will receive a phone number. There you will be given a new phone number where you can arrange the meeting. Money is paid when the boy is delivered. If the boy has been beaten or hurt more then one can do with a dick you will be held responsible because we promise the boys protection against rapists. Only pure sexual use is allowed.
From: joshua@nothing.izzy.com (Pure Stuff) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 14 Feb 1997 21:24:17 GMT Organization: Net Access - Philadelphia's Original ISP Message-ID: <slrn5g9m00.mb1.joshua@nothing.izzy.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5dieu7$p0v@news.bu.edu> <qd3ev4i1o8.fsf@blues.cygnus.com> <5dqfig$pm8@news.bu.edu> <qdiv3yhpyj.fsf@blues.cygnus.com> <5e0ev6$qje@news.bu.edu> <SHESS.97Feb14083248@slave.one.net> In article <SHESS.97Feb14083248@slave.one.net>, Scott Hess wrote: >Some Unix-level stuff naturally requires you to putz with text config >files. Obviously, if you install GNU CVS, you won't have a magical >GUI for it :-). OTOH, things like PPP still usually require at least [hack chop cut] Actually, using xemacs will provide you with a nice hapyp GUI for CVS. There's a 'VC' (version control) menu under the 'Tools' menu, which has context sensitive options (register file, next-action, etc). Makes working with CVS a lot easier (even for someone like me, who actually remembers how to type 'cvs commit'). So, there's your magical gui, emacs :) Joshua "emacs makes it happen" Burgin _________________________________________________________________________ <mailto:joshua@purestuff.com> Joshua Burgin <http://www.purestuff.com/> Repeat after me:`I would like to feed your fingertips to the wolverines.'
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer Subject: Link trick Date: 14 Feb 1997 19:20:53 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5e2dul$adp@nef.ens.fr> Hello, I'm trying to "simulate" the link crtl-drag/link trick in Interface Builder. But I have some problem. I'm using NS3.3 (no Openstep for Mach 4 for the moment... helas...) The simple way to ask my questions is to give you this URL : http://www.eleves.ens.fr:8080/home/jalon/nxtproblems/pseudolink/ where you will find screen shots, sources and my questions (the sources are short...) thanks in advance. --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: woodward@onramp.net (John Woodward) Newsgroups: comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 14 Feb 1997 22:36:21 GMT Organization: OnRamp Technologies; ISP; Dallas/Ft Worth/Houston, TX USA Distribution: comp Message-ID: <5e2pd5$lii@newsread.onramp.net> References: <SHESS.97Feb14084803@slave.one.net> In article <SHESS.97Feb14084803@slave.one.net> shess@one.net (Scott Hess) writes: > > NeXT runtime, -O2 :28 essentially the same > objcrt 1.1.8, -O2 :18 NeXT's 2.5.8 > objcrt 1.1.8, -O6 :16 gcc 2.7.2 with Pentium opts (961122) > > NeXT's version didn't change because it's still doing a function call, > and the function call should still be the same speed. 1.1.8 inlines > them, and then optimizes the inline code. With the Pentium optimized > gcc, it presumably can also schedule things. > > Still, this isn't a very good benchmark, though now I'm wondering > whether -O6 can overcome the miss penalty for a more "real" program. What Pentium opts are these? Where can I find them? john -- ============================================================== John W. Woodward email: woodward@onramp.net Dallas, TX NeXTMail welcome! ==============================================================
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 14 Feb 1997 23:15:58 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5e2rne$d5e@geraldo.cc.utexas.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> Jonathan W. Hendry (jon@subsequent.com) wrote: : Alan Jenks wrote: : : > On Win 95 I have both Borland and MS compilers installed. After : > installing the Borland compiler all my MS Visual C (*.c/cpp) created : > files now insist on openning with the Borland compiler when I double : > click them! I can't have some *.c/cpp files open with VC and others with : > Borland and of course they must end in c/cpp to open with either one. : > : > What is the a type/creator mechanism on NextOS that will prevent this : > step backwards in usability for Mac users in the future? : : There is no 'creator' concept - that idea falls apart in a multiuser : scenario. Ignoring the attempt to brush off the issue with with an air of false superiority, there are legitimate uses for file creator info even in a multi user environment. In essence, creator indicates the primary program best used to examine a file, while file type provides a broader list of secondary apps which can open the file and at least use some of the data. This distinction between best and possible applications to open a file is not inherently based on the number of users. Of course, for standard file types, like GIF/TIFF/JPEG, or for plain text files, this distinction does not mean much, but it can be important for the proprietary file types produced by most third party apps. These apps need to store program specific info, like formating for a Word or Excel document, or layering in a Photoshop document. While a text editor might be able to open a Word document and allow you to read the text, it might lose the formating. Thus such a document has a best app with which to view it in as well as a number of acceptable ones. : Filename extensions are used, but they are more flexible than Windows : extensions. There's no limit on the length of the extension, for : instance. The NeXTSTEP presentation app 'Concurrence' uses a : '.concur' extension. Spaces are allowed in filenames. While the Mac users abhorance of file extensions is largely religious, it will probably need to be honored for the sake of a smooth migration path. However this could be as simple as hiding the extension from view in the Finder. : The WorkspaceManager, an application which plays the role of Apple's : Finder, manages what applications open which files. Each application : tells the workspace what kinds of files it can open. If you select : a file, and bring up an 'Inspector' window (Command-3), you are : shown a scrolling list of icons which represent the applications : that can open that kind of file. One of them is treated as the : default. The default application is shown as the furthest-left icon. : : For a file of type '.tiff', I have 5 icons: IconBuilder.app, : WetPaint.app, Preview.app, WorkspaceManager.app, and Edit.app. : Edit.app is always an option. This may sound odd, but it often : makes sense. Files with no extension are treated as Edit files. : WorkspaceManager.app provides a Contents Inspector (Command-2) : in which documents are displayed (in a small window). You can : create loadable bundles that will extend the Contents Inspector : to handle more filetypes. In this sense, Contents Inspector works like QuickTime, though QuickTime uses/makes custom previews and icons. Custom icons are particularly useful since even the best file name is not always as meaningful as a small version of the image. : If you double-click a file, the default application for that type : of file is used to open it. : : To change the default, you bring up the inspector, select another : application, and click the 'Set Default' button. You don't have : to deal with all the editing garbage that Windows requires. : : To open the file with an application other than the default, : you can either Command-drop the file on the application's icon, : or you can bring up the Inspector and double-click the icon : of the application you want it to open in. (Or you can use the : open menu, in that application.) This is a good example of the kinds of thing that excite me about the possibilities of Rhapsody. By merging the Mac way with the NeXT way Apple can produce something better than either. Of course everyone has their own vision of how this might look, but here's an idea. Suppose the new combined Finder/Workspace Manager works like this. If you double click on a file, it opens in the creator, if you have it, else it opens in the default app for that file type. If you shift-double click, or double click with button 2 or whatever, it brings up an inspector window which allows you to select any app which will open that file type. In addition it will let you change the default app for that file type and also change the creator of that file. : In one way, this may seem like a step backwards. But, in the : 5 years I've been using NeXT's, I've never once had an occasion : to need some utility so I could fix some file rendered useless : by munged type/creator codes. That happened quite a few times : in my 3 years if Mac ownership. (If it wasn't a problem, : there wouldn't be several third-party tools around to work : around it.) : : And, again, creator codes don't work well in a multi-user : environment or network. If one user prefers Painter, and : one user prefers Photoshop, and they both have to work on : a set of files, they're continually going to have creator : problems, because the files will continually have their creator : code set to the other person's app. If we combine the approaches, then no one needs to take a step backward. There are certainly ways in which the Workspace's easy choice of opening app is an improvement. Likewise there is sometimes value in knowing the file's creator, in part to reduce the number of file types. These can easily be merged if one retains these 2 pieces of info. Perhaps one could even have a user preference that set double click to use creator or use default. How to store this and like info (custom icons, previews, etc.), whether by forks or wrappers or hidden files or filename extensions is a technical issue which does not need to impact the look and feel or user experience. Hopefully only the engineers will worry about this. 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: sef@kithrup.com Newsgroups: comp.dcom.net-analysis,comp.dcom.net-management,comp.os.netware.connectivity,comp.os.netware.misc,comp.os.netware.security,comp.ai.neural-nets,comp.sys.newton.misc,comp.sys.newton.programmer,comp.sys.next,comp.sys.next.advocacy,comp.sys.next.bugs,comp.sys.next.hardware,comp.sys.next.marketplace,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.sysadmin,comp.soft-sys.nextstep,comp.protocols.nfs,comp.networks.noctools.bugs,comp.networks.noctools.d,comp.sys.northstar Subject: cmsg cancel <23.0072463750839@news.xs4all.nl> Date: 14 Feb 1997 21:53:53 GMT Control: cancel <23.0072463750839@news.xs4all.nl> Message-ID: <cancel.23.0072463750839@news.xs4all.nl> Sender: cruel@xs4all.nl (Bart) Spam cancelled by sef@kithrup.com
From: warnerr@beethoven.cs.colostate.edu ( richard warner) Newsgroups: comp.sys.next.programmer Subject: Anyone know if OS4Mach 4.1 supports EIDE CDROMS???? Date: 14 Feb 1997 19:47:11 GMT Organization: Colorado State University, Fort Collins, CO 80523 Message-ID: <5e2ffv$3o2s@yuma.ACNS.ColoState.EDU>
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 15 Feb 1997 00:12:36 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5e2v1k$g06@geraldo.cc.utexas.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> John Rudd (jrudd@cygnus.com) wrote: : Tony Nelson wrote: : > I'll be brief. We like Macs. We use Macs because we can understand them. : > We want Macs, not techie Unix stuff. We aren't required to buy your : > favorite toy. If you don't like Macs, GO AWAY. While I abhor the lack of knowledge inherent Tony's post, I don't think Apple can or will ignore users like him. For these users, Apple will hide all outward signs of Unix and make the user experience a lot like Sys 7. Apple has said that they are approaching the UI item by item, taking only the NeXT versions that offer clear benefit. Of course, we don't know what Apple's definition of clear benefit is, but I have a feeling it's some where between Tony's and John's. We also don't know if Apple's approach to de-Unixizing Rhapsody will simply make it so that using and managing a Rhapsody Mac won't require a CLI or whether Apple will go further in this regard. It seems clear from Tevanian's comment to the effect that Rhapsody might include Unix utilities, that this issue has not yet been decided. : Oh, and by the way, unless you plan to stick with System 7, if you stay on : the mac, you DO have to buy my favorite toy. And if you want me to go away, : then stop posting your ignorant drivel in our nextstep newsgroups. This is as short sighted as Tony's comment. The final Rhapsody will combine both NeXT users expectations with those of Mac users, hopefully providing a compromise amenable to most if not all. We all have to expect some disappointments. Mac users will gain a lot of performance and stability from the underlying microkernal. They will also find some changes the the GUI which they will hate in the short run and hopefully love in the long run. Both the compatibility of older apps and availability of new Rhapsody versions will be limited at first and grow with time. Likewise the inclusion of Apple technologies will grow with time. It will probably not be until the combined release 18 months from now that DPS will gain QD GX features, for example. NeXT users will probably see even more changes they don't like in the GUI, though perhaps these can be addressed by preferences. They might lose Unix capability and some hardware options. It also might take several years for Rhapsody to make it to Intel hardware. They will gain improvement in multimedia, and benefit from other Apple technologies. They will also gain since the expanded user base will drive down costs and drive up developer support. For many on both sides the final result will be wonderful, but some on both sides will be disappointed. 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: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 15 Feb 1997 03:49:50 GMT Organization: The Jack Voigt Fan Club Message-ID: <5e3bou$emo$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> In article <5e2rne$d5e@geraldo.cc.utexas.edu>, William Raphael Hix <raph@porter.as.utexas.edu> wrote: \ Of course, for standard \ file types, like GIF/TIFF/JPEG, or for plain text files, this distinction \ does not mean much, but it can be important for the proprietary file types \ produced by most third party apps. Actually, I'd go the other way. Creator information is MOST important when lots of different apps can access the same file type. A WDBN (WorD BiNary) document will always be opened by MSWD (MicroSoft WorD), but a TEXT file can have many apps, and I like the fact that my Alpha docs know they belong to Alpha, my SAS docs know they belong to SAS, my Textures docs know they belong to Textures, and so on. \ Thus such a document has a best app with which to view it in as well as a \ number of acceptable ones. And in many many cases, the "preferred" app is the one with which the document was last saved. And in cases where this is not the case (Internet Explorer saves a GIF you want to edit with Color It!, say) it's a one-time operation to save the doc from the desired app and from then on it opens correctly. \ While the Mac users abhorance of file extensions is largely religious, \ it will probably need to be honored for the sake of a smooth migration \ path. However this could be as simple as hiding the extension from view \ in the Finder. BUT God forbid this should be done the same way as Windows NT 4. While the system _SHOULD_ hide extensions the user doesn't want, it should allow users and programs to name files with extensions which will remain visible. Otherwise, you're squinting at icons to determine which of the three "myprog"s is myprog.sas, which is myprog.log, and which is myprog.lst. Maybe the _real_ solution is to come up with a different extension separator (say a \?), keep the . as a generic character usable anywhere in a filename, use the \ to demarcate the "extension", and have a utility encouraging users to remove any \ characters they may have used in file names. (I just checked my 10,000-file hard drive, and no files contain the \ character, even though it's a legal Mac filename character.) To solve the multi-user problem with creator codes, maybe each user could have a farily small personal database mapping selected type/creator combos to other creators that know the relevant type. This shouldn't be too much overhead... after all, I don't know that there are _that_ many situations where users will want this... certainly not so many that such a table (think MacOS Easy Open, or Internet Config's helper apps) would become cumbersome. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: jm041536@fhda.edu (Joaquin Menchaca) 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: 15 Feb 1997 00:36:42 GMT Organization: De Anza College Message-ID: <jm041536-1402971632160001@mencjo.apple.com> References: <MWRon-2701971033010001@aumi1-a12.ccm.tds.net> <tesuji-1102971354300001@asd16-10.dial.xs4all.nl> <MWRon-1102971733180001@208.137.76.136> > > I'm afraid not, The available targets referred to in the CodeWarrior > Latitude are the Sun Microsystems' Solaris 2.3+, Silicon Graphics(R)' > IRIX(TM) 5.2+ and Hewlett-Packard(R)'s HP-UX(R) 9.03+. So now MW is supporting Unix platforms? Please do not ignore the Intel platform (UnixWare/Solaris, Linux). Also will MW port PowerPlant to X/Windows? Motif? CDE? > > Metrowerks CodeWarrior Gold will continue to support MacOS and Windows and > Rhapsody. > What about the BeOS? Will MW still support the BeOS? Please, Please, don't abandon the BeOS. -- ############################################################### # My opinions are my own and not of any I work for. # ############################################################### # WARNING: DO NOT send unwarranted mail or SPAMS! Further # # proceedings of sending unwarranted email or spams will # # result in fines up to $1000 in damages. # ###############################################################
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: "static inline" methods would be nice ... Date: 14 Feb 97 21:32:47 Organization: Is a sign of weakness Distribution: comp Message-ID: <SHESS.97Feb14213247@howard.one.net> References: <SHESS.97Feb14084803@slave.one.net> <5e2pd5$lii@newsread.onramp.net> In-reply-to: woodward@onramp.net's message of 14 Feb 1997 22:36:21 GMT In article <5e2pd5$lii@newsread.onramp.net>, woodward@onramp.net (John Woodward) writes: In article <SHESS.97Feb14084803@slave.one.net>, shess@one.net (Scott Hess) writes: > With the Pentium optimized gcc, it presumably can also schedule > things. > What Pentium opts are these? Where can I find them? It's a version of gcc 2.7.2 compiled for NS3.3, with the patches from http://www.goof.com/pcg/ applied to it. The goal of that page (pcg==Pentium Compiler Group) is to do a version of gcc which does optimized scheduing for Pentium (and perhaps Pentium Pro). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused title: The Zen of Dummies in a Nutshell in Seven Days>
From: bcollett@hamilton.edu (Brian Collett) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 15 Feb 1997 10:02:49 -0400 Organization: Hamilton College Message-ID: <bcollett-ya023580001502971002490001@news.hamilton.edu> References: <5ddp66$jpc@news.bu.edu> <32FD69A5.673A@subsequent.com> <32FF770C.6601@mcs.com> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5e03pp$thl@portal.gmu.edu>, tfs@gravity.science.gmu.edu ( Tim) wrote: > > Under the current NeXT/bsd filesystem, a file with one character > in it takes up 2 bytes. > -rw------- 1 tfs 2 Feb 13 17:08 foo > > So it's feasible to have allot of small files, hell that's what > losenet news is, lots and lots of small files, many smaller than > the rather huge 32K that you're used to... > Are you sure? The normal unix ls command does not show you the amount of disk space that file uses, only the number of bytes used in the file. You have to use du to find out how much space the file takes but it is normal for unix to have blocks sizes of 512 to 1024 bytes. I haven't used a Next machine but this is the case on many unix systems. Brian.
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 15 Feb 1997 15:56:55 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5e4mc7$86l@nef.ens.fr> References: <5ddp66$jpc@news.bu.edu> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> <bcollett-ya023580001502971002490001@news.hamilton.edu> In article <bcollett-ya023580001502971002490001@news.hamilton.edu>, Brian Collett <bcollett@hamilton.edu> wrote: >Are you sure? The normal unix ls command does not show you the amount of >disk space that file uses, only the number of bytes used in the file. You >have to use du to find out how much space the file takes but it is normal >for unix to have blocks sizes of 512 to 1024 bytes. I haven't used a Next >machine but this is the case on many unix systems. You can use ls -s to see te real space the file takes (and it is always less than the apparent file size : $ mkdir temp $ cd temp $ cat > foo a $ ll foo -rw-r--r-- 1 jalon 2 Feb 15 16:53 foo $ ll -s foo 1 -rw-r--r-- 1 jalon 2 Feb 15 16:53 foo $ du . 2 $ --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Sat, 15 Feb 1997 12:52:16 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> In-Reply-To: <3303B296.6C6@acm.org> Excerpts from netnews.comp.sys.next.programmer: 14-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >> That's what I said, yes. In general, this only happens when someone's >> system was very low on disk space to start with. If you make sure that >> you've got 100 MB free where you swap to, you're not going to have >> problems. > > Well rebooting is an admission of failure in the OS, either by implementation > but even worse by design, and in this case it sounds like it's by design. Operating systems fail when the machine is not provided adequate resources for the tasks that it's supposed to perform. Polite operating systems fail in a reasonably graceful way that may even allows you to correct the problem without rebooting, which is what NEXTSTEP does. Other operating systems tend to panic or lock up. >> Handle how? Specificly what should the OS do when open() fails instead >> of returning EACCESS? > > I explained that in my original post... to explain, the OS is responsible > for maintaining the environment and resources within which an application > runs. If the operating system is not handling such common cases > and expecting an application to handle them, it is not providing > a very good environment, and so its whole raison d'etre for existence > is in question. Apparently, you seem to think the OS should ask the user via an alert panel to browse the filesystem in order to specify where the missing file is. Do you agree that this was your suggestion? But what happens if there isn't a user? Should the process block indefinitely until someone notices that the machine is wedged? What happens if the file exists, but the OS refuses to allow the process to access the file because the process does not have the appropriate permissions? Are you saying that it's the OS' responsibility to allow the process to access the file anyway? [ ... ] >> I assume you're just talking about the first case, where malloc() fails. >> Polite applications warn the user that they couldn't get the memory >> they needed, and they abort the operation being attempted, and return to >> their main event loop. > > Since this is a case that should be handled by every running task, > why burden the application programmer with this task: Because not all tasks will want to handle a particular error condition in the same way? [ ... ] >> You've acknowledged that the OS should not perform inappropriate actions >> when encountering an exception since you gave the specific example of >> killing processes, but you don't appear to realize that your suggestions >> that the OS perform some other action beyond reporting the exceptional >> condition means that the OS will do things which are inappropriate for >> some tasks-- thus, the contradiction. > > No, you don't make sense here: you are attempting to contrive some > contradition. If the OS reports the problem, it is asking the user > for some help, without having to bother the application. And the > kinds of conditions I am talking about are problems with resources, > the exact entity that it is the OSs job to manage. In order to > prove your asserted contradiction you would have to show what is > inappropriate for the OS to handle in any of the example scenarios > I have given. Very good. I'll be happy to do so: Consider a machine like a web server, which does not have a user or administrator on the console. It's the responsibility of the programmers to write the web server so that it returns a 4xx code indicating that the requested resource was not found. It would be completely inappropriate for the web server to stop running and pop up an alert panel that some file could not be found, and wait for someone to tell the program what to do. >>>> How should the OS handle these exceptional conditions? Are you saying >>>> the OS should do the same thing to every process when those errors >>>> occur, instead of passing the error condition to the process and letting >>>> the process decide for itself what should be done? >>> >>> Yes, because many of these things are so common. Why clutter >>> applications just to make up for deficiencies in the OS? >> >> You're dodging the question. It's remarkably easy to claim that the OS >> is deficient, but it's much harder to define alternative behavior that >> the OS should perform that's generally useful for all processes. > > Um, I think I answered yes... how is that "dodging the question"? I have > also defined what the OS should do. Your suggestion for what the OS should do when a file is not found is inappropriate for some tasks, and you haven't given any specific suggestions for what the OS should do when the other two types of exceptions that you brought up as examples occur. > What more do you want, apart from an argument and a boring Internet > flame war? Please stick to the substance. I have been sticking to the substance, while you have not substantiated your claims. If you object to being flamed, I would suggest either coming up with better arguments or not using provocative phrases (for example, "technically deficient"). [ ... ] >> The two aren't mutually exclusive by any means. Right now, we've got >> someone from Unisys who is extolling the virtues of Unisys as "a real >> OS", and slamming other operating systems as "technically deficient". > > No, take out your emotionally provokative tone like "slamming". And precisely when were you going to take out _your_ emotionally provocative tone from phrases like 'technically deficient' or 'a real OS'? Why are you complaining when I've simply responded to your argument using a tone and rhetorical style which is quite similar yours? > I have made some points and given examples, I can't see that who I work > for disqualifies me from this. I didn't say you were disqualified from anything; I said you were biased. Who you work for is certainly relevant when you are employed by Unisys and you start talking about Unisys as a 'real operating system' in contrast to some alternatives. Regardless of whether you choose to admit it or not, you _are_ biased. > Remember, Unisys is a large Unix vendor > as well, so stay off your high horse as your comments are just silly. > You are being personal, please keep it to technical points. Pointing out that your arguments are biased is not a personal attack, since it's obviously relevant to the arguments you've been making. Aside from the issue of bias, where have I been personal? [ ... ] >>> If Apple wants to adopt NeXT and Mach, then it had better be fully >>> aware of the technical deficiencies of Unix, or Apple will lose its >>> edge of superiority. >> >> What "technical deficiencies" are you talking about, and precisely what >> "edge of superiority" did Apple and MacOS have over the NEXTSTEP (which >> is a Unix) operating system? > > Because MacOS made computers useable. There are good things about > Nextstep, but you should be careful about inheriting all the problems > of Unix. You're dodging the question yet again. Specificly, what are all of these "problems of Unix" that Apple might inherit? Specificly, what "technical deficiencies" are you talking about? -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.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 15 Feb 1997 13:08:13 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> In-Reply-To: <5dtpb5$h4t@news.bu.edu> Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & Unix: File S.. by John Siracusa@bu.edu >: It doesn't make sense when files and applications can be used >: by multiple users. > > I don't see how that is. File type and creator information doesn't > vary from user to user. While that is true, the Mac paradigm uses that information to make the decision as to which application should open a particular file. The Mac paradigm doesn't work very well when you consider a multiuser operating system because individual users should be able to decide for themselves which app should open a file and not have their decisions change what happens to other users. > If you're talking about the type of thing that is stored in preference > files on the Mac, then the logical solution is to have separate > preference folders for each user. Correct. That is what NEXTSTEP currently does-- the Workspace keeps track of the preferred opening application within a set of preferences files within each user's home directory. > This doesn't really apply since, abilities aside, Rhaposdy will > be targeted as a single-user system from what I have read. Rhapsody will undoubtedly work just fine as a single-user OS, agreed, but Rhapsody is almost certainly going to be multiuser. It's very easy for a multiuser OS to act like a single-user OS, as NEXTSTEP did with the default 'me' user. The reverse is not true, and it would be a very bad move on Apple's part to not make Rhapsody multiuser. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer,comp.sys.next.sysadmin,comp.sys.next.software Subject: Need Adaptec2940SCSIDriver.config v 3.37 Date: 15 Feb 1997 20:05:13 GMT Organization: The Ohio State University Message-ID: <5e54tp$lm2@charm.magnus.acs.ohio-state.edu> I believe I need a newer version of the Adaptec2940SCSIDriver.config than the one on the 3.3 installation disks. If anyone hase v 3.37 or later, could you please NeXTMail me a copy? Thank you. 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: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer Subject: Mac/NeXT & Unix: New Information Date: 15 Feb 1997 20:22:32 GMT Organization: Boston University Message-ID: <5e55u8$7td@news.bu.edu> From MacWeek: Sources in the boiler room report that Rhapsody will weigh in at about 110 Mbytes of pure chewing satisfaction and come with three levels of Install: EZ, Minimal and Custom. Even better, Mac users can install a version of Rhapsody that will not include a path to Unix, so they never have to soil their hands with the greasy innards of the new OS. --- Interesting... -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: cuahb@DIESPAMDIE.bgu.edu (Adin Hunter Baber) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 15 Feb 1997 16:10:36 -0600 Organization: Eastern IL University Message-ID: <cuahb-1502971610510001@eiuts15.eiu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> Teh main points of this thread seem to me to be: 1)should we keep the resource fork? and 2)how will the file system work in a multi-user environment. 1) I think the resource fork is an interesting idea, for the purposes of storing "meta-info." however, we need to remeber that the resoucre fork contains other info, such as icons. As a programmer going from DOS to Mac, I think the resouce fork is great, as it simplifies some programming aspects. 2)As a person whom owns a Mac that is used by three different people all the time, I think I am somewhat knowledgable on the multi-user aspect. The creation/prefereed program of a document does not cause us any problems. This is mostly due to a launcher palette that I keep on the upper left side of the screen. If somebody wants to open a file from other than its creator app, drag it to the launcher, and its opened. Its not that hard, when you have a place for all of your aliases to be kept. BTW, my launcher has aliases for around forty different apps, organized into six diferent sets, each containing 3 to 8 aliases. So, I find the complaint "that I sould be able to have opened in whatever app I want by double clicking" a little trivial. With my setup, drag-and-drop is as easy as double clicking. In fact, with my setup, I don't even have to click more than twice: first click to go the the right set (assuming its not already there) and the second click is to drag the doc's icon to the launcher. OTOH, the only time I have found a need to have a completelt different setup needed for different users are for prefs for a few apps. Most of these apps are games, or for internet use. Which means to me, what keyboard setup do I want for each game, or who is doing the posting to newsgroups. I think this could be implemented quite easily by simply having a few different prefs folders and a control panel to determine which prefs folder is being used. Hell, this could be done right now if someone wanted to make it for System 7. The only advantage of having it fully integrated into the OS would be that you could save completly different "looks" for the desktop. For example: the System 8 preview CD-ROM. -- Adin Hunter Baber cuahb@bgu.edu Please remove DIESPAMDIE before replying 'The more I learn, the more I learn how little I know' --Socrates
From: recurve@resourceful.com Newsgroups: comp.sys.next.programmer Subject: cc++ question Date: Sat, 15 Feb 1997 20:40:26 GMT Organization: Rosenzweig Investments Message-ID: <E5nw3F.GD@xombi.wizard.net> I'm trying to compile what should be a simple C++ program on NeXTStep 3.2 xombi.wizard.net> cc++ main.cc main.cc:86: warning: return type for `main' changed to integer type ld: Undefined symbols: endl(ostream &) _cerr ostream::operator<<(const char *) ostream::operator<<(ostream &(*)(ostream &)) _cout ostream::operator<<(int) ostream::operator<<(char) xombi.wizard.net> Why is the linker having a problem? Thanks! --- Son of Ginger and Harry, Aaron Rosenzweig http://www.wam.umd.edu/~recurve/ recurve@resourceful.com
Date: Sat, 15 Feb 1997 17:41:04 -0600 From: Dan_Tapp@w3link.com Subject: CGI Handling of Interrupted Transfer Newsgroups: comp.sys.next.programmer Message-ID: <856049492.27218@dejanews.com> Organization: Deja News Usenet Posting Service Hi, all. While I was awaiting our development copy of WebObjects 3.x and other goodies, I busied myself with a small DO project on NS 3.3/Mach/Intel as a learning exercise; namely, a daemon-stub kit for CGI services under Apache. The ddcgi (DILAN Distributed CGI) object, when invoked, knows how to: *Decode URL-encoded special characters characters, *Attempt a connection with a remote object (a "ddcgiDaemon" whose name is part of the URL-encoding), *Pass the CGI environment (including GETted and POSTed values) to the daemon as an NSDictionary of name-value pairs, *Emit standard http headers back to the browser, and *pass HTML from the daemon to the browser, before breaking the connection and terminating. And, in the event the named daemon can't be found, the ddcgi object can emit some explanatory HTML. This little playkit actually got pretty useful to us, and now that I'm ready to move on into WebObjects, I find I need to keep a couple of intranet systems which are based on it up and running. The trouble is, I modified one of the CGI processes this week to send down a fairly large table, and I've discovered that, if a user hits the browser's "stop" button to interrupt a long HTML transfer, it crashes everything all the way back to and including the daemon. I have the daemon's toplevel process (the one invoked on each CGI call) wrapped in an inelegant-but-hardy exception handler..namely, it just tosses the bad connection, bleats a warning to the console, and moves on. It's ugly, but it works...while the cgi stub gave me fits and starts as I learned my way around, it's been hard to bonk one of the daemons, until now. Although I don't know PERL, I have read some sample code, and I conjectured that standard CGI processes don't have to worry about interrupted transfer, i.e. the http server sees the break message from the browser and gracefully accepts (and tosses) the remaining HTML output from a discarded CGI instance, until the instance finally shuts up and goes away. Based on the little knowledge that I've gleaned so far, my conjecture is still sound, and I should be concerned with an Apache configuration issue, rather than error-handling in the CGI stub itself. Does anyone have any comments on my predicament? Thanks & regards, - Dan -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
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: <413853649874@digifix.com> Date: 16 Feb 1997 02:23:10 GMT Organization: Digital Fix Development Message-ID: <22496856059808@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: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Referencing externs from loaded bundle on OpenStep/NT - how? Date: 16 Feb 1997 05:01:45 GMT Organization: Netcom Distribution: world Message-ID: <5e64bp$t62@dfw-ixnews12.ix.netcom.com> References: <vbd8u4mz3j.fsf@eldar.arc.ab.ca> <vbbu9omp4d.fsf@eldar.arc.ab.ca> schack@eldar.arc.ab.ca (Brian Schack) wrote: > Well, I've just discovered the answer. The answer is given by NeXT's > OPENSTEP/NT Developer FAQ, Entry Number: 2462, under the question: > > Q: Why do I get a segmentation fault when trying to use a bundle? > > A: There is a problem with code in a bundle trying to access global > variables in the main application. Typically, when the bundle > code tries to access the global variable, you will get a > segmentation fault. The solution is to put these global symbols > into a framework and link both the application and the bundle > against the framework. You must also implement additional > declarations (given in the next question) to export symbols other > than class and category names from your frameworks. This "hack" works for global variables, but how does one, in a dynamically-loaded module, subclass a class that's defined in the main executable? For example, IB defines attributes inspector classes for various UI objects (e.g. IBButtonInspector). Under Mach, we take advantage of this inspector classes when we write palettes that contain button subclasses. We start with the button attribute inspector nib included with IB, unparse the inspector class to generate a suitable header, subclass and add one or more ivars. We add an appropriate UI to the standard button attribute inspector panel, change the class of the File's Owner to our own IBButtonInspector subclass, build, and load into IB. Works great under Mach. But under OS/NT, our IBButtonInspector subclass fails to build due to a link error: IBButtonInspector not defined. Certainly there must be a "hack" that will solve this problem. Since source to IB isn't available, we can't create a DLL that defines IBButtonInspector and load that into our palette. Any suggestions? -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 OPENSTEP/NT Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: New Information Date: 15 Feb 1997 18:44:44 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5e5hpc$isr@csugrad.cs.vt.edu> References: <5e55u8$7td@news.bu.edu> In article <5e55u8$7td@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > Even better, Mac users can install a version of Rhapsody that will not > include a path to Unix, I.e., Terminal.app? > so they never have to soil their hands with the > greasy innards of the new OS. Boy, would that be a mistake. Better to install it (possibly in some out-of-the-way place that you'd never notice) and just not use it. It might come in handy someday if your system gets totally hosed and the tech-support guy needs to tell you to go in and fix something. I'm sure that Apple can come up with nice GUI replacements for most routine administrative tasks, but I doubt they'd be able to handle every contingency and bizarre way in which you might screw up your system. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Marc Slemko <marcs@znep.com> Newsgroups: comp.sys.next.programmer Subject: making Apache work with NeXT Date: 16 Feb 1997 10:02:34 GMT Organization: University of Alberta Message-ID: <5e6lvq$mp2@pulp.ucs.ualberta.ca> There is no one in the Apache development group that uses the NeXT platform a lot. That means that we have no clue how to make it work properly on various versions of the NeXT OS. I don't even know what these versions that we should worry about may be. We added some fixes to the previous beta that fixed some things on some NeXT boxes but broke the compile on others. I would guess that there are a bunch of different versions around that have incompatabilities between them. The currently released beta is available at: http://www.apache.org/dist/apache_1.2b6.tar.gz We have reports of it failing with: In file included from http_main.c:108: /NextDeveloper/Headers/bsd/netinet/tcp.h:57: duplicate member `th_off' /NextDeveloper/Headers/bsd/netinet/tcp.h:58: duplicate member `th_x2' make: *** [http_main.o] Error 1 I would appreciate it if people who have some experience with various versions of the OS and porting software to it could test this and suggest changes that will make it work on the widest possible range of NeXT boxes. Note that I have no way to test these myself, but will try to get some idea of what is the right way and fix it for the next beta. Thanks.
Newsgroups: comp.sys.next.programmer From: piers@ilink.de (Piers Uso Walter) Subject: Re: Mac/NeXT & Unix: File System Message-ID: <E5no2r.HG0@mediahaus.de> Sender: news@mediahaus.de (News System) Organization: Mediahaus Stroebel in Duesseldorf (Germany) References: <5e3bou$emo$1@newz.oit.unc.edu> Date: Sat, 15 Feb 1997 17:47:14 GMT In article <5e3bou$emo$1@newz.oit.unc.edu> scocca@gibbs.oit.unc.edu (Dave Scocca) writes: > > Maybe the _real_ solution is to come up with a different extension > separator (say a \?), keep the . as a generic character usable > anywhere in a filename, use the \ to demarcate the "extension", and > have a utility encouraging users to remove any \ characters they may > have used in file names. (I just checked my 10,000-file hard drive, > and no files contain the \ character, even though it's a legal Mac > filename character.) Well, there's nothing that keeps you from using a . in a filename in OPENSTEP. I regularly use filenames like 970212.financing.rtf, 970214.shortterm.imp, and 970215.landscape.jpeg (the extensions being rtf, imp and jpeg respectively). Thinking about this I only see two limitations: 1. file name extensions may not contain a . 2. filenames that should have no extension may not contain a . -- -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=- "I think people are happy using Windows, and that's an extremely depressing thought." -= Steve Jobs, 1/96 =- Piers Uso Walter ilink GmbH piers@ilink.de -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-
From: markr@connor-clark.com (Mark Ritchie) Newsgroups: comp.sys.next.programmer Subject: Re: Tutorial Question Date: 13 Feb 1997 15:14:43 GMT Organization: eConnect Message-ID: <5dvb53$705$1@news1.econnect.ca> References: <AF1CE740-3F5BCF@206.101.238.18> "Mark Jenkins" <markj@inwave.com> writes > [munch...] > However, when I click the Convert Button the result that is placed in > the "Amount in Other Currency" field displays :NaN (What does this > indicate?) > What did I do wrong? NaN means 'Not a Number'. You've probably missed a connection in IB. Check that the 'Amount in Other Currency' field is actually connected. Hope that helps... M. -- Mark Ritchie - OPENSTEP Developer - Diamond Lake Consulting Currently under contract to Connor, Clark and Co. Ltd. email:markr@connor-clark.com phone: 416-956-9325
From: jrichmond@i-way.co.uk (Jeff Richmond) Newsgroups: comp.sys.next.software,comp.sys.next.programmer Subject: tcpdump 3.0 - won't recognize en0 Date: Sun, 16 Feb 97 22:21:01 GMT Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Message-ID: <5e819k$pe9@join.news.pipex.net> Keyword: tcpdump, ethernet Hi folks. I've successfully compiled tcpdump 3.0 including the Berkley Packet Filter that comes with it. When I try to run it, I get the following: en0: No such device or address In gdb, its get to a line in pcap-bpf.c with the following: ioctl(fd,BIOCSETIF, (caddr_t) &ifr); This call is failing for some reason but I don't know why. The ifr structure has a valid ifr_name = 'en0'. Any ideas? Oh, I have also created devices in /dev for bpf0 and bpf1 under number 32. I just did a mknod, don't know if anything else is requried there ... note that I have installed the bpf LKS that comes with PPP, should I not load that? Cheers, Jeff Richmond
From: frank@this.NO_SPAM.net (Frank M. Siegert) Newsgroups: comp.sys.next.software,comp.sys.next.programmer Subject: Re: tcpdump 3.0 - won't recognize en0 Date: 16 Feb 1997 23:03:49 GMT Organization: Frank's Area 51 Message-ID: <5e83ol$bi7@bias.ipc.uni-tuebingen.de> References: <5e819k$pe9@join.news.pipex.net> Cc: jrichmond@i-way.co.uk In <5e819k$pe9@join.news.pipex.net> Jeff Richmond wrote: > Hi folks. I've successfully compiled tcpdump 3.0 including the Berkley Packet > Filter that comes with it. When I try to run it, I get the following: > > en0: No such device or address > > In gdb, its get to a line in pcap-bpf.c with the following: > > ioctl(fd,BIOCSETIF, (caddr_t) &ifr); > > This call is failing for some reason but I don't know why. The ifr structure > has a valid ifr_name = 'en0'. Any ideas? Oh, I have also created devices in > /dev for bpf0 and bpf1 under number 32. I just did a mknod, don't know if > anything else is requried there ... note that I have installed the bpf LKS > that comes with PPP, should I not load that? > > Cheers, > > Jeff Richmond > See the NS BPF package on http://www.this.net/~frank/next_cap.html as it was adapted/rewritten by Satoshi Adachi (or the original site in Japan at ftp://ftp.aa.ap.titech.ac.jp/pub/adachi/ ). A vanilla BPF will not work on NS. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Mon, 17 Feb 1997 10:33:12 +1100 Organization: Unisys Message-ID: <33079938.783E@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Barnet wrote: > > Ian Joyner wrote: > > > But in this case I expect the OS to alert the user to decide to close > > down certain processes. This decision is beyond the operating system > > to make, and it is certainly far beyond the scope of an application > > program. > > Which user? Your assumption will only hold for a desktop system. Well no, it holds for multi-user systems. In production systems an error will be reported to the user of the process, but they will probably not be able to change the environment due to security restrictions. So the system operator will probably also be notified. But here we really are getting into matters of policy in how a particular site is run. However, the point is that what I am suggesting applies to both single user and multi user systems. > Furthermore, there's no guarantee there will be a user. What about > systems that sit in a closet and sling bytes (we call them servers)? > Having a message pop up that says "A program can't get enough memory, > which of these 500 processes should die" is not acceptable as > > 1) No one's at the box This is a good point, but then what is your program going to do? After all processes have the same security restrictions. The only way is to ask for manual resolution from someone who has enough security clearance. > 2) who decides what dies? - If any Joe User can go postal because his > program has asked for too much memory then we have a completely > unacceptable security problem. The sysadmin will not likely be > sitting in front of the box - what now? Well to start with, you might not have to kill anything. An experienced operator might have other tricks that can bring the system back to an acceptable mode. This could be suspending certain processes (such as compiles say) to allow other processes to run to completion and free up memory. And your average Joe User will probably not have priviledges to abuse the system. > > So what is the application program going to do because a > > malloc has failed due to environmental factors beyond its control? > > > > Fail gracefully: log an error message (in a logfile or errorfile) > and exit. Yes, but let's try everything else first. Never should the first process that receives an out of memory error just be told to die gracefully. It might be some other process that has gone rampant that is causing the problem. The approaches taken by Unix and most other OSs seem inherently dangerous to me. Supposing that the process terminated is critical. In this case the operator has not been given the chance to suspend or terminate other non-critical processes. > The alternative you describe assumes (at least) two things: there's a > user at the box all the time, the user at the box is able to make an > acceptable decision. In multi-user environments those assumptions simply > don't hold. I think you are talking about 'batch' environments. In that case you have to decide in advance in which ways your system will degrade, and maybe you might implement an auto manager which knows what is running in the system, and manages those resources. If certain problems occur, it can use some heuristics for getting out of the mess. If you don't have this, you must rely on human intervention. Whether a system is batch, multi or single user, it is just unacceptable to terminate a process due to resource shortages. You might be executing an innocent victim. ------------------------------------------------------------------------ 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: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: Broken Pipe? Date: 16 Feb 1997 23:33:03 GMT Organization: Rockwell Avionics - Collins Message-ID: <5e85ff$r8h@castor.cca.rockwell.com> References: <5co1u2$kpn$1@inet-prime.comshare.com> <E5LI4I.IsG@icgned.nl> Cc: hansm@icgned.nl > The most common problem in this type of exercise is stdio buffering in the > shell script. You'd test the shell script in a Terminal window and it'll > work fine (because then you get line buffering). Then you use it at the > far end of a pipe and it'll fail, because then you get block buffering. > > A few unix utilities allow you to turn off buffering, for example cat uses > the -u option to do that. But cat is in a minority here. > > It would be nice if there were a way to tell stdio to not buffer the stdout > stream (an enviromnet variable maybe?). AFAIK, there is no such mechanism. > > Hope this helps, > > -- HansM > Use fflush() to force buffer flushing. Use setbuf() to get control of buffering.
From: Bill Keller <kellerw@okstate.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Windows Native Controls through OpenStep ? Date: Mon, 17 Feb 1997 07:52:29 -0600 Organization: Oklahoma State University, Stillwater OK Message-ID: <3308629D.2DAC@okstate.edu> References: <3326541822.31250673@cornut.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roger Flattin wrote: > I'm asking these questions because we are looking at OpenStep to develop > client/serveur application which doesn't make intensive use of graphics. Some > we have no direct need to use DPS. Then you should use d'ole. It lets you build back-end ole objects using Objective-C and FoundationKit, but you can use anything to do the front end. D'ole comes with interface examples for C++ and Visual Basic. D'ole comes with Openstep enterprise. -- Bill Keller (kellerw@okstate.edu) ---------------------------------
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 16:25:34 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fmlll.nv0.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <5dfhrg$73v@horus.ecmwf.int> On 7 Feb 1997 15:30:56 GMT, Mike Connally <syy@ecmwf.int> wrote: >In article <5dbfr3$g10@dismay.ucs.indiana.edu>, glhansen@copper.ucs.indiana.edu >(Gregory Loren Hansen) writes: >|> If Apple put a nice GUI on any Unix, and provided control panels and menus >|> to manipulate and administrate the system, you'd never know. > >You're forgetting the second (or maybe the first) major >advantage of MacOS over UNIX: the filesystem. A pretty >face can be painted on UNIX, in theory (if not yet in >practice), but injecting a robust object-oriented filesystem >is another matter entirely. Unlike other environments, has anybody taken a closer look at Linux? Linux can support a sh*tload of filesystems *NOW* (though Apple's HFS ain't one of them- yet) so there's nothing implicit in Unix that makes this impossible. Unix has had a tendency to make a file a simple "array of bytes" making the internal structure of a file something the OS doesn't pay attention to. It can be argued that placing aheader on a file will do the trick (as is used w/i Thoroughbred BASIC and other such systems) but this denies the ability to use existing filters on a file. If you hide the resource fork w/i the filesystem, there is a call named ioctl() that allows additional information about a file (usually devices) to be accessed; A file system that allows this normal system call to manipulate the i-node of a file (so we'd have to update the inode structure; Big Deal) would render the Unix system Mac-friendly. >UNIX filesystems typically provide no metadata structures >analogous to the MacOS resource forks. BeOS attempts to >provide something like this, but I believe it's done with >a bolt-on database, not as a native part of the filesystem >structure. NeXT may do something similar (I don't know) >but again, it's likely to be a bolt-on. Like I point out above, this isn't that big a deal. Sure, it's kinda like an add-on (though it isn't really, since it'd be an embedded feature of the file system) but it's a part of the system as a whole. We just use the i-node table as a database. If Linux's ext2 file system is ready for ACLs, there's nothing stopping it from acquiring the "resource fork" or other extended information about a file... >Rhapsody must provide all of the human interface correctness >of MacOS along with at least as good a filesystem architecture >before I'll be interested. So? Unix *has* a very powerful file system paradigm that is easily mutated to take on the feature(s) you're looking for. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 16:30:37 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fmlv4.nv0.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> <5ddtva$u31@csugrad.cs.vt.edu> On 6 Feb 1997 19:45:30 -0500, Nathan M. Urban <nurban@csugrad.cs.vt.edu> wrote: >In article <5ddpn1$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > >> As I stated in my original post, a POSIX subsystem is fine. A Unix >> directory tree appearing on my hard drive after a standard install is >> not. > >I don't understand why not, considering that it doesn't take up that >much more disk space, allows you to run any Unix programs you may wish >to run in the future, is required by the OS to boot and do other >administrative things, and doesn't even need to be seen by you. If you don't want your user to see the "Unix Tree" it's real simple: hide the directories. Either that or the "system folder" would provide a symlink to the true root directory while a user normally lives only in his "home" directory (sure, there's only one user, so big deal!). Perhaps some MacUsers cannot handle the *concept* of a CLI that provides additional visibility... There are enough times w/ Windoze where I'm so impatient I just open up a DOS CLI and deal with the actions I want to take instead of banging my brains out against the File Mangler. While the Mac is more mature, there *are* times when I wish I had a Unix-like toolset for doing dirty deeds. Mind you, I've an extensive MS-DOG toolset that's based on Unix, much of it written by me... -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 16:32:31 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fmm2m.nv0.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <5dal9c$bd1$3@majipoor.cygnus.com> <jk-0602972223190001@ip-salem3-30.teleport.com> On Thu, 06 Feb 1997 22:23:19 -0800, Joel Klecker <jk@esperance.com> wrote: > >Hmm, I wasn't aware that "Reality Distortion Field.app" shipped with >NEXTSTEP. :-) I though Jobs was a walking reality distortion field... Though I've worked in a place where a manager had the honesty to refer to the conference room as the "holodeck". -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: rpk@world.std.com (Robert P. Krajewski) Subject: Re: Mac/NeXT & Unix: File System Sender: news@world.std.com (Mr Usenet Himself) Message-ID: <rpk-ya02408000R1602972229410001@news.std.com> Date: Mon, 17 Feb 1997 03:29:41 GMT Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 References: <5dtd3v$pc2@csugrad.cs.vt.edu> <2938717302@hoult.actrix.gen.nz> <handleym-1302971711510001@handma.apple.com> Mime-Version: 1.0 Organization: The World @ Software Tool & Die In article <handleym-1302971711510001@handma.apple.com>, handleym@apple.com (Maynard Handley) wrote: >However NTFS has unlimited extended attributes which could trivially be >used to hold creator/type info, multiple forks etc. Yes, NTFS definitely supports multiple forks (as multiple data streams). It would be cool if the canonical Rhapsody file system could support all the properties that MacOS HFS does.
From: dfrick@lava.net (Doug Frick) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sun, 16 Feb 1997 17:51:42 -1000 Organization: LavaNet, Inc. Message-ID: <dfrick-1602971751420001@poha014.lava.net> References: <5ddp66$jpc@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5e3bou$emo$1@newz.oit.unc.edu> In article <5e3bou$emo$1@newz.oit.unc.edu>, scocca@gibbs.oit.unc.edu (Dave Scocca) wrote: [...] >Maybe the _real_ solution is to come up with a different extension >separator (say a \?), keep the . as a generic character usable >anywhere in a filename, use the \ to demarcate the "extension", and >have a utility encouraging users to remove any \ characters they may >have used in file names. (I just checked my 10,000-file hard drive, >and no files contain the \ character, even though it's a legal Mac >filename character.) This prompts me to ask some questions: -- What will happen with directory/folder syntax in fully qualified filenames in Rhapsody? I.e., Projects:hacks:foo.c v. /projects/hacks/foo.c. -- What about case sensitivity in filenames? -- What about newlines? What does NeXT use? CR v. LF: is it a problem? I suppose that when Rhapsody switches to a new file system, then some sort of API and translation layer could handle some of this. But I haven't seen any commentary on these issues yet by anybody. -- Doug Frick dfrick@pfr.com dfrick@lava.net
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Mon, 17 Feb 1997 15:34:50 +1100 Organization: Unisys Message-ID: <3307DFEA.2FB0@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@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.programmer: 14-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > > Well rebooting is an admission of failure in the OS, either by implementation > > but even worse by design, and in this case it sounds like it's by design. > > Operating systems fail when the machine is not provided adequate > resources for the tasks that it's supposed to perform. Polite operating > systems fail in a reasonably graceful way that may even allows you to > correct the problem without rebooting, which is what NEXTSTEP does. > > Other operating systems tend to panic or lock up. If NextSTEP does this good. However, don't lump all other OSs into the panic and lock up variety. OSs should provide a decent level of resilliance to resource failure. However, you are right that there comes a point when failure will occur. How does an OS cope with ... whoops all my processors just disappeared. Or if the disk where a critical OS segment must be loaded from disappears (unless you have sufficient replication). > >> Handle how? Specificly what should the OS do when open() fails instead > >> of returning EACCESS? > > > > I explained that in my original post... to explain, the OS is responsible > > for maintaining the environment and resources within which an application > > runs. If the operating system is not handling such common cases > > and expecting an application to handle them, it is not providing > > a very good environment, and so its whole raison d'etre for existence > > is in question. > > Apparently, you seem to think the OS should ask the user via an alert > panel to browse the filesystem in order to specify where the missing > file is. Do you agree that this was your suggestion? Not exactly. The OS should ask the user/an operator what to do, locate the file, kill the process, ignore the file and continue. You have quite a few options. > But what happens if there isn't a user? Should the process block > indefinitely until someone notices that the machine is wedged? That is preferrable to killing the process, which is an extreme form of blocking and you will still have to wait for someone to come and fix it. Or do you mean that the process will be killed and automatically restarted. This is a possibility, but of course the condition that killed the original process might still be in effect. In this case the operator has a much harder job of trying to prevent the continual loop of [kill process; restart process]*. Whichever way you are still blocked. > What happens if the file exists, but the OS refuses to allow the process > to access the file because the process does not have the appropriate > permissions? Are you saying that it's the OS' responsibility to allow > the process to access the file anyway? NO! In that case the process gets a NO FILE. If access to the file is not there. I don't want to give someone a hint that it is actally present or not. That is a security violation in itself. In that case if the user has sufficient system priviledges, they could change the files permissions. Or in a multi-user environment, they could contact an operator who has priviledges. That is better than crashing the application system wouldn't you agree. Particularly if this is some kind of long calculation, database reorg, etc. > [ ... ] > >> I assume you're just talking about the first case, where malloc() fails. > >> Polite applications warn the user that they couldn't get the memory > >> they needed, and they abort the operation being attempted, and return to > >> their main event loop. > > > > Since this is a case that should be handled by every running task, > > why burden the application programmer with this task: > > Because not all tasks will want to handle a particular error condition > in the same way? But what I am saying is that you can do a good OS design by evaluating all those ways, and then giving the option (which might also include some automatic policy that circumvents the user/operator). > [ ... ] > >> You've acknowledged that the OS should not perform inappropriate actions > >> when encountering an exception since you gave the specific example of > >> killing processes, but you don't appear to realize that your suggestions > >> that the OS perform some other action beyond reporting the exceptional > >> condition means that the OS will do things which are inappropriate for > >> some tasks-- thus, the contradiction. > > > > No, you don't make sense here: you are attempting to contrive some > > contradition. If the OS reports the problem, it is asking the user > > for some help, without having to bother the application. And the > > kinds of conditions I am talking about are problems with resources, > > the exact entity that it is the OSs job to manage. In order to > > prove your asserted contradiction you would have to show what is > > inappropriate for the OS to handle in any of the example scenarios > > I have given. > > Very good. I'll be happy to do so: > > Consider a machine like a web server, which does not have a user or > administrator on the console. It's the responsibility of the > programmers to write the web server so that it returns a 4xx code > indicating that the requested resource was not found. > > It would be completely inappropriate for the web server to stop running > and pop up an alert panel that some file could not be found, and wait > for someone to tell the program what to do. Yes, but if you go back through my posts you'll find that I allow for that situation. Sorry, but I have deleted the rest of the post, it just smacks of a personalised flame war, which I don't want to get dragged into, is irrelevant and will bore most readers (and myself). ------------------------------------------------------------------------ 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: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 00:59:26 -0500 Organization: phenix@interpath.com Message-ID: <1997021700592626089546@roxboro-177.interpath.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: ] Excerpts from netnews.comp.sys.next.programmer: 12-Feb-97 Re: Mac/NeXT & ] Unix: File S.. by Peter Moller@dna.lth.se ] >> The reason it seems unthinkable is because it's not necessarily the ] >> real solution. You're talking about taking what is, at its core, a ] >> high-level mapping (applications to file types), and trying to ] >> embed them into a low-level system that has historically dealt only ] >> with the organization and management of the raw bits into ] >> directories and ] > ] > Well, maybee you are right, but let us at least agree that an update ] > of the file system in which a time stamp for *when the file was ] > created* (to complement the three time stamps that exist in the Unix ] > file system describing when the file was last accesses, modified and ] > referenced - if memory serves me) is added would be needed?! ] ] The "last modified" timestamp is generally used as the time when the ] file was created, and the two are equivalent in the case of files that ] have never been modified. If you care about keeping exact track of ] earlier revisions of a file for whatever reason, you can use a ] revision control system. It will keep track of all (or some) of the ] intermediate versions and their timestamps. ] ] Perhaps it's just me, but I don't see much value to preserving the ] timestamp of the creation date of the original version of a file when ] you don't actually have the original file-- just the modified version. ] Can you provide a real-world example of why you'd care about that ] timestamp? A very simple and quit answer is when you have two files with basically the same information and have modified both since their creation and want to know which file is newer. -snip busy file comments- ] > The UFS has it's strengths, especially when coupled with NFS over ] > TCP/IP, but that does not mean it cannot be improved. ] ] Certainly. I don't have any objections to augmenting the UFS in order ] to implement the Mac's current creator and filetype attributes. I ] think it's likely that Apple will do something along those lines ] because it would simplify the transition for Mac users who expect to ] see those in Rhapsody. ] ] However, those Mac attributes are not adequate for handling the ] document-to-application mapping under a multiuser OS for reasons that ] we've already been through. Given that this is the case, I expect to ] see that there will continue to exist something at a higher level ] which lets users select on an individual basis which applications they ] would prefer to have open various document types. I think the Mac attributes are ADEQUATE for d-t-a mapping, they just aren't spectacular. And to make it spectacular you HAVE to have the type/creator. Now how and where those 8 bytes are stored is a totally different question. And (of themselves) almost totally irrelevant. ] Such a system could rely on just the file extension if the Mac-like ] creator/filetype attributes are not available or are not recognized ] [consider a file that has been FTP'ed or is being accessed via a ] remote filesystem like NFS, AFS, etc], but could also pay attention to ] the Mac attributes if they are available and valid. That seems to ] combine the desirable features without changing the way either current ] Mac users or current NEXTSTEP users like to have things work.... I've seen this "accessed via a remote filesystem" argument used before and have never really understood it. If the computer at the other end is a Rhapsody machine then I'd expect the additional information to be passed along, if it isn't a R.M. then what kind of file is being accessed where the person getting it doesn't know what it is? -- John Moreno
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 7 Feb 1997 16:40:10 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45fmmh0.nv0.campbejr@phu989.um.us.sbphrd.com> References: <5d8qta$6np@news.bu.edu> <woody-0402972313420001@192.0.2.1> <5ddpn1$jpc@news.bu.edu> <32FAD8FA.2C40@subsequent.com> On Fri, 07 Feb 1997 02:25:46 -0500, "Jonathan W. Hendry" <jon@subsequent.com> wrote: >John Siracusa wrote: >> >> William Edward Woody (woody@alumni.caltech.edu) wrote: > >> : But get this: Mach is *NOT* Unix. Mach has been used to build a Unix >> : compatable OS, and most people tend to build off of a Unix client >> : built on top of the Mach kernel because that's what most of us >> : programmers are familiar with. >> >> Granted, kernel and system calls are fine. What I'm concerned about >> most is the support even simple Unix-isms like shell scripts require >> in order to work. IMO, this support system is not worth the small >> advantages that a few advanced users will receive because it constrains >> the rest of the OS too much. > >How, exactly, does it 'constrain the rest of the OS too much'? How, >exactly, has it constrained NeXTSTEP? AFAIK (non-authoritative, but I'll pontificate any chance I get) It's the *way* that NeXT implemented the resource/data forks for a file by hiding the file in a subdirectory. This qualifies as a hack and required re-working the "unix-like" utility set. Mach, being a micro-kernel architecture, provides greater ability to take advantage of multiprocessor systems (DEC Unix is a good case in point) and can wear a Unix-like face w/o difficulty (if you're gonna place one on); All that is needed is to intercept the SVID calls and map them onto the Mach API. What bugs me is that no effort was apparently expended on the file system; With the source for Mach would come the ability to doink with the file system internal structures, adding the desired "forks" directly to the file system. Remember, an OS is *not* a filesystem; It merely allows them to be layered on top of devices. What's most important it to take advantage of these layers in the most productive way possible. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: "Olivier Malcor" <olivier72@infonie.fr> Newsgroups: comp.sys.next.programmer Subject: OOFS would be nice Date: 17 Feb 1997 11:59:47 GMT Organization: INFONIE Message-ID: <01bc1cc1$91388ec0$2510c00a@olivier> These are just ideas... The following sentences contain at least once the word "would" each. An object-oriented FS would be nice. The disks would be partitionned into object stores, allowing applications to peek into these stores to edit objects (instead of files). This would lead to a true object persistence system... sthg like an OO database. A store would contain indexes to objects, taking their key values on the value returned from some given methods (similarly to what IXRecordManager was trying to do in NS3.x)... so this would allow querying a store to get a selection of objects responding to some given criterion, instead of merely getting a list of files in a directory. Having OODBMS features into the core of the operating system would be great. Wouldn't it be? om
Newsgroups: comp.sys.next.programmer From: fgalot@x-lan.alienor.fr Subject: MouseDown+Drag and SHIFT!! Message-ID: <E5qq6F.C1p@x-lan.alienor.fr> Sender: news@x-lan.alienor.fr Organization: x&lan Date: Mon, 17 Feb 1997 09:25:26 GMT My mouseDown looks like: mouseDown:theEvent { oldMask = [window addToEventMask:NX_MOUSEDRAGGEDMASK]; while (shouldLoop) { newEvent = [NXApp getNextEvent:(NX_MOUSEUPMASK |NX_MOUSEDRAGGEDMASK|NX_MOUSEEXITEDMASK)] ; switch (newEvent->type){ case NX_MOUSEUP: {...} case NX_MOUSEDRAGGED: { /*Heavy drawing here*/ mouseDownLocation = theEvent->location; /*next I use mouseDownLocation for drawing. But I'd like to use the real mouse position (cursor position?) because there is a shift between the real position of the mouse(cursor) and the point I'm using.*/ } }}} Thanks for help. -- --------------------------------------- ź ź | ź O_O ź ź | O_O -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fred Galot fgalot@x-lan.alienor.fr
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 07:34:14 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <sn2516600iVGI0zSpA@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <5e9cre$if1@horus.ecmwf.int> In-Reply-To: <5e9cre$if1@horus.ecmwf.int> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: File S.. by Mike Connally@ecmwf.int >> One wonders if that's a good thing. One of the largest problems with >> the Mac filesystem is that it's a huge pain trying to transfer files to >> other platforms in a meaningful way. > > What problem is that? Other systems (e.g. UNIX) want to see > a byte stream, which is what exists in the data fork of a Mac > file. [ ... ] Apps are another matter, of course. That "of course" is why the Mac forks are a problem. Either you can put _any_ file on a remote system like an Auspex NFS server, and have it work correctly, or else some crucial parts of what's on a Mac filesystem cannot be stored on remote fileservers because they won't work correctly. I think it would be good if Rhapsody did not suffer from the same heterogenous interoperability problems that Macs currently suffer from trying to share files on non-Mac filesystems. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: wharris@mail.airmail.net (Billy Harris) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 06:58:31 -0600 Organization: Internet America (and a UTA student) Message-ID: <wharris-ya023080001702970658310001@news.iadfw.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <01bc1cb9$37d896c0$2510c00a@olivier>, "Olivier Malcor" <olivier72@infonie.fr> wrote: >>Among the data stored in the application segments (see above), are the >information on which kind of document (file extension) one given app can >open. For example, PhotoShop.app could open ".tiff", ".eps", ".gif"..., >IconBuilder.app could open ".tiff" documents only. The user can choose a >default application (among those able) to open a given kind of document. >This is a user's preference. > >Once more, you have the choice. If you prefer, you can command-drag your >file icon onto a running or "docked" application icon to have it opened in >a different app. I think a lot of people (both NeXt and Mac) don't realize how often you will want different applications to open different files of the same type. A while ago, I drew a funky space picture. The background was a landscape created in KPT Byrce. The space ship was a model from RayDream Designer. I composed the final scene with Photoshop and added the flames and a laser bolt. The point is, that directory had many PICT files. Double-clicking on the space-ship picture should (and does) open RayDream Designer. Double-clicking on the landscape picture should (and does) open KPT Byrce. Double-clicking on the composite picture should (and does) open Photoshop. This behavior is easy to achieve with a creator field, but if I could only choose a single application for a pict file, I'd go crazy waiting for the wrong program to open, quitting, locating the correct program, and dragging the file to the program. -- Billy Harris wharris@mail.airmail.net wharris@vega.uta.edu
From: ndaniel1@swarthmore.edu (Noah M. Daniels) Newsgroups: comp.sys.next.hardware,comp.sys.next.programmer,comp.sys.next.software Subject: Looking for display driver for Compaq notebook Date: Mon, 17 Feb 1997 13:24:34 -0500 Organization: Noah's Ark Message-ID: <ndaniel1-1702971324350001@p9.ts15.metro.ma.tiac.com> I was wondering if anyone can help me - I'm looking for a display driver for a Compaq Contura notebook. None of the drivers included with the OPENSTEP/Mach 4.1 release support any better than black-and-white on the display, though the hardware can handle 8-bit color at 640x480. If I select the Western Digital LCD display driver, it's looking for 1 meg of VRAM, which is more than my notebook has. If I edit the memory maps in 'expert settings' to tell it to look for 300K of VRAM (if the machine supports 640x480x8b it must have at least 300K of VRAM) it still doesn't work; on reboot (either looking for 1 meg or 300K of VRAM) it warns of something like 'unsupported memory width' and defaults to the default VGA driver (which is why I'm getting black and white). Has anyone gotten the Western Digital LCD driver to work with a Compaq Contura 420C notebook or anything similar? Or has anyone attepted to write a driver for this machine? It's a decently solid machine and OPENSTEP handles nicely on it (as long as you stay away from the hardware suspend/hibernate commands, which are flaky with OPENSTEP) and it'd be nice to get OPENSTEP running on it (since the desktop box it had been installed on croaked). Thanks in advance! -- -- Noah M. Daniels ndaniel1@swarthmore.edu http://www.sccs.swarthmore.edu/~ndaniel1/ "He was a brave man who first ate an oyster" - Jonathan Swift "Wonder is the feeling of a philosopher, and philosophy begins in wonder" - Socrates
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 97 09:15:37 GMT Organization: Lund University Message-ID: <peterm.856170937@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> shess@one.net (Scott Hess) writes: >_doesn't_ justify putting that information in _the_ filesystem. This >thread has had suggestions which accomplish the same things over top >of the existing filesystem, rather than by modifying things at a low ^^^^^^^^^ >level. Well, this is a question: Apple (50 million claimed users) buys NeXT (a couple of millions users ?). Apple has one file system, NeXT another. I assume that the unified company will end up having one filesystem. Which one? Either way, one of them will have to change. As a Mac user, I don't see it as a modification to have a created time stamp. I under- stand that you, as a unix user, will view such a thing as a change. And I will, in my turn, view it as a change to not have it and have three time stamps for last change etc. instead. It's a matter of perspective. > This is not a question of "who's right", but rather "how do we make > both happy?" >Well, except that I'm trying to argue that you shouldn't be unhappy >with how it's currently done (in Unix) :-). I've been a unix sysadmin since 1990, and I have missed a creation time stamp all those years. In fact, I've missed a lot of things on my Sun (as much as I have missed some unix-things on the Mac). >More broadly, though, the filesystem obviously cannot be changed to >make everyone happy. Right, but how about maintaining a file system that has been used by several millions of users for more than a decade? >Anything Apple/NeXT come out with _must_ interoperate with NFS in an >almost completely transparent fashion. _MUST_. That's not even an >option. NFS is simply too prevalent. I agree (really!) -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: syy@ecmwf.int (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 10:45:02 GMT Organization: ECMWF (European Weather Centre) Message-ID: <5e9cre$if1@horus.ecmwf.int> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> In article <5ddtq2$ier@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) writes: |> In article <5ddp66$jpc@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: |> |> > I challenge that implication, going so far as to claim that it is |> > the Mac's multi-forked file system that has separated it from other |> > OSes. |> |> One wonders if that's a good thing. One of the largest problems with |> the Mac filesystem is that it's a huge pain trying to transfer files to |> other platforms in a meaningful way. What problem is that? Other systems (e.g. UNIX) want to see a byte stream, which is what exists in the data fork of a Mac file. In my experience, all that's required on the foreign system is to apply the appropriate naming convention, with extension as required, for the foreign system to use the file, as is. Talking data here. Apps are another matter, of course. -- Mike Connally Consultant, Data Handling Project European Centre for Medium-Range Weather Forecasts (ECMWF) Shinfield Park, Reading, Berks RG2 9AX England Tel: +44-1734-499253 Email: Mike.Connally@ecmwf.int
From: Steve Barnet <"mailer-daemon"@[127.0.0.1]> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Mon, 17 Feb 1997 16:46:23 -0600 Organization: UW-Madison Space Science and Engineering Message-ID: <5ean3v$3l5@spool.cs.wisc.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Joyner wrote: > > Steve Barnet wrote: > > > > Ian Joyner wrote: [points of clarification snipped] > > > So what is the application program going to do because a > > > malloc has failed due to environmental factors beyond its control? > > > > > > > Fail gracefully: log an error message (in a logfile or errorfile) > > and exit. > > Yes, but let's try everything else first. Never should the first > process that receives an out of memory error just be told to die > gracefully. > It might be some other process that has gone rampant that is causing > the problem. The approaches taken by Unix and most other OSs seem > inherently dangerous to me. Supposing that the process terminated is > critical. In this case the operator has not been given the chance to > suspend or terminate other non-critical processes. I guess that depends upon what you're talking about. Many UNIX boxen used to randomly terminate processes when resource shortages happened. This caused a howl from almost everyone as it could make graceful recovery difficult if not impossible. That's no longer the behavior of civilized systems. I think IRIX may still do this, but as I said ... I will address possibilty two below. [snip] > > Whether a system is > batch, multi or single user, it is just unacceptable to terminate a > process due to resource shortages. You might be executing an innocent > victim. > Your point is valid and UNIX provides a mechanism for not slaying innocents. Most Unices have a notion of user limits (ulimit). This enables the administrator to set resource limits on a per user basis. So to deal with your scenario (shooting an innocent (possibly crucial) bystander), it's necessary to set user limits appropriately. This can prevent a user from monopolizing the box and (if done wisely) can make sure that crucial processes still have enough room to do their thing. <philosophy> As an admin, the only real problem that I have with your suggestions is that they fundamentally (auto manager aside) require user interaction. The environment I admin is not really a batch environment. In most cases the users of the 90+ UNIX boxes are not priviledged users whether they sit at the machine or not. Personally, I don't want to have to spend my days managing a machine at that level (deciding which processes live or die). I don't have the time. </philosophy> Just my .02 monetary units. ---SteveB -- Steve Barnet--System Administrator steve.barnet@ssec.wisc.edu UW-Madison Space Science and Engineering Center I'm not a rocket scientist, but I play one on TV (608)263-2268
From: Stefano Pagiola <spagiola@worldbank.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 09:20:14 -0500 Organization: World Bank Message-ID: <3308691E.51A7@worldbank.org> References: <5ddp66$jpc@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5e3bou$emo$1@newz.oit.unc.edu> <dfrick-1602971751420001@poha014.lava.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit scocca@gibbs.oit.unc.edu (Dave Scocca) wrote: > Maybe the _real_ solution is to come up with a different extension > separator (say a \?), keep the . as a generic character usable > anywhere in a filename, use the \ to demarcate the "extension", No need. NeXTSTEP uses the whatever is to the right of the LAST . as the extension. I have plenty of filenames with multiple periods in them, and NeXTSTEp parses them all appropriately (eg 961021.Jones.wp is correctly identified as WordPerfect file, not a "jones.wp" file). -- 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: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 10:37:57 +1100 Organization: Unisys Message-ID: <3308EBD5.61F7@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@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.programmer: 17-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >> Operating systems fail when the machine is not provided adequate > >> resources for the tasks that it's supposed to perform. Polite operating > >> systems fail in a reasonably graceful way that may even allows you to > >> correct the problem without rebooting, which is what NEXTSTEP does. > >> > >> Other operating systems tend to panic or lock up. > > > > If NextSTEP does this good. > > However, don't lump all other OSs into the panic and lock up variety > > I didn't say "all other OS's". Granted, but it was somewhat implied. > While there are a few OS's which are as stable than NEXTSTEP, the vast > majority of computer systems are running either MS Windows or MacOS-- > both of which are well known for their lack of stability. True. Please don't think that I am attacking NeXTSTEP or defending MacOS. I am merely pointing out that OS people should reexamine what OSs do, and some major rethinks should be done. > [ ... ] > >> Apparently, you seem to think the OS should ask the user via an alert > >> panel to browse the filesystem in order to specify where the missing > >> file is. Do you agree that this was your suggestion? > > > > Not exactly. The OS should ask the user/an operator what to do, locate > > the file, kill the process, ignore the file and continue. You have > > quite a few options. > > The operating system does not have the decision-making powers of a > human, and it cannot make a decision between the alternatives you've > listed-- it will only do what it's programmed to do. Therefore, you've > either got to pick _one_ of the alternatives, or else provide a > deterministic and decidable algorithm that the OS can use to select an > alternative. I think we are saying the same thing now. That is exactly what I am saying, to OS should in many situations consult a human. After all most of these kinds of conditions are operations errors, particularly in a production environment where programs should be reliable. Development environments are a bit different, and you are more likely to get run away processes causing problems, but then as you say, how does the OS determine exactly which program is at fault? However, we should all be expecting our programs to eventually run in production environments. So for example, this means that out of memory probably means an operations error, as the machine has become overloaded. Out of disk means operations has not cleaned up recently enough. > Of course, you've failed to address the crucial point I've made, which > is that _any_ of the choices you've listed will be an inappropriate > action for some processes. No matter how many choices you come up with > and how complicated the algorithm to select between them is, I'll be > able to come up with situations which require different error handling > than what you've stated that the OS should do. That's an idle threat, but even if I was to embark on this process, it does not invalidate the OS design issue I have outlined. > >> But what happens if there isn't a user? Should the process block > >> indefinitely until someone notices that the machine is wedged? > > > > That is preferrable to killing the process, which is an extreme form > > of blocking and you will still have to wait for someone to come and > > fix it. Or do you mean that the process will be killed and automatically > > restarted. This is a possibility, but of course the condition that > > killed the original process might still be in effect. In this case the > > operator has a much harder job of trying to prevent the continual > > loop of [kill process; restart process]*. Whichever way you are > > still blocked. > > But Unix doesn't block when open() fails-- it returns EACCESS > immediately, which allows to process to decide whether to continue, ask > the user for help, or do whatever else it finds appropriate, such as > terminate. > > That's a far superior solution to blocking. No it's not a far superior solution to blocking. Consider if the open fails for some hardware problem on the disk. OK, the OS passes the failure back to the process, which decides to terminate, and do nothing more. Clearly, this must notify the operator that hardware is malfunctioning, and very likely the operator can help the process out by redirecting it to another disk unit. This is much more robust than just passing the error straight back to the process, which can't do anything. > [ ... ] > >>>> I assume you're just talking about the first case, where malloc() fails. > >>>> Polite applications warn the user that they couldn't get the memory > >>>> they needed, and they abort the operation being attempted, and return to > >>>> their main event loop. > >>> > >>> Since this is a case that should be handled by every running task, > >>> why burden the application programmer with this task: > >> > >> Because not all tasks will want to handle a particular error condition > >> in the same way? > > > > But what I am saying is that you can do a good OS design by evaluating > > all those ways, and then giving the option (which might also include some > > automatic policy that circumvents the user/operator). > > (A) It's impossible for the OS designer to incorperate every possible > way that a process might want to handle every possible error condition, > and, Well you would have to prove it were impossible, but even assuming that it is, that does not mean that OSs should not have better facilities for picking up the many common situations that we are interested in. OSs that don't handle these situations, and many don't, do not provide an adequate level of robustness. > (B) even if it was possible, why would you want to bloat the OS with all > of that code when it's simpler and easier to design processes that > perform the error handling that they need? "Bloat", well Unix has already got bloated, but aside from this that is a silly comment. Why do you think that all application programs should be bloated with code that handles common problems. That adds to the code that a programmer must produce; means you have maintenance problems to handle all the cases; means you have testing problems to test all the cases; means you have just made every project much more expensive to complete (well most projects get killed anyway); and means you have missed the fundamentals of reuse. > Good operating system provide well defined interfaces to support > processes, and these interfaces should be made as small, as simple, and > as elegant as possible while still providing all of the functionality > that's needed. Complex functionality like a window system, or a math > library, or a set of error handling routines belongs in user space, not > in the kernel. > > Ever hear of modularity? Did you ever hear of modular operating systems? Do you understand what an OS kernel is? It is not where I am suggesting putting this functionality, but neither is it in the user space, although that terminology is confused as well. Much of this stuff might run in user process space, but does not need to be written as part of the application. And as for the above point, we have not changed the interface one bit, so you still don't understand my point, before you go into overdrive mode defending Unix, coming out with mindless rhetoric about small interfaces, etc. To explain the interface is still the same. The open call remains the same. What I suggest is to reevaluate the contract of the call, and determine that much of what needs to be done is common, and therefore should not be on the calling side of the interface. In fact if you think about it many errors cannot be handled by the application, they have to be handled between the OS and the operator. ------------------------------------------------------------------------ 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: syy@ecmwf.int (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 14:52:05 GMT Organization: ECMWF (European Weather Centre) Message-ID: <5e9ral$jfu@horus.ecmwf.int> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> In article <sn2516600iVGI0zSpA@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> writes: |> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & |> Unix: File S.. by Mike Connally@ecmwf.int |> >> One wonders if that's a good thing. One of the largest problems with |> >> the Mac filesystem is that it's a huge pain trying to transfer files to |> >> other platforms in a meaningful way. |> > |> > What problem is that? Other systems (e.g. UNIX) want to see |> > a byte stream, which is what exists in the data fork of a Mac |> > file. [ ... ] Apps are another matter, of course. |> |> That "of course" is why the Mac forks are a problem. |> |> Either you can put _any_ file on a remote system like an Auspex NFS |> server, and have it work correctly, or else some crucial parts of what's |> on a Mac filesystem cannot be stored on remote fileservers because they |> won't work correctly. Are you asserting that you can put _any_ file from any UNIX system on _any_ other UNIX system and have it work properly? Executables? Very very wrong. Executables are tied very closely to the OS and HW and don't happily move between platforms. What does move generally well is data. And in that respect, Mac files are as easily portable as files from any other system. Foreign systems will need to have the file contents explained to them by primitive mechanisms like filename extensions, but the data is the same. Put a Mac file onto a UNIX system, give it the appropriate filename extension, and a UNIX app can use the Mac file as-is. I have never encountered anything like the originally quoted "huge pain trying to transfer files to other platforms in a meaningful way". I suspect anyone who says that has never actually tried doing it. It's trivial. -- Mike Connally Consultant, Data Handling Project European Centre for Medium-Range Weather Forecasts (ECMWF) Shinfield Park, Reading, Berks RG2 9AX England Tel: +44-1734-499253 Email: Mike.Connally@ecmwf.int
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 23:40:46 GMT Organization: The Jack Voigt Fan Club Message-ID: <5eaq9u$ofi$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> In article <AF2E42E196681EFC18@node50.tfs.net>, Travis Butler <tbutler@tfs.net> wrote: \ To the point at hand: I think it makes a lot more sense for the default to \ be the application that created a file. Again based on my experience, \ people generally create a file with the application they want to use to \ work with it. The exceptions I see are usually data-acquisition situations \ (including working with scanned images), where you use one program to get \ the file, and a second program to manipulate it. And in many data-acquisition situations, the first program is smart enough to let you tell it what creator code to use. For example, when I download a TEXT file from White Knight, I get the creator code MSWD rather than the one for White Knight (unless it's TeX stuff, in which case I temporarily set it to TEX* instead). D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: pbrown@ashkhabad.berkeley.edu (Paul R. Brown) Newsgroups: comp.sys.next.programmer Subject: font-lock-mode in Terminal.app? Date: 18 Feb 1997 01:00:47 GMT Organization: data communication and networking services Message-ID: <slrn5ghuv8.v6.pbrown@ashkhabad.berkeley.edu> It seems to me that Terminal.app windows could support font-lock-mode under emacs-19.34. I don't really need mouse support, so that would be all I need. (Note that font-lock-mode it broken in Carl Edman's NeXT-ized 19.28.) Has anyone done it or can tell me how to do it? Paul -- _____________________________________________________________________ Paul Brown Grad student, UCB mathematics (510)-843-7817 pbrown@math.berkeley.edu http://math.berkeley.edu/~pbrown/ NeXTmail preferred. _____________________________________________________________________
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 01:24:50 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5eb0d2$1en@news3.digex.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> tbutler@tfs.net (Travis Butler) wrote: > I'm blathering on about this because it seems like a large number > of the arguments by NeXT partisans boil down to 'it has to be > this way if you're on a multiuser system.' Well, as I said, I > don't WANT a multiuser system; and in my experience, this holds That's very nice. And I want to be the ruler of the universe. Looks like today neither of us will get what we want. Many people can and do benefit from multiuser os's. This is the same kind of argument I used to hear from dos heads. We don't want or need GUI. Who needs it? It's useful, and if you don't like it, no one will force you to make use of it. But, for certain server level processes it's great. That way the kids, while they are on their account, won't be able to crash down the web server processes you have going. That way your mother in law won't be able to spitefully kill your tax files. etc etc. -- Thanks, be well, take care, later, John Kheit; Self expressed... 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 | You make the best of what's still around...
From: "Olivier Malcor" <olivier72@infonie.fr> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 11:00:01 GMT Organization: INFONIE Message-ID: <01bc1cb9$37d896c0$2510c00a@olivier> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> > 1) I think the resource fork is an interesting idea... In my opinion, NS manages this kind of facilities in a better way. It gives you the alternative : 1. In terms of file system, NS apps are directories (with .app extension). Of course, these directories appear as icons for the end user, but she can also open the application "as a folder" to browse into its contents (including the executable, localizable interfaces (.nib), icons, sounds, strings, and so on...). 2. The structure of Mach executables is segmented. It allows you to put resources in the file itself, just like the Mac does... For example the application icon is located in the "app" section of the "__ICON" segment. This way, you can store any kind of resources in the executable... > 2)... about opening docs... Among the data stored in the application segments (see above), are the information on which kind of document (file extension) one given app can open. For example, PhotoShop.app could open ".tiff", ".eps", ".gif"..., IconBuilder.app could open ".tiff" documents only. The user can choose a default application (among those able) to open a given kind of document. This is a user's preference. Once more, you have the choice. If you prefer, you can command-drag your file icon onto a running or "docked" application icon to have it opened in a different app. About multi-user facilities: > I think this could be implemented quite easily by simply having a few > different prefs folders and a control panel to determine which prefs > folder is being used. Perhaps because you are sharing your Mac with responsible guys. What if you were sharing some very personal/critical data with your first enemy! or with some apprentice wizard cooking on the system with no restriction! om
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 14:01:53 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0n2_gV200iV7I5aJdw@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> In-Reply-To: <1997021700592626089546@roxboro-177.interpath.net> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: File S.. by John Moreno@interpath.co > ] Perhaps it's just me, but I don't see much value to preserving the > ] timestamp of the creation date of the original version of a file when > ] you don't actually have the original file-- just the modified version. > ] Can you provide a real-world example of why you'd care about that > ] timestamp? > > A very simple and quit answer is when you have two files with basically > the same information and have modified both since their creation and > want to know which file is newer. The answer is whichever file was modified last, and can be answered using the last-modified timestamp; the creation timestamp isn't needed. Again, that doesn't answer my question. [ ... ] >] Such a system could rely on just the file extension if the Mac-like >] creator/filetype attributes are not available or are not recognized >] [consider a file that has been FTP'ed or is being accessed via a >] remote filesystem like NFS, AFS, etc], but could also pay attention to >] the Mac attributes if they are available and valid. That seems to >] combine the desirable features without changing the way either current >] Mac users or current NEXTSTEP users like to have things work.... > > I've seen this "accessed via a remote filesystem" argument used before > and have never really understood it. If the computer at the other end > is a Rhapsody machine then I'd expect the additional information to be > passed along, if it isn't a R.M. then what kind of file is being > accessed where the person getting it doesn't know what it is? You're missing the point. When I access a file via a remote filesystem, I shouldn't need to care whether it's a R.M or not. I should be able to use any type of fileserver without having problems, and I should be able to run executables directly off of the fileserver. Come to think of it, perhaps Apple will provide this functionality by making Rhapsody's system loader understand the AppleDouble format directly as an executable format. It's rather similar to the way NEXTSTEP handles the Mach-O and MAB (FAT binary) executable formats.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 14:11:14 +1100 Organization: Unisys Message-ID: <33091DD2.61FA@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Steve Barnet wrote: > > Ian Joyner wrote: > > It might be some other process that has gone rampant that is causing > > the problem. The approaches taken by Unix and most other OSs seem > > inherently dangerous to me. Supposing that the process terminated is > > critical. In this case the operator has not been given the chance to > > suspend or terminate other non-critical processes. > > I guess that depends upon what you're talking about. Many UNIX boxen > used to randomly terminate processes when resource shortages happened. > This caused a howl from almost everyone as it could make graceful > recovery difficult if not impossible. That's no longer the behavior > of civilized systems. I think IRIX may still do this, but as I said ... Good. > I will address possibilty two below. > > [snip] > > > > > Whether a system is > > batch, multi or single user, it is just unacceptable to terminate a > > process due to resource shortages. You might be executing an innocent > > victim. > > > > Your point is valid and UNIX provides a mechanism for not slaying > innocents. Most Unices have a notion of user limits (ulimit). This > enables the administrator to set resource limits on a per user basis. > So to deal with your scenario (shooting an innocent (possibly crucial) > bystander), it's necessary to set user limits appropriately. This can > prevent a user from monopolizing the box and (if done wisely) can make > sure that crucial processes still have enough room to do their thing. This is a valid point about limits, and it is probably reasonable for the OS to terminate processes that overstay their welcome. (The user may have set the limit in order to minimise their computing bill). However, this is a different problem to when the system as a whole is having resource difficulties. > <philosophy> > > As an admin, the only real problem that I have with your suggestions is > that they fundamentally (auto manager aside) require user interaction. > The environment I admin is not really a batch environment. In most cases > the users of the 90+ UNIX boxes are not priviledged users whether they > sit at the machine or not. Personally, I don't want to have to spend my > days managing a machine at that level (deciding which processes live or > die). I don't have the time. > > </philosophy> Normally you won't have to. If you set up your machines well, then they will be operating within their resources. If a system is out of resources though, an operator is likely to have to get involved, and it is more likely that the users will start complaining. However, it is also perfectly valid, that you could set system options as to what the operator is notified of, or whether the OS can take automatic action. And if you don't set up your systems correctly, so that you have resource problems, then this is an operational error, and such errors are not programming errors, so it is inappropriate to send an error to a program. It is difficult enough to code programs to deal with their own internal errors, let alone have to deal with system errors. In any case, I come back to the original point, that in most cases it is inappropriate for the OS to send an error/exception back to processes that are waiting on resources, without at least trying some recovery, either automatic or with operator assistance first. If the OS doesn't do this then you do not have a very robust OS. > Steve Barnet--System Administrator steve.barnet@ssec.wisc.edu > UW-Madison Space Science and Engineering Center > I'm not a rocket scientist, but I play one on TV Good 'cause this is hardly "rocket science" :-) ------------------------------------------------------------------------ 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: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: New Information Date: 17 Feb 1997 19:47:04 GMT Organization: NeXT Software, Inc. Message-ID: <5eacjo$f6o@news.next.com> References: <5e55u8$7td@news.bu.edu> John Siracusa writes > From MacWeek: > > Sources in the boiler room report that Rhapsody will weigh in at about > 110 Mbytes of pure chewing satisfaction and come with three levels of > Install: EZ, Minimal and Custom. Wow. I wonder how the folks at MacWeek know how much disk space Rhapsody is going to use, when it hasn't even been built yet? -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
From: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 23:34:05 -0500 Organization: TofuSoft Message-ID: <jchan-1702972334050001@pm5-18.apk.net> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> In article <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > For example, let's say I'm using a Sun SPARC and my company has an > Auspex fileserver. I can NFS mount the Auspex server on my Sun, and I > can run Sun SPARC executables stored on the remote machine. In fact, I > could use any type of machine as an NFS fileserver, and be able to run > SPARC binaries stored on that fileserver without any problems. > > I could use Samba and an NT fileserver instead of NFS, if I wanted. Or > I could use a Novell Netware fileserver. Again, it shouldn't matter to > me what the remote fileserver is-- I should be able to store executables > on it and be able to run them. > > However, I can't NFS mount a remote fileserver on a Mac and be able to > run Mac executables, because they require the out-of-band information > stored in their resource forks which is not representable within the > standard NFS/UFS filesystem paradigms. > Situation A: Remote Machine is non-Mac and stores data on a Mac based NFS server. I'd like to point to <http://prozac.cwru.edu/jude/macnfs/Macnfsd.html>. Macnfsd is written by a good friend of mine. It is a Macintosh NFS server [if I understand the terms correctly]. What it does it only transfer the contents of the data fork. So NFS clients will still work normally. Situation B: Remote Machine is a Mac and stores data on an NFS Server I'd like to point to a commercial NFS client for the Mac <http://www.intercon.com/products/nfs-share.html>. In the Macintosh section, you will see the following comments: Apple standard - NFS/Share uses Apple's defined standards (AppleSingle or AppleDouble) for representing files for foreign file systems. This simply allows Macintosh users to store files with their resource and data forks intact. According to the brochure, you will simply see it as an extension of the AppleShare Services. I don't really know how a data file is passed from a Mac NFS client to a Non-Mac NFS client. The AppleSingle/Double storage methods might cause some confusion but I'm sure there are some solutions out there. I've not played enough with NFS to know. --- The Evil Tofu (Only Human)
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 16:47:32 -0500 Organization: phenix@interpath.com Message-ID: <1997021716473229510531@roxboro-170.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <qdafp913g1.fsf@blues.cygnus.com> Stephen Peters <speters@cygnus.com> wrote: ] John 'kzin' Rudd <jrudd@cygnus.com> writes: ] ] > It may seem pendantic to point out the difference between "creator" ] > and what you're talking about, but it is semantically different. ] > The creator of a file is the creator of the file no matter whether ] > you like to use that application or not. If "creator" is going to ] > be recorded, then it really is an attribute of the file itself, and ] > should somehow be stored with it. ] ] Which begs the question to a die-hard Unix user like myself, if you ] add the notion of a `preferred application', what use is the `creator' ] designation other than bookkeeping? As a fallback to a known good ] application? Well for starters some applications can handle the files of a certain type created by one application but not of another - non standard usage and all that rot. ] Ditto on the various discussions on adding the `time created' field to ] augment the last modified and other time codes stored with the file. ] For me, once I start caring about the time the file was first created, ] I start caring about all the changes that were made, which seems to ] scream `revision control system' to me. (And if you copy a file from ] somewhere else, should it inherit the source file's created time?) ] ] Maybe I'm just not seeing it. Can someone help enlighten me? Because when you update a applications then look at the file it often gets translated into the newer version, this is one way of keeping track of when you started something. ] > However, each user should have the option to substitute some other ] > app, in case they don't want to use the actual applications ] > creator.. and that list of preferences would probably be best called ] > "Prefered applications" or something.. which would read something ] > like: ] > ] > I prefer Painter for Photoshop apps. Which would probably be mapped ] > like "Photoshop.app -> Painter.app", and thus when you launched a ] > file created by Photoshop, it would bring up Painter. :-} ] ] Ick. I really don't like this on an application basis. One person ] may normally look at JPEGs under Netscape, whereas I have some neat ] image utility like OmniImage that I use. That doesn't mean I want to ] set up OmniImage as a replacement for Netscape in all circumstances. Your right, and it would NEVER be done on a application or creator basis, it would be done on a file TYPE basis. But consider that often a different application won't get ALL of the information in a file right, when compared to it's creator - it's nice to know that you can always go back to the creator which is guaranteed to be able to display the information properly (assuming that you haven't modified it in some other application). -- John Moreno
From: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 23:44:37 -0500 Organization: TofuSoft Message-ID: <jchan-1702972344370001@pm5-18.apk.net> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eaq9u$ofi$1@newz.oit.unc.edu> In article <5eaq9u$ofi$1@newz.oit.unc.edu>, scocca@gibbs.oit.unc.edu (Dave Scocca) wrote: > In article <AF2E42E196681EFC18@node50.tfs.net>, > Travis Butler <tbutler@tfs.net> wrote: > > \ To the point at hand: I think it makes a lot more sense for the default to > \ be the application that created a file. Again based on my experience, > \ people generally create a file with the application they want to use to > \ work with it. The exceptions I see are usually data-acquisition situations > \ (including working with scanned images), where you use one program to get > \ the file, and a second program to manipulate it. > > And in many data-acquisition situations, the first program is smart > enough to let you tell it what creator code to use. For example, when > I download a TEXT file from White Knight, I get the creator code MSWD > rather than the one for White Knight (unless it's TeX stuff, in which > case I temporarily set it to TEX* instead). > I think Internet Config Aware apps can look up the Internet Config database for default file type / creator codes for various file suffixes. I think Anarchie uses it to set the type / creator code for files I've ftped without my interferance. --- The Evil Tofu (Only Human)
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 16:47:28 -0500 Organization: phenix@interpath.com Message-ID: <1997021716472829510259@roxboro-170.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> John Rudd <jrudd@cygnus.com> wrote: ] In <5dtpb5$h4t@news.bu.edu> John Siracusa wrote: ] > Jonathan W. Hendry (jon@subsequent.com) wrote: ] > : John Siracusa wrote: ] > : > I'd say the registry is a hack to make up for an inane ] > : > filesystem that doesn't allow putting the information contained ] > : > in the registry in the files themselves, where it would make ] > : > more sense. ] > ] > : It doesn't make sense when files and applications can be used ] > : by multiple users. ] > ] > I don't see how that is. File type and creator information doesn't ] > vary from user to user. If you're talking about the type of thing ] > that is stored in preference files on the Mac, then the logical ] > solution is to have separate preference folders for each user. ] > ] > This doesn't really apply since, abilities aside, Rhaposdy will ] > be targeted as a single-user system from what I have read. ] ] It applies if they don't plan to _limit_ it to single user systems. ] Targeting isn't the same as saying "it wont be able to be used for ] applications other than this one". It simply means that is who they ] plan to focus on. ] ] Focusing on single user systems is all well and good, and rather ] appropriate to the mac market.. but again, Apple wants to come out of ] this with a system that scales to servers and such.. and it's not ] going to scale as well if they eliminate multi-user capabilities. ] ] On the otherhand, I don't see how that's relevant to Jonathan's point. ] The application creator is the application creator.. if that ] information is relevant to you, then you use that application. There ] is no need to overload this data. If you want the file type to ] determine the application you launch, instead of the creator, then the ] GUI should have a switch for choosing between the two. Then each user ] keeps a list of bindings for file types to applications. Multi-user ] systems aren't hindered by either of these being stored in the file ] (or the file wrapper, or the inode, or the resource fork). Well, it's never been stored in the resource fork. But other than that you're dead on target. ] The reason this is a problem on a Mac isn't because it's stored in a ] central location.. it's because the Mac doesn't allow you to pick file ] type over file creator for its launching heuristic, and then give a ] seperate file-type <-> application binding for different "profiles" ] (even if its' just swapping a file at runtime). If it did allow this ] (even the crude run time swapping of the binding file), then it ] wouldn't be a problem. It DOES allow you to override the launching application but ONLY if the creating application is not available. It's called Macintosh Easy Open and it could be extended to work properly (override even application which ARE available) in the current system, let alone in the next. Other than these two minor quibbles I agree with you. -- John Moreno
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 16:47:42 -0500 Organization: phenix@interpath.com Message-ID: <1997021716474229511116@roxboro-170.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <SHESS.97Feb13085241@howard.one.net> Scott Hess <shess@one.net> wrote: ] In article <3302E06E.8D@subsequent.com>, ] "Jonathan W. Hendry" <jon@subsequent.com> writes: ] Okay. My beef is with the Macintosh's usage of the creator code, ] not the existence of one. ] ] OK, then, I'll beef. If some bit of information is not really ] necessary, then it shouldn't be added to the filesystem. If the ] creator code is just a nice little bit of trivia which follows a file ] around, but isn't necessary to figure out who to open the file with, ] then who cares? If it's in the information the filesystem maintains, ] then it's a drag on _every_ file, _every_ access, _every_ program. It may be a drag [your trying to save 4 bytes worth] on every file, but it has NOTHING at ALL to do with ACCESSING the file. ] Put another way, if we must have it, rather than a creator code like ] "DRAW", I'd rather have something like "NeXT Draw demo program, ] version 3.14". Even better if it's got fields for creating user, ] date, hostname, etc, etc. Now your saying the opposite since "DRAW" get's mapped to "NeXT Draw demo program version 3.14" instead of it being stored with each file. Of course this doesn't really take care of the different version of the same program since to get that effect you'd have to change the creator each time, but you could make the creation information just a bit larger [2 bytes] and put it in there. -- John Moreno
From: John Hornkvist Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 22:59:14 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5eans2$8jq@nyheter.chalmers.se> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> Cc: olivier72@infonie.fr In <01bc1cb9$37d896c0$2510c00a@olivier> "Olivier Malcor" wrote: >> 1) I think the resource fork is an interesting idea... > >In my opinion, NS manages this kind of facilities in a better way. It gives >you the alternative : > >1. In terms of file system, NS apps are directories (with .app extension). >Of course, these directories appear as icons for the end user, but she can >also open the application "as a folder" to browse into its contents >(including the executable, localizable interfaces (.nib), icons, sounds, >strings, and so on...). > >2. The structure of Mach executables is segmented. It allows you to put >resources in the file itself, just like the Mac does... For example the >application icon is located in the "app" section of the "__ICON" segment. >This way, you can store any kind of resources in the executable... Exactly. Resource forks is only a way to reimplement directories inside a file. Now, in Unix a directory is a file. A file with names and pointers to other files. Making the OS aware that some directories are not really directories but a special sort of file should be simple enough. This could be done using extensions, or by modifying the file system to add a "bundle" bit. However, I think things work well the way they are... >> 2)... >about opening docs... > >Among the data stored in the application segments (see above), are the >information on which kind of document (file extension) one given app can >open. For example, PhotoShop.app could open ".tiff", ".eps", ".gif"..., >IconBuilder.app could open ".tiff" documents only. The user can choose a >default application (among those able) to open a given kind of document. >This is a user's preference. > >Once more, you have the choice. If you prefer, you can command-drag your >file icon onto a running or "docked" application icon to have it opened in >a different app. A couple of days ago I wrote a little application that acts as a dispatcher. You drag a file onto it and it uses another application to open it. You can drag files to its preferences panel and it will let you select an applition other than the workspace managers default for the file type. The idea was that it may at time be nice to have to classes of applications that can open files; "viewers" and "editors". I would use OmniImage when double clicking on a file, but WetPaint when dragged to the dispatcher, for example. The same goes for TeXView/(Edit or Emacs). There is no reason why this system could not be extended to treat files by name instead of by type only. It would become a bit slower, but not unmanageably so -- not even noticeably so, I bet. If anyone wants it, mail me! I wrote a "DesktopPrinter" which does pretty much the same thing, except that it opens the application in the background, starts a print job, and quits the app. However, of the applications I have tried this far only Edit seems to work as advertised... Anyway, the point of this is that the file should not be aware of which application the user wants it opened in, because you cannot count on having one user per system. Using a hash table, or some other data structure, to associate file names with applications in the workspace manager (finder) would be a much nicer approach, IMHO. >About multi-user facilities: >> I think this could be implemented quite easily by simply having a few >> different prefs folders and a control panel to determine which prefs >> folder is being used. > >Perhaps because you are sharing your Mac with responsible guys. What if you >were sharing some very personal/critical data with your first enemy! or >with some apprentice wizard cooking on the system with no restriction! Exactly! I want full security when I use a computer. Other users should not be able to affect my environment. Whenever computers that are not real multi user system are shared problems arise, either from malice or from incompetence. A multi user system saves lots of time for system administrators, and it saves users from trouble. There may also be information on my account that I do not want other users to be able to access. All in all a true multi user system allows you not to care about other users. Inside your own account you rule. You can install the applications you need, run whatever services and daemons you want, and have the directory hierarchy that you wish. The only way you affect other users is the way hard drive space shrinks... --- 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: tbutler@tfs.net (Travis Butler) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 17:16:17 -0600 Organization: The Wandering Powerbook... Message-ID: <AF2E42E196681EFC18@node50.tfs.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> In article <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & >Unix: File S.. by John Siracusa@bu.edu >>: It doesn't make sense when files and applications can be used >>: by multiple users. >> >> I don't see how that is. File type and creator information doesn't >> vary from user to user. > >While that is true, the Mac paradigm uses that information to make the >decision as to which application should open a particular file. > >The Mac paradigm doesn't work very well when you consider a multiuser >operating system because individual users should be able to decide for >themselves which app should open a file and not have their decisions >change what happens to other users. The problem is, I couldn't care less about a multiuser operating system. I bought my Mac for use by a single person: me. With the exception of server machines, every single Mac -- heck, every single *personal computer* -- I've ever seen has been used by one person at a time. The majority of them have been used by a single person, period; if you leave out the CS lab machines, that becomes an overwhelming majority. I'm blathering on about this because it seems like a large number of the arguments by NeXT partisans boil down to 'it has to be this way if you're on a multiuser system.' Well, as I said, I don't WANT a multiuser system; and in my experience, this holds true for the vast majority of machines outside of a lab environment. I don't mind having things in there for the benefit of multiuser setups, as long as they don't get in the way of ordinary single-user operation; but if there's a conflict, I think multiuser features have to take a back seat to convenience features for single users. This gets back to the same argument I keep raising throughout these threads: It doesn't make sense to complicate the user experience for the majority of people to cater to the specialized needs of a small minority. To the point at hand: I think it makes a lot more sense for the default to be the application that created a file. Again based on my experience, people generally create a file with the application they want to use to work with it. The exceptions I see are usually data-acquisition situations (including working with scanned images), where you use one program to get the file, and a second program to manipulate it. For example, BBEdit is my primary text editor; however, when reading or creating documentation files, I'll often use SimpleText, because it supports and displays styled text and BBEdit doesn't. (To bring in another part of the thread, SimpleText stores style information in the resource fork of a file, thus avoiding problems with programs that expect only straight ASCII text.) In this situation, it makes far more sense to have a file-by-file preference, allowing styled text files to open in SimpleText by default, and other text files in BBEdit. >> This doesn't really apply since, abilities aside, Rhaposdy will >> be targeted as a single-user system from what I have read. > >Rhapsody will undoubtedly work just fine as a single-user OS, agreed, >but Rhapsody is almost certainly going to be multiuser. > >It's very easy for a multiuser OS to act like a single-user OS, as >NEXTSTEP did with the default 'me' user. The reverse is not true, and I'm afraid it's your premise that's not true, as you and other NeXT users prove every time you use 'it can't be done that way on a multiuser OS' as an argument -- as you just did above. If many of the conveniences and operating methods that Mac users are used to can't be done on a multiuser OS, then it's obvious that a multiuser OS can't act like the Mac single-user OS. >it would be a very bad move on Apple's part to not make Rhapsody >multiuser. Not if it compromises Apple's traditional ease of use, and especially not if it's for a minority of users. 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: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.programmer Subject: Re: Data from App to Improv using Services? Date: 18 Feb 1997 00:54:50 GMT Organization: University of Sheffield, UK Message-ID: <5eaukq$h4f@bignews.shef.ac.uk> References: <5e1ut7$8uo@stc06.ctd.ornl.gov> In-Reply-To: <5e1ut7$8uo@stc06.ctd.ornl.gov> On 02/14/97, John W. Wooten wrote: > Where can I find out how to take data from an app I'm writing and > put it into Improv for some calculations and formatting? > Improv API? ftp://next-ftp.peak.org/pub/next/apps/devtools/ImprovAPI.N.bs.tar.gz Best wishes, mmalc. --
From: randyj@lubra.sbs.ohio-state.edu (Randy Jackson) Newsgroups: comp.sys.next.programmer Subject: Re: cc++ question Date: 17 Feb 1997 18:37:16 GMT Organization: The Ohio State University Message-ID: <5ea8gs$n50@charm.magnus.acs.ohio-state.edu> References: <E5nw3F.GD@xombi.wizard.net> In-Reply-To: <E5nw3F.GD@xombi.wizard.net> On 02/15/97, recurve@resourceful.com wrote: >I'm trying to compile what should be a simple C++ program on NeXTStep 3.2 > Use -lg++ >xombi.wizard.net> cc++ main.cc >main.cc:86: warning: return type for `main' changed to integer type >ld: Undefined symbols: >endl(ostream &) >_cerr >ostream::operator<<(const char *) >ostream::operator<<(ostream &(*)(ostream &)) >_cout >ostream::operator<<(int) >ostream::operator<<(char) >xombi.wizard.net> > >Why is the linker having a problem? > >Thanks! > >--- >Son of Ginger and Harry, Aaron Rosenzweig >http://www.wam.umd.edu/~recurve/ >recurve@resourceful.com > -- 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.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 97 22:40:36 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb17224036@slave.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> In-reply-to: John Hornkvist's message of 17 Feb 1997 22:59:14 GMT In article <5eans2$8jq@nyheter.chalmers.se> John Hornkvist writes: Resource forks is only a way to reimplement directories inside a file. Which brings up an interesting question ... can anyone tell me if there's a limit on the number of files you can have on HFS? It just occurred to me that perhaps forks are a means of effectively doubling the number of files without requiring more metadata overhead. [I'm making two assumptions, here. One is that Way Back When, Mac had small disks, and for every file which needed a resource fork, you'd have needed twice as much metadata overhead. Furthermore, files may have been referred to with small integers to save space in the metadata.] Now, in Unix a directory is a file. A file with names and pointers to other files. Making the OS aware that some directories are not really directories but a special sort of file should be simple enough. This could be done using extensions, or by modifying the file system to add a "bundle" bit. However, I think things work well the way they are... They do work reasonably the way they are, but I think it would be perfectly appropriate to have a bundle bit. OTOH, I'm not sure quite where it could go without conflicting with directory handling code. For instance, you could use the sticky bit (but it's already used for directories), or a setuid/setgid bit to indicate something special about a directory. OTOH, I keep coming back to the thought that, when you come right down to it, if you _only_ manipulate the file through the UI, it really doesn't make a bit of difference whether it's a forked file, a directory wrapping individual files, or a database filestore of some sort. You don't care. It's only those of us who ever access files from somewhere other than the UI (command-line _or_ programmatically) who care. 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 in Seven Days, Unleashed>
From: Stef <stefan.kuypers@ping.be> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 08:42:26 +0100 Organization: HOSTE NV Message-ID: <33095D61.5859@ping.be> References: <5ddp66$jpc@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5e3bou$emo$1@newz.oit.unc.edu> <dfrick-1602971751420001@poha014.lava.net> <3308691E.51A7@worldbank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefano Pagiola wrote: > > scocca@gibbs.oit.unc.edu (Dave Scocca) wrote: > > Maybe the _real_ solution is to come up with a different extension > > separator (say a \?), keep the . as a generic character usable > > anywhere in a filename, use the \ to demarcate the "extension", > > No need. NeXTSTEP uses the whatever is to the right of the LAST . as > the extension. I have plenty of filenames with multiple periods in > them, and NeXTSTEp parses them all appropriately (eg 961021.Jones.wp is > correctly identified as WordPerfect file, not a "jones.wp" file). I haven't been really following this thread but from a few posts I've read it seems like there is a possibility we will be confronted with those horrible .type extensions to differentiate between file types. I DO hope Apple won't start using these horrible things when all these years we're used to just giving any name to our files. Can you allready imagine all those poor end users who rename their mypict.jpg file to mypict and then find out that double clicking the icon doesn't launch the right app any more? If I'm completely besides the subject (like I said I haven't been completely following this thread) then I apoligize. Stef
From: raymond@rcp.co.uk (Ray Offiah) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Tue, 18 Feb 1997 12:46:13 GMT Organization: Research Machines plc Message-ID: <3309a1c9.11108823@news.rmplc.co.uk> References: <jm041536-1702972018170001@mencjo.apple.com> On 18 Feb 1997 04:22:44 GMT, jm041536@fhda.edu (Joaquin Menchaca) wrote: >OK, > Let's get it straight guys, for those of you still confused. The >current specified Mach kernel under development (if you want to call it >that) is NOT a microkernel. OSF Mach 3.0, used in mkLinux, is an actual >microkernel. Apple's Mach kernel will have features from Mach 3.0, but >will not be the true Mach 3.0. Some are jokingly calling this 'Mach >2.5++'. > Yes, I too would love the latest wiz-bang features loaded into Rhapsody which would slow it down, cause it to be delivered late, and not really provide any benefits to it's users. >The near future is distributed cluster based microkernel which I believe >is evident in Mach 4.0. Microsoft with licenses from DEC will implement a >distributed cluster based Operating System with Windows NT 5.0. Let's also remember that MS has been promising an OO based file system for some time now ... so I think the lesson is (as with ALL software products) 'I'll believe it when I see it'. > Apple >will implement a monolithic kernel with Rhapsody. This kernel will be >upgraded to provide SMP (Symmetrical Multiprocessing). > .... you still haven't said why this is such a huge disaster, or why the kernel cannot be replaced at a later date. >Distributed microkernels will not only use SMP, but will also use other >processors and resources of various computers across high speed network >across different computers. Some may say this is analogous to the Borg in >Star Trek. > I think that, realistically speaking, Apple should do whatever gets Rhapsody into developers hands in the shortest possible time. If that means losing a few folk because they haven't the time to build in Borg technology, then that's a cross they will have to bear. Seems a fair trade to me.
From: tfs@gravity.science.gmu.edu ( Tim) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 17 Feb 1997 19:08:21 GMT Organization: George Mason University, Fairfax Va. Sender: tfs-----@gravity.science.gmu.edu (remove dashes to reply) Message-ID: <5eaab5$66f@portal.gmu.edu> References: <5ddp66$jpc@news.bu.edu> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> <SHESS.97Feb14122040@slave.one.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Summary: oh this was good In article <SHESS.97Feb14122040@slave.one.net>, Scott Hess <shess@one.net> wrote: >In article <5e03pp$thl@portal.gmu.edu>, Scott, that was really a good explenation, and provided way, way more depth than I'd even considered putting in. I realize that most of the things you described come into play with the "space" issue, but I wanted to make the point about the difference in potentialy usable space in a concise manner. The only issue you neglected was the tuneability of the filesystem. For instance on my swapdisk I have maxbpg set pretty high compared to the default set up with a min & max on the swapfile size, because it's purpose is to deal with that one big swapfile. Tim -- ________________________________________________________________ tfs@vampire.science.gmu.edu (NeXTmail, MIME) Tim Scanlon tfs@epic.org (PGP key aval.) crypto is good Seal Technologies Inc. I own my own words
From: fettig@clichy.this.domain.is.not.set (Thomas Fettig) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 17 Feb 1997 21:39:13 +0100 Organization: S.u.S.E GmbH Message-ID: <lsn2t3dv66.fsf@clichy.this.domain.is.not.set> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5du6c1$19c$1@darla.visi.com> <glenn-1402970234300001@61020d0022ct.concentric.net> In-reply-to: glenn@concentric.net.no.spam's message of Fri, 14 Feb 1997 02:34:30 -0400 In article <glenn-1402970234300001@61020d0022ct.concentric.net> glenn@concentric.net.no.spam (Glenn) writes: > > In article <5du6c1$19c$1@darla.visi.com>, David Young <dwy@ace.net> wrote: > > Are you *insane*? Apple's current OS has the *worst* memory management > > architecture of ANY operating system since the advent of the MMU. Period. > > Evidently you haven't done any 16 bit Winderz programming.... > glenn@concentric.net.no.spam So it is the second worst, and that is sad enough. tom
From: apuleius@ix.netcom.com (William Grosso) Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: Tue, 18 Feb 1997 11:13:01 GMT Organization: Netcom Message-ID: <33098bb9.30677792@nntp.ix.netcom.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5ebqe6$hu6@concorde.ctp.com> On 18 Feb 1997 08:49:10 GMT, "Georg Tuparev" <gtupar@ctp.com> wrote: > >I converted 40k lines program using the scripts for 2 days without any problem -- >now the program runs even on NT and Solaris, and very soon with GNU OS ... and is >very happy so. > So, we have: (1) NeXT's claim that 50K lines take approximately a month. (2) Many exchanges such as the following fom c.s.n.misc > > What is involved in taking existing NeXTStep Apps and > migrating them to OpenStep for Sparc? > > Is it "just a recompile"? No, it's a right f**king pain in the arse. (3) Statements from prominent NEXTSTEP programmers, like the following from Don Yachtman (note that I'm avoiding the people that Georg has labelled "NeXT haters"). >It is true. NEXTSTEP != OPENSTEP as far as the API goes. >There are some major differences, some of which are >conceptual and require not just changing method names, but in >some cases completely _rewriting_code. Stuff that uses >streams a lot can be onerous, for example. Having done some >NEXTSTEP->OPENSTEP conversion, I will openly state: >it is non-trivial to do! and (4) Georg's assertion that it's a piece of cake. Draw your own conclusions about the validity of what Georg says. Cheers, Andy "In the beginning, everything was even money" --Mike Caro
From: rflattin@cornut.fr (Roger Flattin) Newsgroups: comp.sys.next.programmer Distribution: world Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 12:02:49 GMT Message-ID: <3812884479.61889221@cornut.fr> Organization: Cornut Informatique SA >The near future is distributed cluster based microkernel which I believe >is evident in Mach 4.0. Microsoft with licenses from DEC will implement a >distributed cluster based Operating System with Windows NT 5.0. Apple >will implement a monolithic kernel with Rhapsody. This kernel will be >upgraded to provide SMP (Symmetrical Multiprocessing). >Distributed microkernels will not only use SMP, but will also use other >processors and resources of various computers across high speed network >across different computers. Some may say this is analogous to the Borg in >Star Trek. As far as I see (in particular official description), the Mach kernel used in NeXTStep is a micro-kernel (i.e. a minimal kernel that handle virtual memory management, multitasking with multiple thread support and interprocess communication). It is able to dispatch processing among several CPU (even if no NeXT commercial product use this fonctionnality) and through a network among several computer (I have been said that this was already the case). Roger FLATTIN rflattin@cornut.fr ---->> On our site a SHAREWARE SQL Query Tool <<-------- --->> Don't forget to Try also our C/S Dev tool <<------- CORNUT Informatique SA Client/Server & SQL RDBMS BP 702 - 42950 St Etienne cedex 9 http://www.cornut.fr/ France email: info@cornut.fr
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.next.sysadmin,comp.sys.mac.advocacy,comp.sys.next.programmer Subject: UK NeXTSTEP-user group meeting: 20 February 1997 Date: 18 Feb 1997 11:15:08 GMT Organization: University of Sheffield, UK Message-ID: <5ec2vs$18d@bignews.shef.ac.uk> Sorry about short notice, and for brevity of this message: Luke Howard of Xedoc is currently in the UK, and has kindly consented to give a talk about NetInfo (which will then lead to a discussion about other aspects of "recent events" :-) at 6:00pm on Thursday 20 February at Complete Works 399 Strand, London. (Just above Stanley Gibbons) 0171 836 0808 Many thanks to Jackie Mackay of Complete Works for agreeing to host this at short notice. Could you please let me know if you're likely to attend. Best wishes, mmalc. --
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 13:49:17 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> In-Reply-To: <5e9ral$jfu@horus.ecmwf.int> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: File S.. by Mike Connally@ecmwf.int > |> Either you can put _any_ file on a remote system like an Auspex NFS > |> server, and have it work correctly, or else some crucial parts of what's > |> on a Mac filesystem cannot be stored on remote fileservers because they > |> won't work correctly. > > Are you asserting that you can put _any_ file from any UNIX > system on _any_ other UNIX system and have it work properly? > Executables? For example, let's say I'm using a Sun SPARC and my company has an Auspex fileserver. I can NFS mount the Auspex server on my Sun, and I can run Sun SPARC executables stored on the remote machine. In fact, I could use any type of machine as an NFS fileserver, and be able to run SPARC binaries stored on that fileserver without any problems. I could use Samba and an NT fileserver instead of NFS, if I wanted. Or I could use a Novell Netware fileserver. Again, it shouldn't matter to me what the remote fileserver is-- I should be able to store executables on it and be able to run them. However, I can't NFS mount a remote fileserver on a Mac and be able to run Mac executables, because they require the out-of-band information stored in their resource forks which is not representable within the standard NFS/UFS filesystem paradigms. > Very very wrong. Executables are tied very closely to the OS and HW and > don't happily move between platforms. Executables are machine specific, correct-- but they can be stored on remote fileservers without any problems, and they should be able to run on the appropriate hardware platform that the executable was compiled for. [ ... ] > I have never encountered anything like the originally quoted > "huge pain trying to transfer files to other platforms in a > meaningful way". I suspect anyone who says that has never > actually tried doing it. It's trivial. Sorry, but you're wrong. Macs do not integrate very well with with heterogenous network fileservers, because their executables won't be runnable when stored on an NFS fileserver (or a NT fileserver, or a Novell fileserver, etc). -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.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Mon, 17 Feb 1997 14:35:54 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <cn2=AO200iV7E5aK9A@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> In-Reply-To: <3307DFEA.2FB0@acm.org> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >> Operating systems fail when the machine is not provided adequate >> resources for the tasks that it's supposed to perform. Polite operating >> systems fail in a reasonably graceful way that may even allows you to >> correct the problem without rebooting, which is what NEXTSTEP does. >> >> Other operating systems tend to panic or lock up. > > If NextSTEP does this good. > However, don't lump all other OSs into the panic and lock up variety I didn't say "all other OS's". While there are a few OS's which are as stable than NEXTSTEP, the vast majority of computer systems are running either MS Windows or MacOS-- both of which are well known for their lack of stability. [ ... ] >> Apparently, you seem to think the OS should ask the user via an alert >> panel to browse the filesystem in order to specify where the missing >> file is. Do you agree that this was your suggestion? > > Not exactly. The OS should ask the user/an operator what to do, locate > the file, kill the process, ignore the file and continue. You have > quite a few options. The operating system does not have the decision-making powers of a human, and it cannot make a decision between the alternatives you've listed-- it will only do what it's programmed to do. Therefore, you've either got to pick _one_ of the alternatives, or else provide a deterministic and decidable algorithm that the OS can use to select an alternative. Of course, you've failed to address the crucial point I've made, which is that _any_ of the choices you've listed will be an inappropriate action for some processes. No matter how many choices you come up with and how complicated the algorithm to select between them is, I'll be able to come up with situations which require different error handling than what you've stated that the OS should do. >> But what happens if there isn't a user? Should the process block >> indefinitely until someone notices that the machine is wedged? > > That is preferrable to killing the process, which is an extreme form > of blocking and you will still have to wait for someone to come and > fix it. Or do you mean that the process will be killed and automatically > restarted. This is a possibility, but of course the condition that > killed the original process might still be in effect. In this case the > operator has a much harder job of trying to prevent the continual > loop of [kill process; restart process]*. Whichever way you are > still blocked. But Unix doesn't block when open() fails-- it returns EACCESS immediately, which allows to process to decide whether to continue, ask the user for help, or do whatever else it finds appropriate, such as terminate. That's a far superior solution to blocking. [ ... ] >>>> I assume you're just talking about the first case, where malloc() fails. >>>> Polite applications warn the user that they couldn't get the memory >>>> they needed, and they abort the operation being attempted, and return to >>>> their main event loop. >>> >>> Since this is a case that should be handled by every running task, >>> why burden the application programmer with this task: >> >> Because not all tasks will want to handle a particular error condition >> in the same way? > > But what I am saying is that you can do a good OS design by evaluating > all those ways, and then giving the option (which might also include some > automatic policy that circumvents the user/operator). (A) It's impossible for the OS designer to incorperate every possible way that a process might want to handle every possible error condition, and, (B) even if it was possible, why would you want to bloat the OS with all of that code when it's simpler and easier to design processes that perform the error handling that they need? Good operating system provide well defined interfaces to support processes, and these interfaces should be made as small, as simple, and as elegant as possible while still providing all of the functionality that's needed. Complex functionality like a window system, or a math library, or a set of error handling routines belongs in user space, not in the kernel. Ever hear of modularity? [ ... ] >>> In order to >>> prove your asserted contradiction you would have to show what is >>> inappropriate for the OS to handle in any of the example scenarios >>> I have given. >> >> Very good. I'll be happy to do so: >> >> Consider a machine like a web server, which does not have a user or >> administrator on the console. It's the responsibility of the >> programmers to write the web server so that it returns a 4xx code >> indicating that the requested resource was not found. >> >> It would be completely inappropriate for the web server to stop running >> and pop up an alert panel that some file could not be found, and wait >> for someone to tell the program what to do. > > Yes, but if you go back through my posts you'll find that I allow for > that situation. And how would you allow for that situation? > Sorry, but I have deleted the rest of the post, it just smacks of > a personalised flame war, which I don't want to get dragged into, > is irrelevant and will bore most readers (and myself). Fine by me-- I've made my points and I'm willing to let them stand if you don't care to debate them further. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: johnh@madcow.dircon.co.uk (John Holdsworth) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer Subject: Bring back List, HashTable classes and string datatype! Date: 17 Feb 1997 20:52:12 GMT Organization: via Direct Connection News service Message-ID: <5eagds$niv$1@newsserver.dircon.co.uk> I don't want to sound like a luddite but... I've put a fair amount of time into scoping the amount of work involved in porting some real applications onto OpenStep only to find that the common classes List, HashTable etc all gone from the OpenStep spec. Arrrrgh! These where useful, tightly written classes that surely would not have been to much effort to port to OpenStep (even inheriting from NSObject( but no, we are told we must use the impossible to subclass NSMutableDictionary and NSArray class clusters. While I appreciate people are trying to help us out by moving us onto these far "better" classes in the real world we have to keep software running not break it (even if we had two years to change over.) Perhaps this might explain why there are allot of NeXTStep apps out there (OmniWeb, Mesa, GateKeeper etc) but very few new OpenStep products that I am aware of. While I'm at it lets keep strings as a data type rather than a class. A char * can go along using dodgy features like a reference count at (char *)string[-1]. EOF would be a good deal simpler and faster if NSString hadn't been invented. Dates have loads of complex behaviour and justify being a class strings are better kept as a datatype. Flaming on... John H. (madcow is a Gateway 2000 PC in case you're wondering)
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: allan@ali.bc.ca (Allan Noordvyk) Subject: Re: Mac/NeXT & Unix: File System Message-ID: <E5rECI.4nu@gateway.ali.bc.ca> Sender: nobody@gateway.ali.bc.ca Cc: syy@ecmwf.int Organization: ALI Technologies Date: Mon, 17 Feb 1997 18:07:30 GMT References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> In comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Mike Connally wrote: > In article <sn2516600iVGI0zSpA@andrew.cmu.edu>, Charles William Swiger > <cs4w+@andrew.cmu.edu> writes: > |> Either you can put _any_ file on a remote system like an Auspex NFS > |> server, and have it work correctly, or else some crucial parts of what's > |> on a Mac filesystem cannot be stored on remote fileservers because they > |> won't work correctly. > > Are you asserting that you can put _any_ file from any UNIX > system on _any_ other UNIX system and have it work properly? > Executables? Very very wrong. Executables are tied very > closely to the OS and HW and don't happily move between > platforms. I think you missed his point. You put the application on a NFS (ie. Network *File* Server) so that the application files are accessible from any client machine on the network. The server and clients can be running completely different operating systems. The server can be running an operating system which can not "run" the application, but that doesn't matter. As far as the server is concerned the application is just a collection of files. The client just accesses the remote file system and runs the application in its own memory space on its own CPU. Not the servers. I do this all of the time. It works great. With NeXT's fat binaries, the clients can even have different chip architectures and but use the same application on the remote file system. This is where the advantage of using a wrapper system really shines. If you have special resource fork or other scheme to represent file/application information, you have to figure out how to encode this on the alien file system and translate it on the fly. The wrapper approach uses a scheme which doesn't require any special representation, since it already works using regular directories. -- 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 * "Change is inevitable, except from a vending machine."
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Updates in EOF 2.0 Date: Tue, 18 Feb 1997 12:34:18 +0100 Organization: Impact GmbH,Cologne, Germany Message-ID: <330993BA.2738@microcomp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo ! According the documentation , method setSavesToDataSourceAutomatically of EOController in 1.1 is in 2.0 obsolete, because changes are directly send to database.On my experience (Sybase 11, NT 4.0, Openstep 4.1) you must still explicitly send saveChanges to EOEditingContext to propagate changes to database. Is there some possibility to let updates in NSTableView to be send direct to database ? Petr Novak
From: pim@Intranet.eo.nl (Pim) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 14:31:17 GMT Organization: Nederlandse Omroepen Message-ID: <5ecefl$5d1@kwek.omroep.nl> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> : : > On Win 95 I have both Borland and MS compilers installed. After : : > installing the Borland compiler all my MS Visual C (*.c/cpp) created : : > files now insist on openning with the Borland compiler when I double : : > click them! I can't have some *.c/cpp files open with VC and others with : : > Borland and of course they must end in c/cpp to open with either one. : : > : : > What is the a type/creator mechanism on NextOS that will prevent this : : > step backwards in usability for Mac users in the future? : : : : There is no 'creator' concept - that idea falls apart in a multiuser : : scenario. Like other people pointed out, even in a multiuser environment, there should be such a thing as a default-application to open up a certain icon with. Changes by a normal users ought to be somehow stored in his/her own homedir or registry, preferences folder or whatever. : Ignoring the attempt to brush off the issue with with an air of false <snip> : : : Filename extensions are used, but they are more flexible than Windows : : extensions. There's no limit on the length of the extension, for : : instance. The NeXTSTEP presentation app 'Concurrence' uses a : : '.concur' extension. Spaces are allowed in filenames. : While the Mac users abhorance of file extensions is largely religious, : it will probably need to be honored for the sake of a smooth migration : path. However this could be as simple as hiding the extension from view : in the Finder. : Excuse me, but I don't see the point of creating a kludge by using filename extensions for filetypes. The filename is, as far as I know, just part of a file's inode in most filesystems. Hence, using hidden filename extensions or a resource with a Type/Creator basically amount to the same thing under a different name. : In this sense, Contents Inspector works like QuickTime, though QuickTime : uses/makes custom previews and icons. Custom icons are particularly : useful since even the best file name is not always as meaningful as a small : version of the image. : A really well-organized mind might be able to make a few destinctive proper- ties of an image and retreive them through those, but in the Real World I guess you're right :-) : How to store this and like info (custom icons, previews, etc.), whether : by forks or wrappers or hidden files or filename extensions is a technical : issue which does not need to impact the look and feel or user experience. : Hopefully only the engineers will worry about this. That sounds, in fact, a lot more sensible.. Regards, Pim r00t@pi.net
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 15:15:21 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5ech29$9qj$1@brachio.zrz.TU-Berlin.DE> References: <5ecefl$5d1@kwek.omroep.nl> In article <5ecefl$5d1@kwek.omroep.nl> pim@Intranet.eo.nl (Pim) writes: [other stuff deleted] > The filename is, as far as I know, just part of > a file's inode in most filesystems. This is not the case in UNIX. I-Nodes/Files are nameless. They are referenced by directory entries, which are named. So you can have multiple (hard) links with different names pointing to the same I-Node/File, as well as multiple (soft) links pointing to a certain path-name. Marcel
From: tfs@gravity.science.gmu.edu ( Tim) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 18 Feb 1997 01:29:32 GMT Organization: George Mason University, Fairfax Va. Sender: tfs----@gravity.science.gmu.edu Message-ID: <5eb0ls$34j@portal.gmu.edu> References: <5d8qta$6np@news.bu.edu> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Summary: umm yet-another-point In article <5ean3v$3l5@spool.cs.wisc.edu>, Steve Barnet <"mailer-daemon"@[127.0.0.1]> wrote: > >Your point is valid and UNIX provides a mechanism for not slaying >innocents. Most Unices have a notion of user limits (ulimit). This >enables the administrator to set resource limits on a per user basis. >So to deal with your scenario (shooting an innocent (possibly crucial) >bystander), it's necessary to set user limits appropriately. This can >prevent a user from monopolizing the box and (if done wisely) can make >sure that crucial processes still have enough room to do their thing. Well, there's one other really good reason for ulimit too, and it's probably the one I've seen most utilized as well. Basicly it's limitation by & for the user. If I am working on/with some program that I've found to have problems for one reason or another, and I don't want it to eat up all the resources of the computer, I can as a user ulimit whichever catagory I have concerns about. Limitation by the admin is a superset of the same capacities that users have. Besides ulimit, there's also "nice" which is more commonly used by users I belive. In a client/server setup, where you want to make sure that users don't hog the resources of a central server (this is common in educational enviornments), ulimiting user processes appropriatly on a server can be quite useful to say the least, and is a common problem that needs dealing withfor the reasons that you described above. Tim -- ________________________________________________________________ tfs@vampire.science.gmu.edu (NeXTmail, MIME) Tim Scanlon tfs@epic.org (PGP key aval.) crypto is good Seal Technologies Inc. I own my own words
From: "Georg Tuparev" <gtupar@ctp.com> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 18 Feb 1997 08:49:10 GMT Organization: Cambridge Technology Partners, Inc. Message-ID: <5ebqe6$hu6@concorde.ctp.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> --- Flame on --- Why some people cannot (or do not want to) understand that backwards-compatibility == M$ All these "I cannot convert to OS", "Where is the List class" etc. questions indicate poor design and implementation, and if somebody writes lasagne code, even backwards compatibility will not help ... he will find another excuse for his handicap. I converted 40k lines program using the scripts for 2 days without any problem -- now the program runs even on NT and Solaris, and very soon with GNU OS ... and is very happy so. --- flame of --- Say hallo to Steve. S. III, David S. and Greg A. They may accept you as a member of their hater club. In article <5eagds$niv$1@newsserver.dircon.co.uk> johnh@madcow.dircon.co.uk (John Holdsworth) writes: > > I don't want to sound like a luddite but... > > I've put a fair amount of time into scoping the amount of work > involved in porting some real applications onto OpenStep only > to find that the common classes List, HashTable etc all gone > from the OpenStep spec. > > Arrrrgh! > > These where useful, tightly written classes that surely would > not have been to much effort to port to OpenStep (even inheriting > from NSObject( but no, we are told we must use the impossible to > subclass NSMutableDictionary and NSArray class clusters. [...] -- ------- /\/\ 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.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 10:35:10 -0500 Organization: phenix@interpath.com Message-ID: <1997021810351033363403@roxboro-161.interpath.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> Scott Hess <shess@one.net> wrote: -snip- ] ] BSD FFS has also been used by several million users for more than a ] decade. ] ] BSD FFS was designed for multitasking timesharing server systems, ] systems with substantially more disk, memory, and CPU than personal ] computers of the day had, in a midsize heterogenous network ] environment. Systems, in fact, which look suspiciously like the ] personal computer systems of today, except that today's PCs have ] high-resolution video output devices. But it can still use some extensions - adding file type/creator and a creation time isn't a bad idea, although where that information is kept is another matter (it could be kept in a database and accessed by fileID#). ] HFS, meanwhile, was designed to run in a box with 128k of RAM, on a ] system which would be used by a single user, in a small homogenous ] networking environment. Not really - MFS was designed for such a machine. HFS was designed for a 1 meg machine with a 20 meg HD and a networking environment that wasn't entirely homogenous. ] Put another way, HFS was designed for the personal computers of ] yesterday, while FFS was designed for the minicomputers of yesterday. ] Today's personal computers are beyond the minicomputers of yesterday ] in many ways. Yes, but they have different needs. -- John Moreno
Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy From: stephen farrell <sfarrell@phaedrus.uchicago.edu> Subject: Re: Apple Mach IS NOT a microkernel!!!!! Content-Type: text/plain; charset=US-ASCII Message-ID: <87u3nayt41.fsf@phaedrus.uchicago.edu> Sender: news@midway.uchicago.edu (News Administrator) Organization: University of Chicago -- Academic Computing Services References: <jm041536-1702972018170001@mencjo.apple.com> <3309a1c9.11108823@news.rmplc.co.uk> Mime-Version: 1.0 (generated by tm-edit 7.89) Date: Tue, 18 Feb 1997 16:30:22 GMT [crap about the Bord deleted] > > I think that, realistically speaking, Apple should do whatever gets > Rhapsody into developers hands in the shortest possible time. If that > means losing a few folk because they haven't the time to build in Borg > technology, then that's a cross they will have to bear. Seems a fair > trade to me. > i don't fully understand this point. developers can go out right now and purchase openstep for mach on intel, sparc, and hppa platforms, and for winNT, and solaris. why doesn't apple encourage them to do so, and make sure that the final product they deliver is simply openstep compliant (or at least just needing trivial fixes and a recompile)?
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 97 15:53:36 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb17155336@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> In-reply-to: syy@ecmwf.int's message of 17 Feb 1997 14:52:05 GMT In article <5e9ral$jfu@horus.ecmwf.int>, syy@ecmwf.int (Mike Connally) writes: In article <sn2516600iVGI0zSpA@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> writes: |> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: File S.. by Mike Connally@ecmwf.int |> >> One wonders if that's a good thing. One of the largest |> >> problems with the Mac filesystem is that it's a huge pain |> >> trying to transfer files to other platforms in a meaningful |> >> way. |> > |> > What problem is that? Other systems (e.g. UNIX) want to see |> > a byte stream, which is what exists in the data fork of a Mac |> > file. [ ... ] Apps are another matter, of course. |> |> That "of course" is why the Mac forks are a problem. |> |> Either you can put _any_ file on a remote system like an Auspex |> NFS server, and have it work correctly, or else some crucial |> parts of what's on a Mac filesystem cannot be stored on remote |> fileservers because they won't work correctly. Are you asserting that you can put _any_ file from any UNIX system on _any_ other UNIX system and have it work properly? Executables? Very very wrong. Executables are tied very closely to the OS and HW and don't happily move between platforms. Ugh, sorry to bust your bubble, but I can place executables from pretty much any Unix (Linux, Solaris, whatever) on my NeXTstation just fine. It's just a file of bytes, after all. Of course, I can't _execute_ the executable. I don't have the right OS or processor for that. But I can act as an NFS fileserver for another Unix system which _does_ have the right OS and processor. _That's_ what you can't do as well for HFS. It's tougher to have a giant SMP SCSI RAID 1+0 100Mbps switching server to handle all of your Mac files, data _and_ apps. Easy as pie (well, close :-) for any version of Unix _I've_ seen. 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 in Seven Days, Unleashed>
From: Michael Hudson <sorry.no.email@nowhere.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 16:56:51 +0000 Organization: University of Leicester, UK Message-ID: <3309DF53.3A07@nowhere.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <msoori-1302971003500001@ms.genetics.bio-rad.com> <3303B988.4E8F@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ian Joyner wrote: > > You are correct that there are several different uses for files, which > need to be identified. However all uses can be designed into an OS, > and a consistent treatment can be designed. > > For example, there is a different treatment for a file that the > application > expects to be there, and one that it might optionally create if it is > not present. > Or a file might be optional, in which case the application might > continue happily without it being there, with your preferences > example it just uses defaults. Yes the application will code for these > cases, but my point is there is a lot more that OSs can and should do. > > If the file is mandatory, what can the application accomplish? The > user or some other process must make the file present. In fact that > is one way of synchronising processes. > Are you saying that when you ask the OS to open a file, you should tell it how badly you want the file? eg namespace file_system { enum requirements { required, optional, create_if_absent }; open_file(const file_spec& in_file, permission in_perm, requirements in_req); }; ... using file_system; open_file(the_file_spec,fsRdWrPerm,optional); open_file(the_file_spec,fsRdWrPerm,required | create_if_absent); This strikes me as being a little like the ios::nocreate flag in the C++ library. Does any OS do this? -- Regards, Michael Hudson Please don't email this address - it's not mine.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 23:05:57 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5eb9r5$iv2@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> In article <AF2E42E196681EFC18@node50.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: > I'm blathering on about this because it seems like a large number of the > arguments by NeXT partisans boil down to 'it has to be this way if you're > on a multiuser system.' Well, as I said, I don't WANT a multiuser system; Well I'm sorry, but too bad. Apple is not going to redesign the entire filesystem to make single users a little happier when it means sacrificing multiuser capability and returning to 80's technology. You can go on all you want about Apple's targeted market, but it's a step backwards and Apple's not going to take it. HFS is one reason why Macs are not considered seriously in server environments. > and in my experience, this holds true for the vast majority of machines > outside of a lab environment. Actually, I know of quite a few machines both in work and home environments which more than one person uses. And there are still good reasons for having a multiuser machine even if only one person uses it. > I don't mind having things in there for the > benefit of multiuser setups, as long as they don't get in the way of > ordinary single-user operation; but if there's a conflict, I think > multiuser features have to take a back seat to convenience features for > single users. There really are not very many instances where having a multiuser filesystem seriously inconveniences single users, your opinions notwithstanding. > To the point at hand: I think it makes a lot more sense for the default to > be the application that created a file. I don't. I've used Macs and I've used NEXTSTEP and I like the NEXTSTEP way far better. I don't want to get a file from somebody and have it open in whatever _they_ like to use. I want all GIFs to open in my preferred GIF viewer, etc. > Again based on my experience, > people generally create a file with the application they want to use to > work with it. They may create it with one application, and then prefer to view it from then on using another. Or they may prefer to view a document someone sends them with one viewer application rather than a full-blown editor. But that's the point you just made below. There are a _lot_ of exceptions though, at least with the files I typically work with. And the documents that I both create and view with the same application are usually with an application that has its own document format, so opening by type doesn't make any difference anyway. > The exceptions I see are usually data-acquisition situations > (including working with scanned images), where you use one program to get > the file, and a second program to manipulate it. > In this situation, it > makes far more sense to have a file-by-file preference, allowing styled > text files to open in SimpleText by default, and other text files in > BBEdit. In practice, I think Apple will probably add something like this, probably in the form of a user-level database of file->app associations. > >It's very easy for a multiuser OS to act like a single-user OS, as > >NEXTSTEP did with the default 'me' user. The reverse is not true, and > I'm afraid it's your premise that's not true, as you and other NeXT users > prove every time you use 'it can't be done that way on a multiuser OS' as > an argument -- as you just did above. It's easy to do, within _reasonable_ constraints. The 'me' account is quite good at fooling people into thinking the machine is a single-user one. But once you start doing idiotic things like writing information about which application should open a document directly into the filesystem, then there's no hope of a multiuser system remaining a multiuser system. If you put that kind of information in a _per-user_ database, where it belongs, then things work perfectly fine and the user is none the wiser. > If many of the conveniences and > operating methods that Mac users are used to can't be done on a multiuser > OS, then it's obvious that a multiuser OS can't act like the Mac > single-user OS. It's all a matter of efficiency. A multiuser OS can emulate a single-user one just fine. > Not if it compromises Apple's traditional ease of use, and especially not > if it's for a minority of users. And another thing. Stop pretending you speak for the majority. Mac users probably prefer the Mac way because it's the only thing they know. NEXTSTEP users generally have used NEXTSTEP _and_ Macs (or something else). The fact that they still prefer the NEXTSETP way says something. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: jalon@drakkar.ens.fr (Julien Jalon) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 04:23:28 GMT Organization: Ecole Normale Superieure, Paris Message-ID: <5ebas0$gqs@nef.ens.fr> References: <5ddp66$jpc@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb0d2$1en@news3.digex.net> In article <5eb0d2$1en@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> wrote: >That's very nice. And I want to be the ruler of the universe. >Looks like today neither of us will get what we want. Many people >can and do benefit from multiuser os's. This is the same kind of >argument I used to hear from dos heads. We don't want or need GUI. >Who needs it? It's useful, and if you don't like it, no one will >force you to make use of it. > >But, for certain server level processes it's great. That way the >kids, while they are on their account, won't be able to crash down >the web server processes you have going. That way your mother in >law won't be able to spitefully kill your tax files. etc etc. > And you can have your own personnal accounts : one to play, one to work, one to develop programs, etc... but the most important : one to install programms (=root) and one to run them (=me, or whatever you want) : result is almost no viruses, or not very dangerous viruses, no dangerous system crahes which remove all the files on your hard disk ! --Julien -- Julien Jalon | Ecole normale superieure jalon@clipper.ens.fr | 45 rue d'Ulm http://www.eleves.ens.fr:8080/home/jalon/ | 75230 Paris Cedex 05 | FRANCE
From: eric@skatter.USask.Ca Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs Subject: OPENSTEP/MACH 4.1 -- printf %g still broken Date: 18 Feb 1997 17:27:13 GMT Organization: University of Saskatchewan Message-ID: <5ecoph$74i@tribune.usask.ca> I just finished installing OPENSTEP/MACH 4.1 (Intel). I then checked to see if my favorite bug had survived yet another version: eric@pisces 224> cat printfcheck.c #include <stdio.h> int main (int argc, char **argv) { printf ("Expect 0.00123: %.3g\n", 0.001234567); printf ("Expect 123: %.3g\n", 123.4567); printf ("Expect 123.5: %.4g\n", 123.4567); printf ("Expect 1e+03: %.3g\n", 999.6); return 0; } eric@pisces 225> cc -o printfcheck printfcheck.c eric@pisces 226> ./printfcheck Expect 0.00123: 0.001 Expect 123: 123.457 Expect 123.5: 123.4567 Expect 1e+03: 999.6 eric@pisces 227> ================================================================== Yes! It's still not fixed! Seven years and three months since I first reported it (way back in the NextStep 1.0 days). I even have the NeXT bug tracking reference numbers [60697, 98369] and an e-mail message from NeXT (September 1994) indicating that, ``it looks like it will finally be fixed in NEXTSTEP release 4.0.'' I wonder if this has any chance of being fixed before OpenStep mutates into Rhapsody? Every other time I have posted an article about this bug I have received mail saying that the behaviour of the NeXT printf is correct. To try and forestall these replies I include the following: The ANSI standard (X3.159-1989) says (Section 4.9.6.1, page 134, line 33): g,G The double argument is converted in style f or e (or in style E in the case of a G conversion specifier), with the precision specifying the number of significant digits. If the precision is zero, it is taken as 1. The style used depends on the value converted; style e (or E) will be use only if the exponent resulting from the conversion is less than -4 or greater than or equal to the precision. Trailing zeros are removed from the fractional portion of the result; a decimal-point character appears only if it is followed by a digit. *** NOTE THE WORDS `precision specifying the number of significant digits'. *** Let's have a look at some examples from the test program: format "%.3g" .001234567 ==== Result was: 0.001 ---- Result should have been: 0.00123 The zero's in 0.00123 are *not* significant. Score 1 against NeXT. format "%.3g" 999.6 ==== Result was: 999.6 ---- Result should have been: 1e+03 The format calls for 3 SIGNIFICANT DIGITS. Rounding 999.6 to three significant digits leaves 1000, which has an exponent equal to the precision and therefore should be printed in e format. Score 2 against NeXT. -- Eric Norum eric@skatter.usask.ca Saskatchewan Accelerator Laboratory Phone: (306) 966-6308 University of Saskatchewan FAX: (306) 966-6058 Saskatoon, Canada. NeXTMail accepted.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 20:29:15 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45ghfmn.oqs.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <slrn45g122e.o78.campbejr@phu989.um.us.sbphrd.com> <peterm.855819006@ulfrun> On 13 Feb 97 07:30:06 GMT, Peter Moller <peterm@dna.lth.se> wrote: >campbejr@phu989.mms.sbphrd.com (John R. Campbell) writes: > >> An inode contains the timestamps of creation, modification >> and access, permissions and an array of block numbers where > >Correction; there is no time stamp that says when the file is created >(a *major* bummer in my opinion). There are three time stamps that tell >you when a file was last: >1. modified (content) stat.ctime (doubles as "creation time" since chmod is not normally changed). >2. mode changed (file attributes) stat.mtime >3. accessed stat.atime Your correction is understood, but remember the context. The ctime isn't changed all that often; It's changed when the inode *itself* has been manipulated rather than the file it refers to. For instance, once a file's created, how often do *you* think the permission bits need to be manipulated, hmmm??? -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
Date: Tue, 18 Feb 1997 11:21:12 -0600 From: amas@lhr-sys.dhl.com Subject: [Q]Getting list of windows in Openstep? Newsgroups: comp.sys.next.programmer Message-ID: <856285888.5928@dejanews.com> Organization: Deja News Usenet Posting Service Is there any way of getting a list of the visible windows in Openstep, and then their rectangles? Thanks - Please email me a copy of your reply Andre-John -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 97 07:47:53 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb18074753@howard.one.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> In-reply-to: John Kheit's message of 18 Feb 1997 05:51:50 GMT In article <5ebg1m$1en@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> writes: jm041536@fhda.edu (Joaquin Menchaca) wrote: > OK, > > Let's get it straight guys, for those of you still confused. > The current specified Mach kernel under development (if you > want to call it that) is NOT a microkernel. To further clarify, the current Mach kernel under development is _not_ "under development" in the same sense as replacing it with some other kernel would be "under development". In fact, insofar as that comparison goes, the current Mach kernel is pretty much finished. > OSF Mach 3.0, used in mkLinux, is an actual microkernel. > Apple's Mach kernel will have features from Mach 3.0, but will > not be the true Mach 3.0. Some are jokingly calling this 'Mach > 2.5++'. Yes, this has been rehashed several times, at least in the NeXT groups. If I remember correctly, some of the issues, and at least some consensus came to this concluse (If I got it wrong, please set me straight folks :) That micro kernels tend to be more buzz word hype than valuable... Why, b/c putting things outside the kernel, in general, results in some serious performance penalties for no real functional benefit. Thus, Avie, and the folks at NeXT (now apple), who really know a thing or two about this stuff, to say the least, opted to keep things monolithic for perfromance reasons. Yet the functionality of a monolithic kernel is not reduced by its monolithicness. Umm, well, hmm. This is a rapidly evolving area, not only because there are people working on the problem of making microkernels more efficient, but because CPU speeds are outrunning I/O speeds, and main memory sizes are growing quickly (though not really getting faster). On a system like a NeXTstation, where the CPU, memory, and I/O are relatively balanced, a monolithic kernel can be easily more efficient. On a machine like a Pentium Pro 200 with 64M or 128M of RAM, a microkernel's inefficiencies start to lessen when compared to a monolithic kernel. The problem is that the system is becoming I/O bound. A monolithic kernel waiting for something to happen is no more efficient than a microkernel waiting for something to happen. On the other hand, a microkernel allows for things like filesystems to be more easily worked on and replaced, thus potentially improving the _net_ performance. Beyond that, on personal computers you tend to have a few processes using significant resources, but not necessarily doing very many kernel calls per unit of CPU time used. [Excepting web browsers, I supposed :-).] In fact, perhaps the single biggest amount of kernel activity on many systems, after virtual memory activity, is probably the context switching between apps and their windowserver. Microkernels must by nature be very focussed on context switch time as it applies to messaging, so if a microkernel were somewhat quicker there, it would probably cancel out the increase in context switches for many users. Also, I would rephrase things as "the functionality of a monolithic kernel 'as delivered by the vendor' is not reduced". But with a monolithic kernel, replacing things like filesystem drivers is much harder. [I'm not talking about CD-ROM-as-NFS-filesystem like what NeXTSTEP has. I'm talking replacing FFS with, say, an LFS, which is used from boot time onward.] Furthermore, similiar arguments about object oriented kernel design were wrung out... Namely that Mach 4.0 was done in C++, thereby making it OOP... It too might be a situation of more buzzword-checklist hype than reasoned implementation. The kernel being a low level layer of the OS, really needs to be tuned as possible, and OO'ness doesn't necessarily make much sense or add much functionality to that layer/level, and results in more of a performance hit than functionality gain. The message-passing _kernel_ needs to be insanely efficient hand-tuned C with assembly. It's in the critical path of almost every operation the system does, for all that it should only be 50k-100k. The stuff you hang off the kernel can be whatever makes the most sense. With today's larger memories, you can afford a certain amount of slop if your filesystem access patterns can be made more efficient. Obviously, if your filesystem code is 2x the size of hand-tuned C, and doesn't implement anything to improve performance, you'll have a net loss. In any case, why are we even discussing a point made by someone who compares distributed computing to "The Borg"? I _very_ much doubt that OS designers watch Star Trek in order to get wonderful new ideas about the future. [Or is the implication that the Borg run a microkernel operating system? Perhaps Amoeba.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 97 11:36:22 GMT Organization: Lund University Message-ID: <peterm.856265782@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> shess@one.net (Scott Hess) writes: >No, it's not! Sigh. BSD FFS already does a wide variety of things >that Mac's UFS can't do or doesn't do well. Things like optimal >placement policy, disk fragmentation prevention, longer filenames (256 >bytes per name versus 32), larger filesystems without "clusters" There are definetley things that I'd like to be included in Rhapsody's filesystem and these are among them. BTW: what character encoding does NeXT's filesystem use? I definetley hope they go for Unicode throughout the OS. >_These_ are the really important things. Personally, I could care >less if you moved the other timestamps out of the filesystem, also. >The _only_ things necessary in the inode are the owner, group, >reference count, size, and direct, and indirect block pointers. As long as the user has a stable file system and not the kind of hack that Micro$oft has created to handle long filenames in Virus 95, yes I agree with you. >Why are the last accessed, modified, and inode updated times in there? >Quite simply for performance reasons. These things are being modified >_all_ of the time. Whether the kernel portion of the filesystem is Well, they are *read* quite often, I agree with that. But I'd like to say two things: 1. The MacOS don't have a tenth as many files as Solaris for instance. Thus, this kind of file info isn't read/changed at all as often. The Mac OS, however, fiddles with resources *all* the time, and thus for a Mac it's more important to have a fast resource manager than a fast filesystem (byt I'd love to see a really fast FS). 2. As far as I know, nothing less than a block (usually 512 bytes) is ever read from the hard disk. I don't know, but I assume that the OS doesn't sequentially read in the file header until it finds the information it looks for, but rather it get's it "directly" via an index, right? So how much time does it takes to use another index? I also assume that the file info in the cache behaves equally. Thus more info in the file header will not take more CPU time (unless that info is often referred/changed), right? Reading a few more bytes from the hard disk is hardly relevant here. >the most sensible place to generate this information is moot, because >it simply can't be generated anywhere else with the same speed. When >you're talking about updating something hundreds or millions of times, >a couple CPU cycles begins to make a difference. Yes, definetley. >On the other hand, files are only created once. The fact that a user >process can't generate that info as fast as the kernel can is besides >the point, because the operation only happens once. Yes. >Specifically, though, you're unhappy because you can't find out when a >file was created easily. You don't say that you're unhappy because >the inode structure doesn't contain a creation timestamp. [No, that's >_not_ a silly distinction. You'd have to modify all of the file As I said above, it's not important how the information is stored; in the FS or in some layer above it (possibly together with some revision and multiuser info), that is right. My only "demand" (if I may have one) is that it's rock solid and built in from scratch, i.e. not a hack. Hacks simply aren't good enough. >management utilities to propagate a new timestamp anyhow, just having >the timestamp there won't do squat.] Is it the applications that modify the other time stamps?? I thought it was the FS. >BSD FFS has also been used by several million users for more than a >decade. So that means we can never change it? >BSD FFS was designed for multitasking timesharing server systems, >systems with substantially more disk, memory, and CPU than personal >computers of the day had, in a midsize heterogenous network Oh, it's a good file system, but it can be improved, and this might be a good time. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 13:27:50 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> In-Reply-To: <jchan-1702972337280001@pm5-18.apk.net> Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & Unix: File S.. by Jerome Chan@apk.net > > Sorry, but you're wrong. Macs do not integrate very well with with > > heterogenous network fileservers, because their executables won't be > > runnable when stored on an NFS fileserver (or a NT fileserver, or a > > Novell fileserver, etc). > > That's not true. An NT Fileserver has AppleShare services. I can (and do > store) my files on a winNT3.51 fileserver. I've also encountered Novell > Fileservers which simply appear to the user as AppleShare Servers when I > was at Case Western Reserve University. I can store these files on a > Novell fileserver and run them without any problems. Questions: 1) Can you run a Mac executable directly off of the remote fileservers without moving locally? 2) Does that functionality come with the base installation of the OS, or do you have to pay for that additional functionality? I know that commercial packages exist which will let you do reasonably complete AppleShare capabilities from a lot of different systems, but that means that things don't work out-of-the-box. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: klui@cup.hp.com (Ken Lui) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 18:29:24 GMT Organization: Hewlett-Packard Company Message-ID: <5ecse4$qsc@hpax.cup.hp.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> In article <5ebg1m$1en@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> wrote: >Thus, Avie, and the folks at NeXT (now apple), who really know a >thing or two about this stuff, to say the least, opted to keep >things monolithic for perfromance reasons. I would guess that time to market had a bigger role. But, yes, it seems performance will be better with a monolithic kernel. Ken -- Ken Lui, klui@cup.hp.com 19111 Pruneridge Avenue General Systems Division Cupertino, CA 95014-0795 USA Open/Intelligent Warehouse Team 1.408.447.3230 FAX 1.408.447.7200
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 10:30:13 -0800 Organization: Cygnus Solutions Message-ID: <qd4tfac6h6.fsf@blues.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <qdafp913g1.fsf@blues.cygnus.com> <1997021716473229510531@roxboro-170.interpath.net> phenix@interpath.com (John Moreno) writes: > Stephen Peters <speters@cygnus.com> wrote: > ] Which begs the question to a die-hard Unix user like myself, if you > ] add the notion of a `preferred application', what use is the `creator' > ] designation other than bookkeeping? As a fallback to a known good > ] application? > > Well for starters some applications can handle the files of a certain > type created by one application but not of another - non standard usage > and all that rot. Hmmm...I suspect that if there were less of an emphasis on the `creator' and more of an emphasis on the types, this kind of situation would occur less often. After all, if MicrosoftWord.app wanted to badly break RTF, they can always create the new MWRTF type. Maybe I'm living in a fantasy world :-) > ] Ditto on the various discussions on adding the `time created' field to > ] augment the last modified and other time codes stored with the file. > ] For me, once I start caring about the time the file was first created, > ] I start caring about all the changes that were made, which seems to > ] scream `revision control system' to me. (And if you copy a file from > ] somewhere else, should it inherit the source file's created time?) > ] > ] Maybe I'm just not seeing it. Can someone help enlighten me? > > Because when you update a applications then look at the file it often > gets translated into the newer version, this is one way of keeping track > of when you started something. But this is kind of my point. For me at least, when I want to know when I started something, I need that information in the context of "what kinds of changes have I made since I created this?" And I think it also begs the paranthetical question I asked above as well. If I copy something, should it inherit the source file's `created' time? If the created time's purpose is to track when I started work, then the answer is yes. If instead the purpose is to track when I started working on this `revision' of the document, then the answer is probably no. In either case, I think it's better to use a revision control system. Heck, maybe we should just write a file system wrapper which does revision control. RCSFS, anyone? (tongue partly in cheek). -- 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: avirr@starnine.com (Avi Rappoport) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 11:55:11 -0800 Organization: StarNine, a subsidary of Quarterdeck Message-ID: <avirr-1802971155110001@avi.starnine.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> It sounds like a useful solution would be for Apple to implement an Error Manager that could be called from applications. That addresses the issue of the application writers not wanting to reinvent the (error) wheel and get the interface and functionality to be consistent. And if designed correctly, the manager could take advantage of OS improvements in the future and applications would automatically get those improvements. Avi _____________________________________________________ Avi Rappoport Product Manager for Mail Products, StarNine/Quarterdeck <mailto:avirr@starnine.com> <http://www.starnine.com> (510) 649-4949
From: "Georg Tuparev" <gtupar@ctp.com> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 18 Feb 1997 12:07:21 GMT Organization: Cambridge Technology Partners, Inc. Message-ID: <5ec61p$iud@concorde.ctp.com> References: <33098bb9.30677792@nntp.ix.netcom.com> If the application to be ported uses IXKit, Speaker & Listener, and DBKit/EOF 1.0 it is pain in the a**** But what people are complaining is that the OS dies not include the List class. And I just do not believe that this will cause alot of headache. The only trouble for me converting AppKit/RootClasses to OS was the Storage (in my example I was already using the DO). And yes, some of the hacks are hard to be ported (e.g. I just had to completely rewrite Andy Stone's exploding menus for the new MiscKit), but this is true for any hack no matter what you are porting. And the List and the HashTable are not the reason for rewriting such a hacks. -- georg -- In article <33098bb9.30677792@nntp.ix.netcom.com> apuleius@ix.netcom.com (William Grosso) writes: > On 18 Feb 1997 08:49:10 GMT, "Georg Tuparev" <gtupar@ctp.com> wrote: > > > >I converted 40k lines program using the scripts for 2 days without any problem -- > >now the program runs even on NT and Solaris, and very soon with GNU OS ... and is > >very happy so. > > > > So, we have: > > (1) NeXT's claim that 50K lines take approximately a month. > (2) Many exchanges such as the following fom c.s.n.misc [...] -- ------- /\/\ 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
Newsgroups: comp.sys.next.programmer From: joerd@mail.wsu.edu Subject: Advice on Project Builder Sender: news@serval.net.wsu.edu (News) Message-ID: <970218104053.207AAFgI.wayne@pareto> Date: Tue, 18 Feb 1997 18:40:53 GMT Content-Type: text/plain; charset=US-ASCII Mime-Version: 1.0 (Generated by Eloquent) Organization: Washington State University I need some advice. I have just upgraded my NextStation (25Mz, 20MB Ram) to Openstep 4.1. I have found that gdb now uses Project Builder for display instead of Edit, thus more or less forcing me to use PB. As I learn PB I have run into some issues that might push me to going back to System 3.3 for the small research oriented programming projects I undertake. (Basically, I want to produce code that runs under generic gcc, so I don't use any of the Nextstep API.) 1. The help/documentation for PB uses the Librarian. The pages have little diamond shaped links to other sections, but the diamonds are not functional. When I click on one it changes color but does not take me to the new location. This makes using the documentation quite frustrating. Is there something wrong with my installation? 2. Using PB is quite slow. From my disk activity it seems that 20MB ram is not sufficient. Can I expect a significant speed up if I jump up to 32 MB ram? 3. Executing gdb from the command line of a terminal leads to ackward interface with PB. For example, when stepping thru code a step into another function in another file doesn't cause PB to bring the window for the new file up to the top, I have to click on the window to manually bring it to the top. Is there a fix for this? 4. "printf()" no longer seems to print to the terminal correctly. It drops "\n" characters and seems to put text in a different buffer than "cout". "cout" works fine. Is this a known bug? Any advice will be greatly appreciated. Wayne Joerding Professor of Economics Ofc: 509-335-6468 Washington State University FAX: 509-335-4362 PO Box 644741 http://cbeunix.cbe.wsu.edu/~joerd/ Pullman WA 99164 email: joerd@mail.wsu.edu "When the facts change, I change my mind. What do you do?" -- John M. Keynes
From: Jason Lincoln <jlincoln@us.oracle.com> Newsgroups: comp.sys.next.programmer Subject: SQL*Net and EOF Date: Tue, 18 Feb 1997 00:58:34 +0000 Organization: Oracle Corp. Message-ID: <3308FEBA.538E@us.oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am trying to connect my NeXTstation to a test Oracle database using SQL*Net v2. I have created a tnsnames.ora file with a description of the database I am trying to connect to. When I try to connect in EOModeler I get a ORA-6152 error. Is there a HOWTO which explains the steps necessary to accomplish the SQL*Net connect from EOF? Thanks, Jason
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 13:39:06 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> In-Reply-To: <33091DD2.61FA@acm.org> Excerpts from netnews.comp.sys.next.programmer: 18-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org > In any case, I come back to the original point, that in most cases it > is inappropriate for the OS to send an error/exception back to processes > that are waiting on resources, without at least trying some recovery, > either automatic or with operator assistance first. If the OS doesn't > do this then you do not have a very robust OS. Blocking a process because the kernel is waiting for an operator to tell it how to proceed when some form of error occurs is the opposite of robust! You can easily deadlock every runnable process if some crucial system resource like inetd (*), named, lookupd, or the swapper encounters a minor problem and must block until a human informs the OS of what to do when that error condition could otherwise be handled within the process. Go perform some research on operating system design theory, Ian. You might learn something about why your suggestion is so mistaken. ------------ (*) Or whatever equivalents you want to consider for non-Unix systems. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Christian Kuhtz <ckuhtz@paranet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 19:49:56 GMT Organization: Netcom Message-ID: <5ed154$fu@sjx-ixn4.ix.netcom.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> shess@one.net (Scott Hess) wrote: [..] > [Or is the implication that the Borg run a > microkernel operating system? Perhaps Amoeba.] Perhaps Amoeba with a NetBSD personality, absorbing any, no matter how old, computing equipment in its path. Voila, BorgOS. -- Christian Kuhtz <ckuhtz@paranet.com> MIME/NeXTmail Ok UNIX/Network Specialist "A German in the U.S., speaking for himself *gasp*" Paranet, Inc., Rocky Mountain Branch http://www.paranet.com/
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 14:30:45 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0n2UBZ600iWk05nyw0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <3308EBD5.61F7@acm.org> In-Reply-To: <3308EBD5.61F7@acm.org> Excerpts from netnews.comp.sys.next.programmer: 18-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org [ ... ] >>> Not exactly. The OS should ask the user/an operator what to do, locate >>> the file, kill the process, ignore the file and continue. You have >>> quite a few options. >> >> The operating system does not have the decision-making powers of a >> human, and it cannot make a decision between the alternatives you've >> listed-- it will only do what it's programmed to do. Therefore, you've >> either got to pick _one_ of the alternatives, or else provide a >> deterministic and decidable algorithm that the OS can use to select an >> alternative. > > I think we are saying the same thing now. That is exactly what I am > saying, to OS should in many situations consult a human. I completely disagree. With the exception of severe errors due to external reasons like hardware failure, the OS should never have to consult a human when an error condition occurs; instead, the OS should report the error to the process, and let the process decide for itself whether human intervention is required. This allows processes to continue running if the process determines for itself that it knows how to proceed after encountering whatever error condition happened, instead of always blocking. [ ... ] >> Of course, you've failed to address the crucial point I've made, which >> is that _any_ of the choices you've listed will be an inappropriate >> action for some processes. No matter how many choices you come up with >> and how complicated the algorithm to select between them is, I'll be >> able to come up with situations which require different error handling >> than what you've stated that the OS should do. > > That's an idle threat, It is neither idle nor a threat. It's merely a fact that I'll be happy to demonstrate for you if you choose to test my words. > but even if I was to embark on this process, it > does not invalidate the OS design issue I have outlined. The OS should report severe errors when they occur, and the OS may require human intervention in the face of hardware failure or other exceptional conditions, but it is completely inappropriate for the OS to require human intervention when an open() call fails because the file wasn't found. Your design suggestion that the OS should always consult a human operator even when minor, correctable error conditions occur instead of passing errors to the process is completely flawed. [ ... ] >> But Unix doesn't block when open() fails-- it returns EACCESS >> immediately, which allows to process to decide whether to continue, ask >> the user for help, or do whatever else it finds appropriate, such as >> terminate. >> >> That's a far superior solution to blocking. > > No it's not a far superior solution to blocking. Consider if the open > fails for some hardware problem on the disk. OK, the OS passes the failure > back to the process, which decides to terminate, and do nothing more. > Clearly, this must notify the operator that hardware is malfunctioning, > and very likely the operator can help the process out by redirecting it > to another disk unit. This is much more robust than just passing the > error straight back to the process, which can't do anything. If an exceptional condition like a drive failure happens, either: (a) you've got a RAID system and redundancy already built in and open() will be successful because the RAID system provided the needed fault tolerance, or (b) the drive failure means that the file is gone, and there is nothing that can be done to get the file back short of replacing the drive and restoring from backups. Asking the human what to do is futile; either the process can continue without the file, in which case having the OS report the error without waiting for the human is superior, or else the process cannot continue until the drive is replaced, and again it won't matter what the human says to do. [ ... ] >>>> Because not all tasks will want to handle a particular error condition >>>> in the same way? >>> >>> But what I am saying is that you can do a good OS design by evaluating >>> all those ways, and then giving the option (which might also include some >>> automatic policy that circumvents the user/operator). >> >> (A) It's impossible for the OS designer to incorperate every possible >> way that a process might want to handle every possible error condition, >> and, > > Well you would have to prove it were impossible, Proof by induction: I can design a simple program which does some operation (like an open()) and is capabable of handling one error which might occur before the process decides to give up and terminate. Assuming I have a program which handles n error conditions, I can write a program which handles n+1 error conditions by adding one operation surrounded by an error handler before the program code for the program which handles n error conditions. If you really want, I can even demonstrate C code for the above, but it should be obvious how to implement that. > ...but even assuming that it is, that does not mean that OSs should not > have better facilities for picking up the many common situations that we > are interested in. OSs that don't handle these situations, and many don't, > do not provide an adequate level of robustness. So you've been claiming. Your attempts to demonstrate why this is true so far have come down to the suggestion that the OS block waiting on human intervention. Try again. > > (B) even if it was possible, why would you want to bloat the OS with all > > of that code when it's simpler and easier to design processes that > > perform the error handling that they need? > > "Bloat", well Unix has already got bloated, Do you remember what I told you about provocative comments? We've already concluded that you are from Unisys and have certain biases for the Unisys operating system, and you are doing a great job of displaying a strong bigotry against Unix. Your bigotry is leading you to make patently false claims-- the Unix aspects of NEXTSTEP require less disk space than some GUI applications, and an order of magnitude less disk space than Microsoft's latest office suite. > but aside from this that is a silly comment. Why do you think that all > application programs should be bloated with code that handles common > problems. Because application programs should decide for themselves how to handle those problems, because they may decide to do different things depending on complex state behavior that is not readily available to the operating system itself. > That adds to the code that a programmer must produce; means you have > maintenance problems to handle all the cases; means you have testing > problems to test all the cases; means you have just made every project > much more expensive to complete (well most projects get killed anyway); > and means you have missed the fundamentals of reuse. Don't try to tell me about code reuse and designing error handling systems. I was the primary author of a popular NEXTSTEP product called CrashCatcher, which only required the addition of one line to the original source code in order to augment an Objective-C program with quite sophisticated error handling functionality. Of course, the developer could add a little more code and be able to perform arbitrarily complex error handling behavior within a framework that was well-debugged, modular, and extensible. >> Good operating system provide well defined interfaces to support >> processes, and these interfaces should be made as small, as simple, and >> as elegant as possible while still providing all of the functionality >> that's needed. Complex functionality like a window system, or a math >> library, or a set of error handling routines belongs in user space, not >> in the kernel. >> >> Ever hear of modularity? > > Did you ever hear of modular operating systems? Yes. > Do you understand what an OS kernel is? Yes. > It is not where I am suggesting putting this functionality, but neither is > it in the user space, although that terminology is confused as well. You mean you are confused by the terminology-- I understand the distinction between user space and kernel space quite well. If the CPU is in kernel mode (or supervisor mode, etc), we're talking about error handling within the operating system which is running in kernel space, and vise versa for "user mode" and "user or process space". [ ... ] > To explain the interface is still the same. The open call remains the > same. What I suggest is to reevaluate the contract of the call, and > determine that much of what needs to be done is common, and > therefore should not be on the calling side of the interface. In fact > if you think about it many errors cannot be handled by the application, > they have to be handled between the OS and the operator. Nonsense. The only errors that must be handled between the OS and the operator are severe errors like hardware failure, and they generally require human intervention for the simple and practical reason that there is no way for any layer of software (whether it be the process or the kernel) to recover. -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.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 19:08:29 GMT Organization: Cygnus Solutions Message-ID: <5ecund$rcn$1@majipoor.cygnus.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> Cc: phenix@interpath.com In <1997021716472829510259@roxboro-170.interpath.net> John Moreno wrote: > John Rudd <jrudd@cygnus.com> wrote: > ] The reason this is a problem on a Mac isn't because it's stored in a > ] central location.. it's because the Mac doesn't allow you to pick file > ] type over file creator for its launching heuristic, and then give a > ] seperate file-type <-> application binding for different "profiles" > ] (even if its' just swapping a file at runtime). If it did allow this > ] (even the crude run time swapping of the binding file), then it > ] wouldn't be a problem. > > It DOES allow you to override the launching application but ONLY if the > creating application is not available. It's called Macintosh Easy Open > and it could be extended to work properly (override even application > which ARE available) in the current system, let alone in the next. That's kind of what I meant.. You can't choose to open by file type _OVER_ file creator. If the file creator data is there, and the file creator app exists on that machine, you MUST use it. You cannot choose a file type application OVER that creator app. I didn't say you can't open by file type at all. I simply said the Mac doesn't give you a choice between the two -- if creator exists you use it, otherwise you use type... no choice. -- 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: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 97 16:18:30 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb17161830@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> In-reply-to: peterm@dna.lth.se's message of 17 Feb 97 09:15:37 GMT In article <peterm.856170937@ulfrun>, peterm@dna.lth.se (Peter Moller) writes: shess@one.net (Scott Hess) writes: >_doesn't_ justify putting that information in _the_ filesystem. >This thread has had suggestions which accomplish the same things >over top of the existing filesystem, rather than by modifying ^^^^^^^^^ >things at a low level. Well, this is a question: Apple (50 million claimed users) buys NeXT (a couple of millions users ?). Apple has one file system, NeXT another. I assume that the unified company will end up having one filesystem. Which one? Either way, one of them will have to change. As a Mac user, I don't see it as a modification to have a created time stamp. I under- stand that you, as a unix user, will view such a thing as a change. And I will, in my turn, view it as a change to not have it and have three time stamps for last change etc. instead. It's a matter of perspective. No, it's not! Sigh. BSD FFS already does a wide variety of things that Mac's UFS can't do or doesn't do well. Things like optimal placement policy, disk fragmentation prevention, longer filenames (256 bytes per name versus 32), larger filesystems without "clusters" (NeXT's 2G limitation is because they're only using 32 bits in the kernel, FFS would be happy enough with larger filesystems), multi-user support, almost seemless NFS integration. _These_ are the really important things. Personally, I could care less if you moved the other timestamps out of the filesystem, also. The _only_ things necessary in the inode are the owner, group, reference count, size, and direct, and indirect block pointers. Why are the last accessed, modified, and inode updated times in there? Quite simply for performance reasons. These things are being modified _all_ of the time. Whether the kernel portion of the filesystem is the most sensible place to generate this information is moot, because it simply can't be generated anywhere else with the same speed. When you're talking about updating something hundreds or millions of times, a couple CPU cycles begins to make a difference. On the other hand, files are only created once. The fact that a user process can't generate that info as fast as the kernel can is besides the point, because the operation only happens once. > This is not a question of "who's right", but rather "how do we > make both happy?" > >Well, except that I'm trying to argue that you shouldn't be >unhappy with how it's currently done (in Unix) :-). I've been a unix sysadmin since 1990, and I have missed a creation time stamp all those years. In fact, I've missed a lot of things on my Sun (as much as I have missed some unix-things on the Mac). Specifically, though, you're unhappy because you can't find out when a file was created easily. You don't say that you're unhappy because the inode structure doesn't contain a creation timestamp. [No, that's _not_ a silly distinction. You'd have to modify all of the file management utilities to propagate a new timestamp anyhow, just having the timestamp there won't do squat.] >More broadly, though, the filesystem obviously cannot be changed >to make everyone happy. Right, but how about maintaining a file system that has been used by several millions of users for more than a decade? BSD FFS has also been used by several million users for more than a decade. BSD FFS was designed for multitasking timesharing server systems, systems with substantially more disk, memory, and CPU than personal computers of the day had, in a midsize heterogenous network environment. Systems, in fact, which look suspiciously like the personal computer systems of today, except that today's PCs have high-resolution video output devices. HFS, meanwhile, was designed to run in a box with 128k of RAM, on a system which would be used by a single user, in a small homogenous networking environment. Put another way, HFS was designed for the personal computers of yesterday, while FFS was designed for the minicomputers of yesterday. Today's personal computers are beyond the minicomputers of yesterday in many ways. Don't think that there aren't things I'd like to change about FFS. I'd like to see journalling, and the ability to defer metadata update. I'd like NeXT to allow the number of disk buffers to interact with VM pages so that server systems can sacrifice VM for better I/O speed. I'd like a reasonable RAID implementation, and their SCSI drivers to work with my Fast-10 SCSI controller at 10MB/s rather than 5MB/s. 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 in Seven Days, Unleashed>
From: danh@qnx.com (Dan Hildebrand) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy,comp.os.qnx Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 14:47:03 -0500 Organization: QNX Software Systems Message-ID: <5ed0vn$if7@qnx.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> In article <5ebg1m$1en@news3.digex.net>, John Kheit <jkheit@cnj.digex.net> wrote: >jm041536@fhda.edu (Joaquin Menchaca) wrote: >> OK, >> Let's get it straight guys, for those of you still confused. >> The current specified Mach kernel under development (if you >> want to call it that) is NOT a microkernel. OSF Mach 3.0, used >> in mkLinux, is an actual microkernel. Apple's Mach kernel will >> have features from Mach 3.0, but will not be the true Mach 3.0. >> Some are jokingly calling this 'Mach >> 2.5++'. > >That micro kernels tend to be more buzz word hype than valuable... Just as with monolithic kernels differing in quality of implementation, microkernels also differ in quality of implementation. There are several microkernel OS's that benefit from having this architecture. >Why, b/c putting things outside the kernel, in general, results in >some serious performance penalties for no real functional benefit. None? There are several, well documented in the literature (why else would all this work into microkernel OS's be done in the first place?) >Thus, Avie, and the folks at NeXT (now apple), who really know a >thing or two about this stuff, to say the least, opted to keep >things monolithic for perfromance reasons. Yet the functionality >of a monolithic kernel is not reduced by its monolithicness. Performance varies dramatically between different kernels, be they monolithic or microkernel. Quality of implementation is more important than microkernel vs monolithic kernel. -- Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd. http://www.qnx.com/~danh 175 Terence Matthews phone: +1 (613) 591-0931 Kanata, Ontario, Canada fax: +1 (613) 591-3579 K2M 1W8
From: jm041536@fhda.edu (Joaquin Menchaca) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 04:22:44 GMT Organization: De Anza College Message-ID: <jm041536-1702972018170001@mencjo.apple.com> OK, Let's get it straight guys, for those of you still confused. The current specified Mach kernel under development (if you want to call it that) is NOT a microkernel. OSF Mach 3.0, used in mkLinux, is an actual microkernel. Apple's Mach kernel will have features from Mach 3.0, but will not be the true Mach 3.0. Some are jokingly calling this 'Mach 2.5++'. The near future is distributed cluster based microkernel which I believe is evident in Mach 4.0. Microsoft with licenses from DEC will implement a distributed cluster based Operating System with Windows NT 5.0. Apple will implement a monolithic kernel with Rhapsody. This kernel will be upgraded to provide SMP (Symmetrical Multiprocessing). Distributed microkernels will not only use SMP, but will also use other processors and resources of various computers across high speed network across different computers. Some may say this is analogous to the Borg in Star Trek. - joaquin -- ############################################################### # My opinions are my own and not of any I work for. # ############################################################### # WARNING: DO NOT send unwarranted mail or SPAMS! Further # # proceedings of sending unwarranted email or spams will # # result in fines up to $1000 in damages. # ###############################################################
From: Jason Patrick <jason@4thdim.com> Newsgroups: comp.sys.next.programmer Subject: NeXTSTEP and JAVA Date: Tue, 18 Feb 1997 13:05:10 -0600 Organization: The crazy fellow Message-ID: <3309FD2B.749A@4thdim.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Does anybody know where I can get the JDK for NeXT? I could not locate it on Sun's sight. Thanks Jason Patrick
From: marcel@sysyem.de Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 20:08:22 GMT Organization: Technical University Berlin, Germany Distribution: world Message-ID: <5ed27m$qgb$1@brachio.zrz.TU-Berlin.DE> References: <SHESS.97Feb18130143@howard.one.net> In article <SHESS.97Feb18130143@howard.one.net> shess@one.net (Scott Hess) writes: [dealyed metadata updates] > You get no argument from here. 1) I'm the only user of the > filesystems in question, and there's really nothing that I can't > rebuild quickly enough as-is. Assuming that the async updates do flow > out to disk relatively frequently (I'd assume during the 30-second > sync), and that they flow out in an orderly fashion (the filesystem is > always recoverable, perhaps without those last three operations). 2) > I put _all_ of my machiens on UPS's, not just servers :-). Check out 'Metadata Update Performance in File Systems' by Gregory Ganger and Yale Patt. They describe a method of reordering metadata updates in such a way as to achieve delayed updating while maintaining consistency. Cool stuff that allows log file-system performance with a traditional FFS. Marcel
Newsgroups: comp.sys.next.programmer From: fgalot@x-lan.alienor.fr Subject: Re:(Correction) MouseDown+Drag and SHIFT!! Message-ID: <E5t4ns.HAE@x-lan.alienor.fr> Sender: news@x-lan.alienor.fr Organization: x&lan References: <E5qq6F.C1p@x-lan.alienor.fr> Date: Tue, 18 Feb 1997 16:33:28 GMT > /*next I use mouseDownLocation for drawing. But I'd > like to use the real mouse position (cursor position?) > because there is a shift between the real position of the > mouse(cursor) and the point I'm using.*/ This shift is not a coordinate shift because I've made a ...convertPoint:mouseDownLocation fromView:nil.. to get the value in the good coordinate system. The shift comes from the drawing time : the mouse is moving while I'm drawing. mouseDown here : ->x DRAWING DRAWING mouse is now here : ->y But my image appears on x... If you could understand my explanations thaks for help. -- --------------------------------------- ź ź | ź O_O ź ź | O_O -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Fred Galot fgalot@x-lan.alienor.fr
From: John Hornkvist Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 21:25:16 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5ed6ns$k4c@nyheter.chalmers.se> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> Cc: shess@one.net In <SHESS.97Feb17224036@slave.one.net> Scott Hess wrote: > > OTOH, I keep coming back to the thought that, when you come right down > to it, if you _only_ manipulate the file through the UI, it really > doesn't make a bit of difference whether it's a forked file, a > directory wrapping individual files, or a database filestore of some > sort. You don't care. It's only those of us who ever access files > from somewhere other than the UI (command-line _or_ programmatically) > who care. > I think much of the debate stems from people -- usually Macintosh users, it seems -- being too interested in how things are done, instead of how well they work. If a normal user does not see a difference, does it really matter how it is done? The point of using systems such as the Mac, or even more so the NeXT is not having to worry about how things work. And still be confident that they do work. Again, the interface is the only thing that matters. Implementation is a trivium. --- 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: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 05:51:50 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ebg1m$1en@news3.digex.net> References: <jm041536-1702972018170001@mencjo.apple.com> jm041536@fhda.edu (Joaquin Menchaca) wrote: > OK, > Let's get it straight guys, for those of you still confused. > The current specified Mach kernel under development (if you > want to call it that) is NOT a microkernel. OSF Mach 3.0, used > in mkLinux, is an actual microkernel. Apple's Mach kernel will > have features from Mach 3.0, but will not be the true Mach 3.0. > Some are jokingly calling this 'Mach > 2.5++'. Yes, this has been rehashed several times, at least in the NeXT groups. If I remember correctly, some of the issues, and at least some consensus came to this concluse (If I got it wrong, please set me straight folks :) That micro kernels tend to be more buzz word hype than valuable... Why, b/c putting things outside the kernel, in general, results in some serious performance penalties for no real functional benefit. Thus, Avie, and the folks at NeXT (now apple), who really know a thing or two about this stuff, to say the least, opted to keep things monolithic for perfromance reasons. Yet the functionality of a monolithic kernel is not reduced by its monolithicness. Furthermore, similiar arguments about object oriented kernel design were wrung out... Namely that Mach 4.0 was done in C++, thereby making it OOP... It too might be a situation of more buzzword-checklist hype than reasoned implementation. The kernel being a low level layer of the OS, really needs to be tuned as possible, and OO'ness doesn't necessarily make much sense or add much functionality to that layer/level, and results in more of a performance hit than functionality gain. Anyway, that's the gist of what I took from previous threads on this topic. If I got something substantially wrong, I hope someone chimes in and corrects my ignorance on the matter :) -- Thanks, be well, take care, later, John Kheit; Self expressed... 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 | Ja tallar ente svenska )^> %^) =^)
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Followup-To: comp.sys.mac.advocacy,comp.sys.next.advocacy Date: Mon, 17 Feb 1997 23:42:39 -0600 Organization: mementech, inc. Message-ID: <3309414F.56250C0F@screaming.org> References: <jm041536-1702972018170001@mencjo.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Joaquin Menchaca wrote: > Let's get it straight guys, for those of you still confused. > The current specified Mach kernel under development (if you > want to call it that) is NOT a microkernel. ...nor does its use prevent it from being replaced with one. > # WARNING: DO NOT send unwarranted mail or SPAMS! what about needless crossposts? [followups trimmed] -- 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: jchan@apk.net (Jerome Chan) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Mon, 17 Feb 1997 23:37:28 -0500 Organization: TofuSoft Message-ID: <jchan-1702972337280001@pm5-18.apk.net> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> In article <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Sorry, but you're wrong. Macs do not integrate very well with with > heterogenous network fileservers, because their executables won't be > runnable when stored on an NFS fileserver (or a NT fileserver, or a > Novell fileserver, etc). That's not true. An NT Fileserver has AppleShare services. I can (and do store) my files on a winNT3.51 fileserver. I've also encountered Novell Fileservers which simply appear to the user as AppleShare Servers when I was at Case Western Reserve University. I can store these files on a Novell fileserver and run them without any problems. --- The Evil Tofu (Only Human)
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 97 21:35:56 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb17213556@slave.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <SHESS.97Feb13085241@howard.one.net> <1997021716474229511116@roxboro-170.interpath.net> In-reply-to: phenix@interpath.com's message of Mon, 17 Feb 1997 16:47:42 -0500 In article <1997021716474229511116@roxboro-170.interpath.net>, phenix@interpath.com (John Moreno) writes: Scott Hess <shess@one.net> wrote: ] In article <3302E06E.8D@subsequent.com>, ] "Jonathan W. Hendry" <jon@subsequent.com> writes: ] Okay. My beef is with the Macintosh's usage of the creator code, ] not the existence of one. ] ] OK, then, I'll beef. If some bit of information is not really ] necessary, then it shouldn't be added to the filesystem. If the ] creator code is just a nice little bit of trivia which follows a file ] around, but isn't necessary to figure out who to open the file with, ] then who cares? If it's in the information the filesystem maintains, ] then it's a drag on _every_ file, _every_ access, _every_ program. It may be a drag [your trying to save 4 bytes worth] on every file, but it has NOTHING at ALL to do with ACCESSING the file. Yes it does. With an inode of a given size, you can fit a given number of inodes in a block. If each inode contained twice as much data, there would be half as many inodes per block, requiring twice as many blocks to be read to retrieve a given set of inodes. On the surface, this looks like a trivial concern. Unfortunately, it's not the inodes you _intend_ to access that get you - it's the inodes you _didn't_ intend to access. Accessing /Users/shess/Work/InDevelopment/SomeCode.subproj/AFile.m doesn't access only the inode associated with AFile.m - it also potentially accesses the inodes for each directory from root on down. Launching a given application might reference a couple hundred inodes in the first couple seconds. I'm not suggesting that adding a creation timestamp to inodes is going to bring the system to its knees. But if you add just any bit of trivia to the inode, you soon _will_ bring the system to its knees. Besides, in this case, you can store the creator info (and other info) in a seperate file. Then only the apps which care about that file pay any penalty at all for having it there. Other programs don't care. [This is all such a stupid discussion, anyhow. Everyone who uses open(2) and other kernel calls as your I/O interface in a shipping GUI application, raise you hands (so that I can slap them). In all likelyhood, you'd be using stdio, or some set of functions from the system's GUI library. If you have NSOpenFile(), NSOpenFork(), NSCreationTime(), and whatnot, then who _cares_ whether it's implemented as files-in-a-directory or forked files with creation timestamp in the inode? In fact, a good argument can be made that it's really none of your business, as any dependencies you code in on forks versus files-in-a-directory restrict what the system's implementors can do in the future.] 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 in Seven Days, Unleashed>
From: exfjnzl@rbf.apfh.rqh (Ravi K. Swamy) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 03:41:42 GMT Organization: Gunsmith Cats Message-ID: <slrn5gi97n.ibl.exfjnzl@c01021-111poe.eos.ncsu.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> In article <SHESS.97Feb17161830@howard.one.net>, Scott Hess wrote: [snip] >Don't think that there aren't things I'd like to change about FFS. >I'd like to see journalling, and the ability to defer metadata update. I know FreeBSD file systems can be mounted to do asynchronous metadata updates. Linux's ext2 does asynch metadata updates by default. (*Please* do not argue which is better for stability etc. it's been beaten to death already) Perhaps it is only the FFS in 4.4 Lite than can do asynch metadata updates? Or perhaps the FreeBSD guys added this. -- Ravi K. Swamy http://www4.ncsu.edu/~rkswamy/www/ rkswamy at eos.ncsu.edu root@genom.com
From: schooley@ee.gatech.edu (David C. Schooley) Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs Subject: Re: OPENSTEP/MACH 4.1 -- printf %g still broken Date: Tue, 18 Feb 1997 15:59:25 -0500 Organization: Georgia Tech Electric Power Jocks Message-ID: <schooley-1802971559250001@bicycle.ee.gatech.edu> References: <5ecoph$74i@tribune.usask.ca> In article <5ecoph$74i@tribune.usask.ca>, eric@skatter.USask.Ca wrote: > I just finished installing OPENSTEP/MACH 4.1 (Intel). I then checked to see if > my favorite bug had survived yet another version: > [snip] > eric@pisces 225> cc -o printfcheck printfcheck.c > eric@pisces 226> ./printfcheck > Expect 0.00123: 0.001 > Expect 123: 123.457 > Expect 123.5: 123.4567 > Expect 1e+03: 999.6 > eric@pisces 227> > I compiled and ran your code under Solaris. I got: Expect 0.00123: 0.00123 Expect 123: 123 Expect 123.5: 123.5 Expect 1e+03: 1e+03 [snip] > > The ANSI standard (X3.159-1989) says (Section 4.9.6.1, page 134, line 33): > > g,G The double argument is converted in style f or e (or in style E in the > case of a G conversion specifier), with the precision specifying the > number of significant digits. If the precision is zero, it is taken > as 1. The style used depends on the value converted; style e (or E) > will be use only if the exponent resulting from the conversion is less > than -4 or greater than or equal to the precision. Trailing zeros are > removed from the fractional portion of the result; a decimal-point > character appears only if it is followed by a digit. > > *** NOTE THE WORDS `precision specifying the number of significant digits'. *** > It looks like whoever is responsible for the ansi libraries at NeXT needs an explanation of the term "significant digits". (Years ago, my high school chemistry teacher refered to them as "significant figures". We called them "sig figs" for short.) On the other hand, the ANSI specification may be somewhat to blame, since it uses the term "precision" to specify the number of significant digits. It looks like the meaning of 'g' and 'G' changed between K&R and the ANSI standard. Either that, or the writer of the ANSI spec didn't know the meaning of "significant digits". From K&R, 2nd ed. g, G: use %e or %E if the exponent is less than -4 or greater than or equal to the precision; otherwise use %f. Trailing zeros and a trailing decimal point are not printed. e, E: [-]m.dddddde+/xx or [-]mddddddE+/xx, where the number of 'd's is given by the precision. f: [-]m.dddddd, where the number of 'd's is given by the precision. So, I agree that NeXT is wrong with regards to the ANSI spec, but I'm not sure that the ANSI spec means what the writer wanted it to say. Removal of the trailing zeros is inconsistent with keeping the proper number of significant digits. For consistency with the sig. fig. specification, the result from printf ("Expect 1e+03: %.3g\n", 999.6); should be 1.00e-3, since that has 3 significant digits, and 1e+03 only has 1. later, ---Dave--- ------------------------------------------------------------- David C. Schooley | Ph.D. in progress | Hey, New York, Georgia Tech Electric Power | <mailto: schooley@ece.gatech.edu> | Please put our flag back! <http://www.ee.gatech.edu/users/schooley/>| -------------------------------------------------------------
From: sschaper@inlink.com Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Tue, 18 Feb 1997 20:22:21 GMT Organization: InLink Message-ID: <330a0f52.17122045@news.inlink.com> References: <jm041536-1702972018170001@mencjo.apple.com> <3309a1c9.11108823@news.rmplc.co.uk> <87u3nayt41.fsf@phaedrus.uchicago.edu> On Tue, 18 Feb 1997 16:30:22 GMT, stephen farrell <sfarrell@phaedrus.uchicago.edu> wrote: > >i don't fully understand this point. developers can go out right now >and purchase openstep for mach on intel, sparc, and hppa platforms, >and for winNT, and solaris. why doesn't apple encourage them to do >so, and make sure that the final product they deliver is simply >openstep compliant (or at least just needing trivial fixes and a >recompile)? If one were to use the Mach 3.0 kernal from MKLinux, would this also work in the present with OpenStep? >
From: John Hornkvist Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 21:31:56 GMT Organization: Chalmers Tekniska Högskola Message-ID: <5ed74c$k4c@nyheter.chalmers.se> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> Cc: jkheit@cnj.digex.net In <5ebg1m$1en@news3.digex.net> John Kheit wrote: >jm041536@fhda.edu (Joaquin Menchaca) wrote: >> OK, >> Let's get it straight guys, for those of you still confused. >> The current specified Mach kernel under development (if you >> want to call it that) is NOT a microkernel. OSF Mach 3.0, used >> in mkLinux, is an actual microkernel. Apple's Mach kernel will >> have features from Mach 3.0, but will not be the true Mach 3.0. >> Some are jokingly calling this 'Mach >> 2.5++'. > >Yes, this has been rehashed several times, at least in the NeXT >groups. If I remember correctly, some of the issues, and at least >some consensus came to this concluse (If I got it wrong, please >set me straight folks :) > >That micro kernels tend to be more buzz word hype than valuable... Well... Micro kernels do have some nice chracteristics. But, as with most things, it has become more of something that "we have, too" than a tool used to provide better operating systems. >Why, b/c putting things outside the kernel, in general, results in >some serious performance penalties for no real functional benefit. Putting things outside the kernel results in performance problems if you don't move enough out of the kernel. The primary cost is switching between user and supervisor moder, and if you have too much functionality in the kernel, you'll be doing a lot of switching. You can make a micro kernel run fast, just as you can make an objective C program run fast. You just have to remember where the problems are. I'm not sure that Mach is the best place to start if you really want a good micro kernel, though. The monolithic but message passing Mach 2.5 is an excellent foundation for an OS, though. >Thus, Avie, and the folks at NeXT (now apple), who really know a >thing or two about this stuff, to say the least, opted to keep >things monolithic for perfromance reasons. Yet the functionality >of a monolithic kernel is not reduced by its monolithicness. It is reduced, but not in a way that will matter on a personal computer. More modular approaches make sense if you run on MPP systems, for example. So, I hope Apple redesigns the kernel before they come out with an OS for systems with more than, say, 64 processors. :) >Furthermore, similiar arguments about object oriented kernel design >were wrung out... Namely that Mach 4.0 was done in C++, thereby >making it OOP... It too might be a situation of more buzzword-checklist >hype than reasoned implementation. The kernel being a low level >layer of the OS, really needs to be tuned as possible, and OO'ness >doesn't necessarily make much sense or add much functionality to >that layer/level, and results in more of a performance hit than >functionality gain. Micro kernel design is similar to RISC chip design; you try to find the most commonly used functions, and then speed those up. Less common things are done by combining simpler operations. If you use static binding and inlining, C++ would be good for the lowest level of an OS, I think. Remember that with C++ object orientation seems to end as soon as you compile... By the way, I would think that NEXTSTEP/OPENSTEP stresses the OS in ways that a normal operating system may not do, and therefore the kernel has to be optimized differently. That may affect the choice of kernel; Mach 3 or "the Copland micro kernel" are unlikely to be optimized for running OPENSTEP. NeXT's Mach is likely to be highly optimized for that purpose. In addition to that it is stable, has been ported to many architectures, and is the foundation for OPENSTEP today. All in all, there is nothing wrong with cool technology, as long as it doesn't get away of important matters. --- 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: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 20:26:00 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45gk3sl.oqs.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <1997021810351033363403@roxboro-161.interpath.net> On Tue, 18 Feb 1997 10:35:10 -0500, John Moreno <phenix@interpath.com> wrote: >Scott Hess <shess@one.net> wrote: > >-snip- >] >] BSD FFS has also been used by several million users for more than a >] decade. >] >] BSD FFS was designed for multitasking timesharing server systems, >] systems with substantially more disk, memory, and CPU than personal >] computers of the day had, in a midsize heterogenous network >] environment. Systems, in fact, which look suspiciously like the >] personal computer systems of today, except that today's PCs have >] high-resolution video output devices. > >But it can still use some extensions - adding file type/creator and a >creation time isn't a bad idea, although where that information is kept >is another matter (it could be kept in a database and accessed by >fileID#). BAD IDEA. The reason behind keeping the information within the file's i-node is *very* simple: synchronization. The more "independant" pieces you have, the more likely a loss of synchronization will occur. Think of a filesystem as a database, tracking it's own use of space. A filesystem resides in a "linear" array of blocks (granules) and some of them are set aside to maintain a list of used granules. (What they are used for most often is not relevant to the model.) The i-nodes track this, but how do you know what to do with this array of record-keeping units? This is where directories come from; A directory provides an access method and name space for the i-nodes. An i-node (except for *extremely* large files) is an atomic object; When additional information is needed for a file, this is the most logical place to "hide" it. If, instead, you want to do it one level up (allowing each name to have different information) hid it in the directory entry (which *can* be done as long as the dirent.h or direct.h files are updated and you disallow anybody from directly getting at the contents of a directory). Now using BSD's FFS looks appealing, it *still* prefers a "clean" shutdown, and a fsck utility would be needed on each startup. Perhaps a newer model is needed; The ADVFS within DEC Unix looks like a parallel development with IBM's JFS for AIX; These are *Journalling* filesystems, allowing updates to be handled in a disk-resident queue (good for recoveries). If we can enhance the i-node structure (and add goodies for it's manipulation, either via ioctl() or other means) at the same time, we'll have something that really *cooks*. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: zander@conextions.com (Aleksey Sudakov) Newsgroups: comp.sys.next.programmer Subject: Re: NeXTSTEP and JAVA Date: 18 Feb 1997 23:54:31 GMT Organization: The Internet Access Company, Inc. Message-ID: <5edffn$1cj@news-central.tiac.net> References: <3309FD2B.749A@4thdim.com> Jason Patrick <jason@4thdim.com> wrote: >Does anybody know where I can get the JDK for NeXT? I could not locate >it on Sun's sight. There is no such thing. There is no complete JDK. There are some problem with AWT port. Anyway one might consider kaffe as a JVM, but I doubt it would build with old version of gcc NeXT is still shipping with Mach. Do I understand things correct? I don't wanna build most recent version of gcc just to compile recent version of kaffe. Regards, Aleksey
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 19 Feb 1997 11:04:19 +1100 Organization: Unisys Message-ID: <330A4383.339A@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Further on this subject there is a new thread in comp.lang.eiffel on "Using REQUIRES for synchronisation." My post there explains what I have been talking about in a slighly different way. What we really have is a concurrency issue. For example, any read to a file is essentially a concurrency problem... your process will probably suspend until the required data is read from disk. Many calls to an OS can be seen this way, as you might have to suspend until the requested resource becomes available. The general principle here is that the OS should do its utmost to satisfy the request, as should any call to any routine. This scheme greatly simplifies client coding as you then don't have to handle a miriad of different exceptions. If a call fails, it really is serious! Now there are certain exceptions, like what if a process overruns certain user set limits. Then swift termination is the best course. Or if you really are running an operator free system, perhaps this might be the best course, but such would have to be set as a system wide option. Besides for operator free systems you really want to ensure a very stable environment, such as a file server... no nasty development and testing of buggy programs on such a machine! As an example of concurrency, consider a stack: class STACK [T] empty: BOOLEAN top: T require not empty end end In a non-concurrent environment, the "require not empty" returns an exception to the caller if the stack is empty. However, in a concurrent environment, the "require not empty" suspends the calling process until some other process has put something in the stack. This ensures implicit synchronisation between processes with no fuss, mess or complication of exception handling in the caller. Now if the client really does not want to suspend they add code to skip the call: if not stack.empty then t := stack.top end Now if we apply that paradigm to files and other OS resources, much of the complication in handling exceptions in applications disappears. Perhaps I did not explain this very well in the first place, but I hope that makes it clearer to Charles. I am also not saying this to defend MacOS or criticise NeXT. However, some of the weaknesses of Unix should be understood, and the fact that Unix is not in many respects the perfect OS. Neither does it handle memory sharing and resource synchronisation at a very high level, and why it has not swept aside all those "horrible mainframe" OSs is due to the fact that it does not have very good server capabilities such as TP monitors, apart from Tuxedo. ------------------------------------------------------------------------ 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: Larry Kendall <lkendall@ix.netcom.com> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 18:32:40 -0400 Organization: Netcom Message-ID: <330A2E07.563D@ix.netcom.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit With The standard Novell for Mac nlms running on 3.1.1 you can store and run your executables from the novell file server. I've been doing it for years. If the program requires system extension they have to be in the ext folder of the local Mac of course. lak
From: Petr Novak <novak@microcomp.de> Newsgroups: comp.sys.next.programmer Subject: Bug with flattened attribute ? Date: Tue, 18 Feb 1997 17:31:42 +0100 Organization: Impact GmbH,Cologne, Germany Message-ID: <3309D96D.7A59@microcomp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hallo ! Sybase 11, EOF 2.0 , NT 4.0 I have following problem: Master-detail relationship,detail NSTableView shows flattened attribute. After delete in detail entity,adaptor deletes also record from entity to which flattened attribute belongs. Is there some possibillity to forbid it ? Petr Novak
From: "Stéphan Mertz" <s.mertz@improve.fr> Newsgroups: comp.sys.next.programmer Subject: Re: Updates in EOF 2.0 Date: 18 Feb 1997 16:54:18 GMT Organization: Improve SA Message-ID: <01bc1dbc$49bc5df0$afbecec2@neuteu> References: <330993BA.2738@microcomp.de> Look at the EODisplayGroup. It's the new manager for the UI in EOF2.0.
From: hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 23:27:30 +0100 Organization: Einzeln auftretender Radfahrer Message-ID: <199702182327301079516@q700.hf.org> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> Scott Hess <shess@one.net> wrote: > In article <5eans2$8jq@nyheter.chalmers.se> John Hornkvist writes: > Resource forks is only a way to reimplement directories inside a > file. > > Which brings up an interesting question ... can anyone tell me if > there's a limit on the number of files you can have on HFS? It just > occurred to me that perhaps forks are a means of effectively doubling > the number of files without requiring more metadata overhead. As far as I recall, there _was_ a limit of about 6k files per volume. But the Mac fs is a moving target, and they may have lifted that restriction before it seriously bit anyone. > [I'm making two assumptions, here. One is that Way Back When, Mac had > small disks, and for every file which needed a resource fork, you'd > have needed twice as much metadata overhead. Furthermore, files may > have been referred to with small integers to save space in the > metadata.] You're close... Actually, the resource fork pattern has always been appealing to me as a perfect approach to handle the hundreds of little data structures that a GUI application needs to run. Icons of various shapes and sizes, templates for menues, windows, dialogs, controls, code snippets... all of who would otherwise have littered the file system - and do so in other OSes. If you can do similar things with wrappers in a consistent manner, then it's for the sake of portability allrigt with me; but portability left aside, the forks add an additional abstraction level in a (for me) simple and elegant manner. > OTOH, I keep coming back to the thought that, when you come right down > to it, if you _only_ manipulate the file through the UI, it really > doesn't make a bit of difference whether it's a forked file, a > directory wrapping individual files, or a database filestore of some > sort. You don't care. It's only those of us who ever access files > from somewhere other than the UI (command-line _or_ programmatically) > who care. Agreed. hauke -- "It's never straight up and down" (DEVO)
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: Referencing externs from loaded bundle on OpenStep/NT - how? Date: 18 Feb 1997 16:49:27 GMT Organization: Netcom Distribution: world Message-ID: <5ecmin$kh2@dfw-ixnews5.ix.netcom.com> References: <vbd8u4mz3j.fsf@eldar.arc.ab.ca> <vbbu9omp4d.fsf@eldar.arc.ab.ca> <5e64bp$t62@dfw-ixnews12.ix.netcom.com> aisbell@ix.netcom.com (Art Isbell) wrote: > How does one, in a > dynamically-loaded module, subclass a class that's defined in the main > executable? > > For example, IB defines attributes inspector classes for various UI > objects (e.g. IBButtonInspector). Under Mach, we take advantage of this > inspector classes when we write palettes that contain button subclasses. We > start with the button attribute inspector nib included with IB, unparse the > inspector class to generate a suitable header, subclass and add one or more > ivars. We add an appropriate UI to the standard button attribute inspector > panel, change the class of the File's Owner to our own IBButtonInspector > subclass, build, and load into IB. Works great under Mach. > > But under OS/NT, our IBButtonInspector subclass fails to build due to a > link error: IBButtonInspector not defined. Certainly there must be a "hack" > that will solve this problem. Since source to IB isn't available, we can't > create a DLL that defines IBButtonInspector and load that into our palette. Thanks to Mont Rothstein <mont@echidna.doverpacific.com> for a workable solution: > If you are working under 4.1 try adding the following to your > Makefile.preamble: > > WINDOWS_PB_LDFLAGS = -Xlinker /FORCE > > This will force the linker to finish even though there are undefined > symbols. Since you will be in IB when the code executes, and therefore the > symbols will exist, this should be fine. And thanks to Paul Marcos <pmarcos@next.com> for warning that using the linker's /FORCE option will cause linking to succeed even when other linking problems exist that will lead to the failure of the executable to perform as expected. For explicit use of a class object when the class hasn't been defined in the current module, NSClassFromString() can be used without generating an unresolved external symbol that would prevent linking. But when subclassing a class that isn't defined in the current module and for which no DLL that defines the class exists, /FORCE may be the only option. Tests are underway to determine whether another approach might exist. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 OPENSTEP/NT Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: David Young <dwy@ace.net> Newsgroups: comp.sys.next.programmer Subject: Re: NeXTSTEP and JAVA Date: 19 Feb 1997 03:44:52 GMT Organization: ace dot net internet technologies Message-ID: <5edsvk$mko$3@darla.visi.com> References: <3309FD2B.749A@4thdim.com> <5edffn$1cj@news-central.tiac.net> Aleksey Sudakov <zander@conextions.com> wrote: : There is no such thing. There is no complete JDK. There are some problem with : AWT port. Anyway one might consider kaffe as a JVM, but I doubt it would : build with old version of gcc NeXT is still shipping with Mach. Do I : understand things correct? I don't wanna build most recent version of gcc : just to compile recent version of kaffe. Old version gcc with Mach compile your source good, comrade. -- # 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: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 17:30:34 -0800 Organization: Esperance Communications Message-ID: <jk-1802971730350001@ip-salem2-01.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <5e9cre$if1@horus.ecmwf.int> <sn2516600iVGI0zSpA@andrew.cmu.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <sn2516600iVGI0zSpA@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Either you can put _any_ file on a remote system like an Auspex NFS >server, and have it work correctly, or else some crucial parts of what's >on a Mac filesystem cannot be stored on remote fileservers because they >won't work correctly. I suggest you learn about a format called AppleDouble, this stores a Mac two-forked file as two separate files on "dumber" file systems (this was originally developed for A/UX, AFAIK). RFC 1740 uses AppleDouble to avoid the interoperability problems in any MIME-complaint Mail User Agent. This is usually handled client side. >I think it would be good if Rhapsody did not suffer from the same >heterogenous interoperability problems that Macs currently suffer from >trying to share files on non-Mac filesystems. Alleged "heterogenous interoperability problems". -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Where do you think the idea for the Borg came from? ;)
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 01:32:46 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Un2duCC00iWX0J_7NE@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> <330A2E07.563D@ix.netcom.com> In-Reply-To: <330A2E07.563D@ix.netcom.com> Excerpts from netnews.comp.sys.next.programmer: 18-Feb-97 Re: Mac/NeXT & Unix: File S.. by Larry Kendall@ix.netcom. > With The standard Novell for Mac nlms running on 3.1.1 you can store and > run your executables from the novell file server. I've been doing it for > years. If the program requires system extension they have to be in the > ext folder of the local Mac of course. Okay, thanks for the correction. Even so, the point still applies to just NFS servers, which is more relevent for me.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: mail25193@pop.net (Fred Trottelhauer) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy,comp.unix.bsd.misc Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 19 Feb 1997 04:31:03 GMT Message-ID: <5edvm7$t2v@news0-alterdial.uu.net> References: <jm041536-1702972018170001@mencjo.apple.com> In <jm041536-1702972018170001@mencjo.apple.com>, jm041536@fhda.edu (Joaquin Menchaca) writes: > Microsoft with licenses from DEC will implement a >distributed cluster based Operating System with Windows NT 5.0. This will need to be watched very carefully, since Microsoft up until now has shown itself to be oriented, under the guise of a cheerily populist "software for the people", only towards foisting stunted garbage onto the public. Mircosoft rakes in billions by virtue of its marketing skill while real computing power is not allowed to reach the masses; Bill gets press as such a lovely bright young man while the interests that would maintain a mediocre status quo and a population which is not independent have their needs met. If this is another effort in that same vein, then it isn't worth a damn. The company reminds me of what a New York City resident said in my hearing one day, "we're the greatest city in the world. We have the greatest art, the most brilliant minds, the finest culture. We buy it all." That mode does nothing to maintain a living discipline, a growing ecosystem (computing ecosystem in this case) - it reduces it to a dead commodity sold by degenerate undead profiteers to stupified consumers. Mircosoft should stick to end-user products for the low end of the market, and keep its nose out of areas of the industry that matter in more than the short term. > [...]Some may say this is analogous to the Borg in >Star Trek. Your references aren't really an asset to your case... Fred Just as an aside, imagine for a moment what things would be like if everyone in the workplace (note ! - just the workplace) who now has a PC on their desk running a DOS/MS derivative would instead have a PC on their desk running Unix with a GUI, a minimal administrative interface, and the productivity tools equivalent to what they have under MS (which exist, please don't even start that discussion.) Imagine ! Half _years_ between reboots No stalls as your OS decides it's time to do some multitasking Fast task switching from the user perspective instead of Sominex-qualified GUIs Real, fast networking without hiccups and hangs Grown-up quality distributed facilities for file sharing and security A computing base that doesn't need a "revolution" every few years just to keep pace with hardware growth and user needs, because instead it is a non-stunted and correct implementation of the cutting edge of developments in the field. Imagine, particularly if you're involved in the business end of things, the BILLIONS of dollars in increased productivity which would be realized if this were the case now, nevermind if it had been the case for the last say eight years. Microsoft just doesn't cut it as the candidate to lead the way into the computing future. Others are more than qualified.
From: Alex Blakemore <alex@genoa.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 18 Feb 1997 04:14:17 GMT Organization: Genoa Software Systems Message-ID: <5ebaap$6db@saturn.genoa.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: johnh@madcow.dircon.co.uk In <5eagds$niv$1@newsserver.dircon.co.uk> John Holdsworth wrote: > I don't want to sound like a luddite but... > I've put a fair amount of time into scoping the amount of work > involved in porting some real applications onto OpenStep only > to find that the common classes List, HashTable etc all gone > from the OpenStep spec. Which is why Object, List, HashTable, StringTable and Storage ARE still available in NeXT's implementation of OPENSTEP, even if they are not officially part of the spec. For backward compatibility. I wouldn't recommend using them in new apps though. > While I'm at it lets keep strings as a data type rather than a class. Give NSString a chance, most people I've observed find it alot simpler to deal with than char * and its nice to only have to remember one approach for allocation, deallocation etc - even if a few operations are a little more awkward. Plus you get Unicode support. -- Alex Blakemore alex@genoa.com NeXT, MIME and ASCII mail accepted
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 18 Feb 1997 19:11:08 GMT Organization: Rockwell Avionics - Collins Message-ID: <5ecusc$9p0@castor.cca.rockwell.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5ebqe6$hu6@concorde.ctp.com> <33098bb9.30677792@nntp.ix.netcom.com> Cc: apuleius@ix.netcom.com > >It is true. NEXTSTEP != OPENSTEP as far as the API goes. > >There are some major differences, some of which are > >conceptual and require not just changing method names, but in > >some cases completely _rewriting_code. Stuff that uses > >streams a lot can be onerous, for example. Having done some > >NEXTSTEP->OPENSTEP conversion, I will openly state: > >it is non-trivial to do! > > and > > (4) Georg's assertion that it's a piece of cake. > > Draw your own conclusions about the validity of what Georg says. > To be fair, a LOT depends on how your code is structured. I wrote a tetris game for NeXTStep 1.0 that was difficult to convert to Openstep. It was one of my first NeXT apps. In contrast, a 44k line app for one of my customers was converted in a "few" days. Of course, the app was already FoundationKit based. We have ended up re-writing a lot of the GUI code for the app anyway to take advantage of the "new" way to do things. Streams, file descriptors, -performWith:afterDelay:cancelPrevious:, and a few others like NXPing are replaced with cumbersome code. Use NSData to simulate streams. I have not found a work around for the lack of file descriptors in Postscript How does MiscSerialPort handle this ? -performWith:afterDelay:cancelPrevious: can be simulated with NSTimer and NSNotification NXPing becomes [[NSDPSContext currentContext] wait]
From: klui@cup.hp.com (Ken Lui) Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs Subject: Re: OPENSTEP/MACH 4.1 -- printf %g still broken Date: 18 Feb 1997 20:51:37 GMT Organization: Hewlett-Packard Company Message-ID: <5ed4op$t4c@hpax.cup.hp.com> References: <5ecoph$74i@tribune.usask.ca> In article <5ecoph$74i@tribune.usask.ca>, <eric@skatter.USask.Ca> wrote: >eric@pisces 224> cat printfcheck.c >#include <stdio.h> > >int main (int argc, char **argv) >{ > printf ("Expect 0.00123: %.3g\n", 0.001234567); > printf ("Expect 123: %.3g\n", 123.4567); > printf ("Expect 123.5: %.4g\n", 123.4567); > printf ("Expect 1e+03: %.3g\n", 999.6); > return 0; >} >eric@pisces 225> cc -o printfcheck printfcheck.c >eric@pisces 226> ./printfcheck >Expect 0.00123: 0.001 >Expect 123: 123.457 >Expect 123.5: 123.4567 >Expect 1e+03: 999.6 >eric@pisces 227> [...] >Every other time I have posted an article about this bug I have received mail >saying that the behaviour of the NeXT printf is correct. To try and forestall >these replies I include the following: The above program runs giving the expected results on HPUX 9.05, if it means anything to you; so your expected results and HPUX's output at least coincides. Ken -- Ken Lui, klui@cup.hp.com 19111 Pruneridge Avenue General Systems Division Cupertino, CA 95014-0795 USA Open/Intelligent Warehouse Team 1.408.447.3230 FAX 1.408.447.7200
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 21:44:02 -0800 Organization: Esperance Communications Message-ID: <jk-1802972144030001@ip-salem2-01.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >However, I can't NFS mount a remote fileserver on a Mac and be able to >run Mac executables, because they require the out-of-band information >stored in their resource forks which is not representable within the >standard NFS/UFS filesystem paradigms. Doesn't the lame wrapper approach cause "problems" equal to that(AppleDouble certainly causes only as many problems as "wrappers")? Ideally, a MacOS NFS client would store Mac files on a NFS server in AppleDouble format (executables in AppleSingle would be better) and make the process seamless to the client Mac (I'm pretty sure that current clients already do this, if they don't, that's a problem). Netatalk and CAP do the reverse, to MacOS they work exactly the same as a "real" AppleShare server, without need of a Mac filesystem on the server (I don't see why a NFS client couldn't do something similar client-side). -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 01:03:00 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ee52k$arh@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <jk-1802972158190001@ip-salem2-01.teleport.com> In article <jk-1802972158190001@ip-salem2-01.teleport.com>, jk@esperance.com (Joel Klecker) wrote: > I don't want to sacrifice the useful > features of HFS and destroy what the Mac is just to satisfy a bunch of > people that probably still won't buy Macs. Huh? You mean the NEXTSTEP people? You think we're going to abandon all the new work going on in the OS just because Apple bought it? (Well, maybe, if they screw up the OS.) NEXTSTEP users stuck with the OS when there was far less incentive to do so; of course they'll buy it from Apple. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 01:01:19 -0500 Organization: phenix@interpath.com Message-ID: <199702190101192935764@roxboro-180.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: ] Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & ] Unix: File S.. by John Siracusa@bu.edu ] >: It doesn't make sense when files and applications can be used ] >: by multiple users. ] > ] > I don't see how that is. File type and creator information doesn't ] > vary from user to user. ] ] While that is true, the Mac paradigm uses that information to make the ] decision as to which application should open a particular file. ] ] The Mac paradigm doesn't work very well when you consider a multiuser ] operating system because individual users should be able to decide for ] themselves which app should open a file and not have their decisions ] change what happens to other users. The Mac way of doing it isn't the BEST way of doing it - a slight modification could be made which would make it about 10 times better - but it really doesn't have anything to do with whether it's a multiuser OS or not. The original system makes the (perfectly reasonable) assumption that *most* of the time your going to be opening files with the application that created it, and it's not too much of a added burden to open the file from within the application if your going to use a different one. This is just as valid for a dozen users as it is for a single one, WHAT has changed since the original system is the number of applications available. With the increase in the number applications available the odds of wanting to use a different application from the creator has gone up - even though it's STILL true *most* of the time for most users - and with the changing odds they need to make a few additions. They made a half-hearted effort with Macintosh Easy Open, and will soon find out that they need to finish it up and do it right. MEO as it is currently address only the most blatant problem with the current method, the one that confusing inexperienced users. -- John Moreno
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 19 Feb 1997 16:10:01 +1100 Organization: Unisys Message-ID: <330A8B29.1D5A@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@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.programmer: 18-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > > In any case, I come back to the original point, that in most cases it > > is inappropriate for the OS to send an error/exception back to processes > > that are waiting on resources, without at least trying some recovery, > > either automatic or with operator assistance first. If the OS doesn't > > do this then you do not have a very robust OS. > > Blocking a process because the kernel is waiting for an operator to tell > it how to proceed when some form of error occurs is the opposite of > robust! You can easily deadlock every runnable process if some crucial > system resource like inetd (*), named, lookupd, or the swapper > encounters a minor problem and must block until a human informs the OS > of what to do when that error condition could otherwise be handled > within the process. You are not only not reading correctly what I am saying, but in your misreadings are quite wrong. > Go perform some research on operating system design theory, Ian. Go do some research on Netiquette. You might find that you get more pleasant exchanges with people. Technically, you should go and use a system other than Unix. > You might learn something about why your suggestion is so mistaken. From what I have seen you certainly don't have a monopoly on truth, and even further quite a meagre understanding, and probably not much experience beyond the confines of Unix. You are doing pretty well in monopolising beligerence. Please come back to the group only when you can write in a politer tone. You are too quick too accuse others of bias, ignorance and stupidity, and this displays a high level of arrogance. I don't subscribe to the belief that this is what Internet news groups are for. As I have said before, please keep it technical. ------------------------------------------------------------------------ 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: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 19 Feb 1997 01:58:55 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mn2eGj200iWXQJ_9lV@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <330A4383.339A@acm.org> In-Reply-To: <330A4383.339A@acm.org> Excerpts from netnews.comp.sys.next.programmer: 19-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org > For example, any read to a file is essentially a concurrency problem... > your process will probably suspend until the required data is read > from disk. That depends entirely upon how the process wants to read the file. The process can decide to perform non-blocking I/O file with the O_NDELAY or O_NONBLOCK flags to open(), or via select() on a set of open file descriptors. > Many calls to an OS can be seen this way, as you > might have to suspend until the requested resource becomes > available. The general principle here is that the OS should do > its utmost to satisfy the request, as should any call to any routine. The general principle is that the OS should attempt to maximize throughput by minimizing the number of resources held simultaneously by any process. The reason why processes may block waiting on a resource to become available is to allow the CPU (which itself is a crucial system resource) to be used by other processes until the current process can make progress. You want to avoid deadlock as best you can, and doing so involves trying to make critical sections as small as possible, as well as trying to avoid resource contention as far as the properties of resources allow. [ ... ] > Perhaps I did not explain this very well in the first place, but I > hope that makes it clearer to Charles. I am also not saying this > to defend MacOS or criticise NeXT. However, some of the weaknesses > of Unix should be understood, and the fact that Unix is not > in many respects the perfect OS. I've never said Unix was the perfect OS-- but I haven't found a better alternative so far, either. > Neither does it handle memory sharing and resource synchronisation at a > very high level, Not at the operating system level, no. That's why people write software layers on top of the OS, such as OPENSTEP, which provide higher level abstractions which use the more primitive functionality provided by the OS. And that's where those high-level abstractions belong-- not in the kernel.... > and why it has not swept aside all those "horrible mainframe" OSs is > due to the fact that it does not have very good server capabilities > such as TP monitors, apart from Tuxedo. Your typical Unix workstation is an entirely different class of machine from a mainframe-- the former is often running a GUI for a user on console, whereas the latter was designed to provide tremendous I/O bandwidth and was intended less for interactive use and more for transaction processing. But the age of "big iron" is mostly over, and even the mainframe's hold on it's traditional strength of large scale server applications is eroding in the face of fast, cheap workstations and distributed computing systems. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: "Terje A. Bergesen" <no.email@to.me.please> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Wed, 19 Feb 1997 08:18:33 +0100 Organization: NSEP Message-ID: <330AA949.3801@to.me.please> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Kheit wrote: [...] > That micro kernels tend to be more buzz word hype than valuable... > Why, b/c putting things outside the kernel, in general, results in > some serious performance penalties for no real functional benefit. I really don't think this is a microkernel vs monolithic issue. I think it is an implementation issue. There are good examples, both in theory and in real life of implementations of microkernel OS's that have good performance. I haven't (sadly, I haven't got the time) looked at QNX for a while, but last time I looked it had a kernel of some 8K or something in that area, and excellent performance. ____________________________________________________________________ --- Terje Bergesen - I speak only for me, not for my employer. --- --- Email adress can be decuted from: t.bergesen at shell.no
From: rmcassid@uci.edu (Robert Cassidy) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Wed, 19 Feb 1997 23:29:20 -0700 Organization: UC Irvine Message-ID: <rmcassid-1902972329210001@dialin9118.slip.uci.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> In article <5ebg1m$1en@news3.digex.net>, jkheit@cnj.digex.net wrote: > of a monolithic kernel is not reduced by its monolithicness. ^ <groan> Sorry, it might be correct but that's just one ugly-assed word :-) -Bobness Cassidyness
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 07:42:43 GMT Organization: Lund University Message-ID: <peterm.856338163@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <slrn45g122e.o78.campbejr@phu989.um.us.sbphrd.com> <peterm.855819006@ulfrun> <slrn45ghfmn.oqs.campbejr@phu989.um.us.sbphrd.com> campbejr@phu989.mms.sbphrd.com (John R. Campbell) writes: > stat.ctime (doubles as "creation time" since chmod is not normally > changed). > For instance, once a file's created, how often do *you* think the > permission bits need to be manipulated, hmmm??? Often enough that this timestamp is *not* a reliable information of when a file was created. Period. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 07:46:03 GMT Organization: Lund University Message-ID: <peterm.856338363@ulfrun> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> shess@one.net (Scott Hess) writes: >Which brings up an interesting question ... And another one: what happends if you move or rename an application in NeXTOS? Can I still double-click my document and have the correct application launch? Or is it like Solaris, where everything have to be where you once put it and don't you dare renaming it! (No need to say I find this reliance of paths infantile and stupid). On my Mac I can rename and move an application and the desktop database finds it immediately when I open a document. Even the aliases (soft links) survive. Rhapsody better keep this behaviour or a lot of Mac users will be angry and encounter problems. Just a question. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 07:52:34 GMT Organization: Lund University Message-ID: <peterm.856338754@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5ecefl$5d1@kwek.omroep.nl> >: While the Mac users abhorance of file extensions is largely religious, >: it will probably need to be honored for the sake of a smooth migration >: path. However this could be as simple as hiding the extension from view >: in the Finder. I wouldn't call it religous, it's practical, logical etc. WHY should the user have to spend mental time and energy trying to remember extensions?? WHY? It's stupid. The application knows it and that suffices. An example: the extension "DOC" in the WIntel world meand "Micro$oft Word Document" and only that. It does not tell you what version of messy word it is. And the named word processor can handle a lot of other file types (from the BNDL-resource of Word 5.1): TEXT, WDBN, GLOS, WHLP, WPRD, sDBN, edtt, WDIC, WDEC, WDPC, SITD - and this is just one application!! One difference of the typical Macintosh user and users of other computer systems is that the Mac user generaly uses more applications than other users. Having to know information which there is no rational reason whatsoever to know would, I'm sure, stifle that using habit. Give me one rational reason to remember extensions! With the Mac scheme of creator/file type, I can easily have both FreeHand 5.5 and FreeHand 7.0 on my hard disk at the same time and use the newer application until I know I really want to have it. And when I throw the old one out, the new one knows directly when I open an old document exactly what kind of document it is and how it should treat it - all without looking at the content of the file (which takes time - at least more time than to look at the file type). And to have extensions but hide it in the Finder - sweeet jesus... So when you look at the files from another point of view (another kind of file browser, your own application or you have files on a floppy and you insert that floppy in a PC or unix machine or you simple transfer a file with ftp to another kind of machine) you will not see the same kind of information that you otherwise do and that's a major "No-no" in the Apple world, and with good reasons. Having this kind of "solution", one might just start to use the fabulous filesystem that WIntel uses... -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: kindall@manual.com (Jerry Kindall) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 17:59:47 -0500 Organization: Manual Labor Message-ID: <kindall-1802971759480001@ppp.manual.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> In article <5ecund$rcn$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: >In <1997021716472829510259@roxboro-170.interpath.net> John Moreno wrote: >> John Rudd <jrudd@cygnus.com> wrote: >> ] The reason this is a problem on a Mac isn't because it's stored in a >> ] central location.. it's because the Mac doesn't allow you to pick file >> ] type over file creator for its launching heuristic, and then give a >> ] seperate file-type <-> application binding for different "profiles" >> ] (even if its' just swapping a file at runtime). If it did allow this >> ] (even the crude run time swapping of the binding file), then it >> ] wouldn't be a problem. >> >> It DOES allow you to override the launching application but ONLY if the >> creating application is not available. It's called Macintosh Easy Open >> and it could be extended to work properly (override even application >> which ARE available) in the current system, let alone in the next. > >That's kind of what I meant.. You can't choose to open by file type _OVER_ >file creator. If the file creator data is there, and the file creator app >exists on that machine, you MUST use it. You cannot choose a file type >application OVER that creator app. I didn't say you can't open by file type >at all. I simply said the Mac doesn't give you a choice between the two -- >if creator exists you use it, otherwise you use type... no choice. Sure there's choice. You can open the appropriate application, then use its Open command to open the file, or you can drag the document icon onto the application icon. In the latter case it can even be an alias. If you have OneClick, you can use my HotPlate palette to force files to be opened by a particular app with one keystroke. For example, I have my Mac configured to open the highlighted files in ResEdit when I hit Command-Shift-R, in Netscape Navigator when I hit Command-Shift-N, in Photoshop when I hit Command-Shift-P, and so on. -- Jerry Kindall <kindall@manual.com> Manual Labor <http://www.manual.com/> Technical Writing; Internet & WWW Consulting Author of the Web Motion Encyclopedia The comprehensive animation and video reference for Web designers Coming Summer '97 from Waite Group Press
From: bwanga@cats.uc*sc.edu (Timothy A. Seufert) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 00:37:12 -0800 Organization: Evil Geniuses For A Better Tomorrow, Inc. Message-ID: <bwanga-1902970037160001@metricom04.ucsc.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> In article <199702182327301079516@q700.hf.org>, hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) wrote: >Actually, the resource fork pattern has always been appealing to me as a >perfect approach to handle the hundreds of little data structures that a >GUI application needs to run. Icons of various shapes and sizes, >templates for menues, windows, dialogs, controls, code snippets... all >of who would otherwise have littered the file system - and do so in >other OSes. > >If you can do similar things with wrappers in a consistent manner, then >it's for the sake of portability allrigt with me; but portability left >aside, the forks add an additional abstraction level in a (for me) >simple and elegant manner. The MacOS resource fork does present many advantages. However, it doesn't really need the concept of a "fork" to work. Forks are just a method of making two files appear as one to the user. There is no reason why the Resource Manager can't be slightly hacked so that it operates on the lone fork of a file in a single-fork file system. A resource file then goes in the app wrapper, along with any other required files (like the executable). All of a sudden, you've got the Resource Manager working inside the app wrapper paradigm. It's better than before because it no longer relies on multiple forks. A cleaner concept might be to rewrite the RM so that what it actually does is to pack a directory tree into a single file. RM calls should work equally well whether a resource tree is in a packed container file or expanded into the filesystem. During progam development, you keep the tree unpacked, for easy manipulation of its contents. For a shipped program, you package the tree into a container file, to reduce the number of files that are actually going onto the end user's system. -- -Tim Seufert, bwanga@cats.uc*sc.edu The * is to fool automated email address grabbers. Remove it if you wish to send me email. No unsolicited commercial junk mail!
From: mkagalen@lynx.dac.neu.edu (Michael Kagalenko) Newsgroups: comp.sys.next.programmer Subject: Re: Anyone know if OS4Mach 4.1 supports EIDE CDROMS???? Date: 18 Feb 1997 23:23:17 -0500 Organization: Northeastern University, Boston, MA. 02115, USA Message-ID: <5edv7m$vn3@lynx.dac.neu.edu> References: <5e2ffv$3o2s@yuma.ACNS.ColoState.EDU> Content-Type: text/html They do, although I have not been able to get OPENSTEP/Mach 4.1 to recognize my Sony CDU 33a. -- ABILITY,n. The natural equipment to accomplish some small part of the meaner ambitions distinguishing able men from dead ones. -- Ambrose Bierce, "The Devil's Dictionary"
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: New Information Date: Wed, 19 Feb 1997 14:28:14 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E5utJ4.6o3@cam-ani.co.uk> References: <E5ur81.5n@icgned.nl> In article <E5ur81.5n@icgned.nl> Hans Mulder <hansm@icgned.nl> writes: > nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: > >In article <5e55u8$7td@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > >I.e., Terminal.app? > Why not install it in the usual place and make it hidden? Move it into /NextAdmin? $an
From: mphunter@249.com (Michael Hunter) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Followup-To: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Date: 19 Feb 1997 15:03:09 GMT Organization: QNX Software Systems Ltd. Message-ID: <5ef4nd$qut@qnx.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> Scott Hess (shess@one.net) wrote: : In any case, why are we even discussing a point made by someone who : compares distributed computing to "The Borg"? I _very_ much doubt : that OS designers watch Star Trek in order to get wonderful new ideas : about the future. [Or is the implication that the Borg run a : microkernel operating system? Perhaps Amoeba.] Since the aliens in ID4 had DOS its wouldn't be a wonder if Apple looked to the stars for their salvation. -- * Michael Hunter (mphunter@qnx.com, http://www.qnx.com/~mphunter)
From: syy@ecmwf.int (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 11:54:58 GMT Organization: ECMWF (European Weather Centre) Message-ID: <5eepmi$r6e@horus.ecmwf.int> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <wharris-ya023080001702970658310001@news.iadfw.net> There's a tendency in the NeXT community not to grok the utility of MacOS features like file type & creator codes, Macintosh Easy Open, and full drag-and-drop capability. NeXTfreaks might say: |> >Among the data stored in the application segments ... are the |> >information on which kind of document (file extension) one given app can |> >open. For example, PhotoShop.app could open ".tiff", ".eps", ".gif"..., |> >IconBuilder.app could open ".tiff" documents only. The user can choose a |> >default application (among those able) to open a given kind of document. |> >This is a user's preference. This is a Mac user's preference too. The file TYPE code is analogous to a filename extension (but unintrusive). An app knows which file types it can handle. The file CREATOR code simply indicates which app created the file. Double-clicking a file tries to launch that app. If the app isn't found, Macintosh Easy Open launches to ask the user to nominate a substitute app which can handle that file type. Easy. From then on, that app becomes that user's preferred launch. And for further user flexibility, there's drag-and-drop. NeXTfreaks might say: |> >Once more, you have the choice. If you prefer, you can command-drag your |> >file icon onto a running or "docked" application icon to have it opened in |> >a different app. That's good. On a Mac it's even better. You can simply drag (no need for the command key) any document onto any app, as long as that app is willing to handle that file type. The app can be anywhere (in a folder, on the desktop, in the Launcher, wherever), and it can be running or not. Doesn't matter. Just drag any document onto any app, and if the app can handle that file type, it will launch (if not already running) and ingest the document. I keep aliases of all my most-used and favourite apps on my desktop, mostly for the specific purpose of drag-and-drop. -- Mike Connally Consultant, Data Handling Project European Centre for Medium-Range Weather Forecasts (ECMWF) Shinfield Park, Reading, Berks RG2 9AX England Tel: +44-1734-499253 Email: Mike.Connally@ecmwf.int
From: danh@qnx.com (Dan Hildebrand) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 19 Feb 1997 08:11:30 -0500 Organization: QNX Software Systems Message-ID: <5eeu62$76s@qnx.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> In article <SHESS.97Feb18074753@howard.one.net>, Scott Hess <shess@one.net> wrote: >In article <5ebg1m$1en@news3.digex.net>, > > That micro kernels tend to be more buzz word hype than valuable... > Why, b/c putting things outside the kernel, in general, results in > some serious performance penalties for no real functional benefit. > Thus, Avie, and the folks at NeXT (now apple), who really know a > thing or two about this stuff, to say the least, opted to keep > things monolithic for perfromance reasons. Yet the functionality > of a monolithic kernel is not reduced by its monolithicness. > >Umm, well, hmm. This is a rapidly evolving area, not only because >there are people working on the problem of making microkernels more >efficient, but because CPU speeds are outrunning I/O speeds, and main >memory sizes are growing quickly (though not really getting faster). >On a system like a NeXTstation, where the CPU, memory, and I/O are >relatively balanced, a monolithic kernel can be easily more efficient. Easily? Can you back this up? While some monolithic kernels are faster than some microkernels, this is not universally true. >Beyond that, on personal computers you tend to have a few processes >using significant resources, but not necessarily doing very many >kernel calls per unit of CPU time used. [Excepting web browsers, I >supposed :-).] In fact, perhaps the single biggest amount of kernel >activity on many systems, after virtual memory activity, is probably >the context switching between apps and their windowserver. >Microkernels must by nature be very focussed on context switch time as >it applies to messaging, so if a microkernel were somewhat quicker >there, it would probably cancel out the increase in context switches >for many users. Exactly - and with so many applications these days being structured as clients and servers (either local or network remote from each other), the speed with which you can do IPC (which implies context switching as part of the IPC), the faster the client/server transactions can occur. A microkernel works to simplify the kernel, with the goal being to then incur the complexity of making that simple kernel perform its operations as efficiently and quickly as possible. -- Dan Hildebrand (danh@qnx.com) QNX Software Systems, Ltd. http://www.qnx.com/~danh 175 Terence Matthews phone: +1 (613) 591-0931 Kanata, Ontario, Canada fax: +1 (613) 591-3579 K2M 1W8
Newsgroups: comp.sys.next.programmer From: Hans Mulder <hansm@icgned.nl> Subject: Re: Mac/NeXT & Unix: New Information Message-ID: <E5ur81.5n@icgned.nl> Note: UNOX is a trademark of "Union Deutsche Lebensmittelwerke GmbH". Sender: news@icgned.nl Organization: hardly any References: <5e55u8$7td@news.bu.edu> <5e5hpc$isr@csugrad.cs.vt.edu> Date: Wed, 19 Feb 1997 13:38:25 GMT nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: >In article <5e55u8$7td@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: >> Even better, Mac users can install a version of Rhapsody that will not >> include a path to Unix, >I.e., Terminal.app? >> so they never have to soil their hands with the >> greasy innards of the new OS. >Boy, would that be a mistake. Better to install it (possibly in some >out-of-the-way place that you'd never notice) and just not use it. Why not install it in the usual place and make it hidden? -- HansM
Newsgroups: comp.sys.next.programmer From: ajkenned@novice.uwaterloo.ca (Andrew Kennedy) Subject: NeXT Development problem Sender: news@novice.uwaterloo.ca (Mr. News) Message-ID: <E5to1t.ntn@novice.uwaterloo.ca> Date: Tue, 18 Feb 1997 23:32:16 GMT Organization: University of Waterloo Keywords: NeXT, menus, selector Hello, I'm relatively new to the NeXT development scene and the answer to this is probably somewhere but I don't know where to start looking. Here's what I'm trying to do. I have an application with multiple bundles. They are linked to the main application and add items to the menu of the main application. I'm trying to add another menu item to the bundle submenu. I added the code in the appropriate files for the new menu item, and sure enough, if I build and install the bundle, the new menu item appears. I've given it a selector action. I have prototyped the method in the header file, added action to the method in the source file and have parsed the file in Interface Builder so that the new action appears correctly in the class file. However, when I select the menu option, it does nothing. Right now its supposed to pop up an alert box but it appears to not even find what I'm trying to do. I must have missed something, probably minor but obviously important. If anyone can shed some light onto this issue, could you reply to me in personal email. I can give you the new code if necessary. Thanks. -- | Andrew "Nad" Kennedy }:> | ajkenned@novice.uwaterloo.ca | | 4B Systems Design Engineering | ajkenned@zeus.uwaterloo.ca | | University of Waterloo | |
Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.next.programmer From: tsikes@netcom.com (Terry Sikes) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Message-ID: <tsikesE5uz8v.AGu@netcom.com> Organization: Netcom References: <5d8qta$6np@news.bu.edu> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <330A4383.339A@acm.org> <Mn2eGj200iWXQJ_9lV@andrew.cmu.edu> Date: Wed, 19 Feb 1997 16:31:43 GMT Sender: tsikes@netcom23.netcom.com In article <Mn2eGj200iWXQJ_9lV@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Your typical Unix workstation is an entirely different class of machine >from a mainframe-- the former is often running a GUI for a user on >console, whereas the latter was designed to provide tremendous I/O >bandwidth and was intended less for interactive use and more for >transaction processing. > >But the age of "big iron" is mostly over, and even the mainframe's hold >on it's traditional strength of large scale server applications is >eroding in the face of fast, cheap workstations and distributed >computing systems. > >-Chuck Also check out Sun's new line of mainframe class machines. Extremely high I/O performance, up to 64 CPUs and Solaris - pointed directly at the big iron buyers. -- Terry Sikes | Software Developer tsikes@netcom.com | C++, Delphi, Java, Win32 (in alphabetical order ;) finger for PGP pub key | Objective objects objectify objectivity. My opinions - mine only! | http://members.aol.com/tsikes
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Wed, 19 Feb 1997 09:19:38 -0600 Organization: mementech, inc. Message-ID: <330B1A0A.52930AE1@screaming.org> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <rmcassid-1902972329210001@dialin9118.slip.uci.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Robert Cassidy wrote: > jkheit@cnj.digex.net wrote: > > > of a monolithic kernel is not reduced by its monolithicness. > ^ > <groan> > Sorry, it might be correct but that's just one ugly-assed word :-) You're right. I think the right word is monolithicitudeinousossity. -- 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,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior From: tom@icgned.nl (Tom Hageman) Subject: Re: Mac/NeXT & Unix: File System Message-ID: <E5uvu4.Mv@icgned.nl> Followup-To: : comp.sys.next.advocacy,comp.sys.mac.advocacy Sender: news@icgned.nl Organization: IC Group References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <1997021810351033363403@roxboro-161.interpath.net> <slrn45gk3sl.oqs.campbejr@phu Date: Wed, 19 Feb 1997 15:18:04 GMT As interesting as this thread may be, it really does not belong in *.programmer anymore. Therefore I would like to ask the contestants to continue their exhortations in *.advocacy. Please? Note Followup... -- __/__/__/__/ 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
Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant From: tom@icgned.nl (Tom Hageman) Subject: Re: Mac/NeXT & Unix: You're all NUTS! Message-ID: <E5uvxB.nr@icgned.nl> Followup-To: : comp.sys.next.advocacy,comp.sys.mac.advocacy Sender: news@icgned.nl Organization: IC Group References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <avirr-1802971155110001@avi.starnine.com> Date: Wed, 19 Feb 1997 15:19:59 GMT As interesting as this thread may be, it really does not belong in *.programmer anymore. Therefore I would like to ask the contestants to continue their exhortations in *.advocacy. Please? Note Followup... -- __/__/__/__/ 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: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 19 Feb 1997 09:08:04 -0700 Organization: Primenet Services for the Internet Message-ID: <AF30771C-22DC6@198.68.42.217> References: <5ef4nd$qut@qnx.com> nntp://news.primenet.com/comp.sys.mac.programmer.misc, nntp://news.primenet.com/comp.sys.powerpc.advocacy, nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.misc, nntp://news.primenet.com/comp.unix.machten, nntp://news.primenet.com/comp.unix.osf.misc, nntp://news.primenet.com/comp.os.mach, nntp://news.primenet.com/comp.os.ms-windows.nt.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > >Since the aliens in ID4 had DOS its wouldn't be a wonder if Apple >looked to the stars for their salvation. Nah. They had Windows. Bill Gates was the last survivor of the Roswell Crash, waiting for rescue and trying to sabatoge the Macintosh Way while he was at it (the ID4 aliens are an interstellar consortium of MIS folk, dedicated to making sure that the Macintosh Way never threatens their hegomony (that's why they attacked Earth)). The irony is that Bill Gates was on the verge of destroying the Mac, but since Windows is designed so that Windows machines can't talk to each other easily, he was unable to communicate that fact to the alien mothership. Since Macs are designed to network with Windows easier than Windows machines are, the PowerBook was able to interface with the mothership before Gates could, and the rest is history. Unfortunately, Apple was unable to sell any PowerBooks, even though one had saved the world, and Windows crushed the Mac, even without help from the aliens. --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
From: IT Connections <mail@it-connect.com> Newsgroups: uk.jobs.offered,uk.jobs.contract,comp.soft-sys.nextstep,comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.advocacy,comp.sys.next.sysadmin Subject: NeXT's Web Objects/Enterprise Objects Job - London based. Date: Wed, 19 Feb 1997 15:55:00 +0000 Organization: IT Connections Distribution: world Message-ID: <$DHk4GAUJyCzEwjn@it-connect.com> MIME-Version: 1.0 NeXT's Web Objects/Enterprise Objects Job - London based. Anyone out there like a job? This is an excellent opportunity to work for one of the coolest companies in the Universe. A developer is required to spearhead the commercialisation of their Web site. This will involve creation of both backend objects via data from an Oracle database and creation of front end dynamic pages using NeXT's Web Objects and Enterprise Objects and HTML. Contractors maybe considered for this role. Salary top pay Contact Andrew Akhurst for an informal discussion or mail CV to him. IT Connections Tel: 01525 840123 98-100 Dunstable Street Fax: 01525 840899 Ampthill Email: mail@it-connect.com Bedfordshire URL: http://www.it-connect.com MK45 2JP
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 09:36:10 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb19093610@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <peterm.856265782@ulfrun> In-reply-to: peterm@dna.lth.se's message of 18 Feb 97 11:36:22 GMT In article <peterm.856265782@ulfrun> peterm@dna.lth.se (Peter Moller) writes: shess@one.net (Scott Hess) writes: >Why are the last accessed, modified, and inode updated times in >there? Quite simply for performance reasons. These things are >being modified _all_ of the time. Whether the kernel portion of >the filesystem is Well, they are *read* quite often, I agree with that. But I'd like to say two things: 1. The MacOS don't have a tenth as many files as Solaris for instance. Thus, this kind of file info isn't read/changed at all as often. The Mac OS, however, fiddles with resources *all* the time, and thus for a Mac it's more important to have a fast resource manager than a fast filesystem (byt I'd love to see a really fast FS). File count shouldn't make much difference - faster is faster, in general. [Well, in the past there were good arguments for 16-bit info, but we're far past that day.] Where it _might_ make a difference is in whether you're willing to put in the effort to make things fast. You're willing to put in more effort if the system is reading millions of files a day versus tens of files. Besides, the one constant in computers is that though you may not need that many _now_ you will next year :-). 2. As far as I know, nothing less than a block (usually 512 bytes) is ever read from the hard disk. I don't know, but I assume that the OS doesn't sequentially read in the file header until it finds the information it looks for, but rather it get's it "directly" via an index, right? So how much time does it takes to use another index? I also assume that the file info in the cache behaves equally. Thus more info in the file header will not take more CPU time (unless that info is often referred/changed), right? Reading a few more bytes from the hard disk is hardly relevant here. It's the latency that's important. If an inode has 96 bytes of information, you can fit 10 inodes in a 1k fragment. If an inode has 128 bytes, you can only fit 8, if it has 160 bytes, you can only fit 6. Everything is accessed in terms of fragments or blocks (8k by default on NeXTSTEP). Inodes are indexed by 32-bit integers, so you never "scan" for inodes, you always know where a given inode is. Obviously you always have to read a fragment to get an inode. Say you currently have 5 fragments worth of inodes in the cache, and you need to read some inode. With 10 inodes/fragment, you have 50 inodes which _might_ be the one you want. With 6 inodes/fragment, you only have 30. Keep in mind that the inode index for files in a directory will tend to be near one another, and the files in a directory will tend to cluster their accesses (after accessing a given file, the system is statistically more likely to access another file in that directory). In the end, the more inodes there are per fragment, the fewer disk reads you'll need to do. [Note: I'm not sure that inode blocks are read by fragment, or by block. Everything above pretty much holds in either case, though, the numbers are just bigger.] My only "demand" (if I may have one) is that it's rock solid and built in from scratch, i.e. not a hack. Hacks simply aren't good enough. Well, if there's one thing I can _guarantee_ will happen, it's that there will be one or more hacks involved. :-). >management utilities to propagate a new timestamp anyhow, just >having the timestamp there won't do squat.] Is it the applications that modify the other time stamps?? I thought it was the FS. Things like copy and archival utilities will have to maintain the creation timestamp, otherwise it's not worth much (you want the creation timestamp of the original, _not_ of the time the new copy was created). This is mostly a concern if it's stored out-of-band, though - "cp -Rp" will copy all files in a directory wrapper, and tar will work without modification. [These changes are by no means limited to just cp and tar, though :-).] >BSD FFS has also been used by several million users for more than a >decade. So that means we can never change it? Uh, the poster I was responding to made a point that HFS has been in use by millions of people for a decade. I was just pointing out that FFS has just as many numbers on its side. >BSD FFS was designed for multitasking timesharing server systems, >systems with substantially more disk, memory, and CPU than >personal computers of the day had, in a midsize heterogenous >network Oh, it's a good file system, but it can be improved, and this might be a good time. As I noted, I'm not averse to improving the filesystem - but I only consider things an "improvement" if they improve the operation of the filesystem. While an indirect goal should be improving the user's satisfaction with the system, the _direct_ goal should be to improve the filesystem's efficiency. In general, the user will get more done on a system with improved response time than on a system with improved throughput. In essence, that's what this thread is about - the creation timestamp is one more bit of info helpful to the user. I'm arguing that this bit is very seldom used, and though it might be useful periodically, it's not useful frequently enough to be worth hazarding throughput. If you make the things the user does hundreds of times a day fast, it's not too painful if you make the things they do once a week a bit slower. -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 19 Feb 97 09:43:31 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb19094331@howard.one.net> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5ebqe6$hu6@concorde.ctp.com> In-reply-to: "Georg Tuparev"'s message of 18 Feb 1997 08:49:10 GMT In article <5ebqe6$hu6@concorde.ctp.com>, "Georg Tuparev" <gtupar@ctp.com> writes: --- Flame on --- Why some people cannot (or do not want to) understand that backwards-compatibility == M$ All these "I cannot convert to OS", "Where is the List class" etc. questions indicate poor design and implementation, and if somebody writes lasagne code, even backwards compatibility will not help ... he will find another excuse for his handicap. I converted 40k lines program using the scripts for 2 days without any problem -- now the program runs even on NT and Solaris, and very soon with GNU OS ... and is very happy so. --- flame of --- <flame> Think what you're saying for a minute. I assert that you can be a talented object oriented designer/architecture/programmer _and_ think differently from NeXT's talented people. OpenStep is nice. That doesn't mean that anything which doesn't translate trivially to OpenStep is a "hack". In fact, I'd argue that anything which _does_ translate trivially to OpenStep was itself a more-or-less trivial application, or perhaps 90% comments. I think the real question is whether your program does indeed run as well as it did under NeXTSTEP. You've been running it through automated regression testing, have you? There are a variety of quite subtle points that differ between NeXTSTEP and OpenStep, where you can go to the documentation for either, and assuming you don't get "This section purposely left blank", you'll find that the results are ambiguous. Your code doesn't run because it doesn't run, not because you went out of your way to hack. And this all _assumes_ that you don't run across one of the multitude of bugs in OpenStep. While I won't assert that OpenStep/Mach and OpenStep/NT are "buggy", there certainly _are_ things at _clear_ odds with their documented behaviour which you end up having to workaround. </flame> [Given the low amount of apps ported from NeXTSTEP to OpenStep, perhaps Georg is arguing that pretty much _all_ of the NeXTSTEP community writes "lasanga" code?] -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 09:51:04 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb19095104@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> <peterm.856341833@ulfrun> In-reply-to: peterm@dna.lth.se's message of 19 Feb 97 08:43:53 GMT In article <peterm.856341833@ulfrun> peterm@dna.lth.se (Peter Moller) writes: hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) writes: >Scott Hess <shess@one.net> wrote: >As far as I recall, there _was_ a limit of about 6k files per volume. That must be a really old figure: I have a HFS-volume with more than 25,000 files on it and there's no problem at all. I think the limit is 32,767 files. Did I write that? Must have dropped a 4 somewhere, as I meant 64k (2^16). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 21:58:18 -0800 Organization: Esperance Communications Message-ID: <jk-1802972158190001@ip-salem2-01.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <5eb9r5$iv2@csugrad.cs.vt.edu>, nurban@vt.edu wrote: >Well I'm sorry, but too bad. Apple is not going to redesign the entire >filesystem to make single users a little happier when it means >sacrificing multiuser capability and returning to 80's technology. You >can go on all you want about Apple's targeted market, but it's a step >backwards and Apple's not going to take it. I think a file system that stores meta-data in the filename (file extensions) is a huge step backwards. I don't want to sacrifice the useful features of HFS and destroy what the Mac is just to satisfy a bunch of people that probably still won't buy Macs. -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
From: David Young <dwy@ace.net> Newsgroups: comp.sys.next.programmer Subject: kaffe redeux Date: 19 Feb 1997 21:55:54 GMT Organization: ace dot net internet technologies Message-ID: <5efsta$4sj$1@darla.visi.com> Okay, after rattling on, I figured it was time to sit down and compile the damn thing. That was the easy part. Then I figured I'd get cool and fix the broken shared library support. I modified the Makefiles to build Mach-O relocatables instead of .a's, and poked around in the VM core to get rld_* to search the path defined in $KAFFE_LIBRARY_PATH (which I set to *Library/Kaffe) for code objects named foo.native. The resulting new version runs HelloWorldApp from the test suite, but the compiler (javac) throws an internal NullPointerException when I try to compile the other test programs. The source is available at ftp://ftp.ace.net/pub/dwy/kaffe-0.81mach.tar.gz. Anyone who wants to play around is welcome, but no guarantees. :) -- # 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: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy,comp.sys.next.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Tue, 18 Feb 1997 20:54:59 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Qn2ZpnS00iWp0GT=M0@andrew.cmu.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> In-Reply-To: <SHESS.97Feb18074753@howard.one.net> Excerpts from netnews.comp.sys.next.advocacy: 18-Feb-97 Re: Apple Mach IS NOT a mic.. by Scott Hess@one.net > To further clarify, the current Mach kernel under development is _not_ > "under development" in the same sense as replacing it with some other > kernel would be "under development". In fact, insofar as that > comparison goes, the current Mach kernel is pretty much finished. Sure, although I do wish Apple/NeXT would support Mach's user-level paging objects so that individual processes like databases and garbage-collecting environments like LISP interpreters could have their own pagers. The NFS implementation could use an update, too. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 18 Feb 97 13:10:01 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb18131001@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5do9vl$mp2$1@newz.oit.unc.edu> <5e03pp$thl@portal.gmu.edu> <SHESS.97Feb14122040@slave.one.net> <5eaab5$66f@portal.gmu.edu> In-reply-to: tfs@gravity.science.gmu.edu's message of 17 Feb 1997 19:08:21 GMT In article <5eaab5$66f@portal.gmu.edu>, tfs@gravity.science.gmu.edu ( Tim) writes: The only issue you neglected was the tuneability of the filesystem. For instance on my swapdisk I have maxbpg set pretty high compared to the default set up with a min & max on the swapfile size, because it's purpose is to deal with that one big swapfile. I've been thinking it would be slick to write a swap partition creation program which gave you a partition with two inodes (/ and /swapfile - why do you need lost+found on such a disk, just recreate from scratch), and completely filled the filesystem. None of this "Meg per cylinder group" or "10% speed vs space" crap for me, nosiree :-). You could _probably_ simulate it pretty closely with standard utilities. You could try specifying an absurd inode count in the disktab, along with putting everything in on cylinder group. Set it to optimize for time, but with a low time-vs-space overhead. Then mkfile the swapfile. That might cause the swapfile to be written in a more-or-less optimal fashion. [I've also been thinking it would be cool to put /usr and other static directories on a fully-packed read-only partition. That would probably improve access times for those files (they'd all be closer together), and free up their 10% overhead on the read-write partition for other things. In effect, if you put 200M on the read-only partition, that would give you an extra 20M free on the read-write partition. Perhaps more if you adjusted the fragment size on the smaller read-only partition (so the 200M would take less overall space). On the other hand, it would be a nightmare to adjust the sizes and install new programs. You'd have to unpack and repack the entire partition. You'd also need the ability to adjust partitioning on the disk dynamically. Doable, perhaps, but annoying as hell.] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: cc++ question Date: Tue, 18 Feb 97 00:56:01 +0100 Organization: Warty Wolfs Message-ID: <9702172355.AA01525@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In article <E5nw3F.GD@xombi.wizard.net>, "Son of Ginger and Harry, Aaron Rosenzweig <recurve@resourceful.com>" wrote: > I'm trying to compile what should be a simple C++ program on NeXTStep 3.2 > > xombi.wizard.net> cc++ main.cc > main.cc:86: warning: return type for `main' changed to integer type > ld: Undefined symbols: > endl(ostream &) [snip] > Why is the linker having a problem? (If this isn't already in the FAQ it should be there...) cc++ main.cc -lg++ should do the trick. Hope this helps, -- __/__/__/__/ 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: "Georg Tuparev" <gtupar@ctp.com> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 19 Feb 1997 21:13:36 GMT Organization: Cambridge Technology Partners, Inc. Message-ID: <5efqe0$st4@concorde.ctp.com> References: <SHESS.97Feb19094331@howard.one.net> In article <SHESS.97Feb19094331@howard.one.net> shess@one.net (Scott Hess) writes: > [Given the low amount of apps ported from NeXTSTEP to OpenStep, > perhaps Georg is arguing that pretty much _all_ of the NeXTSTEP > community writes "lasanga" code?] No. Just ask yourself who is still writing OS Apps. There are not too many left. See as an example the MiscKit :-( ... ore to be even more concrete -- the port of the IXKit. As far as I can remember, there is not a single line ready. The only work I had time to do sofar is to is to write 1 (one) header file and three pages of a draft proposal -- this makes about 2 lines / week. If we work on IXKit with the same speed, it will be finished somewhere in year 2745 ... But better pipe this discussion to /dev/null or to c.s.n.advocacy (it's the same ;-) And about your "hack" comments - not everything that is not beautiful OO is bad, take the love as an example 8~) -- georg -- -- ------- /\/\ 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: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 18 Feb 1997 14:13:41 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5ecv15$d1r@csugrad.cs.vt.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <3309a1c9.11108823@news.rmplc.co.uk> <87u3nayt41.fsf@phaedrus.uchicago.edu> In article <87u3nayt41.fsf@phaedrus.uchicago.edu>, stephen farrell <sfarrell@phaedrus.uchicago.edu> wrote: > i don't fully understand this point. developers can go out right now > and purchase openstep for mach on intel, sparc, and hppa platforms, > and for winNT, and solaris. why doesn't apple encourage them to do so, Well, for one, many Mac developers probably don't have large numbers of spare Sparc, HPPA, or even Intel machines lying around on which to do development. -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 97 13:01:43 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb18130143@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <slrn5gi97n.ibl.exfjnzl@c01021-111poe.eos.ncsu.edu> In-reply-to: exfjnzl@rbf.apfh.rqh's message of 18 Feb 1997 03:41:42 GMT In article <slrn5gi97n.ibl.exfjnzl@c01021-111poe.eos.ncsu.edu>, exfjnzl@rbf.apfh.rqh (Ravi K. Swamy) writes: In article <SHESS.97Feb17161830@howard.one.net>, Scott Hess wrote: [snip] >Don't think that there aren't things I'd like to change about FFS. >I'd like to see journalling, and the ability to defer metadata >update. I know FreeBSD file systems can be mounted to do asynchronous metadata updates. Linux's ext2 does asynch metadata updates by default. (*Please* do not argue which is better for stability etc. it's been beaten to death already) Perhaps it is only the FFS in 4.4 Lite than can do asynch metadata updates? Or perhaps the FreeBSD guys added this. You get no argument from here. 1) I'm the only user of the filesystems in question, and there's really nothing that I can't rebuild quickly enough as-is. Assuming that the async updates do flow out to disk relatively frequently (I'd assume during the 30-second sync), and that they flow out in an orderly fashion (the filesystem is always recoverable, perhaps without those last three operations). 2) I put _all_ of my machiens on UPS's, not just servers :-). In fact, I've been wondering if a Linux NFS server with fast/wide SCSI and striping on the other end of a crossover 100Mbit ethernet would be an improvement over a regular NeXTSTEP FFS with slow/narrow SCSI, for development work. [NeXTSTEP doesn't seem to want to do fast-10 on my NCR controllers. I'd guess it would do wide just fine. No striping, naturally.] Somehow I doubt it would be a net improvement, unless I could move my remote compiles over to the Linux box (would be a possibility, except that I don't think NeXT's ld and kin are GNUish). Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 97 13:14:24 Organization: Is a sign of weakness Distribution: world Message-ID: <SHESS.97Feb18131424@howard.one.net> References: <5ecefl$5d1@kwek.omroep.nl> <5ech29$9qj$1@brachio.zrz.TU-Berlin.DE> In-reply-to: marcel@sysyem.de's message of 18 Feb 1997 15:15:21 GMT In article <5ech29$9qj$1@brachio.zrz.TU-Berlin.DE>, marcel@sysyem.de writes: In article <5ecefl$5d1@kwek.omroep.nl>, pim@Intranet.eo.nl (Pim) writes: [other stuff deleted] > The filename is, as far as I know, just part of > a file's inode in most filesystems. This is not the case in UNIX. I-Nodes/Files are nameless. They are referenced by directory entries, which are named. So you can have multiple (hard) links with different names pointing to the same I-Node/File, as well as multiple (soft) links pointing to a certain path-name. Which brings about a good question or two. The directory entry only contains the name of the link, plus the inode for it. The inode contains the permissions, ownerships, and timestamps. Would a created timestamp refer to the contents of the file or the link? Would the type/creator refer to the contents of the file or the link? Actually, I think you could make arguments either way. [And I could make arguments against either way :-).] Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: enigma <llay@ucsd.edu> Newsgroups: comp.sys.next.programmer Subject: Re: cc++ question Date: Wed, 19 Feb 1997 03:33:52 -0800 Organization: University of California, San Diego Message-ID: <Pine.GSO.3.94.970219032906.11403A-100000@ieng9.ucsd.edu> References: <E5nw3F.GD@xombi.wizard.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII To: recurve@resourceful.com In-Reply-To: <E5nw3F.GD@xombi.wizard.net> On Sat, 15 Feb 1997 recurve@resourceful.com wrote: > I'm trying to compile what should be a simple C++ program on NeXTStep 3.2 > > xombi.wizard.net> cc++ main.cc > main.cc:86: warning: return type for `main' changed to integer type > ld: Undefined symbols: > endl(ostream &) > _cerr > ostream::operator<<(const char *) > ostream::operator<<(ostream &(*)(ostream &)) > _cout > ostream::operator<<(int) > ostream::operator<<(char) > xombi.wizard.net> > > Why is the linker having a problem? I've had the same problem with you when I tried to compile a simple C++ program on NS 3.2. a couple of people suggested using the -lg++ option. However, I've also tried that (if I recall correctly)--somehow it results in the same errors... Perhaps you should try that on your system as well--just in case I made some stupid mistakes... I've since upgraded my system to 4.1, and somehow the errors just magically disappeared... Good luck. Lucas
From: btgsch@rmplc.co.uk (I. T. Manager) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Tue, 18 Feb 1997 20:54:39 +0000 Organization: Bishop Thomas Grant Message-ID: <AF2FC78F96683B00@rm-dynf1-150.rmplc.co.uk> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> In article <Yn2TGaa00iWk05nxw0@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & >Unix: File S.. by Jerome Chan@apk.net >> > Sorry, but you're wrong. Macs do not integrate very well with with >> > heterogenous network fileservers, because their executables won't be >> > runnable when stored on an NFS fileserver (or a NT fileserver, or a >> > Novell fileserver, etc). >> >> That's not true. An NT Fileserver has AppleShare services. I can (and do >> store) my files on a winNT3.51 fileserver. I've also encountered Novell >> Fileservers which simply appear to the user as AppleShare Servers when I >> was at Case Western Reserve University. I can store these files on a >> Novell fileserver and run them without any problems. > >Questions: > >1) Can you run a Mac executable directly off of the remote fileservers >without moving locally? > >2) Does that functionality come with the base installation of the OS, or >do you have to pay for that additional functionality? I know that >commercial packages exist which will let you do reasonably complete >AppleShare capabilities from a lot of different systems, but that means >that things don't work out-of-the-box. Yes for both Netware 3.12 on, and NT server to both questions. > -- 'ric
From: macintsh@bu.edu (John Siracusa) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: New Information Date: 20 Feb 1997 04:13:54 GMT Organization: Boston University Message-ID: <5egj22$sfr@news.bu.edu> References: <5e55u8$7td@news.bu.edu> <5eacjo$f6o@news.next.com> Mark Bessey (MaRK_BeSSeY@NeXT.CoM) wrote: : John Siracusa writes : > From MacWeek: : > : > Sources in the boiler room report that Rhapsody will weigh in at about : > 110 Mbytes of pure chewing satisfaction and come with three levels of : > Install: EZ, Minimal and Custom. : Wow. I wonder how the folks at MacWeek know how much disk space Rhapsody : is going to use, when it hasn't even been built yet? Notice the word "about." MacWeek is usually pretty good with their "guesses" I'd expect it to be a bit bigger with the Unix tree installed. And then there's swap space, of course. Interestingly, an Apple employee wrote a letter to Wired magazine (appears in the new issue) on an unrelated topic and mentioned that he was writing the letter as bits of code were sent from his Mac in Tokyo to Cupertino. His parenthetical comment was "Mac OS 8 alive and well, thank you very much." Makes you wonder 1. if the letter written back before Copland was canceled, and 2. what the heck Apple programmers are doing in Toyko... -----------------+---------------------------------------- John Siracusa | If you only have a hammer, you tend to macintsh@bu.edu | see every problem as a nail. -- Maslow
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 20 Feb 1997 11:20:29 +1100 Organization: Unisys Message-ID: <330B98CD.1135@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <330A4383.339A@acm.org> <Mn2eGj200iWXQJ_9lV@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.programmer: 19-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > > For example, any read to a file is essentially a concurrency problem... > > your process will probably suspend until the required data is read > > from disk. > > That depends entirely upon how the process wants to read the file. The > process can decide to perform non-blocking I/O file with the O_NDELAY or > O_NONBLOCK flags to open(), or via select() on a set of open file > descriptors. Correct. There are many different ways to handle IO. Blocking vs non-blocking is one of them. But this doesn't have much to do with this thread. You haven't told me anything I don't know or haven't used many times in the last 20 years. > > Many calls to an OS can be seen this way, as you > > might have to suspend until the requested resource becomes > > available. The general principle here is that the OS should do > > its utmost to satisfy the request, as should any call to any routine. > > The general principle is that the OS should attempt to maximize > throughput by minimizing the number of resources held simultaneously by > any process. The reason why processes may block waiting on a resource > to become available is to allow the CPU (which itself is a crucial > system resource) to be used by other processes until the current process > can make progress. > > You want to avoid deadlock as best you can, and doing so involves trying > to make critical sections as small as possible, as well as trying to > avoid resource contention as far as the properties of resources allow. > You again haven't told me anything I don't know, but you have not addressed the point either. You are retreating into general principles, without much to say. What I am suggesting actually follows from those principles, and enforces those principles, exactly things like keeping critical sections as small as possible. Your general tone of writing suggests you think I don't know anything about these things. If you can show where what I have suggested breaks the principles, then I can revise or throw away. But there is no revision or throwing away that can be done in the face of abuse. > [ ... ] > > Perhaps I did not explain this very well in the first place, but I > > hope that makes it clearer to Charles. I am also not saying this > > to defend MacOS or criticise NeXT. However, some of the weaknesses > > of Unix should be understood, and the fact that Unix is not > > in many respects the perfect OS. > > I've never said Unix was the perfect OS-- but I haven't found a better > alternative so far, either. Good, but my exact point is that there is still much progress to be made in the OS area. And certainly if you talk to real users of computers, they find other non-Unix solutions better alternatives. Unix hasn't conquered the world exactly because its proponents have thought it was intrinsically good and other systems intrinsically bad. And this attitude meant that they never really addressed what was really wanted in a computer system. Mind you Apple has to some extent suffered from the same mentality, even though Mac was for many years superior (and still in some ways is), they did not really get out there and talk to corporate customers. Gates did! > > Neither does it handle memory sharing and resource synchronisation at a > > very high level, > > Not at the operating system level, no. > > That's why people write software layers on top of the OS, such as > OPENSTEP, which provide higher level abstractions which use the more > primitive functionality provided by the OS. And that's where those > high-level abstractions belong-- not in the kernel.... Right, but as far as an application is concerned that is the OS. > > and why it has not swept aside all those "horrible mainframe" OSs is > > due to the fact that it does not have very good server capabilities > > such as TP monitors, apart from Tuxedo. > > Your typical Unix workstation is an entirely different class of machine > from a mainframe-- the former is often running a GUI for a user on > console, whereas the latter was designed to provide tremendous I/O > bandwidth and was intended less for interactive use and more for > transaction processing. That is a dangerous place for Unix to be. And I hope Apple realises it. As I said they can use the good parts like the Mach Kernel to solve their problems (although for public domain software like Mach, they needn't pay $400M.) The problem facing Unix is it is being squeezed from both sides. Systems like NT are coming up from the bottom (although I think NT is too overblown for most PC uses). And it is being squeezed from the top, because the previous mainframe (for want of a better word) systems provide this functionality much better than Unix. On the other hand, functionality that has only been on high end machines is now rightfully being found on low end machines. And that is the very essence of what I am suggesting in saying that OSs must take more responsibility for handling resource problems. It is this kind of lesson that we can learn from the study of all kinds of OSs. > But the age of "big iron" is mostly over, and even the mainframe's hold > on it's traditional strength of large scale server applications is > eroding in the face of fast, cheap workstations and distributed > computing systems. Well, this sounds like you have been reading too many newspapers and magazines. The server market is currently exploding, and there are more companies that want to run large networks. What is over is the days of expensive, overpriced computing. In a distributed environment what do you think is providing the most powerful nodes? So as such systems can now be built for quite cheap, Unix faces another threat. Companies don't choose computer systems because of a nice warm feeling, or they have a religious sense that it must be Unix because that is good for people. They buy on a price/functionality equation. Saying "big iron" is mostly over is now a statement that has outlived itself by about ten years. The "big iron" that is being sold today is different from ten years ago. It still has room to improve, but it certainly is not static. Even the largest A Series CPUs are now single chip machines (And the smallest A Series have been single chip for years, but now they are zero chip! (And that doesn't mean they are not selling.)) But then from Charles' arguments he is one of those people that believes that Unix is good, and those dirty old mainframes are "proprietary," "legacy," "communistic," and all those other labels that are generally stuck on them in order to prove some misguided point before we actually think. Computers and OSs are just technical artefacts. We should judge them technically, not with the vigour of over-emotional, fundamentalist beliefs. ------------------------------------------------------------------------ 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: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 22:26:08 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <0n2wFEC00iWn0CXEk0@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> <330A2E07.563D@ix.netcom.com> <Un2duCC00iWX0J_7NE@andrew.cmu.edu> <Mike.Connally-ya023680001902972340040001@news.dial.pipex.com> In-Reply-To: <Mike.Connally-ya023680001902972340040001@news.dial.pipex.com> Excerpts from netnews.comp.sys.next.programmer: 19-Feb-97 Re: Mac/NeXT & Unix: File S.. by Mike Connally@dial.pipex > > Okay, thanks for the correction. Even so, the point still applies to > > just NFS servers, which is more relevent for me.... > > No it doesn't. With NFS client software, Macs can use any > file (data or executable) resident on any NFS server. But that NFS client software doesn't come with MacOS, now does it? It's a seperate commercial product.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: mxcs@cris.com (Mark Carmichael) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten Subject: Aliens among our Computers (was <...> IS NOT a microkernel!!!!!) Date: Wed, 19 Feb 1997 10:16:40 -0800 Organization: Seventh Church of Rodney Message-ID: <mxcs-ya02408000R1902971016400001@news.cris.com> References: <5ef4nd$qut@qnx.com> <AF30771C-22DC6@198.68.42.217> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <AF30771C-22DC6@198.68.42.217>, "Lawson English" <english@primenet.com> wrote: > >Since the aliens in ID4 had DOS its wouldn't be a wonder if Apple >looked to the stars for their salvation. Nah. They had Windows. Bill Gates was the last survivor of the Roswell Crash, waiting for rescue and trying to sabatoge the Macintosh Way while he [....] Nefariously seeding technical newsgroups with psycho-viral crosspostings *that we cannont resist responding to* is also part of their evil plan. All of this Borg stuff reminds me of my personal vision of the climatic ending of "Terminator IX", wherein the latest Machine representative is tricked into entering DOS compatibility mode using logic (by an aged William Shatner, in a cameo appearance). -- Mark Carmichael "My phone bill, my opinions."
From: mcgredo@crl.com (Donald R. McGregor) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 10:21:36 -0800 Organization: Miskatonic University Department of Classics Message-ID: <5efgbg$69d@crl.crl.com> References: <5ddp66$jpc@news.bu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jk-1802972144030001@ip-salem2-01.teleport.com> In article <jk-1802972144030001@ip-salem2-01.teleport.com>, Joel Klecker <jk@esperance.com> wrote: >In article <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu>, Charles William Swiger ><cs4w+@andrew.cmu.edu> wrote: > >>However, I can't NFS mount a remote fileserver on a Mac and be able to >>run Mac executables, because they require the out-of-band information >>stored in their resource forks which is not representable within the >>standard NFS/UFS filesystem paradigms. > >Doesn't the lame wrapper approach cause "problems" equal to >that(AppleDouble certainly causes only as many problems as "wrappers")? No. Wrappers are just directories that are handled a special way on the client side by the workspace. -- Don McGregor | "Let us hope that it is not true; but if it is, let mcgredo@crl.com | us pray that it does not become widely known."
From: stanj@cs.stanford.edu (Stan Jirman) Newsgroups: comp.sys.next.programmer Subject: NS4.1: scrollers disappear when window deminiaturized Date: 20 Feb 1997 12:14:00 GMT Organization: Stanford University Message-ID: <5ehf68$c90@nntp.Stanford.EDU> Hi, when I miniaturize a window which has a NSScrollView as its content view, the scroll view is not displayed when I deminiaturize the window. The contents of the ScrollView display just fine, but there are no scroll bars nor arrows. Also, the window frame (with resizing bar at the bottom) doesn't show. Anyone had the same problem? Any solutions? Thanks, - Stan --- Nature photography: http://www-leland.stanford.edu/~stanj NeXTmail and MIME: stanj@cs.stanford.edu
From: jeffh@dnai.com (Jeff Hoekman) Newsgroups: comp.sys.next.programmer Subject: need animation/DPSTimedEntry help Date: Thu, 20 Feb 1997 15:23:57 -0800 Organization: DNAI ( Direct Network Access ) Message-ID: <jeffh-2002971523580001@dnai-207-33-180-197.dialup.dnai.com> I'm getting a flicker in my animation, and I think it's because I'm calling the following three lines to erase/clear my background before drawing: PSsetgray(NX_WHITE); NXRectFill(&r); PSsetgray(NX_BLACK); Is there a better way to 'clear' my drawing surface? After 'clearing' my background, I'm calling this pswrap repeatedly in a loop: defineps lineshow(float x1; float y1; float x2; float y2; float graylevel) graylevel setgray x1 y1 moveto x2 y2 lineto stroke flushgraphics endps This is all for a single frame in the animation. I'm also calling NXPing() after this, but don't know if the call to flushgraphics is necessary. If anyone has or can point me to some programming examples which do this kind of stuff I'd really appreciate them, as well as any help and suggestions about the problems mentioned above. Thank you, Jeff P.S. Please reply via email --thanks alot.
From: jeffh@dnai.com (Jeff Hoekman) Newsgroups: comp.sys.next.programmer Subject: need animation/DPSTimedEntry help Date: Thu, 20 Feb 1997 15:25:49 -0800 Organization: DNAI ( Direct Network Access ) Message-ID: <jeffh-2002971525490001@dnai-207-33-180-197.dialup.dnai.com> I'm getting a flicker in my animation, and I think it's because I'm calling the following three lines to erase/clear my background before drawing: PSsetgray(NX_WHITE); NXRectFill(&r); PSsetgray(NX_BLACK); Is there a better way to 'clear' my drawing surface? After 'clearing' my background, I'm calling this pswrap repeatedly in a loop: defineps lineshow(float x1; float y1; float x2; float y2; float graylevel) graylevel setgray x1 y1 moveto x2 y2 lineto stroke flushgraphics endps This is all for a single frame in the animation. I'm also calling NXPing() after this, but don't know if the call to flushgraphics is necessary. If anyone has or can point me to some programming examples which do this kind of stuff I'd really appreciate them, as well as any help and suggestions about the problems mentioned above. Thank you, Jeff P.S. Please reply via email --thanks alot.
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 13:18:18 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5efg5a$p2e@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <peterm.856338363@ulfrun> In article <peterm.856338363@ulfrun>, peterm@dna.lth.se (Peter Moller) wrote: > And another one: what happends if you move or rename an application in NeXTOS? > Can I still double-click my document and have the correct application launch? Yes, unless you move the application outside one of the folders that the Workspace searches at login time. If you do that, the Workspace will be unable to find the application in order to query it about what document types it can open. (Though the application itself will still run.) Of course, making links to the application instead of physically moving it will still allow it to work. > On my Mac I can rename and move an application and the > desktop database finds it immediately when I open a document. Even the aliases > (soft links) survive. Rhapsody better keep this behaviour or a lot of Mac > users will be angry and encounter problems. I dunno. Rhapsody is just a different paradigm. With its filesystem structure based on directories instead of hard drives, I don't really see much reason why you should ever want or need to move an application outside of its original folder (unless it's into a subfolder you made for organizational purposes, in which case the Workspace will still find it). -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 11:45:15 -0800 Organization: Electronics Service Unit No. 16 Sender: mpaque@mpaque Distribution: world Message-ID: <5efl8b$tv@mpaque.mpaque> References: <5e0ev6$qje@news.bu.edu> In article <5e0ev6$qje@news.bu.edu> macintsh@bu.edu (John Siracusa) writes: > The only remaining reservation I have is > about the whole process of installing apps and then moving them after > they're installed. Is there any possibility of paths getting messed > up? Not really. First, the OPENSTEP API provides mechanisms for applications to ask for application (or bundle, or framework) resources by name and/or type, and takes care of fishing about in the app wrapper to find the right bits, including looking at language preferences the user has selected and what languages are supported by the app. Second, when the user sees an app through the GUI, it's just an icon that can be dragged about. The relationships of the files within the wrapper are unaffected. -- I don't speak for my employer, whoever it is, and they don't speak for me. mpaque@next.com Official business only NeXT Mail OK mpaque@wco.com Non-business or personal mail NeXT mail OK
From: nurban@csugrad.cs.vt.edu (Nathan M. Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 1997 13:23:12 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5efgeg$p9s@csugrad.cs.vt.edu> References: <5ddp66$jpc@news.bu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <wharris-ya023080001702970658310001@news.iadfw.net> <5eepmi$r6e@horus.ecmwf.int> In article <5eepmi$r6e@horus.ecmwf.int>, syy@ecmwf.int (Mike Connally) wrote: > There's a tendency in the NeXT community not to grok the utility > of MacOS features like file type & creator codes, Macintosh Easy > Open, and full drag-and-drop capability. There's a tendency in the Mac community to be unaware that NEXTSTEP _has_ features like drag-and-drop of documents onto apps, and that furthermore, many of the NEXTSTEP community are aware of the Mac features yet do not prefer them. (I, for example, am aware of the Mac open-by-creator process, yet do not prefer to 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 Subject: Re: Mac/NeXT & Unix: New Information Date: 19 Feb 1997 13:25:54 -0500 Organization: Virginia Polytechnic Institute and State University Message-ID: <5efgji$pbg@csugrad.cs.vt.edu> References: <5e55u8$7td@news.bu.edu> <5e5hpc$isr@csugrad.cs.vt.edu> <E5ur81.5n@icgned.nl> In article <E5ur81.5n@icgned.nl>, Hans Mulder <hansm@icgned.nl> wrote: > nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: > >In article <5e55u8$7td@news.bu.edu>, macintsh@bu.edu (John Siracusa) wrote: > > [mention of the possibility that Rhapsody installs might make > > Terminal.app optional] > >Boy, would that be a mistake. Better to install it (possibly in some > >out-of-the-way place that you'd never notice) and just not use it. > Why not install it in the usual place and make it hidden? Sure, that could work. In an emergency, the support guy could say, "Okay, go into Preferences, select `Unhide Unix', run this application and type in these commands. Your system will work again." -- Nathan Urban | nurban@vt.edu | Undergrad {CS,Physics,Math} | Virginia Tech
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 20 Feb 1997 09:33:09 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <An362Z_00iWm02vQI0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> In-Reply-To: <330B98CD.1135@acm.org> Excerpts from netnews.comp.sys.next.programmer: 20-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >>> For example, any read to a file is essentially a concurrency problem... >>> your process will probably suspend until the required data is read >>> from disk. >> >> That depends entirely upon how the process wants to read the file. The >> process can decide to perform non-blocking I/O file with the O_NDELAY or >> O_NONBLOCK flags to open(), or via select() on a set of open file >> descriptors. > > Correct. There are many different ways to handle IO. Blocking vs > non-blocking is one of them. If you understand the difference, why did you claim that "your process would probably suspend..." when a process using non-blocking I/O will not suspend? Contradiction detected. [ ... ] >>> Many calls to an OS can be seen this way, as you >>> might have to suspend until the requested resource becomes >>> available. The general principle here is that the OS should do >>> its utmost to satisfy the request, as should any call to any routine. >> >> The general principle is that the OS should attempt to maximize >> throughput by minimizing the number of resources held simultaneously by >> any process. The reason why processes may block waiting on a resource >> to become available is to allow the CPU (which itself is a crucial >> system resource) to be used by other processes until the current process >> can make progress. >> >> You want to avoid deadlock as best you can, and doing so involves trying >> to make critical sections as small as possible, as well as trying to >> avoid resource contention as far as the properties of resources allow. > > You again haven't told me anything I don't know, but you have not > addressed the point either. You are retreating into general principles, > without much to say. You were the one to first bring up the phrase "general principle", Ian. Go read your words quoted above by ">>>". [ ... ] >> I've never said Unix was the perfect OS-- but I haven't found a better > > alternative so far, either. > > Good, but my exact point is that there is still much progress to be made > in the OS area. And certainly if you talk to real users of computers, > they find other non-Unix solutions better alternatives. According to what you've said, if I find Unix a better solution for some task, then I can't be a "real user of computers"? What nonsense.... [ ... ] >>> Neither does it handle memory sharing and resource synchronisation at a >>> very high level, >> >> Not at the operating system level, no. >> >> That's why people write software layers on top of the OS, such as >> OPENSTEP, which provide higher level abstractions which use the more >> primitive functionality provided by the OS. And that's where those >> high-level abstractions belong-- not in the kernel.... > > Right, but as far as an application is concerned that is the OS. You have one of the most bizzare viewpoints I've ever seen. OPENSTEP is not an operating system; it's an software layer that provides an abstraction _away_ from the specific OS that the application runs on, so that the app can do useful things without having to be written using non-portable, operating-system-specific functionality. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 06:44:28 -0800 Organization: Esperance Communications Message-ID: <jk-2002970644290001@ip-salem1-01.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jk-1802972144030001@ip-salem2-01.teleport.com> <5efgbg$69d@crl.crl.com> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <5efgbg$69d@crl.crl.com>, mcgredo@crl.com (Donald R. McGregor) wrote: >>>stored in their resource forks which is not representable within the >>>standard NFS/UFS filesystem paradigms. >> >>Doesn't the lame wrapper approach cause "problems" equal to >>that(AppleDouble certainly causes only as many problems as "wrappers")? > >No. Wrappers are just directories that are handled a special way >on the client side by the workspace. AppleDouble is two files (which is also "...representable within the standard NFS/UFS filesystem paradigms"), how is that different? -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
Message-ID: <330C6508.2A27@iphysiol.unil.ch.spam> Date: Thu, 20 Feb 1997 15:51:52 +0100 From: Sean Hill <shill@iphysiol.unil.ch> Organization: Knowledge Management Unit/ INFORGE MIME-Version: 1.0 Newsgroups: comp.sys.next.programmer Subject: Instance drawing on OpenStep Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I've been trying to do some instance drawing on OpenStep for windows. I remember having code to do this years and years ago, but can't find it now. I would like to draw a box with dashed lines where the mouse moves during a mouse down. However, when I try it the line is always a single solid line and the inside of the box is always opaque. I've setalpha(0) and I'm only drawing the lines themselves but still it is solid white inside. I tried adding some code to do a PSnewinstance as a NSPeriodic event and that works better but still looks crappy. Is instance drawing actually useful for anything? Should I use compositing instead? Thanks for any sample code and ideas. Sean shill@iphysiol.unil.ch
From: mattera@ssga.ssb.com (Luigi Mattera) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: New Information Followup-To: comp.sys.next.programmer,comp.sys.mac.system Date: 20 Feb 1997 14:51:18 GMT Organization: State Street Message-ID: <5ehod6$5rj@svna0001.clipper.ssb.com> References: <5e55u8$7td@news.bu.edu> <5eacjo$f6o@news.next.com> <5egj22$sfr@news.bu.edu> John Siracusa (macintsh@bu.edu) wrote: : Notice the word "about." MacWeek is usually pretty good with : their "guesses" I'd expect it to be a bit bigger with the Unix : tree installed. And then there's swap space, of course. Bigger? Wouldn't they be smart and just move stuff around? Or are they actually going to have separate Mac and Unix applications? : Interestingly, an Apple employee wrote a letter to Wired magazine : (appears in the new issue) on an unrelated topic and mentioned : that he was writing the letter as bits of code were sent from his : Mac in Tokyo to Cupertino. His parenthetical comment was "Mac OS : 8 alive and well, thank you very much." : Makes you wonder 1. if the letter written back before Copland was : canceled, and 2. what the heck Apple programmers are doing in Toyko... Tokyo? They could be writing the Japanese localization for the Mac OS. (it does exist, you know) Besides which, with a direct T1 line it doesn't matter where on the planet you are located these days.
From: "Jonathan W. Hendry" <jon@subsequent.com> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 18 Feb 1997 18:03:01 -0500 Organization: By Displacement in Metric Tonnes. Message-ID: <330A3525.1077@subsequent.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <avirr-1802971155110001@avi.starnine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Avi Rappoport wrote: > > It sounds like a useful solution would be for Apple to implement an Error > Manager that could be called from applications. That addresses the issue > of the application writers not wanting to reinvent the (error) wheel and > get the interface and functionality to be consistent. And if designed > correctly, the manager could take advantage of OS improvements in the > future and applications would automatically get those improvements. An exception-handling class library would be better, but the result would be the same. -- jon@steeldriving.com
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 20 Feb 1997 10:11:31 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <kn36aXu00iWm02vRk0@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> <8n2mO2O00iWl05_J00@andrew.cmu.edu> <330B8D60.74C1@acm.org> In-Reply-To: <330B8D60.74C1@acm.org> Excerpts from netnews.comp.sys.next.programmer: 20-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >>>> Blocking a process because the kernel is waiting for an operator to tell >>>> it how to proceed when some form of error occurs is the opposite of >>>> robust! You can easily deadlock every runnable process if some crucial >>>> system resource like inetd (*), named, lookupd, or the swapper >>>> encounters a minor problem and must block until a human informs the OS >>>> of what to do when that error condition could otherwise be handled >>>> within the process. >>> >>> You are not only not reading correctly what I am saying, but in your >>> misreadings are quite wrong. >> >> How am I misreading what you've said? > > Most of your responses show little understanding of what I have said, > before you go into ultra defensive mode of Unix. You didn't answer the question; you simply rephrased what you previously said as quoted by ">>>". If you aren't going to provide a specific example of how I've misread your comments, fine-- go right ahead and continue dodging the question. >> What is wrong with my statements? > > Your statements about both robustness and deadlock are wrong. Robustness > is if an application calls a service, it expects the service to perform > that function. If the service does not take responsibility to handle common > error conditions, but just return an exception to the caller, that is > the opposite of robust. If the service needs some operator input to help > solve the situation then ask for it, don't just return an error to the > application, because due to security it may not be able to access the > system resources in the same way as the OS or operator. If the OS itself blocks the process which asked for some service and waits for the user to tell it what to do when an error occurs, then neither the process being blocked nor any other process which depend on that blocked process to make progress will be able to do anything. If any of these blocked processes is supposed to perform the action of asking for user intervention and returning the user's response, the system will be deadlocked. > Your comments about deadlock also show lack of understanding. If a > system resource becomes unavailable to all processes, then everything is > going to lock up. That's correct. How do you get from this statement to my supposed "lack of understanding"? > You are defending the position that all these processes > should be returned an error, when they have no control over the > resource. Correct. Processes do not have "control" over system resources; what is what the operating system is for. The OS manages system resources by implementing serialization mechanisms for non-preemptible resources like tty's, printers, the network, disk I/O to individual files, and so forth, and by implementing means of preempting resources like the CPU which can be preempted (otherwise known as preemptive multitasking). > This is also the opposite of robust. The case of deadlock may require > some human intervention to prevent reoccurrence anyway, but what we > are talking about here is not even a case of deadlock. Having the OS attempt to ask a user what to do when errors occur most certainly can lead to deadlock. I can demonstrate examples of interdependent processes on real-world operating systems which would satisfy the four necessary conditions for deadlock. For example, let's consider NEXTSTEP's WindowServer. Say the WindowServer tries to blit a bunch of bits via a DMA transfer handled by a video driver within the kernel, and the DMA transfer encounters an error. If the OS blocks the WindowServer due to the error and then tries to tell the user an error occured and ask what to do about it by having the WindowServer attempt to pop up an alert panel, the system is going to deadlock because the WindowServer is already blocked trying to draw and will never get unblocked in order to draw that alert panel. Therefore, the system is deadlocked. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 07:50:41 -0800 Organization: Esperance Communications Message-ID: <jk-2002970750410001@ip-salem1-01.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> <330A2E07.563D@ix.netcom.com> <Un2duCC00iWX0J_7NE@andrew.cmu.edu> <Mike.Connally-ya023680001902972340040001@news.dial.pipex.com> <0n2wFEC00iWn0CXEk0@andrew.cmu.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <0n2wFEC00iWn0CXEk0@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >But that NFS client software doesn't come with MacOS, now does it? >It's a seperate commercial product.... Very few Mac users need an NFS client. -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
From: "Nicolas Droux" <droux@nmia.com> Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs Subject: Re: OPENSTEP/MACH 4.1 -- printf %g still broken Date: 20 Feb 1997 15:21:47 GMT Organization: New Mexico Internet Access Message-ID: <01bc1f41$4bafa9b0$c6a63bc6@hyperion> References: <5ecoph$74i@tribune.usask.ca> eric@skatter.USask.Ca wrote in article <5ecoph$74i@tribune.usask.ca>... > eric@pisces 225> cc -o printfcheck printfcheck.c > eric@pisces 226> ./printfcheck > Expect 0.00123: 0.001 > Expect 123: 123.457 > Expect 123.5: 123.4567 > Expect 1e+03: 999.6 > eric@pisces 227> > > ================================================================== > > Yes! It's still not fixed! Seven years and three months since I first reported > it (way back in the NextStep 1.0 days). I even have the NeXT bug tracking > reference numbers [60697, 98369] and an e-mail message from NeXT (September 1994) > indicating that, ``it looks like it will finally be fixed in NEXTSTEP release > 4.0.'' > > I wonder if this has any chance of being fixed before OpenStep mutates into > Rhapsody? Just checked under OPENSTEP NT 4.1, and here's what I got... hyperion[24] openstep/printftest > gcc -o PrintfTest PrintfTest.c hyperion[25] openstep/printftest > PrintfTest.exe Expect 0.00123: 0.00123 Expect 123: 123 Expect 123.5: 123.5 Expect 1e+03: 1e+003 hyperion[26] openstep/printftest > -- Nicolas Droux http://www.cs.unm.edu/~droux
From: "Jeff A. Harrell" <jeff@dmpl.com> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 19 Feb 1997 18:17:12 -0600 Organization: Digital Media Performance Labs Message-ID: <330B9808.ABD@dmpl.com> References: <5d8qta$6np@news.bu.edu> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <330A4383.339A@acm.org> <Mn2eGj200iWXQJ_9lV@andrew.cmu.edu> <tsikesE5uz8v.AGu@netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Terry Sikes <tsikes@netcom.com> Terry Sikes wrote: > In article <Mn2eGj200iWXQJ_9lV@andrew.cmu.edu>, > Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > >Your typical Unix workstation is an entirely different class of machine > >from a mainframe-- the former is often running a GUI for a user on > >console, whereas the latter was designed to provide tremendous I/O > >bandwidth and was intended less for interactive use and more for > >transaction processing. > > > >But the age of "big iron" is mostly over, and even the mainframe's hold > >on it's traditional strength of large scale server applications is > >eroding in the face of fast, cheap workstations and distributed > >computing systems. > > > >-Chuck > > Also check out Sun's new line of mainframe class machines. Extremely > high I/O performance, up to 64 CPUs and Solaris - pointed directly at > the big iron buyers. Just to play the devil's advocate, Sun's UE10K is a direct competitor to Silicon Graphic's Origin 2000 / Cray Origin 2000 series. (To the extent that both systems are based, to one degree or another, on Cray's crossbar architecture.) The SGI Origin product line uses the same OS, GUI or command-line, as the rest of the SGI family. IRIX 6.4 runs on the two- to four-processor Origin 200, the four- to 128-processor Origin 2000, the Onyx2 visualization supercomputer, and the Octane desktop workstation. (A slightly different version runs on O2.) Rumor is that by summer there will be an all-platform release of IRIX 6.4 that runs on everything from Indy to Cray Origin 2000. So, from a user's perspective, there's really very little difference between desktop and supercomputer. -- Jeff Harrell, Systems Engineer Digital Media Performance Labs, Inc. http://www.dmpl.com http://jeff.dmpl.com
Newsgroups: comp.sys.next.programmer Subject: Re: need animation/DPSTimedEntry help Message-ID: <330C9349.2F54@running-start.com> From: Ralph Zazula <zazula@running-start.com> Date: Thu, 20 Feb 1997 10:09:13 -0800 References: <jeffh-2002971525490001@dnai-207-33-180-197.dialup.dnai.com> Organization: Running Start, Inc. MIME-Version: 1.0 To: Jeff Hoekman <jeffh@dnai.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - You might want to try disabling screen updating while you do your drawing. This may be the cause of the flicker. Here's what I typically do (in my View drawing code): /* disable screen updating */ [[self window] disableFlushWindow]; /* do a bunch of drawing to the backing store */ /* update the on-screen window with my new drawing [[[self window] reenableFlushWindow] flushWindow]; See the Window docs for more info. Ralph -- Ralph Zazula Running Start, Inc. zazula@running-start.com 520/760-4890 (4891 FAX) http://www.running-start.com Jeff Hoekman wrote: > > I'm getting a flicker in my animation, and I think it's because I'm > calling the following three lines to erase/clear my background before > drawing: > > PSsetgray(NX_WHITE); > NXRectFill(&r); > PSsetgray(NX_BLACK); > > Is there a better way to 'clear' my drawing surface? > > After 'clearing' my background, I'm calling this pswrap repeatedly in a loop: > > defineps lineshow(float x1; float y1; float x2; float y2; float graylevel) > graylevel setgray > x1 y1 moveto > x2 y2 lineto > stroke > flushgraphics > endps > > This is all for a single frame in the animation. I'm also calling > NXPing() after this, but don't know if the call to flushgraphics is > necessary. > > If anyone has or can point me to some programming examples which do this > kind of stuff I'd really appreciate them, as well as any help and > suggestions about the problems mentioned above. > > Thank you, > Jeff > > P.S. Please reply via email --thanks alot.
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 10:09:23 -0500 Organization: phenix@interpath.com Message-ID: <19970220100923348851@roxboro-169.interpath.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: ] Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & ] Unix: File S.. by John Moreno@interpath.co ] > ] Perhaps it's just me, but I don't see much value to preserving the ] > ] timestamp of the creation date of the original version of a file ] > ] when you don't actually have the original file-- just the modified ] > ] version. Can you provide a real-world example of why you'd care ] > ] about that timestamp? ] > ] > A very simple and quit answer is when you have two files with ] > basically the same information and have modified both since their ] > creation and want to know which file is newer. ] ] The answer is whichever file was modified last, and can be answered ] using the last-modified timestamp; the creation timestamp isn't ] needed. ] ] Again, that doesn't answer my question. My point was there but I apparently didn't make it clear enough: You are doing some ad hoc data acquisition and analysis - you do your first test and save it, then you do your second test and save it. You play with both of them a bit and then go home, where you come down with pneumonia and are out of the office for two weeks. When you come back to the office you can remember which test you did first but not what you named the file. That one's a bit of a stretch tho, so how about this - you have a program that automatically saves (thereby changing the modification date) whenever the file is even viewed. ] [ ... ] ] >] Such a system could rely on just the file extension if the Mac-like ] >] creator/filetype attributes are not available or are not recognized ] >] [consider a file that has been FTP'ed or is being accessed via a ] >] remote filesystem like NFS, AFS, etc], but could also pay attention ] >] to the Mac attributes if they are available and valid. That seems ] >] to combine the desirable features without changing the way either ] >] current Mac users or current NEXTSTEP users like to have things ] >] work.... ] > ] > I've seen this "accessed via a remote filesystem" argument used ] > before and have never really understood it. If the computer at the ] > other end is a Rhapsody machine then I'd expect the additional ] > information to be passed along, if it isn't a R.M. then what kind of ] > file is being accessed where the person getting it doesn't know what ] > it is? ] ] You're missing the point. When I access a file via a remote ] filesystem, I shouldn't need to care whether it's a R.M or not. I ] should be able to use any type of fileserver without having problems, ] and I should be able to run executables directly off of the ] fileserver. ] ] Come to think of it, perhaps Apple will provide this functionality by ] making Rhapsody's system loader understand the AppleDouble format ] directly as an executable format. It's rather similar to the way ] NEXTSTEP handles the Mach-O and MAB (FAT binary) executable ] formats.... I'd think you'd want to use the AppleSingle format, but other that, yeah. What's really important isn't the format of the file, but that the part of the system that transfers files over the network knows about it, and that all of the information is there. About a week ago Jonathan Hendry posted saying that "it would be difficult (if not impossible) to run a Macintosh application that is stored on a non-HFS disk". This sounds plausible but, as I said in my reply to him, since all of the information associated with a file is transfered to a PC disk when you copy a file back and forth it seems to me that if that was the case it would be a failure of the system since it should be possible. I immediately tested this by inserting a DOS formatted disk into my drive and copying a small application to it and then trying to execute it. It worked flawlessly. There is no reason that the same thing couldn't happen over a network connection and in fact I would expect it to work today over a properly setup network. -- John Moreno
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 20 Feb 97 08:54:28 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb20085428@howard.one.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> In-reply-to: danh@qnx.com's message of 19 Feb 1997 08:11:30 -0500 In article <5eeu62$76s@qnx.com> danh@qnx.com (Dan Hildebrand) writes: In article <SHESS.97Feb18074753@howard.one.net>, Scott Hess <shess@one.net> wrote: >On a system like a NeXTstation, where the CPU, memory, and I/O are >relatively balanced, a monolithic kernel can be easily more >efficient. Easily? Can you back this up? While some monolithic kernels are faster than some microkernels, this is not universally true. I was not asserting that all monolithic kernels are more efficient than all microkernels for any machine. I was asserting that for a given system, a monolithic kernel written with the same close attention to detail and overall design as a microkernel for the same system should be more efficient because it can optimize away many operations. It might just take 30 times as long to write the monolithic kernel version. Unless I've _greatly_ misread a variety of papers, microkernels are coming into their own because we are asking entirely too much of our monolithic kernels. The amount of effort it takes to add something new to your monolithic kernel is often so great that you never get around to it - and thus a microkernel can be more efficient in the end. In essence, using a microkernel lets you get to a better design for the system faster than a monolithic kernel, so it wins in the end. This is similar to the differences between object programming and structured programming. Any given system _can_ be written in either. And if you write a given system using the same design in either, the structured version will generally be more efficient, because it doesn't have the object version's overhead. The fly in the ointment is that the structured version generally will never be written that way, though, because it doesn't help you manage complexity well enough. Object languages win in the end because though they might not be faster for a given design, they let you modify the design more easily. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: Koplien@vnet.IBM.com Newsgroups: comp.sys.next.programmer Subject: Record/Playback with SB16Vibra Date: Thu, 20 Feb 97 08:28:40 Organization: IBM Zurich Research Laboratory Message-ID: <5egufj$15lm@grimsel.zurich.ibm.com> Is anybody able to simultaneously record and playback with this soundcard and the latest driver you will find on www.next.com (V3.33 I believe)? I need it for frequence measurements. Henry
Newsgroups: comp.sys.next.programmer Subject: Re: MouseDown+Drag and SHIFT!! Message-ID: <330C9017.6518@running-start.com> From: Ralph Zazula <zazula@running-start.com> Date: Thu, 20 Feb 1997 09:55:35 -0800 References: <E5qq6F.C1p@x-lan.alienor.fr> Organization: Running Start, Inc. MIME-Version: 1.0 To: fgalot@x-lan.alienor.fr Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - I'm assuming you are talking about the shift between the View coordinates and the coordinates given to you in the event (which are relative to the window). You can convert from Window-relative to View-relative coords with the following call: [self convertPoint:&mouseDownLocation fromView:nil]; Check the docs on View for more details. Ralph -- Ralph Zazula Running Start, Inc. zazula@running-start.com 520/760-4890 (4891 FAX) http://www.running-start.com fgalot@x-lan.alienor.fr wrote: > > My mouseDown looks like: > > mouseDown:theEvent > { > oldMask = [window > addToEventMask:NX_MOUSEDRAGGEDMASK]; > while (shouldLoop) { > newEvent = [NXApp getNextEvent:(NX_MOUSEUPMASK > |NX_MOUSEDRAGGEDMASK|NX_MOUSEEXITEDMASK)] > ; > switch (newEvent->type){ > case NX_MOUSEUP: > {...} > case NX_MOUSEDRAGGED: > { > /*Heavy drawing here*/ > mouseDownLocation = theEvent->location; > /*next I use mouseDownLocation for drawing. But I'd > like to use the real mouse position (cursor position?) > because there is a shift between the real position of the > mouse(cursor) and the point I'm using.*/ > } > }}} >
From: quinlan@sfu.ca (Brian Quinlan) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 20 Feb 1997 18:38:23 GMT Organization: Simon Fraser University Message-ID: <5ei5mv$6g6@morgoth.sfu.ca> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> <Mike.Connally-ya023680001902972331330001@news.dial.pipex.com> I think that Apple should leave the Mac Type/Creater model in place. One problem that I have with my cube is that I work with two different types of files that have a .x extension. One is a type of image file and another is a RPC specification file. They also reside in the same directories (don't ask why). I am stuck with half of my .x files having the wrong default application. Type/Creator would immediately solve this problem. I don't care how they hack it into FFS as I think that they should quickly move towards a database style file system that can store arbitrary attributes anyways. -- 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: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 08:43:53 GMT Organization: Lund University Message-ID: <peterm.856341833@ulfrun> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) writes: >Scott Hess <shess@one.net> wrote: >As far as I recall, there _was_ a limit of about 6k files per volume. That must be a really old figure: I have a HFS-volume with more than 25,000 files on it and there's no problem at all. I think the limit is 32,767 files. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 13:23:36 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5e9m4o$4lr@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <wharris-ya023080001702970658310001@news.iadfw.net> wharris@mail.airmail.net (Billy Harris) wrote: > This behavior is easy to achieve with a creator field, but if I > could only choose a single application for a pict file, I'd go > crazy waiting for the wrong program to open, quitting, locating > the correct program, and dragging the file to the program. This has been said a few times, but I suspect you've missed it. It also seems that some people who haven't used NeXTSTEP don't believe me (or anyone else) when I say this, but: Under NeXTSTEP, it is easy to find all applications that know how to open a given type (such as "pict"). What you list as "locating the correct program, and dragging the file to the program" would generally be done differently under NeXTSTEP. You'd: 1) with the document selected (in this case the PICT file), hit command-3 2) up pops a panel which shows the icon of every application which knows how to open a PICT. Double-click on the icon for the application that you want. I have used NeXTSTEP for five or six years. I have used the Mac for at least eight years (and my main responsibility at RPI is Mac support). I have both a Mac and a NeXTstation at home. I have a Mac and two NeXTSTEP machines in my office at work. I am not ignorant of either system. That said, this issue of "needing" a creator-field just isn't the issue that a Mac user might expect it to be. The NeXTSTEP interface works quite well. I don't feel too strongly about which way that Rhapsody ends up handling this. I'm just saying that based on my own experience of using both operating systems constantly, the NeXTSTEP user interface works quite well. In this area I find it better than the MacOS interface. At the same time, I understand that there is some advantage in having Rhapsody behave a lot like the MacOS does. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Tom Hageman <tom@basil.icce.rug.nl> Newsgroups: comp.sys.next.programmer Subject: Re: [Q]Getting list of windows in Openstep? Date: Wed, 19 Feb 97 21:50:09 +0100 Organization: Warty Wolfs Message-ID: <9702192049.AA10717@basil.icce.rug.nl> Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.1mach v148) In article <856285888.5928@dejanews.com>, you wrote: > Is there any way of getting a list of the visible windows in Openstep, > and then their rectangles? Take a look at the Winfo mini-example from NeXTanswers (#1260) at www.next.com. Hope this helps, -- __/__/__/__/ 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: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.advocacy, comp.sys.mac.advocacy Date: Thu, 20 Feb 1997 14:28:48 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <In3_Lk_00iWQQ8c4hL@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> In-Reply-To: <jk-2002970750410001@ip-salem1-01.teleport.com> Excerpts from netnews.comp.sys.next.programmer: 20-Feb-97 Re: Mac/NeXT & Unix: File S.. by Joel Klecker@esperance.c >> But that NFS client software doesn't come with MacOS, now does it? >> It's a seperate commercial product.... > > Very few Mac users need an NFS client. That's true-- but we've drifted away from the issue of Rhapsody. We've also drifted completely away from programming topics, so I'll try to set followups to .advocacy as per someone's request that I just saw. I think it would be nice for Rhapsody to include NFS client/server software for free like NEXTSTEP does. While it doesn't matter to me personally, I'd also expect that Apple will include their own networking and fileserver protocols (AppleTalk/EtherTalk and AppleShare) so that current Mac users don't need to transition to something else. I think it would be nice to figure out a way of representing out-of-band information currently in Mac resource/data forks in a way that it does not have to archived in the way AppleDouble/AppleSingle formats do now on non-Mac filesystems. The concept of wrappers (ie, directories which are treated by the GUI as though they were an individual file) works pretty well, I think. NeXT's Mach-O format used to store lots of things with an executable that are now stored as seperate files in an .app wrapper (ex, the file icon, help files, .nibs, etc), and the wrapper system works better. However, I'd still survive even if Apple decided to keep a filesystem more like the HFS than the Berkeley FFS with forks, seperate creator and file type information, the creation timestamp, and everything else that's been discussed/argued. I'd prefer something better, but Apple has to compromise between backwards compatibility, time required to change NeXT's technology, and their future goals for Rhapsody-- and the lord only knows what will be the results.... :-) -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 20 Feb 1997 20:52:24 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5eidi8$9nt@news3.digex.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <jcr.856421720@idiom.com> jcr@idiom.com (John C. Randolph) wrote: > John Kheit <jkheit@cnj.digex.net> writes: > [munch] > >things monolithic for perfromance reasons. Yet the functionality > >of a monolithic kernel is not reduced by its monolithicness. > Good God, John! Please please, just 'John' will be fine. :) > You're going to be a Lawyer! You should know that the correct > word isn't"Monolithicness", it's "monolithicity!" Actually, neither show up in websters. > "Monolithicness", actually spelled "monoliTHICKness," is a > different word altogether, meaning: "The smallest dimension of > that thing in Kubric's movie, 2001," or: "The mental state of > believing that statically linking everything is Just Fine." Now I see how L. Ron. Hubbard became god :) > Yours for a more erudite, and sesquipedalian c.s.n.a, Mine for a more plain spoken, blunt, and effective communication, sans perwinkle obfuscation of content, or pedantic clutching to semantics. :) -- Thanks, be well, take care, later, John Kheit; Self expressed... 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 | Ja tallar ente svenska )^> %^) =^)
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 20 Feb 1997 14:55:01 -0700 Organization: Primenet Services for the Internet Message-ID: <AF3219BD-76C68@198.68.42.250> References: <5eidi8$9nt@news3.digex.net> nntp://news.primenet.com/comp.sys.mac.programmer.misc, nntp://news.primenet.com/comp.sys.powerpc.advocacy, nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.misc, nntp://news.primenet.com/comp.unix.machten, nntp://news.primenet.com/comp.unix.osf.misc, nntp://news.primenet.com/comp.os.mach, nntp://news.primenet.com/comp.os.ms-windows.nt.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John Kheit <jkheit@cnj.digex.net> said: >jcr@idiom.com (John C. Randolph) wrote: >> You're going to be a Lawyer! You should know that the correct >> word isn't"Monolithicness", it's "monolithicity!" > >Actually, neither show up in websters. Monolithicism, on the other hand, does. Webster's 3rd New International Dictionary: Monolithicism -the state of being monolithic. --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
From: Alex Blakemore <alex@genoa.com> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 20 Feb 1997 03:31:43 GMT Organization: Genoa Software Systems Message-ID: <5eggiv$8t7@saturn.genoa.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5ebqe6$hu6@concorde.ctp.com> <33098bb9.30677792@nntp.ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: apuleius@ix.netcom.com In <33098bb9.30677792@nntp.ix.netcom.com> William Grosso wrote: > (1) NeXT's claim that 50K lines take approximately a month. > (2) Many exchanges such as the following fom c.s.n.misc > No, it's a right f**king pain in the arse. > (3) Statements from prominent NEXTSTEP programmers,> >it is non-trivial to do! > (4) Georg's assertion that it's a piece of cake. > Draw your own conclusions about the validity of what Georg says. The cost to convert varies tremendously and depends on several factors. 1. was the original app reasonable well designed, modular, written in a maintainable way, or was it slapped together. 2. how well do the converters know the app, old NeXTSTEP, OPENSTEP 3. does the app use features such as dbkit that went away completely, or streams which changed significantly. 4. does the already use foundation classes. Given a well designed well written non-dbkit app with skilled experienced developers you might approach NeXT's estimates. Unfortunately, that's not often the case. -- Alex Blakemore alex@genoa.com NeXT, MIME and ASCII mail accepted
From: Online@MacTech.com ( nick.c @MT ) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: New Information Date: Thu, 20 Feb 1997 13:47:21 -0800 Organization: MacTech Magazine Message-ID: <Online-ya02408000R2002971347210001@news.ucla.edu> References: <5e55u8$7td@news.bu.edu> <5eacjo$f6o@news.next.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit mark_bessey@next.com wrote: >John Siracusa writes >> From MacWeek: >> >> Sources in the boiler room report that Rhapsody will weigh in at about >> 110 Mbytes of pure chewing satisfaction and come with three levels of >> Install: EZ, Minimal and Custom. > >Wow. I wonder how the folks at MacWeek know how much disk space Rhapsody >is going to use, when it hasn't even been built yet? Sources say: the Knife has a time machine. ____Nicholas C. DeMello, Ph.D.___________________________________________ "MacTech Online"--MacTech Magazine, for Mac OS Programmers and Developers http://www.MacTech.com/ _/ _/ _/ _/_/_/ _/ _/ Chemistry: Nick@chem.UCLA.edu _/_/ _/ _/ _/ _/ _/_/_/ MacTech: Online@MacTech.com _/ _/_/ _/ _/ _/ _/ http://www.chem.ucla.edu/~nick/ _/ _/ _/_/_/ _/ _/
From: Online@MacTech.com ( nick.c @MT ) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: New Information Date: Thu, 20 Feb 1997 13:54:04 -0800 Organization: MacTech Magazine Message-ID: <Online-ya02408000R2002971354040001@news.ucla.edu> References: <5e55u8$7td@news.bu.edu> <5eacjo$f6o@news.next.com> <5egj22$sfr@news.bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit macintsh@bu.edu (John Siracusa) wrote: >Makes you wonder 1. if the letter written back before Copland was >canceled, and 2. what the heck Apple programmers are doing in Toyko... Might have something to do with the launch of MacTech Japan. It's supposed to include dev info from Apple Japan as well as the regular MacTech fair... XPLAIN AND ASCII LAUNCH MACTECH JAPAN Westlake Village, CA and Tokyo, Japan -- February 17, 1997 -- Xplain Corporation, the publisher of MacTech Magazine, today announced that it is launching MacTech Japan with noted Japanese publisher, ASCII Corporation. Until today, Japanese MacOS developers have had to work twice as hard by using English based documentation. Not only did they have to battle the technical issues, but a language barrier as well. Now, MacTech Japan, a fully localized version of MacTech Magazine in the United States (MacTech US), solves that. Starting initially as a bi-monthly publication, MacTech Japan will not only include translated articles from MacTech US, but will also include translated information from Apple Japan and the Japanese developer community. ....... <full press release avaiable at <http//www.mactech.com/> ____Nicholas C. DeMello, Ph.D.___________________________________________ "MacTech Online"--MacTech Magazine, for Mac OS Programmers and Developers http://www.MacTech.com/ _/ _/ _/ _/_/_/ _/ _/ Chemistry: Nick@chem.UCLA.edu _/_/ _/ _/ _/ _/ _/_/_/ MacTech: Online@MacTech.com _/ _/_/ _/ _/ _/ _/ http://www.chem.ucla.edu/~nick/ _/ _/ _/_/_/ _/ _/
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 19 Feb 1997 11:12:50 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <8n2mO2O00iWl05_J00@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> In-Reply-To: <330A8B29.1D5A@acm.org> Excerpts from netnews.comp.sys.next.programmer: 19-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >>> In any case, I come back to the original point, that in most cases it >>> is inappropriate for the OS to send an error/exception back to processes >>> that are waiting on resources, without at least trying some recovery, >>> either automatic or with operator assistance first. If the OS doesn't >>> do this then you do not have a very robust OS. >> >> Blocking a process because the kernel is waiting for an operator to tell >> it how to proceed when some form of error occurs is the opposite of >> robust! You can easily deadlock every runnable process if some crucial >> system resource like inetd (*), named, lookupd, or the swapper >> encounters a minor problem and must block until a human informs the OS >> of what to do when that error condition could otherwise be handled >> within the process. > > You are not only not reading correctly what I am saying, but in your > misreadings are quite wrong. How am I misreading what you've said? What is wrong with my statements? You've made vague assertions without anything to back your claims up. I'm afraid that "proof by assertion" doesn't qualify as a legitimate argument. >> Go perform some research on operating system design theory, Ian. > > Go do some research on Netiquette. You might find that you get > more pleasant exchanges with people. I have plenty of pleasant exchanges with people. One of the two email messages I received at cs4w@andrew overnight was someone thanking me for my comments about named. I've never really thought about it, but I probably get thanked by some person or other several times a week for information I've provided them. However, I have a policy of responding to people's messages using a similiar tone and rhetorical style. If you object to my tone, look at some of the phrases _you've_ used. > Technically, you should go and use a system other than Unix. Do yourself a favor and stop trying to tell me what OS's I've used; it's nothing but a strawman argument. I have used many operating systems besides Unix. >> You might learn something about why your suggestion is so mistaken. > > From what I have seen you certainly don't have a monopoly on truth, Nope, I don't-- I am wrong some of the time, and that is fine by me since I learn more from being wrong than I do from being correct. I'm willing to publicly acknowledge when I'm wrong because I try hard not to let my own confidence in the validity of what I believe prevent me from accepting facts even when they contradict my beliefs. > and even further quite a meagre understanding, Perhaps that's true. But what does that imply about you, who hasn't been able to refute my arguments about operating system design? Why don't you start by readdressing the technical points made in the paragraph above starting with "Blocking a process..." instead of making claims that you don't even try to substantiate? > and probably not much experience beyond the confines of Unix. This strawman appears again, I see. > You are doing pretty well in monopolising beligerence. Please come > back to the group only when you can write in a politer tone. I make no apologies for responding to your arguments the way I have. You don't have to like it since you're free to place me in a killfile if you so desire. > As I have said before, please keep it technical. Only a hypocrite would attempt to criticise my ability to make technical points after you've made comments like "Unix is bloated" or strawman arguments such as your repeated claim that my knowledge of operating systems is limited to Unix! I've gotten into the same exact argument in another thread with some other anti-Unix person who was convinced that the Unix aspects of NEXTSTEP require 100 MB or more (he claimed that 100 MB was a conservative estimate, actually) when the truth of the matter is that the Unix CLI layer under NEXTSTEP requires under 15 MB. Even after this fact was pointed out to him by showing the results of 'du /bin /usr/bin /usr/ucb /usr/etc', he responded by saying that maybe Unix only would require 50 MB! You want to have a friendly, technical discussion, Ian? Well, I'll be happy to provide you with one after you stop your Unix bigotry and start responding with technical points of your own instead of making unsubstantiated claims. You can start by withdrawing your assertion that "Unix is bloated" now that you've got some facts to work with.... -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: michael (Michael F. DeMan) Newsgroups: comp.sys.next.programmer Subject: Re: PDO and hooking in an ORB Date: 21 Feb 1997 02:03:35 GMT Organization: NeXT Software, Inc. Message-ID: <5eivpn$rnt@news.next.com> References: <32FA645B.2C4A@abacus.com> Cc: jimg@abacus.com In <32FA645B.2C4A@abacus.com> Jim Gagnon wrote: > I'm in the process of learning OpenStep and am having problems in > finding documentation on how to take an existing ORB and tie it into PDO > so that it can successfully interoperate with other ORBs. If I can tie > our application's object engine in with PDO, I can port all non-GUI code > over in one fell swoop and focus on creating a new user interface for > it. > > Any advice would be welcome. Thanks! > > NeXT is supposed to be shipping an IIOP/CORBA compliant interface this summer. If you can wait a while and spend the $ for it when it arrives it should alleviate all your problems. Mike DeMan michael@rum.cs.wwu.edu
From: jweiss@MCS.COM (Jerry S. Weiss) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten Subject: Re: Aliens among our Computers (was <...> IS NOT a microkernel!!!!!) Date: 19 Feb 1997 17:03:17 -0600 Organization: MCSNet, Chicagoland's finest Internet provider - 312-803-6271 Message-ID: <5eg0rl$s14$1@Jupiter.Mcs.Net> References: <5ef4nd$qut@qnx.com> <AF30771C-22DC6@198.68.42.217> <mxcs-ya02408000R1902971016400001@news.cris.com> In article <mxcs-ya02408000R1902971016400001@news.cris.com>, Mark Carmichael <mxcs@cris.com> wrote: >In article <AF30771C-22DC6@198.68.42.217>, "Lawson English" ><english@primenet.com> wrote: > > > > >Since the aliens in ID4 had DOS its wouldn't be a wonder if Apple > >looked to the stars for their salvation. > > Nah. They had Windows. Bill Gates was the last survivor of the Roswell > Crash, waiting for rescue and trying to sabatoge the Macintosh Way while he > [....] > >Nefariously seeding technical newsgroups with psycho-viral crosspostings >*that we cannont resist responding to* is also part of their evil plan. > >All of this Borg stuff reminds me of my personal vision of the climatic >ending of "Terminator IX", wherein the latest Machine representative is >tricked into entering DOS compatibility mode using logic (by an aged >William Shatner, in a cameo appearance). > Actually you could probably get any electronic device with more than two transistors to fail by simply exposing it to a sample of William Shatner's singing talent (or lack thereof). All the more reason why Vulcans, given their finely tuned logic and excellent hearing won't come withing 100 parsecs of this silly little rock. It would be nice to use one Bill to defeat the other and his changeling operating system. Alas the resultant back blast from such an event would sterilize the entire planet. Instead, I think we need to trust Steve and try to imagine how he would look in pointed ears ;-)
From: Mike.Connally@dial.pipex.com (Mike Connally) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 23:37:09 +0000 Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Message-ID: <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > However, I can't NFS mount a remote fileserver on a Mac and be able to > run Mac executables, because they require the out-of-band information > stored in their resource forks which is not representable within the > standard NFS/UFS filesystem paradigms. Wrong. NFS client software is available for MacOS from several vendors, and any Mac file (documents or executables) can reside on any NFS server platform and be used by the Mac transparently. > Executables are machine specific, correct-- but they can be stored on > remote fileservers without any problems, and they should be able to run > on the appropriate hardware platform that the executable was compiled > for. Yes. No problem for Macs with NFS client software, > Sorry, but you're wrong. Macs do not integrate very well with with > heterogenous network fileservers, because their executables won't be > runnable when stored on an NFS fileserver (or a NT fileserver, or a > Novell fileserver, etc). And I repeat: yes they are. -- Mike Connally Reading, England 'At 50, everyone has the face he deserves.' - George Orwell
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 19 Feb 1997 22:56:18 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.856421720@idiom.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> John Kheit <jkheit@cnj.digex.net> writes: [munch] >things monolithic for perfromance reasons. Yet the functionality >of a monolithic kernel is not reduced by its monolithicness. Good God, John! You're going to be a Lawyer! You should know that the correct word isn't"Monolithicness", it's "monolithicity!" "Monolithicness", actually spelled "monoliTHICKness," is a different word altogether, meaning: "The smallest dimension of that thing in Kubric's movie, 2001," or: "The mental state of believing that statically linking everything is Just Fine." Yours for a more erudite, and sesquipedalian c.s.n.a, -jcr
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 21 Feb 1997 11:29:53 +1100 Organization: Unisys Message-ID: <330CEC81.5A34@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@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.programmer: 20-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >>> For example, any read to a file is essentially a concurrency problem... > >>> your process will probably suspend until the required data is read > >>> from disk. > >> > >> That depends entirely upon how the process wants to read the file. The > >> process can decide to perform non-blocking I/O file with the O_NDELAY or > >> O_NONBLOCK flags to open(), or via select() on a set of open file > >> descriptors. > > > > Correct. There are many different ways to handle IO. Blocking vs > > non-blocking is one of them. > > If you understand the difference, why did you claim that "your process > would probably suspend..." when a process using non-blocking I/O will > not suspend? > > Contradiction detected. Do you understand the meaning of the word probably? I understand non blocking IO thank you. It says, "Dear M. OS, please perform this function for me, oh and by the way, if you can't, don't bother I'll find something else to do." Blocking requests are quite different, they say "Dear M. OS, please get me this, and I'll wait around until you can." > According to what you've said, if I find Unix a better solution for some > task, then I can't be a "real user of computers"? > > What nonsense.... You are correct, your previous statement was nonsense. Please stop putting words in my mouth, and then arguing as if I said them. And you are the first to accuse others of the strawman tactic! > >> That's why people write software layers on top of the OS, such as > >> OPENSTEP, which provide higher level abstractions which use the more > >> primitive functionality provided by the OS. And that's where those > >> high-level abstractions belong-- not in the kernel.... > > > > Right, but as far as an application is concerned that is the OS. > > You have one of the most bizzare viewpoints I've ever seen. Not at all. From the applications viewpoint, when it calls a system level service for a resource, it is calling the OS. Doesn't matter how the system is implemented, whether its got multiple layers, structured as free standing modules or whatever. > OPENSTEP is not an operating system; it's an software layer that > provides an abstraction _away_ from the specific OS that the application > runs on, so that the app can do useful things without having to be > written using non-portable, operating-system-specific functionality. Well, I think we're actually saying the same thing here, so I can't see why you were picking an argument above. As I said, to the application, that abstraction you are talking about is the OS. If the application can tell any different, then it's not an abstraction! ------------------------------------------------------------------------ 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: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 19 Feb 1997 17:39:03 GMT Organization: Global Objects Inc. Message-ID: <5efdrn$beo@news.xmission.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5ebqe6$hu6@concorde.ctp.com> <33098bb9.30677792@nntp.ix.netcom.com> <5ecusc$9p0@castor.cca.rockwell.com> embuck@palmer.cca.rockwell.com (Erik M. Buck) wrote: I think first part was me, a while back, if I recall correctly. Seems vaguely familiar... :-) > > >It is true. NEXTSTEP != OPENSTEP as far as the API goes. > > >There are some major differences, some of which are > > >conceptual and require not just changing method names, but in > > >some cases completely _rewriting_code. Stuff that uses > > >streams a lot can be onerous, for example. Having done some > > >NEXTSTEP->OPENSTEP conversion, I will openly state: > > >it is non-trivial to do! > > > > and > > > > (4) Georg's assertion that it's a piece of cake. > > > > Draw your own conclusions about the validity of what Georg says. > > To be fair, a LOT depends on how your code is structured.[...]. That's it in a nutshell. It really depends upon what the code you started with looks like. As Georg asserts, in many cases code _can_ convert easily. I've found certain NEXTSTEP constructs that don't map well, but I've also found that once converted to OPENSTEP there's usually an improvement in the code I converted as a result. (I've written plenty of bad code in my time; the stuff I'd call "good" code tends to be easier to convert, so...) So, while there may be some work involved, it does seem to be worth the effort to do the conversion. > I have not found a work around for the lack of file descriptors > in Postscript > How does MiscSerialPort handle this ? Or MiscSubprocess... Right now, they don't. If anyone has any ideas and would like to complete the conversion, be my guest. :-) Right now, I've got other fish to fry, so it will be a while before I get time to bang on that problem... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: vickery@tornado.svs.com (Jeffrey M. Vickery) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy,comp.unix.bsd.misc Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Wed, 19 Feb 1997 12:44:07 -0600 Organization: Sun Valley SoftWare, Ltd. (tornado) Message-ID: <vickery-ya02408000R1902971244070001@brownfox> References: <jm041536-1702972018170001@mencjo.apple.com> <5edvm7$t2v@news0-alterdial.uu.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5edvm7$t2v@news0-alterdial.uu.net>, mail25193@pop.net wrote: > Just as an aside, imagine for a moment what things would be like if everyone > in the workplace (note ! - just the workplace) who now has a PC on their desk > running a DOS/MS derivative would instead have a PC on their desk running Unix > with a GUI, a minimal administrative interface, and the productivity tools > equivalent to what they have under MS (which exist, please don't even start that > discussion.) Fred: I can't agree with you more! In fact, an aquaintance of mine that used to work for John Deer (The farm equipment people) as a programmer told me all about the system that he used to do updates for back in what I believe was the early 80's... Since Windows didn't exist at this time, Unix was really widely used in the business world - but usually with badly written packages that one would use via a terminal. However, Deer decided to implement a workgroup system that ran over SVR4 with Berkeley enhancements (essentially just the 'r'-series commands). What they found is that they could write their own windowing system (similar to X11) that could be customized for their own use - not somebody else's interface guidelines (i.e. MS Windows). Releasing updates was a snap because, of course, the system was easy to patch. Instead of hinging their technological ability on how often Microsoft would decide to release an update, they had a powerful client/server based system that could be easily modified by an in-house staff of "computer geeks" that knew Unix. Imagine how much money would be saved in the American business (hell, the global business) if such systems were implemented today. Instead of letting Gates get a share of everything, everything would be based on an industry-standard that can be ported to practically any other Unix platform. One common complaint is that you would then have systems that can't talk to each other. The contrary, though, is true - TCP/IP is good enough to drive a network as large as the Internet - why wouldn't it be good enough for corporate Intranet's? MS and any other Windows peddling company seems to think so as well, as they're dumping millions into the Intranet philosophy...Something that could have been done with Unix systems almost 20 years ago. I think relying on a key player like MS to provide updates for "everything" will be the downfall...or at least I hope it will be. Anyway, enough ranting... Best, Jeff +---------------------------------------------------------------------------+ | Jeffrey M. Vickery | Electronic Mail: vickery@tornado.svs.com | | System Administrator +--------------------------------------------------+ | tornado.svs.com | World Wide Web: http://tornado.svs.com/~vickery/ | +---------------------------------------------------------------------------+
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: Fabien_Roy@free.fdn.org Subject: Re: Mac/NeXT & Unix: File System Message-ID: <E5wKH0.363@free.fdn.fr> Sender: news@free.fdn.fr Organization: Fabien Roy Consultant. References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> <peterm.856341833@ulfrun> Date: Thu, 20 Feb 1997 13:07:48 GMT peterm@dna.lth.se (Peter Moller) wrote: > hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) writes: > >Scott Hess <shess@one.net> wrote: > >As far as I recall, there _was_ a limit of about 6k files per volume. > > That must be a really old figure: I have a HFS-volume with more than 25,000 > files on it and there's no problem at all. I think the limit is 32,767 files. > > > -- > -------------------------------------------------------------------------- > Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT > Department of Computer Science, Lund Institute of Technology > Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21 How long did it take to reconstruct the finder database over your 25,000 files? -- 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: michael (Michael F. DeMan) Newsgroups: comp.sys.next.programmer Subject: Re: How to make "STOP" button? Date: 21 Feb 1997 01:53:12 GMT Organization: NeXT Software, Inc. Message-ID: <5eiv68$rnt@news.next.com> References: <5cp1vh$a0h@kaopala.mhpcc.edu> Cc: altenber@acpub.duke.edu In <5cp1vh$a0h@kaopala.mhpcc.edu> Lee Altenberg wrote: > 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 > There are lots of ways to do this, the easist is to simply hookup your stop button to a method that sets up a boolean value.... - stopButtonClicked: sender { theGlobalBoolean = FALSE; } Then check the value of that boolean in your loop. You can query the button itself but the overhead in making the query could be much higher - plus if it's a non-toggle button the user would have to be clicking on it at just the right time to ensure it was in the 'isPressed' state when the app. check it. Good luck, Mike DeMan michael@rum.cs.wwu.edu
From: aisbell@ix.netcom.com (Art Isbell) Newsgroups: comp.sys.next.programmer Subject: Re: How to make "STOP" button? Date: 21 Feb 1997 04:22:18 GMT Organization: Netcom Distribution: world Message-ID: <5ej7tq$csp@dfw-ixnews7.ix.netcom.com> References: <5cp1vh$a0h@kaopala.mhpcc.edu> <5eiv68$rnt@news.next.com> michael (Michael F. DeMan) wrote: > In <5cp1vh$a0h@kaopala.mhpcc.edu> Lee Altenberg wrote: > > 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 > > > > There are lots of ways to do this, the easist is to simply hookup your stop > button to a method that sets up a boolean value.... > > - stopButtonClicked: sender { > theGlobalBoolean = FALSE; > } Unless you set up your own event loop or run a modal event loop, the mouse-down/mouse-up events necessary to activate the button won't be serviced until after the loop completes which isn't a very good STOP implementation :-) > Then check the value of that boolean in your loop. You can query the button > itself but the overhead in making the query could be much higher - plus if > it's a non-toggle button the user would have to be clicking on it at just the > right time to ensure it was in the 'isPressed' state when the app. check it. Unless you're running a multithreaded app, the loop won't be checking the button's state at the same time that the button is being pressed. -- Art Isbell NeXT/MIME Mail: aisbell@ix.netcom.com Trego Systems Voice/Fax: +1 408 335 2515 OPENSTEP/NT Voice Mail: +1 408 335 1154 managed care solutions US Mail: Felton, CA 95018-9442
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Thu, 20 Feb 1997 20:43:25 -0600 Organization: mementech, inc. Message-ID: <330D0BCD.5AD3C7F6@screaming.org> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <jcr.856421720@idiom.com> <5eidi8$9nt@news3.digex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit John Kheit wrote: > jcr@idiom.com (John C. Randolph) wrote: > > > > "Monolithicness", actually spelled "monoliTHICKness," is a > > different word altogether, meaning: "The smallest dimension of > > that thing in Kubric's movie, 2001," or: "The mental state of > > believing that statically linking everything is Just Fine." > > Now I see how L. Ron. Hubbard became god :) Speaking of clever obfuscation, has anybody here actually read Dianetics? I swear: there are scores of plain, blunt words used as special Scientologist jargon -- none of which is given an adequate definition -- and the book is littered with footnotes defining "hard words" like prefrontal lobes arthritis sinusitis bursitis diabetes vacillate ...and then slowly throughout the book, L Ron Hoover starts slipping in L Ron Hoover's First Church of Appliantology Nomenclature(tm) -- all of which are defined in terms of each other. It's a fascinating tangled web of stupidity, written in a plain, easy to read form. And it makes a great gift, too! -- 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: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 02:19:35 GMT Organization: MHPCC Message-ID: <5ej0nn$6t6@kaopala.mhpcc.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> Cc: cs4w+@andrew.cmu.edu Here's an example of why I can't stand the Mac's HFS file system. I just bought the Sonata font from Adobe. Adobe told me the Mac version would work with NEXTSTEP. So, I got the suckah, and put it on a Power Mac. I then used Fetch to send it over the network to my PC running NEXTSTEP 3.3. Fetch allowed me to pick Mac Binary II or BinHex. I tried both. When Opener on the NeXT side opens the *.hqx or *.bin files, it shows 0 bytes in the *.data file. All the data is in the *.rsrc files, i.e. the resource fork. Why is all the font data (these are the bitmap and outline files) in the resource fork, not the data fork? Anyway, the outline file is supposed to be ASCII PostScript, but it has lots of binary data in it. What a PITA! By the way, if you know what is wrong and how to fix it, please drop me a note. -- ======================================================================= 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: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 21 Feb 1997 06:39:11 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5ejfuf$ae2@news4.digex.net> References: <5eidi8$9nt@news3.digex.net> <AF3219BD-76C68@198.68.42.250> "Lawson English" <english@primenet.com> wrote: > John Kheit <jkheit@cnj.digex.net> said: Monolithicism, on the > other hand, does. Webster's 3rd New International Dictionary: > Monolithicism -the state of being monolithic. In the states, the authority is likely to be the 9th or newer version. -- Thanks, be well, take care, later, John Kheit; Self expressed... 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 | Ja tallar ente svenska )^> %^) =^)
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 19 Feb 97 12:25:56 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb19122556@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <wharris-ya023080001702970658310001@news.iadfw.net> <5eepmi$r6e@horus.ecmwf.int> In-reply-to: syy@ecmwf.int's message of 19 Feb 1997 11:54:58 GMT In article <5eepmi$r6e@horus.ecmwf.int> syy@ecmwf.int (Mike Connally) writes: There's a tendency in the NeXT community not to grok the utility of MacOS features like file type & creator codes, Macintosh Easy Open, and full drag-and-drop capability. . The file TYPE code is analogous to a filename extension (but unintrusive). An app knows which file types it can handle. As on NeXTSTEP. The file CREATOR code simply indicates which app created the file. Double-clicking a file tries to launch that app. NeXTSTEP tries to launch whichever app you've indicated you prefer to open that particular type of file with. If the app isn't found, Macintosh Easy Open launches to ask the user to nominate a substitute app which can handle that file type. Easy. From then on, that app becomes that user's preferred launch. NeXTSTEP in this case pops up an inspector, where you can choose to either do a one-time launch of that file in any of the apps that claim to handle it, or you can set it for all files of that type. You can also get that inspector by selecting a file and hitting Command-2 or something (sorry, I don't know offhand which menu item gets you there). And for further user flexibility, there's drag-and-drop. NeXTfreaks might say: |> >Once more, you have the choice. If you prefer, you can |> >command-drag your file icon onto a running or "docked" |> >application icon to have it opened in a different app. That's good. On a Mac it's even better. You can simply drag (no need for the command key) any document onto any app, as long as that app is willing to handle that file type. The app can be anywhere (in a folder, on the desktop, in the Launcher, wherever), and it can be running or not. Doesn't matter. Just as on NeXTSTEP, pretty much (NeXTSTEP has different notions of some of the things you mentioned, but it works in the context of those different notions, go figure). The main reason Command-drag is used instead of plain drag is because apps had already implemented plain-drag onto app icons before NeXT made the change. They didn't want to screw existing programs with an incompatible addition. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 20 Feb 1997 22:30:07 -0700 Organization: Primenet Services for the Internet Message-ID: <AF328494-208653@206.165.42.206> References: <jcr.856487960@idiom.com> nntp://news.primenet.com/comp.sys.mac.programmer.misc, nntp://news.primenet.com/comp.sys.powerpc.advocacy, nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.misc, nntp://news.primenet.com/comp.unix.machten, nntp://news.primenet.com/comp.unix.osf.misc, nntp://news.primenet.com/comp.os.mach, nntp://news.primenet.com/comp.os.ms-windows.nt.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John C. Randolph <jcr@idiom.com> queried: >>Monolithicism -the state of being monolithic. > >Well, the thirty-day killfile entry expired, and what do I see right away? >An article by Lawson, demonstrating once again, that he has far more time >on his hands than I do. > >-jcr > >PS: So, Lawson: Any luck on the GX advocacy fight? So, John, how's the Gratituous Insult business? I mean, if you don't have enough time look up a word in a dictionary, but DO have enough time to flame me, I gotta assume that yours was a work-related post, right? --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
From: fuckyou@yourass.xxx Newsgroups: comp.sys.next.programmer Subject: laptop4sale! - laptop4sale.doc (1/1) Date: Fri, 21 Feb 1997 10:15:43 GMT Organization: Easyway Communication Inc. Message-ID: <330d74cf.3832599@news.easyway.net> begin 644 laptop4sale.doc MT,\1X*&Q&N$`````````````````````/@`#`/[_"0`&```````````````! M`````0``````````$````@````$```#^____``````````#_____________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________]_____O____[___\$````!0````8````'```` M"````/[_____________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_____________________________________________U(`;P!O`'0`(`!% M`&X`=`!R`'D````````````````````````````````````````````````` M```````````6``4`__________\!``````D"``````#`````````1@`````` M`````````.`^YHG>'[P!`P```,`+````````5P!O`'(`9`!$`&\`8P!U`&T` M90!N`'0````````````````````````````````````````````````````` M`!H``@$"````__________\````````````````````````````````````` M`````````````````@L````````!`$,`;P!M`'``3P!B`&H````````````` M````````````````````````````````````````````````````$@`"`/__ M_____________P`````````````````````````````````````````````` M`"T```!>```````````````````````````````````````````````````` M````````````````````````````````````````````````____________ M____```````````````````````````````````````````````````````` M`````````0````(````#````!`````4````&````!P````@````)````"@`` M``L````,````#0````X````/````$````!$````2````$P```!0````5```` M%@```!<````8````&0```!H````;````'````!T````>````'P```"`````A M````(@```",````D````)0```"8````G````*````"D````J````*P```"P` M``#^____+@```/[_____________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M____________________________________________________________ M_______________________________<I64`(\`)!``````````````````` M```&`P``K`0```(+````````````````````````I@$````````````````` M````````````````````````````+`H``&P````L"@``;``````````````` M````````````````````````````````%`H``!0````````````````````` M``````````````````````````````````````H```H````*"@``"@`````` M````````J@(``%P````H"@``!``````````````````````````````````` M````````````````````````````````````````````[`H```(````````` M``````````````````````````````````````````````````````````"8 M"@``5````.X*```4```````````````````````````````````````````` M`````````````````P`$``$``0`````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M````````````````````````````````````````7``3``````!-4R!386YS M(%-E<FEF``P````"`%-Y;6)O;``,(`````!3>7-T96T`%0``````5&EM97,@ M3F5W(%)O;6%N`!40`````%1I;65S($YE=R!2;VUA;@`@("`@*BHJ*BHJ*DQ! M4%1/4"!&3U(@4T%,12HJ*BHJ*BH-#4=!5$5705DR,#`P(%!%3E1)54TQ,C`@ M#3$V345'(%)!30TQ+C)'24<@2$%21"!$4DE610U214U/5D5!0DQ%($-$+5)/ M32!!3D0@1DQ/3U!9#4-(25!3("8@5$5#2"X@5DE$14\@04-#14Q%4D%43U(- M15-3(%-/54Y$#4)524Q$($E.(%-014%+15)3#3(X+CA00TU#24$@34]$14T- M041!4%1%0R!30U-)($-!4D0H<&-M8VEA*0TH=VET:"`R(&-A8FQE<R!G;V]D M(&9O<B!A;GD@<V-S:2!D979I8V5S*0U724Y$3U=3.34@0T0-34E#4D]33T94 M(%!23T9%4U-)3TY!3"!#1`TH86-C97-S+'=O<F0L97AC96PL;6]N97D@971C M+BXN+BXN+BD-0D%45$%2629#05)264E.1R!#05-%#0TD,3<P,"XP,"!N97<@ M>6]R:R!A<F5A('!L96%S90U#3TY404-4($%4(&1E;'1I<S%`:&]T;6%I;"YC M;VT-#0`````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````````````&`P``"@,``"<#```H`P`` M*0,``$`#``!!`P``2@,``$L#``!<`P``70,``'D#``!Z`P``F0,``)H#``"C M`P``I`,``+4#``"V`P``Q@,``,<#``#@`P``X0,```H$```+!```%P0``!@$ M```Q!```,@0``%8$``!7!```;`0``&T$``!N!```BP0``(P$``"J!```JP0` M`*P$``#[]_/OZ^?CW]O7T\_+Q\._N[>SKZNGHY^;EY./BX>#?WMW<V]K:0`` M```````````````````#70,`!ET$`&,<```&700`8QP```9=!`!C'```!ET$ M`&,<```&700`8QP```9=!`!C'```!ET$`&,<```&700`8QP```9=!`!C'``` M!ET$`&,<```&700`8QP```9=!`!C'```!ET$`&,<```&700`8QP```9=!`!C M'```!ET$`&,<```&700`8QP```9=!`!C'```!ET$`&,<```&700`8QP```9= M!`!C'```!ET$`&,<```&700`8QP```9=!`!C'```!ET$`&,<```&700`8QP` M``9=!`!C'```!ET$`&,<```&700`8QP```9=!`!C'```!ET$`&,<```&700` M8QP```9=!`!C'```!ET$`&,P```&700`8S````9=!`!C,```!ET$`&,H```` M)@8#```H`P``*0,``$$#``!+`P``70,``'H#``":`P``I`,``+8#``#'`P`` MX0,```L$```8!```,@0``%<$``!M!```;@0``(P$``"K!```K`0``/D````` M``#S````````[0```````.<```````#A````````VP```````-4```````#/ M````````R0```````,,```````"]````````MP```````+$```````"K```` M````I0```````)\```````"9````````DP```````(T```````"'```````` M```````````````````````````````````````````````````````````` M``4```4!%/```0````4```4!%/```0````4```4!%/```0````4```4!%/`` M`0````4```4!%/```0````4```4!%/```0````4```4!%/```0````4```4! M%/```0````4```4!%/```0````4```4!%/```0````4```4!%/```0````4` M``4!%/```0````4```4!%/```0````4```4!%/```0````4```4!%/```0`` M``4```4!%/```0````4```4!%/```0````4```4!%/```0````4```4!%/`` M`0````4```4!%/```0`````4!@,``*P$```#``8#``"L!```!```````I@$` M````_____P``_____R('```.``\`"``!`$L`#P``````&@``0/'_`@`:``9. M;W)M86P``@````,`80D$`````````````````````````"(`04#R_Z$`(@`6 M1&5F875L="!087)A9W)A<&@@1F]N=`````````````````````0````````` MT`(````````````````````````````````````````````````````````` M``````````````````````````````````````#_0!0````````````````` M```````````````````````````````````````````````````````````` M```````````````````````````````!`/[_`PH``/____\`"0(``````,`` M``````!&'````$UI8W)O<V]F="!7;W)D(#8N,"!$;V-U;65N=``*````35-7 M;W)D1&]C``````#T.;)Q```````````````````````````````````````` M```````````````````````````````````````````````````````````` C```````````````````````````````````````````````` ` end
From: allman@pat.mdc.com (Mark Allman ) Newsgroups: comp.sys.next.programmer Subject: Shared object libraries (rld) using OpenStep 4.1 Date: 19 Feb 1997 15:46:47 GMT Organization: McDonnell Douglas, Houston Division Message-ID: <5ef797$m78@cisu2.jsc.nasa.gov> OpenStep 4.1 for Mach question: Some C code I'm compiling and putting into a shared object library (via ld -r) for later dynamic loading (using rld) is now refusing to be loaded. I've begged and pleaded, but to no avail. The error I'm now getting is something like "cannot use rld with dynamic shared libraries." Since all the "standard" libraries (e.g., libsys_s.dylib) are now dynamic shared libraries, are the rld routines no longer usable? I can switch to use dyld routines and use libtool--is this what I should do? Can someone point to some documentation (man pages aren't telling the complete story) that discusses rld routines under OpenStep 4.1? Also, I noticed that we can no longer build static executables, since there are no static "standard" libraries. Try compiling the "Hello, world" program using the -static compile/link switch. -- Mark Allman -- Sr. Engineer, McDonnell Douglas Aerospace, allman@pat.mdc.com -- Software consulting (Perl, C, Python, ...), ghost@ghost.neosoft.com -- (see: http://pup.princeton.edu/titles/5857.html)
From: Mike.Connally@dial.pipex.com (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 23:31:33 +0000 Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Message-ID: <Mike.Connally-ya023680001902972331330001@news.dial.pipex.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5ecund$rcn$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: [about the Mac] > > That's kind of what I meant.. You can't choose to open by file type _OVER_ > file creator. If the file creator data is there, and the file creator app > exists on that machine, you MUST use it. You cannot choose a file type > application OVER that creator app. I didn't say you can't open by file type > at all. I simply said the Mac doesn't give you a choice between the two -- > if creator exists you use it, otherwise you use type... no choice. Wrong. You can either drag-and-drop any file of a compatible type onto any app (easy) or you can launch the app and the use the File Open dialog to open any document of a compatible type (fiddly, but Windows people seem to like it). -- Mike Connally Reading, England 'At 50, everyone has the face he deserves.' - George Orwell
From: Mike.Connally@dial.pipex.com (Mike Connally) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 23:40:04 +0000 Organization: UUNet PIPEX server (post doesn't reflect views of UUNet PIPEX) Message-ID: <Mike.Connally-ya023680001902972340040001@news.dial.pipex.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> <330A2E07.563D@ix.netcom.com> <Un2duCC00iWX0J_7NE@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <Un2duCC00iWX0J_7NE@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Excerpts from netnews.comp.sys.next.programmer: 18-Feb-97 Re: Mac/NeXT & > Unix: File S.. by Larry Kendall@ix.netcom. > > With The standard Novell for Mac nlms running on 3.1.1 you can store and > > run your executables from the novell file server. I've been doing it for > > years. If the program requires system extension they have to be in the > > ext folder of the local Mac of course. > > Okay, thanks for the correction. Even so, the point still applies to > just NFS servers, which is more relevent for me.... No it doesn't. With NFS client software, Macs can use any file (data or executable) resident on any NFS server. -- Mike Connally Reading, England 'At 50, everyone has the face he deserves.' - George Orwell
From: "Georg Tuparev" <gtupar@ctp.com> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 21 Feb 1997 10:57:10 GMT Organization: Cambridge Technology Partners, Inc. Message-ID: <5ejv26$bsl@concorde.ctp.com> References: <5egap7$beo@news.xmission.com> In article <5egap7$beo@news.xmission.com> don@globalobjects.com (Don Yacktman) writes: > Perhaps we should include a List/HashTable implementation in > the MiscKit for people who are hopelessly attached to that API? Everyone is free to grab them from GNU's foundation implementation ;-) ... but some people prefer to complain :-( Coll to see some folks like Don and Tomi still around .. to balance the optimism... -- georg -- -- ------- /\/\ 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: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 97 07:23:57 GMT Organization: Lund University Message-ID: <peterm.856509837@ulfrun> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> <peterm.856341833@ulfrun> <E5wKH0.363@free.fdn.fr> Fabien_Roy@free.fdn.org writes: >How long did it take to reconstruct the finder database over your 25,000 >files? I dunno; a couple of minutes (not that many actually). Something inbetween five and ten minutes. That's OK if you do it once a year or so. I fact, I can't remember when I last did it, I think it was in 1996 but I'm not sure. -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 23:02:14 +0100 Organization: Einzeln auftretender Radfahrer Message-ID: <19970219230214660250@q700.hf.org> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> <peterm.856341833@ulfrun> <SHESS.97Feb19095104@howard.one.net> Scott Hess <shess@one.net> wrote: > In article <peterm.856341833@ulfrun> peterm@dna.lth.se (Peter Moller) writes: > hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) writes: > >Scott Hess <shess@one.net> wrote: > >As far as I recall, there _was_ a limit of about 6k files per volume. > > That must be a really old figure: I have a HFS-volume with more > than 25,000 files on it and there's no problem at all. I think the > limit is 32,767 files. > > Did I write that? Must have dropped a 4 somewhere, as I meant 64k > (2^16). > > Later, > -- > scott hess You didn't; Peter got the quote wrong. =8) hauke -- "It's never straight up and down" (DEVO)
From: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.system Date: 21 Feb 1997 03:43:30 -0800 Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Message-ID: <5ek1p2$31n@crl9.crl.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> <01bc171f$45774280$ceec1fcc@rthelen.ix.netcom.com> <32FF8CA1.33C1@subsequent.com> <Followup to c.s.m.p.codewarrior deleted> Jonathan W. Hendry (Jonathan W. Hendry (jon@subsequent.com)) wrote: : Randy Thelen wrote: : > In the second case, Macintosh applications have traditionally stored their : > M68000 executable code in the resource fork. Which is, if you really think : > about, a pretty unusual thing. Further, the Macintosh 'fat' applications : > store their PowerPC data in the data fork of the application. Which, if you : > remember, broke some applications which actually stored their preference : > data in the data fork of themselves. : : NeXT's Mach allows a file to have multiple segments. Fat NeXT apps store : each architecture's binary in a different segment. Mach knows how to : execute the proper segment. Similar idea, different implementation. Mac PowerPC code can exist as code fragments, such as PEF containers, which may reside in resource forks and separate files as well. Not quite as symmetric as Mach, though, though I'd fashion it's an interesting exercise to extend the Mixed Mode Manager to Java code. (Isn't that what Sonata is up to?). Connectix overrode the stock 68K emulator handily enough. : One area where wrappers have an advantage over forks is in a : multi-platform : environment. Since NeXT applications consist of files and directories, : they can 'live' on any OS, so long as there are no filename limits (8.3, : etc.). : A NeXTSTEP application is runnable regardless of what kind of filesystem : it is stored on. It doesn't matter if the application server is a NeXT, : a Sun, a Linux box, or an NT box. : Conversely, it would be difficult (if not impossible) to run a Macintosh : application that is stored on a non-HFS disk. Er, I've run Mac apps mounted from a SCO Unix (SVR3.2) box. AFS running under CAP. Didn't connect the Unix disk _physically_ onto the IIci's SCSI bus, though; that would have been something. :-) Basically it mapped the resource and data forks _and_ the FInfo information in the HFS onto plain files and directories with no change to the clients. : IMHO, the Unix filesystem is like TCP/IP. The NeXT Workspace is like : HTTP, running : on top of TCP/IP. The Workspace implements functionality : that doesn't : exist in the Unix filesystem, much like Netscape implements : functionality : that doesn't exist in TCP/IP. : : The Mac filesystem is like a combination of TCP/IP and HTTP. It's an : interesting combination, and it adds some useful functionality, but at : the : cost of compatability with normal 'TCP/IP'. Anyone know how much difference is there (protocol-wise) between reading/writing to DOS floppies and reading/writing to NTFS/etc. volumes? Just curious, as Macs have little trouble with the former. Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
From: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.mac.system,comp.sys.next.programmer Date: 21 Feb 1997 06:04:34 -0800 Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Message-ID: <5eka1i$3qo@crl9.crl.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <Mn0tGpa00iV3A4W=0F@andrew.cmu.edu> [Snipped followup to c.s.m.p.codewarrior] (Charles William Swiger (cs4w+@andrew.cmu.edu)) wrote: : Excerpts from netnews.comp.sys.next.programmer: 13-Feb-97 Re: Mac/NeXT & : Unix: File S.. by Peter Moller@dna.lth.se : >> Perhaps it's just me, but I don't see much value to preserving the : >> timestamp of the creation date of the original version of a file when : >> you don't actually have the original file-- just the modified version. : >> Can you provide a real-world example of why you'd care about that : >> timestamp? : > : > Easily; quite often I try to figure out which version of a file or a : > program is the oldest and the created time stamp is very handy in those : > situations. : The last-modified timestamp serves that purpose better than the creation : timestamp does. If the file has never been editted, the last-modified : timestamp is identical to the creation timestamp. If the file has been : changed, the last-modified timestamp will tell you which version is : oldest whereas the creation timestamp does not. : Try again. How's this: I have 2 builds of an application. The one built later inadvertently introduces a subtle bug. Both copies are later patched in the field to correct a minor misspelling, but before the bug is discovered. Which version is which? The "older" file isn't necessarily the least recently modified. Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 21 Feb 1997 11:51:51 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mn3R_bK00iVCM22gol@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> <8n2mO2O00iWl05_J00@andrew.cmu.edu> <330B8D60.74C1@acm.org> <kn36aXu00iWm02vRk0@andrew.cmu.edu> <330CE9E4.60AB@acm.org> In-Reply-To: <330CE9E4.60AB@acm.org> [ ...followups redirected out of the programmer groups... ] Excerpts from netnews.comp.sys.next.programmer: 21-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org > Well, unfortunately because of the way you have pursued the argument of > this thing, this would become a you're dodging the question... no you're > dodging the question match. Respond to the original comment which I've placed below quoted by "C>" and explain how I misread your comments: C> Blocking a process because the kernel is waiting for an operator to tell C> it how to proceed when some form of error occurs is the opposite of C> robust! You can easily deadlock every runnable process if some crucial C> system resource like inetd (*), named, lookupd, or the swapper C> encounters a minor problem and must block until a human informs the OS C> of what to do when that error condition could otherwise be handled C> within the process. ...with specific examples, or do not respond. > To get a more reasonable line, you should stop accusing others in these > groups of doing exactly what it is that you are doing. Precisely what is it that I am doing that I have accused other of doing? Be sure to provide specific examples that include direct and uneditted quotes from me that also include adequate context. > From your first response to what I said, you jumped straight in and > responded as if I was some kind of biased idiot. If you wish to demonstrate that you are actually not, in own your words, a 'biased idiot': Address the issue of whether "Unix is bloated" by reconciling your statement with the demonstrable facts of the size of Unix as provided by the 'du' command. [ ... ] >> If the OS itself blocks the process which asked for some service and >> waits for the user to tell it what to do when an error occurs, then >> neither the process being blocked nor any other process which depend on >> that blocked process to make progress will be able to do anything. > > The process is blocked because the OS has not been able to service its > request for a resource. Correct. > That is it. Incorrect. That single process may hold other resources which cannot be released while it's blocked, or that single process may generate information which other processes require. Blocking one process may impact many other processes, or even the entire operating system. > If the programmer does not want the process to block on a currently > unavailable resource, I have already told you how to cater for that > situation. This claim is untrue. I was the first person to bring up the concept of non-blocking I/O into this argument, as a scan through prior articles will demonstrate. > Processes do not block on each other. Processes most certainly can block on each other. The producer-consumer paradigm is one of the most basic examples of using remote procedure calls for IPC. > Processes block on resources. Deadlock occurs because one process locks a > resource, and a second process locks another resource. Then both processes > try to lock the resource that the other process already has locked. That's the simplest example of the necessary conditions for deadlock. There are many, mnay other ways of creating deadlock. > Your previous example was if one resource is unavailable, then all > processes will block on it. There were two resources in my example-- the feedback from the user is also a resource, albeit one that is not part of the computer and therefore is not under the control of the operating system. _That_ is the primary reason why having the OS block a process and wait for the user to tell it what to do is such a bad idea! The OS cannot determine or control when it will actually get a response, because it involves a resource which the OS does not control. > What I am saying is if resources under the control of a resource > manager are unavailable, it is the resource managers responsibility > to ensure availability, and to resolve contention on the resource. Deadlock prevention, and/or deadlock detection and resolution are very difficult issues that do not have graceful solutions. Either you require processes to request all of the resources they will need before reserving any resources (which is hard to do especially when the process may not be able to figure out what it will need), or you have to do antisocial things like killing off lots of processes when they do become deadlocked. Both solutions impose a lot of overhead and generally make the system less efficient because resources will be used less efficiently. It's why most operating systems ignore the issue of deadlock entirely and simply try to make sure they can provide enough resources so that deadlock doesn't happen very often. > It is bad policy for a resource manager just to hand an error back > to a running process. That is incorrect. There are plenty of circumstances where having the resource manager just hand errors back is the best policy that could be followed. While you've claimed to understand non-blocking I/O, Ian, you obviously don't understand that when the data isn't available yet, the OS "just hand[s] an error back to a running process"-- namely, EWOULDBLOCK. If you actually understood non-blocking I/O then you would realize that the central concept represents a direct contradiction of your assertion that it's "a bad policy for a resource manager...." I'm not going to bother with the rest of this noise-- somehow, I simply don't feel a need to refute more of Ian's assertions that I don't understand deadlock. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.system Date: 21 Feb 1997 04:48:28 -0800 Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Message-ID: <5ek5is$3d9@crl9.crl.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <Followup to c.s.m.p.codewarrior removed> Jonathan W. Hendry (Jonathan W. Hendry (jon@subsequent.com)) wrote: : John 'kzin' Rudd wrote: : > Which would probably be mapped like "Photoshop.app -> Painter.app", : > and thus when you launched a file created by Photoshop, it would : > bring up Painter. :-} : : The problem with this arrangement is that it creates a potentially : large set of mappings, especially when you get into mapping to : both creator and type. It seems more useful to just map types, : and not creators. Hmmm...Let's say I want to change the preferences for several applications, each having a disparate set of preference parameters. Who/what knows which file goes to which application? Every one of the files is of type 'pref'. Another example: a file of type '%*\C4/' that's unrecognizable to just about everything in existence except to the one application that created it, for _it_ surely knows what to do with it. I take it you mean '...more useful to just map types, and not _just_ creators'? In any case I think it's useful to have both. I agree with you, though, that their _use_ must be implemented wisely. Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
From: karish@well.com (Chuck Karish) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 21 Feb 1997 17:56:51 GMT Organization: MindSpring Enterprises Message-ID: <330de131.1384575934@news.mindspring.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> <5ejud7$2pk@crl9.crl.com> On 21 Feb 1997 02:45:59 -0800, van@crl.com (Van C. Bagnol) wrote: > To have _multiple_ users _each_ with a different mapping preference for > individual files looks like it's a many-to-one correspondence. Seems > that can get unwieldy to manage, or at least one that begins to parallel > the filesystem for _each user_. (Everyone gets a Desktop database). You mean the way it was done in A/UX? Don't forget that Apple has a long history of supporting (and abandoning, but that's another story) Unix. These are not new issues. Some pretty good solutions have already been implemented. Chuck Karish karish@mindcraft.com Mindcraft, Inc. 415 323 9000 x117
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,c Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 21 Feb 1997 18:33:55 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5ekpqj$am9@netty.york.ac.uk> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000 <33091DD2.61FA@acm.org> On Tue, 18 Feb 1997 14:11:14 +1100, Ian Joyner <i.joyner@acm.org> wrote: > In any case, I come back to the original point, that in most cases it > is inappropriate for the OS to send an error/exception back to processes > that are waiting on resources, without at least trying some recovery, > either automatic or with operator assistance first. If the OS doesn't > do this then you do not have a very robust OS. what sort of behaviour *is* appropriate in general for an OS when a process is waiting on resources ? lack of memory: the process needs the memory for something, presumably to accomplish the task it set out to do. perhaps the most robust approach is to put the process to sleep until there is some memory available. can't access a file files can represent many things. in a unix system, a file might represent a tape drive, a display device, a configuration file or a user's word process file. the actions to be taken should any of these resources be missing varies enormously, from "please go and put the tape in" to "you've mistyped the filename, please try again". is there anything that can more accurately judge the most appropriate action to take on missing resources than the application itself ? unlike memory, an application does not always *need* the resource in order to process correctly. in many cases, the resource will only be used if it is available (e.g. optional configuration scripts). so in order for the OS to take some sort of appropriate recovery action, the application must indicate to the OS the nature of the recovery action to be taken. but where do you stop ? is it really necessary (or even desirable) for an OS to have inbuilt knowledge of all the recovery actions needed for the conditions above ? surely all your suggestion boils down to is a need for a new system call: int calloperator(char *msg); that informs the operator of a particular condition, and waits for a human response. now what happens if somebody is remotely logged in at 2am and this happens ? it's not an easy problem, but i don't think you've got a solution either! cheers, rog.
From: jm041536@fhda.edu (Joaquin Menchaca) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 21 Feb 1997 19:08:01 GMT Organization: De Anza College Message-ID: <jm041536-2102971103330001@mencjo.apple.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> In article <SHESS.97Feb20085428@howard.one.net>, shess@one.net (Scott Hess) wrote: > > Unless I've _greatly_ misread a variety of papers, microkernels are > coming into their own because we are asking entirely too much of our > monolithic kernels. The amount of effort it takes to add something > new to your monolithic kernel is often so great that you never get > around to it - and thus a microkernel can be more efficient in the > end. In essence, using a microkernel lets you get to a better design > for the system faster than a monolithic kernel, so it wins in the end. > > This is similar to the differences between object programming and > structured programming. Any given system _can_ be written in either. > And if you write a given system using the same design in either, the > structured version will generally be more efficient, because it > doesn't have the object version's overhead. The fly in the ointment > is that the structured version generally will never be written that > way, though, because it doesn't help you manage complexity well > enough. Object languages win in the end because though they might not > be faster for a given design, they let you modify the design more > easily. > This is very well said. That was my orginal concern about the decision about using a monolithic kernel from NeXTSTEP (OPENSTEP for Mach). I think technically this is a mistake. It may be outrageous to say this, but I think NuKernel of Copland is a better choice as it combines the best of Apple with the best of NeXT (OPENSTEP). Playing devil's advocate: For the business side, this could be the correct decision. Apple needs to ship a developement system hosting NeXT for developers. This needs to be done as soon as possible. Afterwards, the kernel may have more features, but the monolithic kernel was probaly chosen in order to have a little risks and be able to meet deadlines. This is a sound decision. Afterwards, there is no reason, Apple could upgrade their monolithic kernel (Mach 2.5++) to that of a better kernel like good microkernel and/or a distributed cluster based kernel to the highend publishing, server, and rendering markets. Just my thoughts. joaquin -- ############################################################### # My opinions are my own and not of any I work for. # ############################################################### # WARNING: DO NOT send unwarranted mail or SPAMS! Further # # proceedings of sending unwarranted email or spams will # # result in fines up to $1000 in damages. # ###############################################################
From: Stacy Marsella <marsella@isi.edu> Newsgroups: comp.sys.next.software,comp.sys.next.programmer Subject: confused about bundles Re: Sequence.app problems Date: Fri, 21 Feb 1997 09:13:56 -0800 Organization: USC Information Sciences Institute Message-ID: <330DD7D4.6EBA@isi.edu> References: <5ej5ke$d58@alto.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bundle experts, riddle me this.. Stacy Marsella wrote: > > I am having a problem with Sequence.app v0.9.8 (the version at CCRMA) > on a nextstation (nextstep3.2). The eventlist view does not work. > When I hilite a partname and select Eventlist from the Part menu > nothing happens except the following error message gets displayed in > the Console window: > Sequence[181]: Assertion failed: loadNIBSection: could not find data > > Any Suggestions or Clues? ... > Stacy Marsella I seem to have fixed this problem. It turns out EventList is a bundle and in the EventList.bundle subdirectory is its nib subdir, EventList.nib. Well I created a link to EventList.nib in the main directory of Sequence.app and now it is working. My question is why is it working? Do bundles have default areas in the app subdir where they are willing to look and for some reason loading on my machine is not looking there? Could there be absolute paths in the EventList code (I looked in the binary and didn't find any but I may have missed it)? Thanks, Stacy marsella@isi.edu
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 20 Feb 1997 01:52:39 GMT Organization: Global Objects Inc. Message-ID: <5egap7$beo@news.xmission.com> References: <33098bb9.30677792@nntp.ix.netcom.com> <5ec61p$iud@concorde.ctp.com> "Georg Tuparev" <gtupar@ctp.com> wrote: > If the application to be ported uses IXKit, Speaker & > Listener, and DBKit/EOF 1.0 it is pain in the a**** > > But what people are complaining is that the OS does not > include the List class. [...]. I'd agree with Georg on this point--List and HashTable aren't needed to move to OPENSTEP. If you really need to make a special subclass, then it gets to be a pain because NSArry/ NSDictionary, being class clusters, don't subclass well. But usually with minor improvements to a design, this can be worked around since a subclass isn't always the best answer. Perhaps we should include a List/HashTable implementation in the MiscKit for people who are hopelessly attached to that API? Those would be easier to subclass, at least, and we could probably do better than NeXT's original implementation if we tried hard enough... (I know these classes are is in OS/Mach for back compatability, but they will likely go away someday.) Depending upon the code you're converting, the conversion can get nasty, but I've not found lack of Lists and HashTables to be the nasty parts. OS-specific parts are often some of the worst offenders, followed by what Georg listed, with some of my own additions: IXKit, 3DKit--both of which the MiscKit is trying to rectify--DBKit, Speaker, Listener, and NXStreams. In the latter cases, OPENSTEP provides something better and I'd rather go through a little pain to use the improved base. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 21 Feb 1997 12:06:49 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.856555295@idiom.com> References: <jcr.856487960@idiom.com> <AF328494-208653@206.165.42.206> "Lawson English" <english@primenet.com> writes: >So, John, how's the Gratituous Insult business? Pretty good. I can always count on getting a reaction out of you! Still, I'm keeping the day job. >I mean, if you don't have enough time look up a word in a dictionary, but >DO have enough time to flame me, I gotta assume that yours was a >work-related post, right? And, if you think you've been flamed by me, then I can only surmise that you're not very experienced at net.flamage. -jcr
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 11:12:51 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <wn37U3O00iWm02vE40@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> In-Reply-To: <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> Excerpts from netnews.comp.sys.next.programmer: 19-Feb-97 Re: Mac/NeXT & Unix: File S.. by Mike Connally@dial.pipex >> However, I can't NFS mount a remote fileserver on a Mac and be able to >> run Mac executables, because they require the out-of-band information >> stored in their resource forks which is not representable within the >> standard NFS/UFS filesystem paradigms. > > Wrong. How is what I said wrong? AppleSingle and AppleDouble are archive formats, and my NFS server cannot represent the Mac resource forks the way HPS does without using such a mechanism. It's entirely comparible to the situation where you've got a .tar or .tgz archive on a DOS machine, and that archive contains filenames which can't be represented correctly under DOS's 8.3 filename limitations. > NFS client software is available for MacOS from several > vendors, and any Mac file (documents or executables) can reside > on any NFS server platform and be used by the Mac transparently. I already said that I was aware that commercial products exist which provide so-called "transparent" NFS support; but you don't get that software with MacOS, you have to pay for it. I don't have to pay for NFS on a Unix box, and there are commercial NFS implementations for the PC at $40 per client (QVT), whereas the cheapest Mac NFS client is $250 per machine. (From the NFS FAQ, http://www.rtd.com/pcnfsfaq/SecA.html and SecZ.html) Furthermore, let's consider exactly how transparent things really are. What happens when you do have this commercial Mac NFS client software. If I save a document like plain old ASCII text file or some common WP format like MS-Word from a Mac onto the NFS server, do I get (a) a file that I can walk over to a non-Mac system and be able to use as-is, or do I get (b) an AppleSingle or AppleDouble file that I can't use as-is? -Chuck PS: We could ask the same questions for SMB/Samba and for AppleShare, too. Of course, the wasted space from the blocksize of the Mac HFS on big drives means Macs are inefficient fileservers. An NT/Server box running on a FAT filesystem would also be inefficient, but you have NTFS as an alternative. Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Erik Sherman <104047.2607@CompuServe.COM> Newsgroups: comp.sys.next.programmer,pgh.next-users,sdnet.next Subject: Reporter seeks NeXT users Date: 20 Feb 1997 00:25:44 GMT Organization: CompuServe, Inc. (1-800-689-0736) Message-ID: <5eg5m8$bbp$2@mhadf.production.compuserve.com> I am writing an article for a national magazine on the experiences companies have had using the NeXT operating system. If you have used it in a corporation, non-profit, etc., I'd be interested in speaking with you. You can reach me at esherman@world.std.com. Erik Sherman
From: scocca@gibbs.oit.unc.edu (Dave Scocca) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 21:44:04 GMT Organization: The Jack Voigt Fan Club Message-ID: <5el4v4$kj2$1@newz.oit.unc.edu> References: <5ddp66$jpc@news.bu.edu> <peterm.856341833@ulfrun> <E5wKH0.363@free.fdn.fr> <Sword-2002972100410001@line033.nwm.mindlink.net> In article <Sword-2002972100410001@line033.nwm.mindlink.net>, Andrew Brownsword <Sword@mindlink.net> wrote: \ The HFS file format divides a disk into 65,536 chunks (sectors, clusters, \ blocks, whatever) and keeps a bitmap of which ones are allocated. Hence \ there is a hard limit at 65536, and in practice it will be considerably \ lower than that because most files are more than 1 block, plus each \ directory and the boot blocks take some away as well. Not to mention the fact that the resource fork and the data fork _each_ require a minimum of one block, so in effect anything with a resource fork takes up two spaces. I use some programs (e.g. Alpha, Textures, BBEdit) which put resource forks on a lot of things, and so have a bunch of small text files each taking up 63K on my 2GB hard drive. D. -- * The Minstrel in the Gallery http://sunsite.unc.edu/scocca/ * * D. A. Scocca (scocca@gibbs.oit.unc.edu) "Heteroskedastic" * * "My love does not, cannot _make_ her happy. My love can only * * release in her the capacity to be happy." --J. Barnes *
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 20 Feb 1997 10:31:44 +1100 Organization: Unisys Message-ID: <330B8D60.74C1@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> <8n2mO2O00iWl05_J00@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.programmer: 19-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >>> In any case, I come back to the original point, that in most cases it > >>> is inappropriate for the OS to send an error/exception back to processes > >>> that are waiting on resources, without at least trying some recovery, > >>> either automatic or with operator assistance first. If the OS doesn't > >>> do this then you do not have a very robust OS. > >> > >> Blocking a process because the kernel is waiting for an operator to tell > >> it how to proceed when some form of error occurs is the opposite of > >> robust! You can easily deadlock every runnable process if some crucial > >> system resource like inetd (*), named, lookupd, or the swapper > >> encounters a minor problem and must block until a human informs the OS > >> of what to do when that error condition could otherwise be handled > >> within the process. > > > > You are not only not reading correctly what I am saying, but in your > > misreadings are quite wrong. > > How am I misreading what you've said? Most of your responses show little understanding of what I have said, before you go into ultra defensive mode of Unix. > What is wrong with my statements? Your statements about both robustness and deadlock are wrong. Robustness is if an application calls a service, it expects the service to perform that function. If the service does not take responsibility to handle common error conditions, but just return an exception to the caller, that is the opposite of robust. If the service needs some operator input to help solve the situation then ask for it, don't just return an error to the application, because due to security it may not be able to access the system resources in the same way as the OS or operator. Your comments about deadlock also show lack of understanding. If a system resource becomes unavailable to all processes, then everything is going to lock up. You are defending the position that all these processes should be returned an error, when they have no control over the resource. This is also the opposite of robust. The case of deadlock may require some human intervention to prevent reoccurrence anyway, but what we are talking about here is not even a case of deadlock. > You've made vague assertions without anything to back your claims up. > I'm afraid that "proof by assertion" doesn't qualify as a legitimate > argument. Well, once again, Charles goes off the deep end into arguments about assertions, strawman arguments (of which he is the largest contributor), and stuff I really can't be bothered responding to. I notice he is a student attempting to complete his final year at Carnegie Mellion University. I suggest that he goes and learns something, instead of wasting time flaming on the net, and come back after he has learnt his lessons and gained much more experience. [Rest of abuse deleted] ------------------------------------------------------------------------ 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: stephen@ccc1.tamu.edu (Stephen Johnson) Newsgroups: comp.sys.next.programmer Subject: compiling multi-binary? Date: 19 Feb 1997 23:45:23 GMT Organization: Texas A&M University, College Station, Texas Message-ID: <5eg3aj$61q@news.tamu.edu> How do I compile for multiple platforms on a single platform? I'm compiling on a NeXT but need it for an Intel, also. Any pointers would be helpful, Stephen
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 21 Feb 1997 11:18:44 +1100 Organization: Unisys Message-ID: <330CE9E4.60AB@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> <8n2mO2O00iWl05_J00@andrew.cmu.edu> <330B8D60.74C1@acm.org> <kn36aXu00iWm02vRk0@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.programmer: 20-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >>>> Blocking a process because the kernel is waiting for an operator to tell > >>>> it how to proceed when some form of error occurs is the opposite of > >>>> robust! You can easily deadlock every runnable process if some crucial > >>>> system resource like inetd (*), named, lookupd, or the swapper > >>>> encounters a minor problem and must block until a human informs the OS > >>>> of what to do when that error condition could otherwise be handled > >>>> within the process. > >>> > >>> You are not only not reading correctly what I am saying, but in your > >>> misreadings are quite wrong. > >> > >> How am I misreading what you've said? > > > > Most of your responses show little understanding of what I have said, > > before you go into ultra defensive mode of Unix. > > You didn't answer the question; you simply rephrased what you previously > said as quoted by ">>>". If you aren't going to provide a specific > example of how I've misread your comments, fine-- go right ahead and > continue dodging the question. Well, unfortunately because of the way you have pursued the argument of this thing, this would become a you're dodging the question... no you're dodging the question match. To get a more reasonable line, you should stop accusing others in these groups of doing exactly what it is that you are doing. From your first response to what I said, you jumped straight in and responded as if I was some kind of biased idiot. I don't take it personally, as I have noticed your responses to others have showed a similar line of discourtesy. There are interesting things to be said in this thread, but unfortunately, you continue to make it extremely boring by jumping in and arguing about methods of argument. > >> What is wrong with my statements? > > > > Your statements about both robustness and deadlock are wrong. Robustness > > is if an application calls a service, it expects the service to perform > > that function. If the service does not take responsibility to handle common > > error conditions, but just return an exception to the caller, that is > > the opposite of robust. If the service needs some operator input to help > > solve the situation then ask for it, don't just return an error to the > > application, because due to security it may not be able to access the > > system resources in the same way as the OS or operator. > > If the OS itself blocks the process which asked for some service and > waits for the user to tell it what to do when an error occurs, then > neither the process being blocked nor any other process which depend on > that blocked process to make progress will be able to do anything. The process is blocked because the OS has not been able to service its request for a resource. That is it. If the programmer does not want the process to block on a currently unavailable resource, I have already told you how to cater for that situation. Processes do not block on each other. Processes block on resources. Deadlock occurs because one process locks a resource, and a second process locks another resource. Then both processes try to lock the resource that the other process already has locked. Your previous example was if one resource is unavailable, then all processes will block on it. What I am saying is if resources under the control of a resource manager are unavailable, it is the resource managers responsibility to ensure availability, and to resolve contention on the resource. It is bad policy for a resource manager just to hand an error back to a running process. It's like Basil Fawlty saying to the person at the desk "Hurry up, there are people waiting." > If any of these blocked processes is supposed to perform the action of > asking for user intervention and returning the user's response, the > system will be deadlocked. No, you don't understand deadlock. Once the first process clears, all other processes will also clear. How is a system level service going to block on a user process? It just won't happen by design. Not only do you not understand deadlock, but you don't understand that it is irrelevant to what I am saying. > > Your comments about deadlock also show lack of understanding. If a > > system resource becomes unavailable to all processes, then everything is > > going to lock up. > > That's correct. How do you get from this statement to my supposed "lack > of understanding"? > > > You are defending the position that all these processes > > should be returned an error, when they have no control over the > > resource. > > Correct. Processes do not have "control" over system resources; what is > what the operating system is for. Now you are close to understanding! > The OS manages system resources by implementing serialization mechanisms > for non-preemptible resources like tty's, printers, the network, disk > I/O to individual files, and so forth, and by implementing means of > preempting resources like the CPU which can be preempted (otherwise > known as preemptive multitasking). > > > This is also the opposite of robust. The case of deadlock may require > > some human intervention to prevent reoccurrence anyway, but what we > > are talking about here is not even a case of deadlock. > > Having the OS attempt to ask a user what to do when errors occur most > certainly can lead to deadlock. I can demonstrate examples of > interdependent processes on real-world operating systems which would > satisfy the four necessary conditions for deadlock. > > For example, let's consider NEXTSTEP's WindowServer. Say the > WindowServer tries to blit a bunch of bits via a DMA transfer handled by > a video driver within the kernel, and the DMA transfer encounters an > error. If the OS blocks the WindowServer due to the error and then > tries to tell the user an error occured and ask what to do about it by > having the WindowServer attempt to pop up an alert panel, the system is > going to deadlock because the WindowServer is already blocked trying to > draw and will never get unblocked in order to draw that alert panel. > > Therefore, the system is deadlocked. This doesn't sound like a very well designed system. Some errors will be in the category of lower level. Such primitive errors should by-pass standard mechanisms for display, if there is the possibility that the standard mechanism has become unusable. This is not a new problem, and OSs are already designed for this possibility. However, as usual your example is irrelevant to my original point that resource managers provided as part of the OS should take more responsibility to resolve resource problems before returning exceptions to clients. This greatly simplifies the client programming. Now I suppose you will respond with more accusations of bias, strawman arguments, dodging the question, etc. ------------------------------------------------------------------------ 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: jcr@idiom.com (John C. Randolph) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 20 Feb 1997 17:21:57 -0800 Organization: A poorly-installed InterNetNews site Message-ID: <jcr.856487960@idiom.com> References: <5eidi8$9nt@news3.digex.net> <AF3219BD-76C68@198.68.42.250> "Lawson English" <english@primenet.com> writes: >John Kheit <jkheit@cnj.digex.net> said: >>jcr@idiom.com (John C. Randolph) wrote: >>> You're going to be a Lawyer! You should know that the correct >>> word isn't"Monolithicness", it's "monolithicity!" >> >>Actually, neither show up in websters. >Monolithicism, on the other hand, does. Webster's 3rd New International >Dictionary: >Monolithicism -the state of being monolithic. Well, the thirty-day killfile entry expired, and what do I see right away? An article by Lawson, demonstrating once again, that he has far more time on his hands than I do. -jcr PS: So, Lawson: Any luck on the GX advocacy fight?
From: tbrown@netset.com (Ted Brown) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 21 Feb 1997 23:57:34 -0500 Organization: NetSet Internet Services -- Columbus, Ohio Message-ID: <tbrown-2102972357350001@ppp007.dialup.cmh.netset.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> In article <AF2E42E196681EFC18@node50.tfs.net>, tbutler@tfs.net (Travis Butler) wrote: >The problem is, I couldn't care less about a multiuser operating system. I >bought my Mac for use by a single person: me. With the exception of server >machines, every single Mac -- heck, every single *personal computer* -- >I've ever seen has been used by one person at a time. The majority of them >have been used by a single person, period; if you leave out the CS lab >machines, that becomes an overwhelming majority. Apple seems to think that there are 2-3 users/mac. I too bought my Mac for use by a single person: me. But, it happens to be regularly used by friends, my father, and visitors. It doesn't matter if the machine is used by one person at a time, it matters that more than one person uses the machine. A multi-user machine can adapt itself to the current user (or multiple needs per user, like development, gaming, and browsing). With a multi-user OS, I could leave my friends/visitors (for one it's the only time he touches a computer), w/o worrying that they'll accidentally delete things, mess with private files, change some configuration, etc. I've owned a NeXT Cube, I'll welcome Apple making additions for multiple users. Apple is known for getting the little things right and making a system that works as a whole. NeXT did the same thing. I'll restate something that other NeXT users have said -- *use* OpenStep before you work yourself into a tizzy. Sure OpenStep uses file extentions, but somehow it didn't rub me the wrong way like they did on Win 3.1, and still do on Win 95 (though less so now that I have long file names). Apple won't be succeed/fail on something like CREATOR/TYPE codes. Resource forks are nice, but are nothing when compared to an .app directory and .nib files. Nor did the concept of putting applications where "the OS wanted them", rub me the wrong way. I tend to put apps in my Applications folder on my Mac anyway. I don't really like to spend time figuring out where to put stuff, I'd rather just throw them in the default location. You mention that it's the "macintosh way" to let the user decide where to put stuff. I'll counter that it's the macintosh way to allow the user to forget/ignore mundane things like "where do I install this app". I usually want to put *data* files where I want them, rather than Applications. I put aliases to apps where I want quick access to them. All of this I can do under NeXTStep. Again, I think that you are looking at NeXTStep as pieces, rather than the gestalt. -- Ted Brown tbrown@netset.com
From: j-norstad@nwu.edu (John Norstad) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Fri, 21 Feb 1997 20:36:01 -0600 Organization: Northwestern University Message-ID: <j-norstad-2102972036010001@legume186142.nuts.nwu.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: > NuKernel should have been scrapped before > a single line of code was written. Protected memory, but only for certain, > "special" processes? What a crock of sh*t. To pick a nit, this has nothing to do with NuKernel, but with the higher levels of Copland. I'd rephrase your statement: *Copland* should have been scrapped .... what you said. NuKernel was actually a pretty nice kernel, at least as far as I could tell from the white paper released way back in 1995. It was the rest of Copland that sucked, specifically the crazy requirement that any task which drew in a window or interacted with the user had to live in the blue box, and hence could not benefit from preemptive scheduling or protected memory, which in turn led to the even crazier notion that apps would be factored into "server" and "UI" tasks which communicated via Apple events. Yuck. Rhapsody is a much better idea. I think Rhapsody as OpenStep on NuKernel would have been just fine, but would have taken longer to develop than Rhapsody as OpenStep on Mach. This time to market factor is why Mach was chosen, I believe. Due to ignorance, I have no opinion on the relative purely technical merits of Mach vs. NuKernel. -- John Norstad <mailto:j-norstad@nwu.edu> <http://charlotte.acns.nwu.edu/jln/>
From: Sword@mindlink.net (Andrew Brownsword) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 21:00:41 -0800 Organization: MIND LINK! - British Columbia, Canada Message-ID: <Sword-2002972100410001@line033.nwm.mindlink.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <199702182327301079516@q700.hf.org> <peterm.856341833@ulfrun> <E5wKH0.363@free.fdn.fr> In article <E5wKH0.363@free.fdn.fr>, Fabien_Roy@free.fdn.org wrote: >peterm@dna.lth.se (Peter Moller) wrote: >> hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) writes: >> >Scott Hess <shess@one.net> wrote: >> >As far as I recall, there _was_ a limit of about 6k files per volume. >> >> That must be a really old figure: I have a HFS-volume with more than 25,000 >> files on it and there's no problem at all. I think the limit is 32,767 >files. >> > The HFS file format divides a disk into 65,536 chunks (sectors, clusters, blocks, whatever) and keeps a bitmap of which ones are allocated. Hence there is a hard limit at 65536, and in practice it will be considerably lower than that because most files are more than 1 block, plus each directory and the boot blocks take some away as well. The other unfortunate side effect is that if you have a disk of 2^63 bytes, the smallest possible file is 2^47 bytes. This is funny because it is so extreme. The reality that a 9 gig drive has a minimum file size of 144K isn't so funny. A new file system is long overdue for performance, flexibility and efficiency reasons. The file system Apple was building for Copland looked pretty impressive, and was fully multi-threaded and format independant. Hopefully they can salvage something from that effort, but anything is better than the current file system (except DOS, mind you). -- Andrew Brownsword Software Engineer "What I said here is what I said, not what anybody else said. I'm speaking for just me, myself, and I."
Date: Thu, 20 Feb 1997 12:51:14 -0600 From: Benoit.Marchant@questintl.com Subject: EOF2 and DO troubles Newsgroups: comp.sys.next.programmer Message-ID: <856464472.8723@dejanews.com> Organization: Deja News Usenet Posting Service Hi, I have a strange thing. I have a framework with me enterprise objects and eomodel, and an application based on this framework. I order to access appController which owns editigContext etc ..., I made appController a root object of a NSConnection and register it from my enterprise objects. So in a class method in my EO's framework, I implemented a fetch to retrieve special instances by fetching with an editingContext obtained by sending a message to the proxy on appController. It works, my method return a correct NSArray with instances in it. I my application I get this array and extract an instance of it named for exemple aFamily. If I add it in a relation of an eo just created with the same eoeditingContext as one used for the fetch before (which is obtained by [appController editingContext], the application go in a a spin when I execute [editingContext saveChanges] and finally crashed. If I make another variable aFaultFamily by aFaultFamily = [editingContext faultForGlobalID:[aFamily globalID] editingContext:editingContext] and insert it in the relation, it works like a charm. If I make a po of both instances, I get same results po aFaultFamily <IngredientFamily: 0xc2c77c> (gdb) po aFamily <IngredientFamily: 0xc2c77c> If I make print I get print aFamily $1 = (class IngredientFamily *) 0xbba6ac (gdb) print aFaultFamily $2 = (class IngredientFamily *) 0xc2c77c Does someone could explain me what is the reason ? Is it not recommended to use editingContext over NSConnection ? What are other solutions to keep business rules in the EO's framework insted of doing categories in the app when it's necessary to make fetch from class methods ? Thanks in advance for any help and ligth !! Benoit Marchant -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: peterm@dna.lth.se (Peter Moller) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 97 07:28:46 GMT Organization: Lund University Message-ID: <peterm.856510126@ulfrun> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> <5ej0nn$6t6@kaopala.mhpcc.edu> altenber@acpub.duke.edu (Lee Altenberg) writes: >Here's an example of why I can't stand the Mac's HFS file system. I just bought >the Sonata font from Adobe. Adobe told me the Mac version would work with >NEXTSTEP. So, I got the suckah, and put it on a Power Mac. I then used Fetch >to send it over the network to my PC running NEXTSTEP 3.3. Fetch allowed me to >pick Mac Binary II or BinHex. I tried both. When Opener on the NeXT side opens Which version of Fetch was that? Fetch has to my knowledge always had the option of 1) AppleSignle, 2) AppleDouble, 3) Raw data and 4) BinHex. Of these, you should of course use Raw data. I admit this is kinda confusing, but this is the way it will be until all computer systems have the same kind of file system (which I guess/hope will never happend) *or* well thought out "Helper System" than can aid you when "talking" (in a wide since) to another computer system. I guess we need C3PO :-) -- -------------------------------------------------------------------------- Peter.Moller@dna.lth.se, System Manager @ DNA & LUDAT Department of Computer Science, Lund Institute of Technology Box 118, S-221 00 LUND, Sweden, tfn +46 -46 10 41 56, fax +46 -46 13 10 21
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 08:13:08 GMT Organization: Save the Skeet Foundation Message-ID: <5em9qk$3eu@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> Cc: tokarek@students.uiuc.edu In <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> it appeared that Ryan Tokarek wrote: > On 22 Feb 1997, Gary W. Longsine wrote: > > > In <jm041536-2102971103330001@mencjo.apple.com> it appeared that Joaquin > > Menchaca wrote: > > > In article <SHESS.97Feb20085428@howard.one.net>, shess@one.net (Scott > > > Hess) wrote: > > > > > <snip> > > > This is very well said. That was my original concern about the decision > > > about using a monolithic kernel from NeXTSTEP (OPENSTEP for Mach). I > > > think technically this is a mistake. It may be outrageous to say this, > > > but I think NuKernel of Copland is a better choice as it combines the best > > > of Apple with the best of NeXT (OPENSTEP). > > > > Then you haven't got a clue. NuKernel should have been scrapped before > > a single line of code was written. Protected memory, but only for certain, > > "special" processes? What a crock of sh*t. > No, no. You haven't a clue. > > _Every_ process was to be protected under Copland with NuKernel. The > collection of tasks that ran as one large task (the compatibility box) and > was run internally with cooperative multitasking was protected (CMT > because of the continued use of a non-reentran GUI). No OS task nor any > other task could read from or write to anything in the compatibility box. [munch] > You were mistaken. Although you are technically correct in the strictest sense, when you say that every process would have had protected memory, you offer a misleading claim about the worthiness of Copland and the NuKernel, and fail to acknowledge the ugly truth: Copland would have forced <ALL> ordinary user applications, even brand spanking new ones for MacOS 8, to reside in the same memory space. Only apps specially written could get their own memory space, and the only apps eligible for such special treatment were those without a GUI. Who thought that was a good idea? Who in the hell thought <that> was a good idea? I don't even know <who> thought <that> was a good idea. Although I am perhaps guilty of being a bit inflammatory, I am nonetheless right. You are defending the (indefensible) technological equivalent of Windows 95, which as you probably know is a horrible, unstable, hunk of junk. Copland would have been just like it. I am *sooo* glad that usenet is not deciding the architecture of Rhapsody. Popular vote in Mac.advocacy would have picked: <> NuKernel <> Punt UNIX (in favor of what? nobody ever said) <> MacOS GUI (long may it wither) <> GX (punt DPS) <> Open Transport <> The MacOS filesystem Now, this looks like Pink/Taligent/Copland, to me: Over 5 years. Nearly 1/2 a billion dollars. Still no OS. In the meantime, NeXT delivered to market several iterations of a rock-solid modern operating system, and premier developer tools, which had all the features that both Apple and Microsoft failed to produce. Apple has finally caught a bout of the clue, in buying NeXT and making good use of the NeXT technology & talent. I only wish they had merged two years ago. /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: "Joseph A. Woo" <jwoo@wootech.com> Newsgroups: comp.sys.mac.system,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 21 Feb 1997 02:00:21 -0800 Organization: Wootech Corporation Message-ID: <330D7233.CE1@wootech.com> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For those of you that are posting this thread to the PowerPlant newsgroup, please stop. This newsgroup is for PowerPlant, and not Next or UNIX. Thanks. Joseph A. Woo Sr. Software Engineer Wootech Corporation
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 07:04:21 GMT Organization: Save the Skeet Foundation Message-ID: <5em5pl$3eu@news.platinum.com> References: <5eldq2$kj@news.platinum.com> <AF3392D0-8B354@198.68.42.175> Cc: english@primenet.com In <AF3392D0-8B354@198.68.42.175> it appeared that "Lawson English" wrote: > Gary W. Longsine <gary-nospam-@screaming.org> said: >> > >Then you haven't got a clue. NuKernel should have been scrapped before > >a single line of code was written. Protected memory, but only for > certain, > >"special" processes? What a crock of sh*t. > No, only "special" processes would NOT be protected: those that were > sitting in the Blue Box. Bzzzt! Thank you for playing, Contestant Two! Tell him about the consolation prize, Bob! Our second contestant will receive, as consolation for playing, and losing, "You Bet Your Mission Critical Custom Application" -- two quotations! These bits of knowledge hail from chapter 3, (Address Spaces and Memory Protection), of the detailed, well-written, Copland-friendly and authoritative description of the mercifully killed Copland project -- "MacOS 8 Revealed: A Technical Tour of the New Mac OS", published by Apple Press, written by Tony Francis... " Our contestant will also be given a small box, with an ant in it, and some left-over pizza that we have back-stage... "MacOS 8 assigns all cooperative programs to a shared address space. [...] These applications, by the way, are cooperative programs because they present a human interface." and later in the chapter... "If you're a developer, you can begin preparing to take advantage of multiple address spaces by determining whether some portion of your product benefits from the extra protection afforded by a separate address space. If so, you should plan to implement this portion as a server program." The dirty little secret of MacOS 8 was that, under Copland's NuKernel, [x] All ordinary applications (not just System 7 apps), by default, run in what we now think of as the "Blue Box" -- a single address space, where they are free to trample each other. [x] All applications with a GUI interface <MUST> swim in the community memory pool. [x] As a developer, you must go out of your way to design server processes for applications that, "could benefit" from protected memory [x] Even Windows NT has a better memory protection architecture than that I stand by my proposition that, were I the highly paid Sr. VP at Apple in charge of Copland, sitting in a room with a bunch of engineers who described this kind of architecture to me, as the foundation of our new <modern> OS, I would have fired the idiots on the spot. I normally don't get quite this harsh, but really folks, there is not much room for argument here. Copland, kernel and all, was fundamentally mis-architected, and even if there exist interesting ideas in the project, it is very doubtful that any of the actual code will ever be of use to anyone writing a modern OS. /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 20 Feb 1997 17:57:16 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> In-Reply-To: <19970220100923348851@roxboro-169.interpath.net> Excerpts from netnews.comp.sys.next.programmer: 20-Feb-97 Re: Mac/NeXT & Unix: File S.. by John Moreno@interpath.co > ] The answer is whichever file was modified last, and can be answered > ] using the last-modified timestamp; the creation timestamp isn't > ] needed. > > My point was there but I apparently didn't make it clear enough: You > are doing some ad hoc data acquisition and analysis - you do your first > test and save it, then you do your second test and save it. You play > with both of them a bit and then go home, where you come down with > pneumonia and are out of the office for two weeks. When you come back > to the office you can remember which test you did first but not what you > named the file. That one's a bit of a stretch tho, so how about this - > you have a program that automatically saves (thereby changing the > modification date) whenever the file is even viewed. Both of those sound a little contrived, I'm afraid. I've done random bits of data acquisition and you pretty much always put a date/timestamp within the data file itself. As for the always-saves-even-unchanged program, I'd say that it was simply broken. :-) Basicly, my claim is that the only circumstances that I can think of where I would really care about the distinction between the last-modified and creation timestamps are when I'd want to use a complete revision control system..... >] Come to think of it, perhaps Apple will provide this functionality by >] making Rhapsody's system loader understand the AppleDouble format >] directly as an executable format. It's rather similar to the way >] NEXTSTEP handles the Mach-O and MAB (FAT binary) executable >] formats.... > > I'd think you'd want to use the AppleSingle format, but other that, > yeah. What's really important isn't the format of the file, but that the > part of the system that transfers files over the network knows about it, > and that all of the information is there. [ ... ] Agreed. And doing so would ease some of the requirements for the NFS and other fileserver implementations which have to interact with the MacOS or Rhapsody. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: wagnerer@umich.edu (Eric Wagner) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 02:31:21 -0500 Organization: University of Michigan EECS Message-ID: <wagnerer-2202970231210001@inferno.eecs.umich.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> In article <19970220100923348851@roxboro-169.interpath.net>, phenix@interpath.com (John Moreno) wrote: *Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: * *] Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT *& *] Unix: File S.. by John Moreno@interpath.co *] > ] Perhaps it's just me, but I don't see much value to preserving the *] > ] timestamp of the creation date of the original version of a file *] > ] when you don't actually have the original file-- just the modified *] > ] version. Can you provide a real-world example of why you'd care *] > ] about that timestamp? *] > *] > A very simple and quit answer is when you have two files with *] > basically the same information and have modified both since their *] > creation and want to know which file is newer. *] *] The answer is whichever file was modified last, and can be answered *] using the last-modified timestamp; the creation timestamp isn't *] needed. *] *] Again, that doesn't answer my question. * *My point was there but I apparently didn't make it clear enough: You *are doing some ad hoc data acquisition and analysis - you do your first *test and save it, then you do your second test and save it. You play *with both of them a bit and then go home, where you come down with *pneumonia and are out of the office for two weeks. When you come back *to the office you can remember which test you did first but not what you *named the file. That one's a bit of a stretch tho, so how about this - *you have a program that automatically saves (thereby changing the *modification date) whenever the file is even viewed. * *] [ ... ] *] >] Such a system could rely on just the file extension if the Mac-like *] >] creator/filetype attributes are not available or are not recognized *] >] [consider a file that has been FTP'ed or is being accessed via a *] >] remote filesystem like NFS, AFS, etc], but could also pay attention *] >] to the Mac attributes if they are available and valid. That seems *] >] to combine the desirable features without changing the way either *] >] current Mac users or current NEXTSTEP users like to have things *] >] work.... *] > *] > I've seen this "accessed via a remote filesystem" argument used *] > before and have never really understood it. If the computer at the *] > other end is a Rhapsody machine then I'd expect the additional *] > information to be passed along, if it isn't a R.M. then what kind of *] > file is being accessed where the person getting it doesn't know what *] > it is? *] *] You're missing the point. When I access a file via a remote *] filesystem, I shouldn't need to care whether it's a R.M or not. I *] should be able to use any type of fileserver without having problems, *] and I should be able to run executables directly off of the *] fileserver. *] *] Come to think of it, perhaps Apple will provide this functionality by *] making Rhapsody's system loader understand the AppleDouble format *] directly as an executable format. It's rather similar to the way *] NEXTSTEP handles the Mach-O and MAB (FAT binary) executable *] formats.... * *I'd think you'd want to use the AppleSingle format, but other that, *yeah. What's really important isn't the format of the file, but that the *part of the system that transfers files over the network knows about it, *and that all of the information is there. About a week ago Jonathan *Hendry posted saying that "it would be difficult (if not impossible) to *run a Macintosh application that is stored on a non-HFS disk". This *sounds plausible but, as I said in my reply to him, since all of the *information associated with a file is transfered to a PC disk when you *copy a file back and forth it seems to me that if that was the case it *would be a failure of the system since it should be possible. I *immediately tested this by inserting a DOS formatted disk into my drive *and copying a small application to it and then trying to execute it. It *worked flawlessly. There is no reason that the same thing couldn't *happen over a network connection and in fact I would expect it to work *today over a properly setup network. * Actually such a system already works at the Univ of Michigan. We use the afs file system which esentially puts all user accounts and commercial software into one file structure that acts as the basis for the computers on campus. Mac's access afs through the chooser and use any of the files they have just used on there unix account. In fact I make extensive use of this myself. I have a telnet window open to a computational server that saves its output to a file and a graphics program on the mac both accessing the same file system displaying the data. Works pretty well in my case. Plus I like CodeWarriers IDE on the mac to write the programs (love that color coding) and a quick make on the comp server side compiles the program and runs it. The only complaint I have is that the icons for the unix files when seen from the mac side are quite ugly. Eric
From: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 21 Feb 1997 02:45:59 -0800 Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Message-ID: <5ejud7$2pk@crl9.crl.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> (M (anti_email_spam@real.address.in.sig)) wrote: : In <5ddtsg$oba$1@majipoor.cygnus.com>, jrudd@cygnus.com wrote: : > In <5ddp66$jpc@news.bu.edu> John Siracusa wrote: <Discussions about data/resource forks in files vs "wrapper" directories, text vs binary configuration files, etc., snipped> Having worked with MacOS and NeXTSTEP, and lurked in the BeOS newsgroups since their inception, it seems that everyone here has some valid points as well as preconceptions about what the "other side" does regarding the treatment of formatted vs freeform data in files. The same arguments came up in discussions of how Be's filesystem should be structured. Lemme give some of my observations: 1. The use of directories to encapsulate and structure n-fork data sets ("files") seems to me to be a rather elegant concept. One architecture, one API, rather than the split filesystem / resource map database and APIs that the Mac's HFS currently uses. Look at how the Finder displays custom icons: hidden "Icon\r" files for directories, 'ICN#' -16455 resources for files. It would demand performance from the filesystem at least better than that in the current Resource Manager. 2. There still needs to be a class of "raw data fork" to contain what is ubiquitously "default" data, for example, vanilla text sans the font information/window positions/icon images, etc. 3. The type of a document is not equivalent to how the user works with it. For *.c or *.html files the user may in different circumstances launch different IDEs, browsers, or editors, for different files with the same extension or even for the same file at different times. A configuration file, for example, _can_ be text but that doesn't preclude other apps from manipulating it more effectively/safely. 4. To have a mapping between documents and applications to launch for them at the granularity of individual files implies information at potential- ly one-to-one correspondence with the files. (e.g., filename suffixes or type/creator codes.) To have _multiple_ users _each_ with a different mapping preference for individual files looks like it's a many-to-one correspondence. Seems that can get unwieldy to manage, or at least one that begins to parallel the filesystem for _each user_. (Everyone gets a Desktop database). I suppose they can inherit the global mapping and simply override. 5. Tacking filename extensions to type the data in a file IMHO never seemed that elegant, but it _is_ a common convention (*.c, *.h, *.html). It's okay when it coincides with the user's level of abstraction _but_ it invades the namespace when it doesn't. "Thoughts on Foo Design.rtf" looks funnier than "Thoughts on Foo Design". (Affixes are useful but as a user I'd rather think in terms of content as opposed to syntax, especially if it's a compound document anyway.) 6. The ability to move/rename documents/applications in the filesystem and for things still to be able to find each other and work, is an expected feature for many Mac users, and is part of the Mac experience. (_Some_ files/folders are immovable/renameable but they are few and I don't think are considered a problem.) Renaming "System Folder" to "Engine Room" and moving it into "Etc", moving software from "Stuff to Evaluate" to "My Applications" and "Discard after Easter" folders, and renaming applications is no more effort than rearranging a clothes closet. However, the robustness needed to have documents itinerant and still locatable might conflict with the efficiency needed for (1). 7. It's often better to think of files/documents as _objects_ anyway. Just as there can be several 'accessor methods' to an object's internal variables, there can be several front-ends to edit a config file. It shouldn't matter to the user whether it's in binary, text, or Swahili, as long as there are safe enough methods to access it for the casual user and powerful enough ones for the knowledgeable user. If you think about it _all_ documents (even textfiles) are accessed by a UI "method" of one form or another. The base method for accessing a text document is simply Edit / SimpleText / whatever. (It's not as if you're directly manipulating the magnetic polarities on the platter.) (You _would_ have a general fork editor if SimpleText and ResEdit were rolled into a single application. Well okay, BBEdit and Resorcerer. :-) The key is that if configuration data really _is_ text but its integrity requires special formatting or syntax, it simply shouldn't be openable by default with simple text editors -- just as an internal variable of an object shouldn't be accessed directly. If you don't want people to open things with a plain screwdriver, don't attach the cover with plain screws! A standard _structured_ text format, such as NeXT's PropertyList, or Apple's MCF, or even AppleScript, would make textual config files easier to handle, though I suppose for performance/space/maintain- ability it's really up to the implementation. One could just as well do it with PPobs. 8. The primary GUI "shell" can enforce the interface consistency. In the Finder I can double-click the System file and "look inside" the system sounds, or do the same to the Users & Groups control panel to "see" the users. They both look and act like folder windows even though one is a control panel and the other the system file. A ResEdit look-alike can be written to work with resource-fork-like directories. Protocols can (and have) been written to make Unix filesystems map to HFS's data+resource+FInfo file forks. I remember in comp.sys.next.* that someone had basically replicated the functionality of the NeXT Workspace Manager in a relatively modest number of lines of code. Would it be that hard to put a Finder "shell" in the yellow box? After all, Greg Landweber managed to build "Greg's Buttons", a File Viewer lookalike for the Mac. Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 23:19:19 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eap1n$c6r@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <Mn0tGpa00iV3A4W=0F@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Peter Moller@dna.lth.se writes: > > SomeoneProbablyNamed Charles Swiger wrote: > >> Perhaps it's just me, but I don't see much value to preserving > >> the timestamp of the creation date of the original version of > >> a file when you don't actually have the original file-- just > >> the modified version. Can you provide a real-world example > >> of why you'd care about that timestamp? > > > > Easily; quite often I try to figure out which version of a file > > or a program is the oldest and the created time stamp is very > > handy in those situations. > > The last-modified timestamp serves that purpose better than the > creation timestamp does. If the file has never been editted, > the last-modified timestamp is identical to the creation timestamp. > If the file has been changed, the last-modified timestamp will > tell you which version is oldest whereas the creation timestamp > does not. This will probably not be a convincing enough example, I just know that I've found this useful at times on MTS: When talking about timestamps, you are not always comparing different versions of the same file. Sometimes you are comparing unquestionably different files, which are related somehow. In that case, it can be useful to notice that the creation date of one set of files are all about the same, even though their last-modified time is different. Back in the world of Macs, I can tell you that there's a very very useful program called "Keyserver" (www.sassafras.com) which takes advantage of the creation date info. It ignores the lastdatachange info, and for good reason. Keyserver is used to key applications, thus making sure that you're living up to the licensing agreements of the application. Using keyserver is much nicer than the NeXTSTEP method of each developer coming up with their own unique schemes to track the licenses of their individual products. What it uses to identify an application is it's size, and it's creation date. It can't use the modification date, as that may change. I'm skipping over a bunch of details here, as I'm not really out to describe all the ins and outs of Keyserver. In any case, this works very well. It'd be a shame to lose it. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Jim_Miller@suite.com Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 22 Feb 1997 04:17:21 GMT Organization: OnRamp Technologies; ISP; Dallas/Ft Worth/Houston, TX USA Message-ID: <5els0h$agc@newsread.onramp.net> References: <5dvfhi$s0i@sjx-ixn2.ix.netcom.com> <5dvuuq$3fs@news.next.com> mpaque@next.com (Mike Paquette) wrote: >The assorted DYLD environment variables are strictly for debugging >purposes. They aren't available to apps running from the Workspace, >or when running as the superuser (root) for obvious reasons. This is bad. We sell a product that consists of a bunch of executables (that run in the background), a couple of OpenStep applications (launched from the Workspace), and a dynamic library. The executables and OpenStep applications are linked with the dynamic library, and our customers will link their OpenStep apps with the dynamic library. The lack of a DYLD mechanism that works for apps launched from the Workspace will force our customers to install our dynamic library in a directory that has the same path as the directory the library was built in. In other words, our customers will have to install our product into a specific directory with a fixed name and path. They will not be able to install our product into a directory of their chosing. If they do, then none of our OpenStep applications that use our dynamic library will run. Am I correct, of am I misunderstanding something? Jim_Miller@suite.com -- ____________________________________________________________________ The Internet is a land bridge for memes ____________________________________________________________________
From: frank@this.NO_SPAM.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 14:03:56 GMT Organization: Frank's Area 51 Message-ID: <5eka0c$98d@bias.ipc.uni-tuebingen.de> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> <5ej0nn$6t6@kaopala.mhpcc.edu> Cc: altenber@acpub.duke.edu In <5ej0nn$6t6@kaopala.mhpcc.edu> Lee Altenberg wrote: > Here's an example of why I can't stand the Mac's HFS file system. I just bought > the Sonata font from Adobe. Adobe told me the Mac version would work with > NEXTSTEP. So, I got the suckah, and put it on a Power Mac. I then used Fetch > to send it over the network to my PC running NEXTSTEP 3.3. Fetch allowed me to > pick Mac Binary II or BinHex. I tried both. When Opener on the NeXT side opens > the *.hqx or *.bin files, it shows 0 bytes in the *.data file. All the data is > in the *.rsrc files, i.e. the resource fork. Why is all the font data (these > are the bitmap and outline files) in the resource fork, not the data fork? > Anyway, the outline file is supposed to be ASCII PostScript, but it has lots of > binary data in it. What a PITA! By the way, if you know what is wrong and how > to fix it, please drop me a note. > Copy your Sonata font on a Macintosh HFS Disk 1.44 MByte as plain file (it should have the 'Shaded A' icon for a PS font), get my FontConvert.app from peanuts.leo.org or next-ftp.peak.org, install and start in on your NeXT (Running NS 3.x or OS 4.x). Insert and mount your Mac Disk, show FontConvert the font, it should be able to convert it painlessly and will calculate a suitable AFM file in the process... BTW FontConvert.app is freeware/send-me-some-money-if-you-really-like-it-ware, the next release will be using the CAP (Appletalk) file name scheme for resource and finderinfo data, so you can directly use a network mounted Appleshare'ed volume. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: fucuco@hamlet.net (Good Friend) Newsgroups: comp.sys.next.hardware,comp.sys.next.marketplace,comp.sys.next.misc,comp.sys.next.programmer,comp.sys.next.software Date: Fri, 21 Feb 1997 10:30:13 GMT Message-ID: <cancel.330d7930.6000913@news.uoknor.edu> Subject: cmsg cancel <330d7930.6000913@news.uoknor.edu> Control: cancel <330d7930.6000913@news.uoknor.edu> Organization: Usenet Canal Historique ECP/EMP aka SPAM or pyramidal scheme (MMF) cancelled by bofh@keltia.freenix.fr It may also be an image too small for newsbot to be activated. See report in news.admin.net-abuse.bulletins. Date: Fri Feb 21 15:14:41 1997 Original subject was: Learn to Make $$$FAST CASH$$$ With Honest Work
From: akki@sic.co.jp (KAWAMATSU Akira) Newsgroups: comp.sys.next.programmer Subject: Questions another Page Orientation at Once Date: 21 Feb 1997 08:23:44 GMT Organization: Software Industrial Co., Ltd. Tokyo Japan. Distribution: comp Message-ID: <5ejm2g$l1d@inetserv.sic.co.jp> Hi. I'm new here in this group. I have a Question about Printing by NeXT programming. Q. How to print another Page orientation at once. I wanna print Portlait and Landscape Format(A4) at One print Action. First page is OK, but second page cannot print well for affecting first page Orientation. (at the case,2nd page is prined by Portlait image.) I wanna change page orientation directly. If you know some hints,Please email to me. environment: OS : NeXTSTEP 3.3J(Japanese Edition) lang : Objective-C Thanks in advance. -- written by Akira Kawamatsu From Japan to Love.
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Fri, 21 Feb 1997 10:42:41 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Un3Q9l_00iVC022esD@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> In-Reply-To: <330CEC81.5A34@acm.org> [ ...Followups redirected out of the programmer groups... ] Excerpts from netnews.comp.sys.next.programmer: 21-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >> If you understand the difference, why did you claim that "your process >> would probably suspend..." when a process using non-blocking I/O will >> not suspend? >> >> Contradiction detected. > > Do you understand the meaning of the word probably? Yes. In this context it would mean that some task has non-deterministic behavior which is being described by probabilities as to whether the process would block or not. However, whether a process will suspend or not is deterministic-- either it will or it won't depending on whether it used blocking or non-blocking I/O. Therefore, "probably" is an inappropriate term to use. [ ... ] >> According to what you've said, if I find Unix a better solution for some >> task, then I can't be a "real user of computers"? >> >> What nonsense.... > > You are correct, your previous statement was nonsense. Please stop > putting words in my mouth, and then arguing as if I said them. Isn't it odd how you deleted your words which I was responding to? Here's what you said: > Good, but my exact point is that there is still much progress to be made > in the OS area. And certainly if you talk to real users of computers, > they find other non-Unix solutions better alternatives My comment was fully justified by this statement of yours, which in your own words was "real users of computers" "find other non-Unix solutions better alternatives". I have good reason to question both this overgeneralization and the reason why you would make an association between "real computer users" and "non-Unix solutions". > And you are the first to accuse others of the strawman tactic! A strawman argument is an attempt to distort someone's argument until it says something untrue and then refute this untruth as if you were responding to the original argument. I didn't distort your words in the above exchange-- the question I asked was an obvious way of refuting your overgeneralized claim. Futhermore, I made sure that I quoted everything you'd said instead of snipping off the relevant context the way you did. You cannot accuse me of distorting your words when I quoted exactly what you said. I don't resort to strawman arguments. I don't need to. On the other hand, it's a fact that you did resort to strawman arguments when you repeatedly claimed that I haven't used other operating systems aside from Unix sufficiently. It's also a fact that you were wrong to claim that "Unix is bloated". I believe you were lying when you claimed that you wanted to have a technical discussion, Ian. I challenge you to disprove my belief by addressing the technical points that I have made. Start by addressing your claims about the size of Unix as compared to on the observable facts from using the 'du' command. Judging from your past and current behavior, however, you'll snip this whole section instead of responding to it or admitting the truth. >>>> That's why people write software layers on top of the OS, such as >>>> OPENSTEP, which provide higher level abstractions which use the more >>>> primitive functionality provided by the OS. And that's where those >>>> high-level abstractions belong-- not in the kernel.... >>> >>> Right, but as far as an application is concerned that is the OS. >> >> You have one of the most bizzare viewpoints I've ever seen. > > Not at all. From the applications viewpoint, when it calls a system > level service for a resource, it is calling the OS. That's a tautology-- if you're calling a "SYSTEM level service", obviously you're involving the "operating SYSTEM". However, you can do lots of things with OPENSTEP that do not involve system level resources and the OS at all. >> OPENSTEP is not an operating system; it's an software layer that >> provides an abstraction _away_ from the specific OS that the application >> runs on, so that the app can do useful things without having to be >> written using non-portable, operating-system-specific functionality. > > Well, I think we're actually saying the same thing here, > so I can't see why you were picking an argument above. No, we're not-- I'm saying there is a distinction between an OS and software components not in the OS which provide useful functionality to application. > As I said, to the application, that abstraction you are talking about is > the OS. If the application can tell any different, then it's not an > abstraction! But OPENSTEP provides functionality which does not have any analogue at the operating-system level. It can't possibly provide an abstraction for something which does not exist! -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: frank@this.NO_SPAM.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 22 Feb 1997 16:06:29 GMT Organization: Frank's Area 51 Message-ID: <5en5i5$f84@bias.ipc.uni-tuebingen.de> References: <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> <5ej0nn$6t6@kaopala.mhpcc.edu> <5eka0c$98d@bias.ipc.uni-tuebingen.de> <1997022211003422003@rhrz-ts2-p1.rhrz.uni-bonn.de> Cc: theisen@akaMail.com In <1997022211003422003@rhrz-ts2-p1.rhrz.uni-bonn.de> Dirk Theisen wrote: > Hello Frank! > > Frank M. Siegert <frank@this.NO_SPAM.net>: > > the next release will > > be using the CAP (Appletalk) file name scheme for resource and finderinfo > > data, so you can directly use a network mounted Appleshare'ed volume. > > BTW: netatalk has a much nicer scheme of storing the resource forks etc. > It is hidden in a folder (.AppleDouble ?) that is normally not shown on > the unix side (because of the "."). > What about using this for FontConvert? netatalk does not run on NeXTSTEP/OpenStep, so of what use can this be? Beside the CAP naming scheme is a .resource directory for the resource fork part and a .finderinfo for the - guess what :) > Netatalk is faster anyway... :-) This is to be determined. It can be fast a hell - if it does not work on NS/OS all speed is quite useless :). I am unable to understand the holy war of 'netatalk' against 'CAP', both are solutions for a special problem. Both work and both has their strengths and weaknesses. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy
From: raph@porter.as.utexas.edu (William Raphael Hix) Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.mac.system,comp.sys.mac.programmer.codewarrior,comp.sys.next.programmer Date: 21 Feb 1997 21:34:13 GMT Organization: The University of Texas at Austin, Austin, Texas Message-ID: <5el4cl$88i@geraldo.cc.utexas.edu> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <jchan-1702972337280001@pm5-18.apk.net> <Yn2TGaa00iWk05nxw0@andrew.cmu.edu> <330A2E07.563D@ix.netcom.com> <Un2duCC00iWX0J_7NE@andrew.cmu.edu> Charles William Swiger (cs4w+@andrew.cmu.edu) wrote: : Excerpts from netnews.comp.sys.next.programmer: 19-Feb-97 Re: Mac/NeXT & : Unix: File S.. by Mike Connally@dial.pipex : > > Okay, thanks for the correction. Even so, the point still applies to : > > just NFS servers, which is more relevent for me.... : > : > No it doesn't. With NFS client software, Macs can use any : > file (data or executable) resident on any NFS server. : : But that NFS client software doesn't come with MacOS, now does it? : It's a seperate commercial product.... True, but the NFS client plus the Mac OS still cost much less than NeXTStep. I don't think cost or Apple's choice to leave secondary features like NFS to third party developers can be used to argue against the utility of creator codes in addition to file types. Now such issues (including what is secondary) might play a role in the choices Apple makes in the development of Rhapsody, but for the essentually UI issue of files remembering their creator, the decision will likely be based on ease of use and easing migration of current Mac users to Rhapsody. By saving creator and file type, Rhapsody can easily be adapted to provide either Mac or NeXT users with a GUI which functions as they expect. The technical issues of how to store such info and separate the data from the rest don't really impact this decision. Either using NeXT style wrappers, which essentially make each file a directory containing separate files for data, etc., or the current Mac fork structure, which essentially splits each file foo into 2 files, a foo.data and a foo.rsrc, can be made to work with a Unix style filesystem. To the ordinary user, they would look the same. Only if you looked at the filesystem with ls, assuming that Rhapsody has ls, could you tell the difference. 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: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 21 Feb 1997 14:35:01 -0700 Organization: Primenet Services for the Internet Message-ID: <AF33668D-114FF@198.68.42.182> References: <5ejfuf$ae2@news4.digex.net> nntp://news.primenet.com/comp.sys.mac.programmer.misc, nntp://news.primenet.com/comp.sys.powerpc.advocacy, nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.misc, nntp://news.primenet.com/comp.unix.machten, nntp://news.primenet.com/comp.unix.osf.misc, nntp://news.primenet.com/comp.os.mach, nntp://news.primenet.com/comp.os.ms-windows.nt.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit John Kheit <jkheit@cnj.digex.net> said: [on my citing Webster's 3rd International] >In the states, the authority is likely to be the 9th or newer >version. yar, but I picked up the entire 3 volume set for $25, so I'm willing to put up with a few obsolete definitions... --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
Newsgroups: comp.sys.next.programmer From: thomas_zhou@swissbank.com Subject: 3 times NILoginPanel Message-ID: <1997Feb19.234918.6357@il.us.swissbank.com> Sender: root@il.us.swissbank.com (Operator) Organization: Swiss Bank Corporation CM&T Division Date: Wed, 19 Feb 1997 23:49:18 GMT I am trying to modify the NILoginPanel so it will give user 3 times logging attempts, but 'cancel' button is not working well which is required to hit 3 times to exit. Can anyone tell me how to modify my code so 'cancel' can exit from the loop? Following is my code: - verifyUser { int counter = 0; BOOL tmp; NILoginPanel *loginPanel; loginPanel = [NILoginPanel new]; if (loginPanel == nil) exit(-1); counter++; [loginPanel setDelegate: passwordDelegate]; tmp = ([loginPanel runModalWithValidation: self inDomain: NXArgv[0] withUser: NXUserName() withInstruction: "Please Enter Collat Password..." allowChange: YES]); while (tmp != YES && counter < 3) { counter++; [loginPanel setDelegate: passwordDelegate]; tmp = ([loginPanel runModalWithValidation: self inDomain: NXArgv[0] withUser: NXUserName() withInstruction: "Please Enter Collat Password..." allowChange: YES]); }; switch (tmp) { case YES: break; default: case NO: if (counter >= 3) { NXRunAlertPanel("User Authentication", "Password Incorrect", "GoodBye", 0, 0); exit(2);} break; } return self; } Tom
From: hauke@Espresso.Rhein-Neckar.DE (Hauke Fath) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 19 Feb 1997 23:02:15 +0100 Organization: Einzeln auftretender Radfahrer Message-ID: <19970219230215660315@q700.hf.org> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> <peterm.856338363@ulfrun> <5efg5a$p2e@csugrad.cs.vt.edu> Nathan M. Urban <nurban@csugrad.cs.vt.edu> wrote: > In article <peterm.856338363@ulfrun>, peterm@dna.lth.se (Peter Moller) wrote: > > > And another one: what happends if you move or rename an application in > > NeXTOS? Can I still double-click my document and have the correct > > application launch? [This is a hot one...] > Yes, unless you move the application outside one of the folders that the > Workspace searches at login time. If you do that, the Workspace will be > unable to find the application in order to query it about what document > types it can open. (Though the application itself will still run.) Bummer. > > On my Mac I can rename and move an application and the desktop database > > finds it immediately when I open a document. Even the aliases (soft > > links) survive. Rhapsody better keep this behaviour or a lot of Mac > > users will be angry and encounter problems. > > I dunno. Rhapsody is just a different paradigm. With its filesystem > structure based on directories instead of hard drives, I don't really > see much reason why you should ever want or need to move an application > outside of its original folder (unless it's into a subfolder you made > for organizational purposes, in which case the Workspace will still find > it). Look at it the other way 'round: Why should a (desktop machine) OS _force_ me to keep applications in special places and _not_ move them? This definitely touches the heart of the "Macintosh Way" of doing things. The paths paradigm may be fine if you are working from a command line like your father and grandfathers and have your $PATH set right. But for a GUI that wants to be more than the M$ crap? Frankly: A machine that forces me to keep in mind paths and locations, a machine that spits out "sharing violations" when I move an open folder (like NT 4) is not a Macintosh to me. (A bit pathetic, but that's about what I feel.) -- I should add that I run one of my Macs under NetBSD/mac68k and hack the kernel. Now I've seen the NeXT "wrappers" pattern, and I think Apple can make things look the same on the surface. But they will have a hard time providing the "Macintosh Way" of treating files (and apps in special) with a BSD ffs. Sure, you can always add another abstraction layer and bring your machine to a crawl... hauke -- "It's never straight up and down" (DEVO)
From: jrudd@cygnus.com (John Rudd) Newsgroups: comp.sys.next.programmer Subject: Re: compiling multi-binary? Date: 22 Feb 1997 01:51:47 GMT Organization: Cygnus Solutions Message-ID: <5eljfk$n01$1@majipoor.cygnus.com> References: <5eg3aj$61q@news.tamu.edu> Cc: stephen@ccc1.tamu.edu In <5eg3aj$61q@news.tamu.edu> Stephen Johnson wrote: > How do I compile for multiple platforms on a single platform? I'm > compiling on a NeXT but need it for an Intel, also. > > Any pointers would be helpful, > There's a "-arch " argument for the compiler. If you're on teh command line, you'd do something like this: cc foo.c -arch sparc -arch etc In Project Builder, when you go to build there's an "options" button that allows you to select a architectures -- 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: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 22 Feb 1997 13:30:09 -0800 Organization: Electronics Service Unit No. 16 Sender: mpaque@mpaque Distribution: world Message-ID: <5enoh1$dg@mpaque.mpaque> References: <gandreas-2202970855160001@news.skypoint.com> In article <gandreas-2202970855160001@news.skypoint.com> gandreas@mirage.skypoint.com (Glenn Andreas) writes: > Well, in the context of Rhapsody, isn't probably needed. Assuming they go > with a BSD 4.4 (or even 4.3) style file system, it is trivial to add > creator and type information to the file system. There are several long > fields in the inode that are unused, so using the for creator and type is > a no-brainer. Of course, getting and setting these values is a bit > trickier, since a POSIX stat call won't work (the struct you pass in > doesn't have any unused fields). While this works well in a local filesystem, the added inode information may not be preserved when mapped into vnodes for network file systems, such as NFS or Novell fileservers. -- I don't speak for my employer, whoever it is, and they don't speak for me. mpaque@next.com Official business only NeXT Mail OK mpaque@wco.com Non-business or personal mail NeXT mail OK
From: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 22 Feb 1997 13:30:02 -0800 Organization: Electronics Service Unit No. 16 Sender: mpaque@mpaque Distribution: world Message-ID: <5enogq$d9@mpaque.mpaque> References: <5els0h$agc@newsread.onramp.net> In article <5els0h$agc@newsread.onramp.net> Jim_Miller@suite.com writes: > mpaque@next.com (Mike Paquette) wrote: > > >The assorted DYLD environment variables are strictly for debugging > >purposes. They aren't available to apps running from the Workspace, > >or when running as the superuser (root) for obvious reasons. > > This is bad. We sell a product that consists of a bunch of > executables (that run in the background), a couple of OpenStep > applications (launched from the Workspace), and a dynamic library. > The executables and OpenStep applications are linked with the dynamic > library, and our customers will link their OpenStep apps with the > dynamic library. Non-NeXT frameworks that third parties are expected to link with should be installed in /LocalLibrary/Frameworks in the current Mach based products. You can also dynamically add libraries into your app at runtime, through the usual object oriented APIs or the C API (e.g., NSAddLibrary(const char * library)). If you MUST use the environment variables, I suggest you break your app into a launcher part which reads the defaults database, configures the environment properly, and then launches your actual app. This will help protect your app from being spoofed by bogus DYLD environment parameters, and let you set up the app's runtime configuration using the usual defaults mechanism. -- I don't speak for my employer, whoever it is, and they don't speak for me. mpaque@next.com Official business only NeXT Mail OK mpaque@wco.com Non-business or personal mail NeXT mail OK
From: Ryan Tokarek <tokarek@students.uiuc.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sat, 22 Feb 1997 11:56:20 -0600 Organization: University of Illinois at Urbana Message-ID: <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> <5em9qk$3eu@news.platinum.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5em9qk$3eu@news.platinum.com> On 22 Feb 1997, Gary W. Longsine wrote: > it appeared that Ryan Tokarek wrote: > > On 22 Feb 1997, Gary W. Longsine wrote: > > > > > it appeared that Joaquin Menchaca wrote: > > > > shess@one.net (Scott Hess) wrote: > > > > > > > <snip> > > > > > > Then you haven't got a clue. NuKernel should have been scrapped before > > > a single line of code was written. Protected memory, but only for > > > certain, "special" processes? What a crock of sh*t. > > > > No, no. You haven't a clue. > > > > _Every_ process was to be protected under Copland with NuKernel. The > > collection of tasks that ran as one large task (the compatibility box) and > > was run internally with cooperative multitasking was protected (CMT > > because of the continued use of a non-reentran GUI). No OS task nor any > > other task could read from or write to anything in the compatibility box. > > [munch] > > > You were mistaken. > > Although you are technically correct in the strictest sense, when you say > that every process would have had protected memory, you offer a misleading > claim about the worthiness of Copland and the NuKernel, and fail to > acknowledge the ugly truth: I was not defending Copland, but NuKernel. > Copland would have forced <ALL> ordinary user applications, even brand > spanking new ones for MacOS 8, to reside in the same memory space. Only apps > specially written could get their own memory space, and the only apps > eligible for such special treatment were those without a GUI. That's what I said... it looks like you only read my first paragraph and ignored (and cut out) the rest. <snip rant> > Although I am perhaps guilty of being a bit inflammatory, I am nonetheless > right. No, you are fundamentally wrong. Had you actually read my full post, you would have seen that. You are correct that Copland put all applications that required use of the GUI in a single shared memory space, but to the kernel that was just to be a single process (task... whatever). Internal to the compatibility box, there was a scheduler that decided which task (internal to the compatibility box mind you) would be next to take processor time. This had nothing to do with NuKernel. The compatibility box task was to have the third highest priority (below real time and below certain OS tasks) for preemptive scheduling with other tasks. The compatability box ***was protected from other tasks***. It was one segment of protected memory. Is this getting clearer? The issue with "partial protected memory" in Copland was not due to a kernel limitation. It was an inherant design limitation due to the fact that Apple wanted to retain it's non-reentrant GUI and a shared adddress space for applications that made use of it. Apple could have used any kernel for Copland. They could have used Mach 2.5 They decided to write their own kernel (NuKernel). That there is an arguement over this is because _you_ do not understand what was supposed to be happening. You are mistaken. > You are defending the (indefensible) technological equivalent of > Windows 95, which as you probably know is a horrible, unstable, hunk of junk. > Copland would have been just like it. I am *sooo* glad that usenet is not > deciding the architecture of Rhapsody. Read my words, and understand. I AM NOT DEFENDING COPLAND!!!!!!!!! The technical issues with using NuKernel for Rhapsody are not what you think they are. You have misunderstood a fundamental concept here. > Popular vote in Mac.advocacy would have picked: > > <> NuKernel There _are_ technical reasons not to use NuKernel, but they aren't the ones you think they are. > <> Punt UNIX (in favor of what? nobody ever said) No, don't get rid of Unix entirely. Make it so that it's availlable, but not necessary. <small snip> > <> Open Transport What's wrong with OpenTransport? Do you understand its primary purpose? > <> The MacOS filesystem Only to retain backward compatibility. I don't mind if Rhapsody uses some other file system, but I want to be able to see my HFS formated partitions and disks as well. Ryan Tokarek <tokarek@students.uiuc.edu>
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 17 Feb 1997 22:49:47 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eanab$c6r@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > Excerpts from netnews.comp.sys.next.programmer: 17-Feb-97 Re: Mac/NeXT & > Unix: File S.. by John Moreno@interpath.co > > ] Perhaps it's just me, but I don't see much value to preserving > > ] the timestamp of the creation date of the original version of > > ] a file when you don't actually have the original file-- just > > ] the modified version. Can you provide a real-world example of > > ] why you'd care about that timestamp? > > > > A very simple and quit answer is when you have two files with > > basically the same information and have modified both since > > their creation and want to know which file is newer. > > The answer is whichever file was modified last, and can be answered > using the last-modified timestamp; the creation timestamp isn't > needed. > > Again, that doesn't answer my question. If the two timestamps are available, people will find uses for them. Back in the days when mainframes ruled the earth, the operating system used at RPI was one called "MTS" (Michigan Terminal System). Files on it had four different timestamps. Creation date, last data-change time, last catalog-change time, and even last reference date. All of these were useful, in one context or another. Can people survive without them? Yes. Are people *worse off* with them? No, don't be silly. They are nice to have, even if other operating systems don't have them. Now, the way MTS handled creation-date is different from the way the Mac handles it, so I'm not saying it's an exact mapping. And no, right this second I can't give you a real-world example of how this is useful, because I haven't used MTS much in the last eight or nine years. I *do* know that I *did* use all of these timestamps when I spent most of my time on MTS, so I'm aware that they can be useful. I also know that I missed some of these when working on Unix, but I'll admit it was only a minor annoyance. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 21 Feb 1997 14:35:39 -0800 Organization: Esperance Communications Message-ID: <jk-2102971435400001@ip-salem1-20.teleport.com> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> <wn37U3O00iWm02vE40@andrew.cmu.edu> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <wn37U3O00iWm02vE40@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: >AppleSingle and AppleDouble are archive formats, and my NFS server >cannot represent the Mac resource forks the way HPS does without using >such a mechanism. AppleDouble is closer to "wrappers", it is a two file representation of a dual-fork file(with the exception that there is no enclosing directory). It (and AppleSingle) is not an archive format, rather it is a way to represent a single Mac file on a foreign filesystem. >Furthermore, let's consider exactly how transparent things really are. >What happens when you do have this commercial Mac NFS client software. >If I save a document like plain old ASCII text file or some common WP >format like MS-Word from a Mac onto the NFS server, do I get (a) a file >that I can walk over to a non-Mac system and be able to use as-is, or do >I get (b) an AppleSingle or AppleDouble file that I can't use as-is? You get (a), the whole point of AppleDouble is that the resource fork is separated from the data fork. AppleSingle should only be used to encode a mac-specific file, say an executable. -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 21 Feb 1997 17:43:11 -0700 Organization: Primenet Services for the Internet Message-ID: <AF3392D0-8B354@198.68.42.175> References: <5eldq2$kj@news.platinum.com> nntp://news.primenet.com/comp.sys.mac.programmer.misc, nntp://news.primenet.com/comp.sys.powerpc.advocacy, nntp://news.primenet.com/comp.sys.next.advocacy, nntp://news.primenet.com/comp.sys.next.programmer, nntp://news.primenet.com/comp.sys.next.misc, nntp://news.primenet.com/comp.unix.machten, nntp://news.primenet.com/comp.unix.osf.misc, nntp://news.primenet.com/comp.os.mach, nntp://news.primenet.com/comp.os.ms-windows.nt.advocacy Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Gary W. Longsine <gary-nospam-@screaming.org> said: > >Then you haven't got a clue. NuKernel should have been scrapped before >a single line of code was written. Protected memory, but only for certain, >"special" processes? What a crock of sh*t. > No, only "special" processes would NOT be protected: those that were sitting in the Blue Box. --------------------------------------------------- Apple is a company, but Macintosh is a community. -S.M. King ---------------------------------------------------
From: Ryan Tokarek <tokarek@students.uiuc.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Fri, 21 Feb 1997 20:40:30 -0600 Organization: University of Illinois at Urbana Message-ID: <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5eldq2$kj@news.platinum.com> On 22 Feb 1997, Gary W. Longsine wrote: > In <jm041536-2102971103330001@mencjo.apple.com> it appeared that Joaquin > Menchaca wrote: > > In article <SHESS.97Feb20085428@howard.one.net>, shess@one.net (Scott > > Hess) wrote: > > > > > <snip> > > This is very well said. That was my original concern about the decision > > about using a monolithic kernel from NeXTSTEP (OPENSTEP for Mach). I > > think technically this is a mistake. It may be outrageous to say this, > > but I think NuKernel of Copland is a better choice as it combines the best > > of Apple with the best of NeXT (OPENSTEP). > > Then you haven't got a clue. NuKernel should have been scrapped before > a single line of code was written. Protected memory, but only for certain, > "special" processes? What a crock of sh*t. No, no. You haven't a clue. _Every_ process was to be protected under Copland with NuKernel. The collection of tasks that ran as one large task (the compatibility box) and was run internally with cooperative multitasking was protected (CMT because of the continued use of a non-reentran GUI). No OS task nor any other task could read from or write to anything in the compatibility box. (The plan for Copland was to be much like Windows95... it was to be an interim OS to get users up to a level so that a major OS transition could take place with a relative minimum of fuss that the user would have to go through... their goal was too hard to implement in a timely fashion it seems.) Because Apple wished to retain backwards compatibility with System 7 applications, because Apple didn't want to make the GUI reentrant at the time, and because older apps expected a flat memory model, Apple decided to go with a compatibility box. This was to be one large segment of protected memory that ran the GUI and applications that required the use of the GUI (System 7 and the main portions of Mac OS 8 apps). The tasks running inside the compatibility box were to have very limited memory protection from each other (all code would have been protected). This was because, to the kernel, the compatibility box was just one task, one segment of protected memory. NuKernel had full protected memory with preemptive multitasking and SMP for all tasks. People only call it partial protected memory and PMT because of issues with the internals of the compatibility box. I'm not really defending Apple. They fiddled and diddled with Copland too long, but their problems were not with the kernel... they had problems implementing backwards compatibility in that fashion. As far as I know, there was nothing in particular that was wrong with NuKernel (except prehaps that it wasn't as well tested like Mach 2.5 has been). You were mistaken. Ryan Tokarek <tokarek@students.uiuc.edu>
From: allman@pat.mdc.com (Mark Allman ) Newsgroups: comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.misc Subject: (Repost) Shared object libraries (rld) using OpenStep 4.1 Date: 21 Feb 1997 23:07:38 GMT Organization: McDonnell Douglas, Houston Division Message-ID: <5el9rq$21v@cisu2.jsc.nasa.gov> References: <5ef797$m78@cisu2.jsc.nasa.gov> OpenStep 4.1 for Mach question: Some C code I'm compiling and putting into a shared object library (via ld -r) for later dynamic loading (using rld) is now refusing to be loaded. I've begged and pleaded, but to no avail. The error I'm now getting is something like "cannot use rld with dynamic shared libraries." Since all the "standard" libraries (e.g., libsys_s.dylib) are now dynamic shared libraries, are the rld routines no longer usable? I can switch to use dyld routines and use libtool--is this what I should do? Can someone point to some documentation (man pages aren't telling the complete story) that discusses rld routines under OpenStep 4.1? Also, I noticed that we can no longer build static executables, since there are no static "standard" libraries. Try compiling the "Hello, world" program using the -static compile/link switch. -- Mark Allman -- Sr. Engineer, McDonnell Douglas Aerospace, allman@pat.mdc.com -- Software consulting (Perl, C, Python, ...), ghost@ghost.neosoft.com -- (see: http://pup.princeton.edu/titles/5857.html)
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 18 Feb 1997 02:53:09 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eb5il$fv7@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> tbutler@tfs.net (Travis Butler) wrote: > The problem is, I couldn't care less about a multiuser operating > system. I bought my Mac for use by a single person: me. With the > exception of server machines, every single Mac -- heck, every > single *personal computer* -- I've ever seen has been used by > one person at a time. The majority of them have been used by a > single person, period; if you leave out the CS lab machines, that > becomes an overwhelming majority. Many of the macs in homes have multiple people using it at different times. Someone like me might have a truly personal Mac, but other families often have fewer personal computers than they have people. > I'm blathering on about this because it seems like a large number > of the arguments by NeXT partisans boil down to 'it has to be > this way if you're on a multiuser system.' Well, as I said, I > don't WANT a multiuser system; and in my experience, this holds > true for the vast majority of machines outside of a lab environment. I prefer the NeXTSTEP way of doing things because it works better, for me, as a person who is pretty much the only one using my NeXTSTEP machines. While I do run Mac labs, and really would like multi-user capabilities there, my NeXTSTEP machines are pretty used only by me. I still think the NeXTSTEP interface works better, even ignoring multi-user issues. We aren't saying "this obviously sucks for an individual user, but you'll just have to grit your teeth and bear the pain because we want multi-user capabilities". Ignoring the multi-user issues, I (personally) could probably argue that either the Mac interface or the NeXTSTEP interface is better. Each has their strong points, and it's basically a subjective argument as to which one is better. However, when it comes to multi-user issues, it's fairly objective to say that NeXTSTEP handles those issues better. It's tiring to keep arguing subjective issues, because there's nothing you can do to make them objective. Thus, some NeXTSTEP advocates trot out the multi-user issues because that's objective. It isn't because NeXTSTEP is problematic as a single-user system, it's just that there is no good way to prove that it works well until we get "you" (the generic you) to use it for awhile. It really does work quite well, and I'm saying this as a person who used Macs for many years before I saw a NeXT. > I don't mind having things in there for the benefit of multiuser > setups, as long as they don't get in the way of ordinary single-user > operation; but if there's a conflict, I think multiuser features > have to take a back seat to convenience features for single users. NeXTSTEP is quite convenient for individual users. > This gets back to the same argument I keep raising throughout > these threads: It doesn't make sense to complicate the user > experience for the majority of people to cater to the specialized > needs of a small minority. I don't think it makes sense to complicate the user experience either. My position is that the NeXTSTEP user interface does *not* "complicate" anything. It's just different than the MacOS interface. Personally I would be fairly comfortable with either a MacOS or NeXTSTEP interface on Rhapsody, so I'm not insistent on trying to get my own way. Either way is fine with me, but I do wish to state that the NeXTSTEP interface works a lot better than a longtime Mac user might expect based on it's description. It really is very well done. I suspect Rhapsody will be very well done too, one way or another. I look forward to it's release, whether it's Mac-ish or NeXTSTEP-ish, just so we will have something more interesting to talk about. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 00:14:58 GMT Organization: Save the Skeet Foundation Message-ID: <5eldq2$kj@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> Cc: jm041536@fhda.edu In <jm041536-2102971103330001@mencjo.apple.com> it appeared that Joaquin Menchaca wrote: > In article <SHESS.97Feb20085428@howard.one.net>, shess@one.net (Scott > Hess) wrote: > > > > > Unless I've _greatly_ misread a variety of papers, microkernels are > > coming into their own because we are asking entirely too much of our > > monolithic kernels. The amount of effort it takes to add something > > new to your monolithic kernel is often so great that you never get > > around to it - and thus a microkernel can be more efficient in the > > end. In essence, using a microkernel lets you get to a better design > > for the system faster than a monolithic kernel, so it wins in the end. Which says nothing about the <size> of the kernel. What everyone seems to forget is that <size> isn't everything. Microkernels are best defined in terms of how the kernel design is abstracted -- not the size of the binary. If several different parts, properly abstracted, are compiled into the same binary, you really have a hybrid micro-monolith kernel -- which is what damned near every vendor is shipping today. Like NeXT, they are all using dynamically loaded device drivers, but the core OS server is compiled into the same binary with the microkernel. > This is very well said. That was my original concern about the decision > about using a monolithic kernel from NeXTSTEP (OPENSTEP for Mach). I > think technically this is a mistake. It may be outrageous to say this, > but I think NuKernel of Copland is a better choice as it combines the best > of Apple with the best of NeXT (OPENSTEP). Then you haven't got a clue. NuKernel should have been scrapped before a single line of code was written. Protected memory, but only for certain, "special" processes? What a crock of sh*t. /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 21 Feb 1997 00:44:38 -0500 Organization: phenix@interpath.com Message-ID: <19970221004438207835@roxboro-184.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <qdafp913g1.fsf@blues.cygnus.com> <1997021716473229510531@roxboro-170.interpath.net> <qd4tfac6h6.fsf@blues.cygnus.com> Stephen Peters <speters@cygnus.com> wrote: ] phenix@interpath.com (John Moreno) writes: ] > Stephen Peters <speters@cygnus.com> wrote: ] > ] Which begs the question to a die-hard Unix user like myself, if ] > ] you add the notion of a `preferred application', what use is the ] > ] `creator' designation other than bookkeeping? As a fallback to a ] > ] known good application? ] > ] > Well for starters some applications can handle the files of a ] > certain type created by one application but not of another - non ] > standard usage and all that rot. ] ] Hmmm...I suspect that if there were less of an emphasis on the ] `creator' and more of an emphasis on the types, this kind of situation ] would occur less often. After all, if MicrosoftWord.app wanted to ] badly break RTF, they can always create the new MWRTF type. ] ] Maybe I'm living in a fantasy world :-) Well, I don't want to know anything about your fantasies, but as far as emphasis on types goes - I don't think so. I've never had two projects that used the same file structure. Different programs have different needs. Just for starters, I've never been able to find a program that will correctly translate from xWORKS WP to yWORKS WP. The graphics are ALWAYS lost and quite often a good deal of the formatting. ] > ] Ditto on the various discussions on adding the `time created' ] > ] field to augment the last modified and other time codes stored ] > ] with the file. For me, once I start caring about the time the file ] > ] was first created, I start caring about all the changes that were ] > ] made, which seems to scream `revision control system' to me. (And ] > ] if you copy a file from somewhere else, should it inherit the ] > ] source file's created time?) ] > ] ] > ] Maybe I'm just not seeing it. Can someone help enlighten me? ] > ] > Because when you update a applications then look at the file it ] > often gets translated into the newer version, this is one way of ] > keeping track of when you started something. ] ] But this is kind of my point. For me at least, when I want to know ] when I started something, I need that information in the context of ] "what kinds of changes have I made since I created this?" And I'm usually looking to see it's okay to throw it away - and the last modification time just doesn't do it. ] And I think it also begs the paranthetical question I asked above as ] well. If I copy something, should it inherit the source file's ] `created' time? If the created time's purpose is to track when I ] started work, then the answer is yes. If instead the purpose is to ] track when I started working on this `revision' of the document, then ] the answer is probably no. In either case, I think it's better to use ] a revision control system. I'll answer these in reverse. A revision control system is overkill 9 times out of 10 - and is only half-way usable that 1 time. Interesting question, but I'd have to say that if a file is duplicated then it should have the same file info as the original - after all if you want to track the start of this revision then the file can always be created from within the application. It is something that you might want to make setable by a preference or use a modifier to reverse it. -- John Moreno
From: engelhar@dreamscape-solutions.com (Michael Engelhart) Newsgroups: comp.sys.next.programmer Subject: NS 3.0 Date: 22 Feb 1997 20:28:11 GMT Organization: The Internet Access Company, Inc. Message-ID: <engelhar-2202971530310001@p14.ts1.newbr.nj.tiac.com> Hello all- I'm thinking of buying an old 33MhZ NeXT Station turbo for pretty cheap. It comes with NS 3.0 user/developer installed. Is this worth learning NeXT development on? I currently develop for the Mac and couldn't find any info about versions of NS previous to 3.3 on their site. Also, can you upgrade relatively easily to 3.3? I'm just trying to get a head start on Rhapsody. Also, are there any good tech references out in publication on NeXTStep?....any info would be greatly appreciated. thanks, Mike
From: jk@esperance.com (Joel Klecker) Newsgroups: comp.sys.mac.programmer.misc,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.system Date: Sat, 22 Feb 1997 20:31:40 -0800 Organization: Esperance Communications Message-ID: <jk-2202972031400001@ip-salem2-07.teleport.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <jk-1802972158190001@ip-salem2-01.teleport.com> <1997022211004522664@rhrz-ts2-p1.rhrz.uni-bonn.de> Fingerprint="12 92 9C E4 60 DF 62 CD FC AD 18 47 9A 74 E7 D1" In article <1997022211004522664@rhrz-ts2-p1.rhrz.uni-bonn.de>, theisen@akaMail.com (Dirk Theisen) wrote: >Joel Klecker <jk@esperance.com>: >> I think a file system that stores meta-data in the filename (file >> extensions) is a huge step backwards. > >What does it matter if I don't see it? >Treat the extension as a "system part" of the directory entry, not >directly editable by users. I don't want to lose the flexibility of the type/creator system either. I don't have a problem with hiding things from users when there is no more elegant way, but the type/creator system works well, and doesn't impact that much on interoperability. [comp.sys.mac.programmer.codewarrior replaced with comp.sys.mac.programmer.misc and followups set to comp.sys.mac.advocacy, comp.sys.next.advocacy, and comp.sys.mac.system] -- Joel Klecker (jk@esperance.com) <URL:http://www.esperance.com/> PGP Key available from my webpage, see "X-PGP-Key" header for fingerprint. We are Microsoft. You will be assimilated. Resistance is futile. -- Rejected Microsoft ad slogans
From: izumi@pinoko.berkeley.edu (Izumi Ohzawa) Newsgroups: comp.sys.next.programmer Subject: Re: How to make "STOP" button? Date: 22 Feb 1997 22:59:02 GMT Organization: University of California, Berkeley Distribution: world Message-ID: <5entnm$pc5@agate.berkeley.edu> References: <5eiv68$rnt@news.next.com> In article <5eiv68$rnt@news.next.com> michael (Michael F. DeMan) writes: >In <5cp1vh$a0h@kaopala.mhpcc.edu> Lee Altenberg wrote: >> 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 >> > > There are lots of ways to do this, the easist is to simply hookup your stop >button to a method that sets up a boolean value.... > >- stopButtonClicked: sender { > theGlobalBoolean = FALSE; >} > > Then check the value of that boolean in your loop. I don't think your stopButtonClicked: method will get called until after the loop ends, in a single-threaded application. Thus, the button press will not break the loop. Here's what I actually use in my curve fitting application where sometimes I want to stop non-converging fitting attempts. I add a method to a Button class using category, and then give the 'id' of the abort button to a lengthy numerical computation loop. Then in the compute loop, the button state is periodically checked by: for(;;) { ... Long computation loop here ... // Check abort button every once in a while if(((niteration % 20) == 0) && abortButton) { if([abortButton isButtonPressed]) break; } } It works well, and avoids DO, timed entry, or threads for a stupid STOP button. --- ButtonPressed.h -- #import <appkit/Button.h> @interface Button(ButtonPressed) - (BOOL)isButtonPressed; @end --- end of ButtonPressed.h -- --- ButtonPressed.m -- /* ButtonPressed.m Category method to check button press. */ #import <appkit/appkit.h> #import "ButtonPressed.h" @implementation Button(ButtonPressed) - (BOOL)isButtonPressed /* * This is a category method that adds a (abort) button for querying button press * during a lengthy loop operation (like some numerical computation). * You give the button object's id to the computation engine, which should * then call this method periodically to see if the user pressed the button. * If the method returns YES, it breaks the computation loop, returning the * control to GUI. * It can be used to do other things, e.g., to elicit status reporting from * a long computational loop. */ { NXEvent *e = [NXApp getNextEvent:NX_MOUSEDOWNMASK waitFor:0.0 threshold:NX_MODALRESPTHRESHOLD]; if (e) { /* if there is a mouse down event waiting for us */ NXPoint p = e->location; [self convertPoint:&p fromView:nil]; if(NXMouseInRect(&p, &bounds, NO)) // if the click is within the bounds of button return YES; } return NO; } @end ---- end of ButtonPressed.m ---
From: markeaton_@_mindspring_._com (Mark Eaton) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Fri, 21 Feb 1997 21:32:11 -0800 Organization: MindSpring Enterprises Message-ID: <markeaton_-ya02408000R2102972132110001@news.mindspring.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: > > Then you haven't got a clue. NuKernel should have been scrapped before > a single line of code was written. Protected memory, but only for certain, > "special" processes? What a crock of sh*t. Whats really a crock of sh*t is when you make an off the cuff statement like that without really knowing whether its true or not. When you do that, you're no better than Lawson English... (FYI- NuKernel does not extend memory protection just to certain, "special" processes...) -Mark ---> markeaton_@_mindspring_._com
From: joshua@precipice-mp.com (Joshua Whalen) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 04:48:41 -0500 Organization: Precipice Multimedia Productions Message-ID: <joshua-ya02408000R2202970448410001@news.interport.net> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> <wn37U3O00iWm02vE40@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > Furthermore, let's consider exactly how transparent things really are. > What happens when you do have this commercial Mac NFS client software. > If I save a document like plain old ASCII text file or some common WP > format like MS-Word from a Mac onto the NFS server, do I get (a) a file > that I can walk over to a non-Mac system and be able to use as-is, or do > I get (b) an AppleSingle or AppleDouble file that I can't use as-is? You get exactly what you saved to disk. Apple Double and Apple Single are only applied to files which contain resource forks. Since files (except for things like unflattened Quicktme movies or unflattened MacroMedia projectors) don't have resource forks, they aren't encoded. Joshua
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: New Information Date: 17 Feb 1997 22:52:50 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eang2$c6r@usenet.rpi.edu> References: <5e55u8$7td@news.bu.edu> <5eacjo$f6o@news.next.com> MaRK_BeSSeY@NeXT.CoM (Mark Bessey) wrote: > John Siracusa writes > > From MacWeek: > > > > Sources in the boiler room report that Rhapsody will weigh in > > at about 110 Mbytes of pure chewing satisfaction and come with > > three levels of Install: EZ, Minimal and Custom. > > Wow. I wonder how the folks at MacWeek know how much disk space > Rhapsody is going to use, when it hasn't even been built yet? MacWeek knows everything. Don't you remember all of it's articles about Apple buying Be? --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: joshua@precipice-mp.com (Joshua Whalen) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 04:48:06 -0500 Organization: Precipice Multimedia Productions Message-ID: <joshua-ya02408000R2202970448070001@news.interport.net> References: <5ddp66$jpc@news.bu.edu> <5ddtq2$ier@csugrad.cs.vt.edu> <sn2516600iVGI0zSpA@andrew.cmu.edu> <5e9ral$jfu@horus.ecmwf.int> <cn2_Uhe00iV7E5aIdE@andrew.cmu.edu> <Mike.Connally-ya023680001902972337090001@news.dial.pipex.com> <wn37U3O00iWm02vE40@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit > Furthermore, let's consider exactly how transparent things really are. > What happens when you do have this commercial Mac NFS client software. > If I save a document like plain old ASCII text file or some common WP > format like MS-Word from a Mac onto the NFS server, do I get (a) a file > that I can walk over to a non-Mac system and be able to use as-is, or do > I get (b) an AppleSingle or AppleDouble file that I can't use as-is? You get exactly what you saved to disk. Apple Double and Apple Single are only applied to files which contain resource forks. Since files (except for things like unflattened Quicktme movies or unflattened MacroMedia projectors) don't have resource forks, they aren't encoded. Joshua
From: theisen@akaMail.com (Dirk Theisen) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 11:00:45 +0100 Organization: University of Bonn, Germany Message-ID: <1997022211004522664@rhrz-ts2-p1.rhrz.uni-bonn.de> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <jk-1802972158190001@ip-salem2-01.teleport.com> Hi, Joel! Joel Klecker <jk@esperance.com>: > I think a file system that stores meta-data in the filename (file > extensions) is a huge step backwards. What does it matter if I don't see it? Treat the extension as a "system part" of the directory entry, not directly editable by users. One problem I see is that this could lead to different files with the same name (but different type). This may by confusing (or wonderful). Bug or feature? I don't know. I would probably like converting a file and have two versions with the same name afterwards. Greetings Dirk -- The TriMedia chip used by Apple will handle several times what MMX can. Student of computer science, University of Bonn, Germany http://titan.informatik.uni-bonn.de/~theisen/
From: theisen@akaMail.com (Dirk Theisen) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 11:00:34 +0100 Organization: University of Bonn, Germany Message-ID: <1997022211003422003@rhrz-ts2-p1.rhrz.uni-bonn.de> References: <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> <5ej0nn$6t6@kaopala.mhpcc.edu> <5eka0c$98d@bias.ipc.uni-tuebingen.de> Hello Frank! Frank M. Siegert <frank@this.NO_SPAM.net>: > the next release will > be using the CAP (Appletalk) file name scheme for resource and finderinfo > data, so you can directly use a network mounted Appleshare'ed volume. BTW: netatalk has a much nicer scheme of storing the resource forks etc. It is hidden in a folder (.AppleDouble ?) that is normally not shown on the unix side (because of the "."). What about using this for FontConvert? Netatalk is faster anyway... :-) Greeting Dirk -- The TriMedia chip used by Apple will handle several times what MMX can. Student of computer science, University of Bonn, Germany http://titan.informatik.uni-bonn.de/~theisen/
From: Ryan Tokarek <tokarek@students.uiuc.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sat, 22 Feb 1997 23:37:34 -0600 Organization: University of Illinois at Urbana Message-ID: <Pine.SOL.3.91.970222232011.23885A-100000@ux8.cso.uiuc.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> <5em9qk$3eu@news.platinum.com> <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> <5eodgh$ors@lynx.dac.neu.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: <5eodgh$ors@lynx.dac.neu.edu> On 22 Feb 1997, Michael Kagalenko wrote: > Ryan Tokarek (tokarek@students.uiuc.edu) wrote > ]<small snip> > ]> <> Open Transport > ] > ]What's wrong with OpenTransport? Do you understand its primary purpose? > > I don't. Perhpas, you could explain ? Is it yet another proprietary > standard ? As I understand it (and I do not know the details so people with more knowledge of OT step in here), OpenTransport provides a network-neutral API. Programs can use the various OT APIs to deal with networking, and they won't need to know which networking standard is being used (TCP/IP, IPX, AppleTalk, whatever). It adds a layer of abstraction that can be used to send infromation over any network with the app having to know the nature or details of the network. You can use OpenTransport to deal with specific details of a certain network protocol, but OpenTransport provides the tools to deal with any network (that OpenTransport is configured for) without the app having to know which one. Taking a look at the info on TCP for OpenTransport (in the Control Panel), it appears to be based on "Mentat Portable Streams" and "Mentat TCP"... if that's meaningful to you (it isn't to me). I don't know whether there is an equivalent in NeXTStep, but that's roughly what OpenTransport does. I don't know whether it would be advantageous to port it over to Rhapsody, but it it's the Mac's current networking API. > ]> <> The MacOS filesystem > ] > ]Only to retain backward compatibility. I don't mind if Rhapsody uses some > ]other file system, but I want to be able to see my HFS formated > ]partitions and disks as well. > > OPENSTEP/Mach 4.1 for intel can access Apple fs, so it seems that > Rhapsody will do it by default. Great! That's what I thought, but Gary's post seemed to imply otherwise. Ryan Tokarek <tokarek@students.uiuc.edu>
From: Shimpei Yamashita <shimpei@argo.patnet.caltech.edu> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 23:48:58 -0800 Organization: Hummingbird Heaven Message-ID: <7fafow55ed.thoron@argo.patnet.caltech.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> gary-nospam-@screaming.org (Gary W. Longsine) writes: > > In <markeaton_-ya02408000R2102972132110001@news.mindspring.com> it appeared > that Mark Eaton wrote: > > In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary > > W. Longsine) wrote: > > > > > > > > Then you haven't got a clue. NuKernel should have been scrapped before > > > a single line of code was written. Protected memory, but only for > certain, > > > "special" processes? What a crock of sh*t. > > > > Whats really a crock of sh*t is when you make an off the cuff statement > > like that without really knowing whether its true or not. When you do that, > > you're no better than Lawson English... > > That's a pretty low blow, especially since I've provided some pretty clear > documentation, from Copland-friendly sources, to back up my claim. It doesn't help when you misread documentations. You didn't read the white paper on the *microkernel*, did you? I have. > > (FYI- NuKernel does not extend memory protection just to certain, "special" > > processes...) > > Wrong. Plainly, clearly, demonstrably, incontestably wrong. Ordinary > Copland applications, even brand new ones written for the Copeland OS, are > <required> to share the same memory pool -- not just the legacy System 7 apps > (as is the case with the new Blue Box.) Yes, and irrelevant. What the Copland OS was or was not supposed to be capable of is not directly applicable to what NuKernel (which is just the *microkernel* handling process creation and scheduling; Copland was to be a lot more than just that!). NuKernel was perfectly capable of hosting a completely protected, preemmptively multitasking OS; indeed, Gershwin (the "advanced" version of Copland that never happened) was supposed to use NuKernel. Copland was not capable of protecting all processes, but that isn't the microkernel's problem. Ragging NuKernel for Copland's problem is like implementing MS-DOS on top of Mach and blaming Mach for the horrible attributes of DOS.... I'm inclined to agree, actually, that Copland's OS design was fundamentally flawed. I was willing to live with it for a while as a stopgap measure, but never as a semipermanent solution. Again, irrelevant for deciding on the merits of NuKernel. -- Shimpei Yamashita <http://www.cco.caltech.edu/%7Eshimpei/> (Note: Currently experimenting with a new newsreader (gnus). Apologies in advance for malformed or spurious posts or replies.)
From: gandreas@mirage.skypoint.com (Glenn Andreas) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Sat, 22 Feb 1997 08:55:16 -0600 Organization: GAndreas Software Message-ID: <gandreas-2202970855160001@news.skypoint.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <jk-1802972158190001@ip-salem2-01.teleport.com> <1997022211004522664@rhrz-ts2-p1.rhrz.uni-bonn.de> In article <1997022211004522664@rhrz-ts2-p1.rhrz.uni-bonn.de>, theisen@akaMail.com (Dirk Theisen) wrote: > Hi, Joel! > > Joel Klecker <jk@esperance.com>: > > I think a file system that stores meta-data in the filename (file > > extensions) is a huge step backwards. > > What does it matter if I don't see it? > Treat the extension as a "system part" of the directory entry, not > directly editable by users. Well, in the context of Rhapsody, isn't probably needed. Assuming they go with a BSD 4.4 (or even 4.3) style file system, it is trivial to add creator and type information to the file system. There are several long fields in the inode that are unused, so using the for creator and type is a no-brainer. Of course, getting and setting these values is a bit trickier, since a POSIX stat call won't work (the struct you pass in doesn't have any unused fields). This isn't hypothetical either - I've actually done it several years ago to add a form of manditory access control (Type Enforcement) to a BSD kernel for making a commercial firewall. There is something satisfying about doing an "ls" and seeing things like: /bsd kern:bbox /tmp/ temp:diry (directories, since they are also files, also got a creator and type). -- Glenn Andreas Author of Macintosh games: gandreas@skypoint.com Theldrow 2.3 http://www.skypoint.com/members/gandreas Blobbo 1.0.2 ftp://ftp.skypoint.com/pub/members/g/gandreas Unsolicited bulk email will be proofread for a US$500/k, min $1000
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 21 Feb 1997 00:44:35 -0500 Organization: phenix@interpath.com Message-ID: <19970221004435207619@roxboro-184.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> John Rudd <jrudd@cygnus.com> wrote: ] In <1997021716472829510259@roxboro-170.interpath.net> John Moreno wrote: ] > John Rudd <jrudd@cygnus.com> wrote: ] > ] The reason this is a problem on a Mac isn't because it's stored in ] > ] a central location.. it's because the Mac doesn't allow you to ] > ] pick file type over file creator for its launching heuristic, and ] > ] then give a seperate file-type <-> application binding for ] > ] different "profiles" (even if its' just swapping a file at ] > ] runtime). If it did allow this (even the crude run time swapping ] > ] of the binding file), then it wouldn't be a problem. ] > ] > It DOES allow you to override the launching application but ONLY if ] > the creating application is not available. It's called Macintosh ] > Easy Open and it could be extended to work properly (override even ] > application which ARE available) in the current system, let alone in ] > the next. ] ] ] That's kind of what I meant.. You can't choose to open by file type ] _OVER_ file creator. If the file creator data is there, and the file ] creator app exists on that machine, you MUST use it. You cannot ] choose a file type application OVER that creator app. I didn't say ] you can't open by file type at all. I simply said the Mac doesn't ] give you a choice between the two -- if creator exists you use it, ] otherwise you use type... no choice. That's true, and I consider it a defect in MEO. OTOH for 90% of the people it's a problem that occurs between almost never and never. The reason I consider it a defect is that you shouldn't design a system based exclusively on what most people are doing most of the time, you do the basics then you extend the functionality to the less often used functions. Often the average user doesn't know that something would be beneficial until after they seen it in action. -- John Moreno
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 20:53:23 GMT Organization: Save the Skeet Foundation Message-ID: <5enmc3$bra@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> Cc: markeaton_@_mindspring_._com In <markeaton_-ya02408000R2102972132110001@news.mindspring.com> it appeared that Mark Eaton wrote: > In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary > W. Longsine) wrote: > > > > > Then you haven't got a clue. NuKernel should have been scrapped before > > a single line of code was written. Protected memory, but only for certain, > > "special" processes? What a crock of sh*t. > > Whats really a crock of sh*t is when you make an off the cuff statement > like that without really knowing whether its true or not. When you do that, > you're no better than Lawson English... That's a pretty low blow, especially since I've provided some pretty clear documentation, from Copland-friendly sources, to back up my claim. > (FYI- NuKernel does not extend memory protection just to certain, "special" > processes...) Wrong. Plainly, clearly, demonstrably, incontestably wrong. Ordinary Copland applications, even brand new ones written for the Copeland OS, are <required> to share the same memory pool -- not just the legacy System 7 apps (as is the case with the new Blue Box.) COMEDY BREAK: Tai-Kwon-Leap Master: Who disrupts our meditation as a pebble disturbs the pond? Tai-Kwon-Leap Student: Ooh! ooh! Me! Ed Gruberman! I'm so shocked at the tremendous waste of resources that went into the backward architecture of Copland that I tend to emote on the topic -- sorry. I just don't understand why anyone would spend almost half a billion dollars, and over 5 years on OS research (Pink, Taligent, Copland) and fail to grok something so basic as a rational protected memory scheme. (I also don't understand why people are so infatuated with a research kernel (Copland's NuKernel) that's never seen the production light of day and doesn't offer an improvement over kernels that I've been using for years... but that's another topic.) Again, I suggest that you check out the Apple Press book on Copland. It was written by folks friendly to the Copland project, and states in clear, matter-of-fact language how the OS was to work. "MacOS 8 Revealed: A Technical Tour of the New Mac OS", Tony Francis, ISBN 0-201-47955-9, Apple Press, August 1996. In the strictest technical sense, perhaps I was too harsh on the poor, defenseless little NuKernel, which is after all, only a sequence of ones and zeros on a plastic platter. The NuKernel itself might (in theory) allow protected memory for any process, if you worked out the Copland-specific stuff. -- but using NuKernel as the core of the NeXT OS would take rather a lot of work, for really zero gain. Anyway, nobody has yet offered proof that my general claim is incorrect. The designers of Copland wandered very far down an expensive and pointless track. They should have had their leashes jerked back long, long ago. If they had presented me with such a kludge two years ago, after hundreds of millions of dollars and three years wasted on Pink and Taligent, I would have fired them as being fundamentally incompetent. Period. Copland + NuKernel = No protected memory for ordinary applications. Under Copland, developers must take special steps to arrange for protected memory for "applications that could benefit" from it. The first, and very, very special, step is that one must hack the user interface out of the app. That means that all the problems Mac users have with the average user apps taking down other apps would still exist in Copland, with the minor enhancement that your kernel would still be running after your entire workspace crashes. As a user of a UNIX based OS, I don't have this problem. If I'm mistaken about this, then I apologize, I've been misled by the Apple documentation on their own project. However, the literature and discussion seems to leave little room for doubt (I'm not the only person supporting this claim). So the NuKernel was better than anything ever to run on a Mac before. Big deal. It's really no better than several kernels which have been running <in production> for several years: NeXT MachOS, Solaris, AIX, Linux, Windows NT. All of those production operating systems have kernels which are at least as good as NuKernel, and some are probably better in certain respects. They all have the advantage of having been actually <used> in production environments, and survived through several new versions. Now what about kernels that are much better than NuKernel? I'd say you have to go look at other research kernels, probably the real-time ones like RTMach, and BeOS. Maybe the distributed things like Plan9 and Inferno. Copland is dead. Long live the new MacOS (MachOS). /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: mkagalen@lynx.dac.neu.edu (Michael Kagalenko) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 1997 22:28:17 -0500 Organization: Northeastern University, Boston, MA. 02115, USA Message-ID: <5eodgh$ors@lynx.dac.neu.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> <5em9qk$3eu@news.platinum.com> <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> Content-Type: text/html Ryan Tokarek (tokarek@students.uiuc.edu) wrote in article <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> <pre><blink> ]<small snip> ]> <> Open Transport ] ]What's wrong with OpenTransport? Do you understand its primary purpose? I don't. Perhpas, you could explain ? Is it yet another proprietary standard ? ] ]> <> The MacOS filesystem ] ]Only to retain backward compatibility. I don't mind if Rhapsody uses some ]other file system, but I want to be able to see my HFS formated ]partitions and disks as well. OPENSTEP/Mach 4.1 for intel can access Apple fs, so it seems that Rhapsody will do it by default. -- ABILITY,n. The natural equipment to accomplish some small part of the meaner ambitions distinguishing able men from dead ones. -- Ambrose Bierce, "The Devil's Dictionary"
From: Jonathan Hendry <jon@steeldriving.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sun, 23 Feb 1997 02:52:04 -0500 Organization: Steel Driving Software, Inc. Message-ID: <330FF724.6302@steeldriving.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Gary W. Longsine wrote: > Anyway, nobody has yet offered proof that my general claim is incorrect. The > designers of Copland wandered very far down an expensive and pointless track. > They should have had their leashes jerked back long, long ago. If they had > presented me with such a kludge two years ago, after hundreds of millions of > dollars and three years wasted on Pink and Taligent, I would have fired them > as being fundamentally incompetent. Period. > > Copland + NuKernel = No protected memory for ordinary applications. I think it's more like Copland GUI = No protected memory for ordinary applications. My understanding is that non-GUI processes would run with all the benefits of a modern OS. Daemon-style things, drivers, etc. would be fine. That's a pretty tiny minority of the software though. The limiting factor there was apparently the GUI. If the GUI had been separated out into its own process, like NeXT's WindowServer, this probably wouldn't be a problem. Warning: Bad analogy ahead. Copland sounds like a combination of WorkspaceManager.app and the WindowServer. Copland applications with GUIs would be like threads spawned off of this mutant Workspace - no protected memory. Since only one WindowServer can run at a time, only one instance of this mutant app could run at a time. Non-GUI programs wouldn't be affected by this limitation.
From: Pohl Longsine <pohl@screaming.org> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: cancel <330F33DC.79FD284E@screaming.org> Control: cancel <330F33DC.79FD284E@screaming.org> Date: Sat, 22 Feb 1997 12:37:44 -0600 Organization: WaveFront Communications, Inc. Message-ID: <330F3CF8.7FF84FF5@screaming.org> References: <330F33DC.79FD284E@screaming.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This message was cancelled from within Mozilla.
From: rft@cg.tuwien.ac.at (Robert F Tobler) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 23 Feb 1997 13:49:51 GMT Organization: Vienna University of Technology, Austria Message-ID: <5ephtv$mac@news.tuwien.ac.at> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <anti_email_spam-0902971903220001@uas-du-01-03.jun.alaska.edu> <5ejud7$2pk@crl9.crl.com> Cc: van@crl.com In <5ejud7$2pk@crl9.crl.com> Van C. Bagnol wrote: > To have _multiple_ users _each_ with a different mapping preference for > individual files looks like it's a many-to-one correspondence. Seems > that can get unwieldy to manage, or at least one that begins to parallel > the filesystem for _each user_. (Everyone gets a Desktop database). I > suppose they can inherit the global mapping and simply override. > Is it really that unwiedly to manage? You only need one database per user, that is managed by the Workspace/Finder and opened when the user logs in. It contains one entry for each file for which the user has overridden the default mapping according to filetype. Since only a fraction of the files of a user need such an entry, and each entry will be on the order of less than 100 bytes (this is an estimate), the overhead for such a database is negligible. Under Nextstep the database already exists for per application+user preferences. It should be trivial to add the mapping tha maps files to their opening application. ------------------------------------------------------------------------ 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: gsupport@mttam.com Newsgroups: comp.sys.next.programmer Subject: Attention Apple, Sun and NeXT developers Date: 23 Feb 1997 15:15:58 GMT Organization: VVI Data Control Specialists Message-ID: <5epmve$qt4@news3.digex.net> Originator: gsupport@ Attention Apple, Sun and NeXT developers. Start your participation in the OpenGraph Gamma Program now and receive ... 1. Proven OpenGraph technology used now by the largest OpenStep customers to monitor billions of dollars worth of products. 2. No-fee technical support via e-mail, no-fee use of the OpenGraph gamma version during the gamma program, and no entrance fee (its free). 3. Free commercial copies of the GraphBuilder** application for ALL computers in participant's company, and one copy of OpenGraph-Developer** and OpenGraph-User*** sent to participants at the end of the gamma program. OpenGraph is successful because we make it a win-win situation for everybody involved. This gamma program is yet another example of that approach. To take advantage of this offer act now by contact VVI-DCS at gsupport@mttam.com. _________________________________ PRESS RELEASE: OpenGraph/OpenStep Gamma Program VVI Data Control Specialists (VVI-DCS) 311 Adams Ave. State College, PA 16803 Attn: OpenGraph Coordinator 814-234-9613 ; 888-DCS-OPEN gsupport@mttam.com State College, PA, 20 January 1997: VVI-DCS announced an expansion of its OpenGraph on OpenStep gamma program. If your business is interested in gamma testing OpenGraph please contact VVI-DCS at gsupport@mttam.com. "We've been working on the OpenGraph/OpenStep port for about a year now." said John Brilhart, Chief Technical Officer at VVI-DCS. "Our customers are reporting complex data sets from global real-time data feeds up to 500 events per second. That type of data reporting requires reliable and optimized report software. The gamma program is an important final part of our total quality control of the OpenGraph port." John adds, "The improvements and new features accompanying that port ensures our commanding lead in the high-end data reporting markets. With OpenStep and OpenGraph we provide compelling and unique solutions which have market advantages for our customers. For that reason we've always been fully committed to OpenStep on all platforms and have been working with NeXT and Sun for quite a while. We expect to apply the same level of commitment to the Apple version of OpenStep when it becomes available." About VVI-DCS: VVI-DCS, founded in 1989, builds custom OpenStep based data report and acquisition systems for the financial service, manufacturing, pharmaceutical and biotech industries and is the leading supplier of high-end data report software for the OpenStep market. About OpenGraph: OpenGraph is a framework of Objective-C and C++ objects for reporting data in graph and textual formats and consists of a graph building application and pre-built objects. OpenGraph accepts real-time feeds from any source and serves as a graphing front-end for real-time financial analysis, transaction, production and inventory analysis, database systems, and instrumentation. OpenGraph is fully object-oriented and is well suited to systems which require reliability, exacting specifications and performance. OpenGraph Status (OpenStep Versions): OpenGraph V3.3a is running in gamma mode in these configurations: (1) Solaris/OpenStep, (2) Mach/OpenStep V4.1 on SPARC/Intel/NeXT computers, (3) Windows NT V4.0/OpenStep. A non-disclosure agreement is required for participation in the gamma program. OpenGraph Status (NEXTSTEP Versions): The OpenGraph V3.2k CD is available for NeXT, HP PA-RISC, SPARC, and Intel computers running NEXTSTEP V3.2 or V3.3. OpenGraph V3.2m is available on DAT and a contract basis for NeXT, HP PA-RISC, SPARC, and Intel computers running NEXTSTEP V3.2 or V3.3. _________________________________ A non-disclosure agreement is required for participation in the gamma program. ** no-license-fee commercial use license. ***no-license-fee and royalty-free commercial use license. (C) Copyright 1997 VVimaging, Inc. (VVI-DCS); All rights reserved. OpenGraph, GraphBuilder, VVI Data Control Specialists, VVI-DCS, and VVimaging are trademarks of VVimaging, Inc. (VVI-DCS). NeXT, NEXTSTEP and OpenStep are trademarks of NeXT Software, Inc. Sun Microsystems and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC international, Inc. in the United States and other countries. Intel is a registered trademarks of Intel. Microsoft and Windows are registered trademarks of Microsoft, Inc. Windows NT is a trademark of Microsoft, Inc. All other trademarks and service marks belong to their respective owners.
From: younghoon KIL <ppai@soback.kornet.nm.kr> Newsgroups: comp.sys.next.hardware,comp.sys.next.programmer,comp.sys.next.software Subject: Re: Looking for display driver for Compaq notebook Date: Mon, 24 Feb 1997 00:30:51 +0900 Organization: KORNET Message-ID: <331062A4.2A19@soback.kornet.nm.kr> References: <ndaniel1-1702971324350001@p9.ts15.metro.ma.tiac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7bit To: "Noah M. Daniels" <ndaniel1@swarthmore.edu> Please visit http://www.deepspacetech.com/ or http://www.bifrostworks.com younghoon KIL ppai@soback.kornet.nm.kr http://soback.kornet.nm.kr/~ppai (NEXTSTEP, OPENSTEP Q&A & Info Board written by Korean)
From: flight@mathi.uni-heidelberg.de (Gregor Hoffleit) Newsgroups: comp.sys.next.programmer Subject: Re: kaffe redeux Date: 23 Feb 1997 20:57:54 GMT Organization: University of Heidelberg, Germany Message-ID: <5eqb0i$4p4@sun0.urz.uni-heidelberg.de> References: <5efsta$4sj$1@darla.visi.com> On 19 Feb 1997 21:55:54 GMT, David Young <dwy@ace.net> wrote: >Okay, after rattling on, I figured it was time to sit down and >compile the damn thing. > >That was the easy part. Then I figured I'd get cool and fix the >broken shared library support. I modified the Makefiles to build >Mach-O relocatables instead of .a's, and poked around in the VM >core to get rld_* to search the path defined in $KAFFE_LIBRARY_PATH >(which I set to *Library/Kaffe) for code objects named foo.native. > >The resulting new version runs HelloWorldApp from the test suite, >but the compiler (javac) throws an internal NullPointerException >when I try to compile the other test programs. Hi David, I took your posting as motivation to take another attempt at shared libs and kaffe, this time successfully (the fragements in the current kaffe are reminiscents of my first try, but then, kaffe wasn't mature enough so I stopped). I'm confident that the upcoming 0.8.2 release will contain working shared libs support for NEXTSTEP. The main problem is that NEXTSTEP doesn't support development of custom shared libs; what's possible are dynamically loadable object files, which can mimick some aspects of shlibs. Anyway, it's not reasonable to install all of the libs used in kaffe as dynamically loadable modules, it only makes sense for optional libs (biss, sawt, net). kaffe's current setup makes it difficult to support this configuration, I'm working with Tim on fixing this for 0.8.2. Gregor PS: BTW, the only real problem with shared libs support was that kaffe sometimes tries to load a library twice or more. NEXTSTEP's rld_load isn't too glad about this. -- | 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: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 23 Feb 1997 21:10:42 GMT Organization: Save the Skeet Foundation Message-ID: <5eqboi$pfr@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <Pine.SOL.3.91.970221201754.16688A-100000@ux5.cso.uiuc.edu> <5em9qk$3eu@news.platinum.com> <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> <5eodgh$ors@lynx.dac.neu.edu> <Pine.SOL.3.91.970222232011.23885A-100000@ux8.cso.uiuc.edu> Cc: tokarek@students.uiuc.edu In <Pine.SOL.3.91.970222232011.23885A-100000@ux8.cso.uiuc.edu> it appeared that Ryan Tokarek wrote: > On 22 Feb 1997, Michael Kagalenko wrote: [much] > > ]> <> The MacOS filesystem > > ] > > ]Only to retain backward compatibility. I don't mind if Rhapsody uses some > > ]other file system, but I want to be able to see my HFS formated > > ]partitions and disks as well. > > > > OPENSTEP/Mach 4.1 for intel can access Apple fs, so it seems that > > Rhapsody will do it by default. > > Great! That's what I thought, but Gary's post seemed to imply otherwise. I did mention something about this.. I think it was in another thread... where I said: ||> The MacOS filesystem will be supported by Rhapsody for dual-boot systems, but ||> it will not be the primary filesystem. The MacOS filesystem will, in time, ||> go the way of the Dodo. I didn't mention that NeXTSTEP already supports read/write/format of DOS and MacIntosh floppies, and read/write for DOS filesystems, so Rhapsody will probably offer something similar for PowerMac users. There area also third-party utilities which support several (over a dozen) filesystem types under NeXTSTEP/OpenStep. I think there is a free one (still being developed?) based on work done originally for Linux, and called "vmount" but I may be mistaken on the details here. This utility will probably be maintained, and I would expect that eventually you'll be able to read/write to Linux, MacOS, and BeOS filesystems from Rhapsody, on your quad-boot PowerMac... (MacOS support will be built-in, the others will probably be available from a free or inexpensive utility). pretty cool, eh? Intel users should be able to read/write to Linux, BeOS, NT, OS/2, and possibly other filesystem types as well, with a third-party utility of this type. Anyway, continued support for the MacOS filesystem will be a part of Rhapsody -- when running Rhapsody you will be able to read/write to your MacOS filesytem on a dual-boot machine. (Probably not the other way around, though.) /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: bchin@us.net (Bill Chin) Newsgroups: comp.sys.next.programmer Subject: help: dissolving image Date: 23 Feb 1997 21:27:26 GMT Organization: US Net - MD,DC,VA ISP - info@us.net Message-ID: <5eqcnu$nio@news.us.net> Hi, I'm trying to get an image to dissolve in over another view under OPENSTEP/Mach 4.0. It was originally NEXTSTEP code, and I've mutated it to this point: (inside of - (void)drawRect:(NSRect)aRect) NSDPSContext *currentContext = [NSDPSContext currentContext]; int i; for (i=1; i<=20; i++) { [theImage dissolveToPoint:(aRect.origin) fromRect:aRect fraction:((float)i/30.0)]; [infoPanel flushWindow]; [currentContext flush]; [currentContext wait]; // for NXPing() } Unfortunately, I still only get the final result. The other view is a NSBox, so it's opaque and the image should use it to dissolve in. The window is buffered. I know it's doing something since it takes a while to finish. Any advice? Thanks in advance, ..Bill Chin bchin@us.net s0wwchin@atlas.vcu.edu
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 23 Feb 1997 22:13:28 GMT Organization: Save the Skeet Foundation Message-ID: <5eqfe8$pfr@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> Cc: shimpei@argo.patnet.caltech.edu In <7fafow55ed.thoron@argo.patnet.caltech.edu> it appeared that Shimpei Yamashita wrote: > gary-nospam-@screaming.org (Gary W. Longsine) writes: [StuffGaryWrote munch]; In this week's exciting continuation of our story, Gary will say, "...NuKernel is the be-all and end-all of kernel design". And now, let's rejoin our story, already in progress... > It doesn't help when you misread documentations. You didn't read the > white paper on the *microkernel*, did you? I have. OK. I concede. And I'd love to read one, by the way. You wouldn't happen to have a URL handy, would you? The work I did read was oriented to the Copland MacOS8 as a whole, and so it seems likely that I incorrectly interpreted the ability of the bare NuKernel, due to excessive extrapolation from limited information. > Yes, and irrelevant. What the Copland OS was or was not supposed to be > capable of is not directly applicable to what NuKernel (which is just the > *microkernel* handling process creation and scheduling; Copland was to be > a lot more than just that!). NuKernel was perfectly capable of hosting a > completely protected, preemmptively multitasking OS; indeed, Gershwin (the > "advanced" version of Copland that never happened) was supposed to use > NuKernel. Copland was not capable of protecting all processes, but that > isn't the microkernel's problem. Ragging NuKernel for Copland's problem is > like implementing MS-DOS on top of Mach and blaming Mach for the horrible > attributes of DOS.... It also seems, given the years-long, never-ending research nature of the Apple OS project, almost as likely that the Gershwin version of the NuKernel (a gleam on a whiteboard?) would have required significant development beyond the Copland version of the kernel, in order to actually and for real, support a modern OS. NuKernel's suitability for a modern OS really is very dependant on how it was implemented, and how far along that implementation really was. I doubt that NuKernel is the be-all and end-all of kernel design, and I really doubt if the implementation was ready from prime-time. Did they cut any corners, because they knew it would be years before the hosted OS actually tried to use certain features? Probably not, from what you say. > I'm inclined to agree, actually, that Copland's OS design was > fundamentally flawed. I was willing to live with it for a while as > a stopgap measure, but never as a semipermanent solution. Again, > irrelevant for deciding on the merits of NuKernel. Now for the 5-year, 1/2 billion dollar question: If NuKernel design was abstracted correctly, and it was implemented well enough to host a modern OS complete with protected memory, etc., why, then, is the architecture of Copland so horribly broken that it can't offer protected memory to GUI applications, even though the kernel would allow it? Is it, as someone previously suggested, because of the "non-reentrant" MacOS-descended GUI? Hmm... if that really is the case, why is everyone so hot to have this GUI ported over to Rhapsody? To cripple Rhapsody, and drive the final nail in Apple's coffin? You see, I'm sure, that I'll be wearing an asbestos suit for quite a while, regardless of whether (as seems likely) new information will cause me to change my mind about exactly which parts of Copland were responsible for its horrible brokenness. 8^) /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.programmer Subject: Re: help: dissolving image Date: 23 Feb 1997 22:21:48 GMT Organization: Rockwell Avionics - Collins Message-ID: <5eqfts$i4l@castor.cca.rockwell.com> References: <5eqcnu$nio@news.us.net> Cc: bchin@us.net You only get one flushWindow per call to drawRect: This is because -display calls windows -disableFlushWindow: method You need to implement your drawRect: method to be called 20 times rather than looping 20 times within drawRect: Use NSTimer to get the effect you want. In <5eqcnu$nio@news.us.net> Bill Chin wrote: > > Hi, > > I'm trying to get an image to dissolve in over another view > under OPENSTEP/Mach 4.0. It was originally NEXTSTEP code, > and I've mutated it to this point: > > (inside of - (void)drawRect:(NSRect)aRect) > > NSDPSContext *currentContext = [NSDPSContext currentContext]; > int i; > > for (i=1; i<=20; i++) { > [theImage dissolveToPoint:(aRect.origin) fromRect:aRect > fraction:((float)i/30.0)]; > [infoPanel flushWindow]; > [currentContext flush]; > [currentContext wait]; // for NXPing() > } > > Unfortunately, I still only get the final result. > The other view is a NSBox, so it's opaque and the image > should use it to dissolve in. The window is buffered. > I know it's doing something since it takes a while to > finish. Any advice? > > Thanks in advance, > > ..Bill Chin > bchin@us.net > s0wwchin@atlas.vcu.edu >
From: boshons@seanet .com(Boshon Sprague) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 23 Feb 1997 22:43:30 GMT Organization: Seanet Online Services, Seattle WA Message-ID: <5eqh6i$bf7@q.seanet.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> Let me step out on a limb here and comment on the fact that we apparently have a large number of unemployed microkernel designers posting. I was at one of many next PR sessions where a (somewhat) noted OO jornalist tried to nail down a OS point with the Nexter doing the session, something like this: Press : I dont see the benfits in your presentation of the (mach) OS perfomace issue with object communication. Nexter : This is the best overall solution for 99% of the performance issuse. Press : You don't really understand what OS issues exist (outside of next (M$)) Next : What is your background in OS design? Press : None.... Nexter : I personnaly hold over 25 specific patents in OS design in my careeer before next, and i feel this is THE BEST system overall ever. Press : But how?.... Nexter : Must be the pretzels. once again, Listen to my words, dont worry we are going to get ALL of the good technology That can be stuffed into this new apple pie. Boshon
From: ndaniel1@swarthmore.edu (Noah M. Daniels) Newsgroups: comp.sys.next.hardware,comp.sys.next.programmer,comp.sys.next.software Subject: Re: Looking for display driver for Compaq notebook Date: Sun, 23 Feb 1997 18:14:54 -0500 Organization: Noah's Ark Message-ID: <ndaniel1-2302971814540001@p0.ts24.metro.ma.tiac.com> References: <ndaniel1-1702971324350001@p9.ts15.metro.ma.tiac.com> <331062A4.2A19@soback.kornet.nm.kr> In article <331062A4.2A19@soback.kornet.nm.kr>, ppai@soback.kornet.nm.kr wrote: > Please visit http://www.deepspacetech.com/ or > http://www.bifrostworks.com Hmm.. the former has some drivers though I don't think they're the right ones. However, the bifrostworks link doesn't work... the domain does not exist. I also tried bitfrostworks.com, in case you made a typo, but that didn't work either. Any ideas? Thanks, -- -- Noah M. Daniels ndaniel1@swarthmore.edu http://www.sccs.swarthmore.edu/~ndaniel1/ "He was a brave man who first ate an oyster" - Jonathan Swift "Wonder is the feeling of a philosopher, and philosophy begins in wonder" - Socrates
From: markeaton_@_mindspring_._com (Mark Eaton) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sun, 23 Feb 1997 15:18:51 -0800 Organization: MindSpring Enterprises Message-ID: <markeaton_-2302971518520001@ip124.santa-clara7.ca.pub-ip.psi.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> In article <5eqfe8$pfr@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: > > And I'd love to read one, by the way. You wouldn't happen to have a URL > handy, would you? Hmm. I looked around on the OS Home page, <http://www.macos.apple.com/>, but I couldn't find it. (That is where I have read the white paper in the past.) > It also seems, given the years-long, never-ending research nature of the > Apple OS project, almost as likely that the Gershwin version of the NuKernel > (a gleam on a whiteboard?) would have required significant development beyond > the Copland version of the kernel, in order to actually and for real, support > a modern OS. NuKernel's suitability for a modern OS really is very dependant > on how it was implemented, and how far along that implementation really was. > I doubt that NuKernel is the be-all and end-all of kernel design, and I > really doubt if the implementation was ready from prime-time. Did they cut > any corners, because they knew it would be years before the hosted OS > actually tried to use certain features? Probably not, from what you say. > Gary, its maddening trying to carry on an amicable conversation with someone when they go out of their way to be adversarial. Thats the main reason Lawson is in my killfile. > Now for the 5-year, 1/2 billion dollar question: If NuKernel design was > abstracted correctly, and it was implemented well enough to host a modern OS > complete with protected memory, etc., why, then, is the architecture of > Copland so horribly broken that it can't offer protected memory to GUI > applications, even though the kernel would allow it? Because there exist companies like Microsoft. That base their top-selling Office software on OLE for Macintosh. OLE peeks into the heaps of other processes. It does stuff like walk the (private) window lists of those processes. It modifies the (private, read-only) visible and clipping structures of those processes. It pokes holes in their clipping structures. All so OLE client processes can draw content that looks 'embedded' in the fore-process. And Copland's goal was to run all that crap and provade as many buzz-word OS features as possible to those apps. Thats the main reason it failed. > Is it, as someone previously suggested, because of the "non-reentrant" > MacOS-descended GUI? Hmm... if that really is the case, why is everyone so > hot to have this GUI ported over to Rhapsody? To cripple Rhapsody, and drive > the final nail in Apple's coffin? Copland failed for a number of reasons. None of them related to NuKernel. As far as the GUI goes, you can't really be so naiive, can you? A GUI is just a pattern of bits on-screen. 'Porting' the Mac GUI really means using whatever graphics API Rhapsody ends up using to draw windows, controls, etc. according the the Apple advanced look-n-feel. Or, hopefully, abstracting the look-n-feel into an Appearance Manager so that it is more flexible. In either case, the look of the GUI has nothing to do with the kernel, the re-entrancy of the graphics system, memory protection, or anything else brought up in this thread. And a nail in Apple's coffin? Oh please... Get a clue and cut the FUD... > > You see, I'm sure, that I'll be wearing an asbestos suit for quite a while, > regardless of whether (as seems likely) new information will cause me to > change my mind about exactly which parts of Copland were responsible for its > horrible brokenness. Uhh huh. You wouldn't get flamed so much if you toned your attitude down a notch... -Mark ---> markeaton_@_mindspring_._com
From: j-norstad@nwu.edu (John Norstad) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sun, 23 Feb 1997 17:27:33 -0600 Organization: Northwestern University Message-ID: <j-norstad-2302971727330001@legume186169.nuts.nwu.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> In article <5eqfe8$pfr@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: > Is it, as someone previously suggested, because of the "non-reentrant" > MacOS-descended GUI? Hmm... if that really is the case, why is everyone so > hot to have this GUI ported over to Rhapsody? To cripple Rhapsody, and drive > the final nail in Apple's coffin? In Rhapsody, the old non-reentrant MacOS GUI API and window drawing and display management architecture will only live in the "blue box" compatibilty part of the system, where unmodified old System 7 applications will run. In the "yellow box" part of Rhapsody, there will be an entirely different reentrant GUI API and window and display management architecture - NeXT's OpenStep application kit framework classes and display postcript. In Rhapsody, preemptively scheduled memory protected apps running in the yellow box will be able to draw on the screen and interact with the user. This wasn't the case in Copland. This is the big difference. The look and feel of Rhapsody's GUI is reportedly supposed to be Mac-like, with many improvements, including perhaps some from NeXTSTEP. This will all be based on top of the new OpenStep and display postcript model, however, not on top of the old System 7 APIs. None of this has anything do with the Mach vs. NuKernel issue. Make sense now? -- John Norstad <mailto:j-norstad@nwu.edu> <http://charlotte.acns.nwu.edu/jln/>
From: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 24 Feb 1997 00:22:04 GMT Organization: Save the Skeet Foundation Message-ID: <5eqmvc$pfr@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> <markeaton_-2302971518520001@ip124.santa-clara7.ca.pub-ip.psi.net> Cc: markeaton_@_mindspring_._com In <markeaton_-2302971518520001@ip124.santa-clara7.ca.pub-ip.psi.net> it appeared that Mark Eaton wrote: > > And I'd love to read one, by the way. You wouldn't happen to have a URL > > handy, would you? > > Hmm. I looked around on the OS Home page, <http://www.macos.apple.com/>, > but I couldn't find it. (That is where I have read the white paper in the > past.) Thanks for looking. > Gary, its maddening trying to carry on an amicable conversation with > someone when they go out of their way to be adversarial. Thats the main > reason Lawson is in my killfile. And thanks for being patient with me, Mark, I'll try to behave. I'm really *not* trying to compete with Lawson. I am simply flabbergasted at the sheer volume of anti-Mach FUD that gets spread here, much of it in the guise of, "The NuKernel was perfect, Apple is stupid for going with a ten year old kernel like Mach." As I'm sure you know, I've been patiently posting non-inflammatory, accurate, and helpful information, since the day of the merger, as to the merits of Mach (and other NeXT bits), and why Apple should adopt OpenStep, "lock, stock, and MachOS", as I've said several times, and they have now done. Last week, as an experiment, I decided to attack Copland and NuKernel head-on, in an effort to shake up the debate a little, and try to gain some ground. I read up in the best source I could find, and opened fire. The only bit I regret is the "crock of sh*t" line. That one really upset people, and I hereby apologize for the inflammatory nature of that remark. By and large, the remainder of my contributions on this topic have been civil, honest, and display a willingness to learn from the views expressed by others (like you) who are able to support their opinions with rational analysis and credible sources. And just in case you've misinterpreted my posts today as sarcasm, let me re-iterate that I have in fact conceded on the fundamental point of contention: It seems that the NuKernel itself probably isn't fundamentally flawed with respect to its handling of protected memory, as I originally claimed. This defect seems to have been introduced by other elements of Copland which lie outside NuKernel. Now, can't I have a little fun with the concession, too? I mean, it really doesn't change the fact that Copland's design is horribly broken... > > Now for the 5-year, 1/2 billion dollar question: If NuKernel design was > > abstracted correctly, and it was implemented well enough to host a modern OS > > complete with protected memory, etc., why, then, is the architecture of > > Copland so horribly broken that it can't offer protected memory to GUI > > applications, even though the kernel would allow it? > Because there exist companies like Microsoft. That base their top-selling > Office software on OLE for Macintosh. OLE peeks into the heaps of other > processes. It does stuff like walk the (private) window lists of those > processes. It modifies the (private, read-only) visible and clipping > structures of those processes. It pokes holes in their clipping > structures. All so OLE client processes can draw content that looks > 'embedded' in the fore-process. This really is a bummer, and I hadn't thought of the implications of the Office suite on the OS design. You are right, of course. Micro$oft, of course, could always decline to migrate the popular Office applications to a new MacOS which had a different architecture and didn't allow these awful things to happen to a process. That would be somewhat bad for Apple, possibly so bad even that Apple might have feared it would be world-ending. OpenStep has changed all that, though. Rhapsody might wind up producing applications that are so cool that nobody *cares* if Office is available on the PowerMac or not. And that, I'm sure, we all agree on. > > Is it, as someone previously suggested, because of the "non-reentrant" > > MacOS-descended GUI? Hmm... if that really is the case, why is everyone so > > hot to have this GUI ported over to Rhapsody? To cripple Rhapsody, and drive > > the final nail in Apple's coffin? > > Copland failed for a number of reasons. None of them related to NuKernel. > As far as the GUI goes, you can't really be so naive, can you? No, I'm not. I was just having fun with that one. Probably too much fun. Sorry. > A GUI is > just a pattern of bits on-screen. 'Porting' the Mac GUI really means using > whatever graphics API Rhapsody ends up using to draw windows, controls, > etc. according the the Apple advanced look-n-feel. Or, hopefully, > abstracting the look-n-feel into an Appearance Manager so that it is more > flexible. In either case, the look of the GUI has nothing to do with the > kernel, the re-entrancy of the graphics system, memory protection, or > anything else brought up in this thread. Yes, I think it's most likely that many of the advanced features from NeXT, Copland, and other Apple and NeXT research will be incorporated into a new Rhapsody GUI that is wonderful and happy. It will have so many compelling cool things that it will be attractive to MacOS, NeXTSTEP, OS/2, Windows and Windows95 users. That is the cool part of all this. We all get a modern OS with lots of cool new toys that isn't crushed under the M$ hegemony. I'm already planning to buy a PowerMac to run it on. I believe that Apple should be rewarded for doing the right thing (and mostly I loathe PCs.) Peace, /gary -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Mon, 24 Feb 1997 10:40:18 +1100 Organization: Unisys Message-ID: <3310D562.2A8F@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <3308EBD5.61F7@acm.org> <0n2UBZ600iWk05nyw0@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit If you are bored of seeing the same thing go round and round, please skip this now. Charles really has nothing new to say, but in the interests of trying to give him an answer, here we go again... Charles William Swiger wrote: > > Excerpts from netnews.comp.sys.next.programmer: 18-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > [ ... ] > >>> Not exactly. The OS should ask the user/an operator what to do, locate > >>> the file, kill the process, ignore the file and continue. You have > >>> quite a few options. > >> > >> The operating system does not have the decision-making powers of a > >> human, and it cannot make a decision between the alternatives you've > >> listed-- it will only do what it's programmed to do. Therefore, you've > >> either got to pick _one_ of the alternatives, or else provide a > >> deterministic and decidable algorithm that the OS can use to select an > >> alternative. > > > > I think we are saying the same thing now. That is exactly what I am > > saying, to OS should in many situations consult a human. > > I completely disagree. With the exception of severe errors due to > external reasons like hardware failure, the OS should never have to > consult a human when an error condition occurs; instead, the OS should > report the error to the process, and let the process decide for itself > whether human intervention is required. Let's go back to one of the original examples. You are writing a modest amount of information to a file, and some other process is chewing up disk space so that you run out of disk. Quite a few processes could get hung up on this, so are you going to return an exception to them all? This is an operations problem, so should be dealt with at that level. Let's see "operations" ---> "operating system"... get it! > This allows processes to continue running if the process determines for > itself that it knows how to proceed after encountering whatever error > condition happened, instead of always blocking. You have already solved this problem by suggesting non-blocking operation. In the above case a non-blocking write. In that case the application has told the OS to "go do this, I'm going onto other things." So in this case it makes more sense if the disk runs out of space for the OS to get operators involved to solve the space problem. This saves a lot of effort in applications programming. > The OS should report severe errors when they occur, and the OS may > require human intervention in the face of hardware failure or other > exceptional conditions, but it is completely inappropriate for the OS to > require human intervention when an open() call fails because the file > wasn't found. Absolutely wrong! It is not "completely inappropriate." As I have said the file might not be present because of some operations error. Or the program might have used some file name that is not the right one. So the operators should be able to make the file present, or redirect input. Your assertion is "completely inappropriate", I have disproved your assertion by counter-example. > Your design suggestion that the OS should always consult a human > operator even when minor, correctable error conditions occur instead of > passing errors to the process is completely flawed. No, I did not say "always." In this case you design into an application what you want to do. However, by default the OS should handle these error conditions. What I am saying is make the system calls handle 95% of cases. More advanced applications or system software such as databases, etc may be coded for concurrency. I don't see how what I am suggesting can be "completely flawed" as a large class of machines works this way. When are you going to stop your huffing and puffing? > If an exceptional condition like a drive failure happens, either: > > (a) you've got a RAID system and redundancy already built in and open() > will be successful because the RAID system provided the needed fault > tolerance, or > > (b) the drive failure means that the file is gone, and there is nothing > that can be done to get the file back short of replacing the drive and > restoring from backups. Asking the human what to do is futile; Wrong again. Humans will get involved in replacing the drive. The customer will get very annoyed if their process gets suspended waiting for engineers to arrive, or it gets killed. Humans might say, "OK I'll copy the backup file to another unit, and redirect input from there." Or if the backup is on tape perhaps redirect input from tape. This certainly isn't futile. Unless of course you are suggesting that providing a better and more robust service is futile. Simply put, it is the job of the OS and the operators to keep the system running. It should not be the task of an application to have to cater for myriads of possible exceptions. This greatly complicates applications development, and the maintenance problem. Applications should address the problem they are supposed to solve, not systems problems. > either > the process can continue without the file, in which case having the OS > report the error without waiting for the human is superior, or else the > process cannot continue until the drive is replaced, and again it won't > matter what the human says to do. As I said, it does! > Proof by induction: > > I can design a simple program which does some operation (like an open()) > and is capabable of handling one error which might occur before the > process decides to give up and terminate. > > Assuming I have a program which handles n error conditions, I can write > a program which handles n+1 error conditions by adding one operation > surrounded by an error handler before the program code for the program > which handles n error conditions. > > If you really want, I can even demonstrate C code for the above, but it > should be obvious how to implement that. This proves nothing! (except that you are full of bluster). > > ...but even assuming that it is, that does not mean that OSs should not > > have better facilities for picking up the many common situations that we > > are interested in. OSs that don't handle these situations, and many don't, > > do not provide an adequate level of robustness. > > So you've been claiming. Your attempts to demonstrate why this is true > so far have come down to the suggestion that the OS block waiting on > human intervention. Try again. You have completely misunderstood what I have said. At no point have I said that the OS blocks. In the case of blocking IO, all this runs on the application process, so it is only the application that blocks. That is the OS provides the services, but the services are actually running on user processes. > > > (B) even if it was possible, why would you want to bloat the OS with all > > > of that code when it's simpler and easier to design processes that > > > perform the error handling that they need? > > > > "Bloat", well Unix has already got bloated, > > Do you remember what I told you about provocative comments? > > We've already concluded that you are from Unisys and have certain biases > for the Unisys operating system, and you are doing a great job of > displaying a strong bigotry against Unix. "We've"? Yes it's you and the rest of the world. I think not. Your form of argument comes down to accusing others of bigotry and biases, strawman arguments, accusing other of doing exactly what you are doing. Your argument process is extremely Socratic and in many cases offensive. I suggest you read "Parallel Thinking" by Edward De Bono. I am not bigoted against Unix, but I do not accept that it is the most modern or useful OS in the world, nor that the rest of the world should be forced to swallow Unix, because it is not that good. This is not bigotry only fact. > Your bigotry is leading you to make patently false claims-- the Unix > aspects of NEXTSTEP require less disk space than some GUI applications, > and an order of magnitude less disk space than Microsoft's latest office > suite. "False claims"? Where did I say that Nextstep requires more disk space than some GUI applications and Microsoft's office suite? Stop making things up. I have made absolutely no false claims. You are very tiresome, but I won't be bullied off the topic, and other people shouldn't be either. > Because application programs should decide for themselves how to handle > those problems, because they may decide to do different things depending > on complex state behavior that is not readily available to the operating > system itself. In fact it is the other way around. The OS can in most cases decide better how to handle most of these errors. That's what an OS is for. Let the OS handle the system, so that applications can handle their specific problem. > > That adds to the code that a programmer must produce; means you have > > maintenance problems to handle all the cases; means you have testing > > problems to test all the cases; means you have just made every project > > much more expensive to complete (well most projects get killed anyway); > > and means you have missed the fundamentals of reuse. > > Don't try to tell me about code reuse and designing error handling systems. Judging from the above, that's exactly what you need to be taught! Go back to your class and open your mind up, and learn some lessons. Perhaps you need to think about what is the difference between applications and systems programming. > I was the primary author of a popular NEXTSTEP product called > CrashCatcher, which only required the addition of one line to the > original source code in order to augment an Objective-C program with > quite sophisticated error handling functionality. Of course, the > developer could add a little more code and be able to perform > arbitrarily complex error handling behavior within a framework that was > well-debugged, modular, and extensible. So does this mean you have biases? > > To explain the interface is still the same. The open call remains the > > same. What I suggest is to reevaluate the contract of the call, and > > determine that much of what needs to be done is common, and > > therefore should not be on the calling side of the interface. In fact > > if you think about it many errors cannot be handled by the application, > > they have to be handled between the OS and the operator. > > Nonsense. The only errors that must be handled between the OS and the > operator are severe errors like hardware failure, and they generally > require human intervention for the simple and practical reason that > there is no way for any layer of software (whether it be the process or > the kernel) to recover. You are yet again repeating yourself. You say "only errors are hardware errors". I have said that file not present is an operational error, depending on how the application has asked for it. Operational errors should clearly be handled between OS, and operator. However, the OS in this case IS an extension of the application process, a point which you have clearly missed. If resources such as disk become full, it is an operations problem, not an exception that applications should in general have to code around. ------------------------------------------------------------------------ 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: gary-nospam-@screaming.org (Gary W. Longsine) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 23 Feb 1997 23:42:30 GMT Organization: Save the Skeet Foundation Message-ID: <5eqkl6$pfr@news.platinum.com> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> <5eqh6i$bf7@q.seanet.com> Cc: boshons@seanet .com Must be the pretzels... I'll have to remember that... ;^) /gary In <5eqh6i$bf7@q.seanet.com> it appeared that Boshon Sprague wrote: > Let me step out on a limb here and comment on the fact that we apparently > have a large number of unemployed microkernel designers posting. I was at one > of many next PR sessions where a (somewhat) noted OO jornalist tried to nail > down a OS point with the Nexter doing the session, something like this: > > Press : I dont see the benfits in your presentation of the (mach) OS > perfomace issue with object communication. > > Nexter : This is the best overall solution for 99% of the performance issuse. > > Press : You don't really understand what OS issues exist (outside of next > (M$)) > > Next : What is your background in OS design? > > Press : None.... > > Nexter : I personnaly hold over 25 specific patents in OS design in my > careeer before next, and i feel this is THE BEST system overall ever. > > Press : But how?.... > > Nexter : Must be the pretzels. > > > once again, Listen to my words, dont worry we are going to get ALL of the > good technology That can be stuffed into this new apple pie. > > Boshon > -- Gary W. Longsine, Systems Engineer | ____/| OpenStep, MachOS, PLATINUM Technologies, Inc. | \ o.O| Objective-C: l_o_n_gsine@platinum.com (NeXTmail | =(_)= (Can i have his spam?) & MIME) |. U Elegance is Relevant.
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 22 Feb 97 21:24:56 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb22212456@howard.one.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> In-reply-to: gary-nospam-@screaming.org's message of 22 Feb 1997 00:14:58 GMT In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) writes: > In article <SHESS.97Feb20085428@howard.one.net>, > shess@one.net (Scott Hess) wrote: > > Unless I've _greatly_ misread a variety of papers, microkernels > > are coming into their own because we are asking entirely too > > much of our monolithic kernels. The amount of effort it takes > > to add something new to your monolithic kernel is often so > > great that you never get around to it - and thus a microkernel > > can be more efficient in the end. In essence, using a > > microkernel lets you get to a better design for the system > > faster than a monolithic kernel, so it wins in the end. Which says nothing about the <size> of the kernel. What everyone seems to forget is that <size> isn't everything. Microkernels are best defined in terms of how the kernel design is abstracted -- not the size of the binary. If several different parts, properly abstracted, are compiled into the same binary, you really have a hybrid micro-monolith kernel -- which is what damned near every vendor is shipping today. Like NeXT, they are all using dynamically loaded device drivers, but the core OS server is compiled into the same binary with the microkernel. Actually, I'd argue size comes into play, too, if only indirectly. If the vendor does things in microkernel terms internally, but turns around and compiles everything into a monolithic kernel for the outside world, most of the functionality is lost, at least to the outside world. The power of a microkernel isn't so much that it lets the _vendor_ make changes easily, though that's nice. The power of microkernels should be that it lets outside programmers add their own pagers, filesystems, and whatnot, without having to do High And Mighty Black Magic to accomplish it. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: JamesCurran@CIS.CompuServe.com (James M. Curran) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer Subject: Re: Objective C? Date: Mon, 24 Feb 1997 01:20:38 GMT Organization: InterServ News Service Message-ID: <5eqq6n$s7s@lal.interserv.com> References: <330E54AC.167E@innosys.com> <petrichE5zqx1.LCv@netcom.com> <5eo65r$53l@lal.interserv.com> <petrichE61n5I.DoK@netcom.com> <856715712.25573@dejanews.com> In <<856715712.25573@dejanews.com>>, mark@oaai.com wrote: >[Redirected to comp.sys.*.programmer] >Just wanted to point out two things: >* Direct access to member variables (instance variables) under Objective >C is allowed, but is rarely used in practice: >{ > MyFoo *f = [[MyFoo alloc] init]; > f->bar = 6.0; >} So does C++, but it's use too, is not encouraged. And, with inline functions, is rarely needed, ie, inline MyFoo::SetBar(float b) { bar = b;} : MyFoo *f = new MyFoo; f.SetBar(6.0); will produced object code identical to what yours would. >* For operations that are performed repeatedly, in a tight loop for >instance, Objective C provides a mechanism for retrieving the function >pointer corresponding to a method. This is more commonly used when an >application is being tuned: >{ > int i; > IMP setIMethod; > MyFoo *f = [[MyFoo alloc] init]; > // retreive the function pointer corresp. to -[MyFoo setI:] > setIMethod = [f methodForSelector:@selector(setI:)]; > for (i = 0; i < 100000; i++) { > // call the function. In ObjC, methods take "self" from the first > // argument and _cmd from the second. > setIMethod(f, @selector(setI:), i); > } >} Which is just foisting off on to the programmer, things that the compiler should be able to do, but can't do to requirement of the language spec. Now, let us assume that f is actually an array of MyFoos. Hence the equilvant c++ code is just: int i; MyFoo *f = new MyFoo[100000]; for (i=0; i < 10000; i++) f[i].setl(i); // equilavent to MyFoo_setl(f[i], i); // as efficent as any simply // function call. Next, let us assume that f is an array of objects of various classes all derived from MyFoo, each with a different setl member function. Here all I'd have to do is declare the setl function in the MyFoo class definition as "virtual". The code example above stays the same int i; MyFoo *f = GetArrayOfMyFooObject(); for (i=0; i < 10000; i++) f[i].setl(i); // equilavent to (f[i].setl)(f[i], i); // as efficent as any function-through- // point call. In effeciency, this is the same as your first example, (which wouldn't work in this example). It also has a much cleaner syntax.. Truth, James
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 24 Feb 1997 01:48:30 GMT Organization: MHPCC Message-ID: <5eqs1e$3rb@kaopala.mhpcc.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <1997021700592626089546@roxboro-177.interpath.net> <0n2_gV200iV7I5aJdw@andrew.cmu.edu> <19970220100923348851@roxboro-169.interpath.net> <Qn3BPAO00iVC4BZPhJ@andrew.cmu.edu> <5ej0nn$6t6@kaopala.mhpcc.edu> <5eka0c$98d@bias.ipc.uni-tuebingen.de> Cc: frank@this.NO_SPAM.net In <5eka0c$98d@bias.ipc.uni-tuebingen.de> Frank M. Siegert wrote: > Copy your Sonata font on a Macintosh HFS Disk 1.44 MByte as plain file (it > should have the 'Shaded A' icon for a PS font), get my FontConvert.app from > peanuts.leo.org or next-ftp.peak.org, install and start in on your NeXT > (Running NS 3.x or OS 4.x). Insert and mount your Mac Disk, show FontConvert > the font, it should be able to convert it painlessly and will calculate a > suitable AFM file in the process... > > BTW FontConvert.app is > freeware/send-me-some-money-if-you-really-like-it-ware, the next release will > be using the CAP (Appletalk) file name scheme for resource and finderinfo > data, so you can directly use a network mounted Appleshare'ed volume. > > I had tried FontConvert.app before on a converted *.rsrc file, and it crashes my Window Server. Using FontConvert.app on the file on the Mac HFS disk did the trick. A kind soul sent me the properly converted files. But I still don't have the converted bitmap files that came with the Adobe distribution. 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: akac@mail.utexas.edu (Alex Kac) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Sun, 23 Feb 1997 21:13:42 -0600 Organization: WI Message-ID: <akac-ya02408000R2302972113420001@newshost.cc.utexas.edu> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <5enmc3$bra@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: : In <markeaton_-ya02408000R2102972132110001@news.mindspring.com> it appeared : that Mark Eaton wrote: : > In article <5eldq2$kj@news.platinum.com>, gary-nospam-@screaming.org (Gary : > W. Longsine) wrote: : > : > > : > > Then you haven't got a clue. NuKernel should have been scrapped before : > > a single line of code was written. Protected memory, but only for : certain, : > > "special" processes? What a crock of sh*t. : > : > Whats really a crock of sh*t is when you make an off the cuff statement : > like that without really knowing whether its true or not. When you do that, : > you're no better than Lawson English... : : That's a pretty low blow, especially since I've provided some pretty clear : documentation, from Copland-friendly sources, to back up my claim. : : > (FYI- NuKernel does not extend memory protection just to certain, "special" : > processes...) : : Wrong. Plainly, clearly, demonstrably, incontestably wrong. Ordinary : Copland applications, even brand new ones written for the Copeland OS, are : <required> to share the same memory pool -- not just the legacy System 7 apps : (as is the case with the new Blue Box.) : : COMEDY BREAK: : Tai-Kwon-Leap Master: Who disrupts our meditation as a pebble disturbs the : pond? : Tai-Kwon-Leap Student: Ooh! ooh! Me! Ed Gruberman! : : I'm so shocked at the tremendous waste of resources that went into the : backward architecture of Copland that I tend to emote on the topic -- sorry. : : I just don't understand why anyone would spend almost half a billion dollars, : and over 5 years on OS research (Pink, Taligent, Copland) and fail to grok : something so basic as a rational protected memory scheme. (I also don't : understand why people are so infatuated with a research kernel (Copland's : NuKernel) that's never seen the production light of day and doesn't offer an : improvement over kernels that I've been using for years... but that's another : topic.) : : Again, I suggest that you check out the Apple Press book on Copland. It was : written by folks friendly to the Copland project, and states in clear, : matter-of-fact language how the OS was to work. : : "MacOS 8 Revealed: A Technical Tour of the New Mac OS", Tony Francis, ISBN : 0-201-47955-9, Apple Press, August 1996. : Sir, this book and ALL the claims about are about the OS in general. After reading all of your posts, you obviously do not know a kernel based OS works. The NuKernal supported protected memory, SMP, threads, and pre-emptive multitasking. That is the kernel. Now how the actual OS (it sits atop the kernel) uses that kernel is a different matter. Apple could have used the AIX kernel and still had the same problem. The reason? Because the actual OS only used what it needed from the kernel. It told the kernel, I am setting up a protected memory partition for ALL apps, one for servers, and one for networking/OS things. The kernel obeyed. It is like have a whole yard of wood, nails, metal girders, construction workers, and all the supplies to build a skyscraper and only using what you need to build a small house. The kernel did provide full protected memory to weild however the OS asked it to. It just so happened that the Copland OS was going to give applications no protection.
From: nspace@cts.com (Jerry Stratton) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.system Date: Sun, 23 Feb 1997 19:28:39 -0800 Organization: Negative Space Message-ID: <nspace-2302971928400001@nspace2.cts.com> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> <19970221004435207619@roxboro-184.interpath.net> In article <19970221004435207619@roxboro-184.interpath.net>, phenix@interpath.com (John Moreno) wrote: >] That's kind of what I meant.. You can't choose to open by file type >] _OVER_ file creator. If the file creator data is there, and the file >] creator app exists on that machine, you MUST use it. You cannot >] choose a file type application OVER that creator app. I didn't say >] you can't open by file type at all. I simply said the Mac doesn't >] give you a choice between the two -- if creator exists you use it, >] otherwise you use type... no choice. Well, it does give you a choice. If the application you want is visible, and that application tells the operating system it can handle that file type, you can drag & drop onto that application. This works regardless of whether or not the owning application exists. Perhaps it would be nice to have an additional "File" menu item which forces Easy Open to query the operating system for all apps that claim to handle the file type. On the other hand, I can't honestly think of a time when I wanted to open a file by other than the creator when e desired app wasn't already visible, generally in the launcher. Jerry jerry@hoboes.com http://www.hoboes.com/ e-mail help@hoboes.com What Your Children Are Doing: http://www.hoboes.com/Children/
Date: Sun, 23 Feb 1997 10:41:09 -0600 From: mark@oaai.com Subject: Re: Objective C? Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer Message-ID: <856715712.25573@dejanews.com> Organization: Deja News Usenet Posting Service References: <330E54AC.167E@innosys.com> <petrichE5zqx1.LCv@netcom.com> <5eo65r$53l@lal.interserv.com> <petrichE61n5I.DoK@netcom.com> [Redirected to comp.sys.*.programmer] Just wanted to point out two things: * Direct access to member variables (instance variables) under Objective C is allowed, but is rarely used in practice: { MyFoo *f = [[MyFoo alloc] init]; f->bar = 6.0; } * For operations that are performed repeatedly, in a tight loop for instance, Objective C provides a mechanism for retrieving the function pointer corresponding to a method. This is more commonly used when an application is being tuned: { int i; IMP setIMethod; MyFoo *f = [[MyFoo alloc] init]; // retreive the function pointer corresp. to -[MyFoo setI:] setIMethod = [f methodForSelector:@selector(setI:)]; for (i = 0; i < 100000; i++) { // call the function. In ObjC, methods take "self" from the first // argument and _cmd from the second. setIMethod(f, @selector(setI:), i); } } Regards, Mark --- M. Onyschuk and Associates Inc. Software Systems for the U.S. and Canadian Financial Industries. 15 La Rose Ave. Suite 702, Weston Ontario M9P 1A7 (416)241-3076 In article <petrichE61n5I.DoK@netcom.com>, petrich@netcom.com (Loren Petrich) wrote: > > In article <5eo65r$53l@lal.interserv.com>, > James M. Curran <JamesCurran@CIS.CompuServe.com> wrote: > > To carry your example a bit further, since all the functions are > >defined inline, the machine code generated for this how be EXACTLY the > >same as it would be if you had written it was: > > >petrich@netcom.com (Loren Petrich) wrote: > >[I modified this a bit to make it a better example] > > >>for (int i=0; i<bs; i++) > >> B.val(i) = Complex(A.val(i) + A.val(i+1), 0); > > Or: > > for (int i=0; i<bs; i++) { > B.val(i).real = A.val(i) + A.val(i+1); > B.val(i).imag = 0; > } > > [C translation deleted -- it was not nearly as elegant] > > > It allows for remarkable control of the generate code, which is why C > >and now C++ is the defacto standard in systems programming. > > I may add that I started out programming with Fortran, which has > built-in arrays (also a feature of Java), so that's why constructing a > good array class has been critical for me. > > [Objective C version...] > > >-(id) val:(int) index > >{ > > return(Contents[index]); > >} > > >void set:(int) index, (id) value; > >{ > > Contents[index] = value; > >} > >.... > > What is especially interesting here is that one cannot do > call-by-reference in Objective C, as one can on C++, thus requiring both > separate functions for transmitting and receiving values (val, set). > OTOH, with C++, one can imitate Fortran/Java arrays much more successfully > ("val" both transmits and receives values, thanx to its call by > reference), and be able to have such constructs as CntList.val(i)++ . > > [confusing Objective C syntax...] > > I agree that C++'s > > object.method(arg) > > is a more natural extension of plain C than ObjC's > > [object method: arg] > > -- the C++ approach treats classes as an extension of structs, and methods > as a kind of function. > > > And, in constrast to the C++, which require NO function calls in the > >loop, the Objective C require at least 6, plus three table look-ups, > >per iteration! > > This means that ObjC objects will not be very good for *anything* > that has to be done a large number of times. > > > So, for the advantage of run-time object binding (a requirement of > >"pure" OOP, but unnecessary in 99.999999% of all OOP programs), you > >must put up with a contorted syntax, barely any type safety at all and > >significant run-time speed & space penalties. (C++'s syntax grew > >naturally out of C, is incredibly strict about type safety, and design > >to have absolutely NO speed or space penalty over C or even > >assembler). > > However, runtime method resolution is OK if one does not have to > do it very often, and it also helps get around the Fragile Base Class > problem. Thus, it could be useful for implementing some OS services -- > creating a window or a dialog box or a network connection or a thread is > not something that happens very frequently by computer-chip standards. > > The Fragile Base Class problem is a serious one for implementing > OS services, since these will generally need to be upgraded to add > features, fix bugs, speed them up, etc. -- Be, Inc. has been > much-criticized for implementing the bulk of the BeOS's API in C++. > > IMO, the best possibility would be to have Objective C++ -- so it > will be possible to use whichever sort of construct is appropriate for > the problem at hand. > -- > Loren Petrich Happiness is a fast Macintosh > petrich@netcom.com And a fast train > My home page: http://www.webcom.com/petrich/home.html > Mirrored at: ftp://ftp.netcom.com/pub/pe/petrich/home.html -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: embuck@palmer.cca.rockwell.com (Erik M. Buck) Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 23 Feb 1997 17:52:47 GMT Organization: Rockwell Avionics - Collins Message-ID: <5eq05f$grn@castor.cca.rockwell.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> Cc: johnh@madcow.dircon.co.uk > I've put a fair amount of time into scoping the amount of work > involved in porting some real applications onto OpenStep only > to find that the common classes List, HashTable etc all gone > from the OpenStep spec. > > Arrrrgh! List and HashTable could be re-implemented or borrowed from GNUStep. The issue that probably sealed their fate was reference counting. I think the HashTable functions are still in OpenStep. You will need to manage your own reference counts. > These where useful, tightly written classes that surely would > not have been to much effort to port to OpenStep (even inheriting > from NSObject( but no, we are told we must use the impossible to > subclass NSMutableDictionary and NSArray class clusters. They are not exacly impossible to subclass. > While I'm at it lets keep strings as a data type rather than a class. > A char * can go along using dodgy features like a reference count at > (char *)string[-1]. EOF would be a good deal simpler and faster if > NSString hadn't been invented. Dates have loads of complex behaviour > and justify being a class strings are better kept as a datatype. Strings have loads of complex behavior and justify being a class. Of course, feel free to use char *s as much as you want. OpenStep is happy to accept char *s via [NSString stringWithCString:]. Just remember that OpenStep is based on reference counting. In NeXTstep, most of the string related methods HAD to copy their data to prevent memory errors. For example: when you used the -setTitle: method, you were often unnecessarily duplicating a string. Furthermore, when the string was something dynamic (like a file system path), more and more memory management issues came into play. If the string was distributed via DO, there were problems. The NSString class nicely encapsulates all of these issued and nearly eliminates all string related memory issues. NSStrings also provide an opportunity to use less overall memory by safely allowing immutable string sharing. Objective-C still has its roots in C. Nothing stops you from using char * or casting ints as pointers etc. It is just considered bad style (error prone!). Also "using dodgy features like a reference count at (char *)string[-1]" is extremely "dodgy!". This kind of game is exactly what encapsulation is meant to hide. How much memory should I allocate for a string intended for use by another object given your "spotty" reference count scheme ? What if I don't have access to the source code for the other objects ?
From: Norbert Heger <bertl@hal.kph.tuwien.ac.at> Newsgroups: comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 24 Feb 1997 08:22:37 GMT Organization: Vienna University of Technology, Austria Message-ID: <5erj4d$4ut@news.tuwien.ac.at> References: <5ecusc$9p0@castor.cca.rockwell.com> Originator: bertl@gemini Erik M. Buck <embuck@palmer.cca.rockwell.com> wrote: > -performWith:afterDelay:cancelPrevious: can be simulated with > NSTimer and NSNotification What's wrong about using NSObject's: - (void)performSelector:(SEL)aSelector object:(id)anArgument afterDelay:(NSTimeInterval)delay; + (void)cancelPreviousPerformRequestsWithTarget:(id)aTarget selector:(SEL)aSelector object:(id)anArgument - 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: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 21 Feb 1997 02:56:57 -0800 Organization: CRL Dialup Internet Access (415) 705-6060 [Login: guest] Message-ID: <5ejv1p$2r4@crl9.crl.com> References: <5ddp66$jpc@news.bu.edu> <tonyn-ya02408000R0702971600220001@news.tiac.net> <5dgma6$rat$1@majipoor.cygnus.com> <peterm.855561144@ulfrun> <5dmrj5$si2@nef.ens.fr> Julien Jalon (Julien Jalon (jalon@drakkar.ens.fr)) wrote: : In article <peterm.855561144@ulfrun>, Peter Moller <peterm@dna.lth.se> wrote: : >jrudd@cygnus.com (John Rudd) writes: : [...problem with a NeXT...] : >"Checking System Resources" came up and then nothing. A manual told me to : >press ctrl-alt-q (or something) the get a shelltool and see what was happening. : >It was waiting for a DNS-server. And it waited and it waited. Very intuitive. : >Very non-unix. : : If this happen on a Mac (and it happens often) : the system doesn't : boot and you can't do almost anything, even if you are an advanced user, and : sometimes you have to reinstall the system. Actually I boot from the CD and run Disk First Aid to fix it. Did so last night for the first time on my home machine. (Another thing is to carve a small partition with a minimal system and disk repair software. If your main partition volume doesn't boot, it finds the next one and you're all set to run diagnostics.) Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
Newsgroups: comp.sys.next.programmer From: piers@ilink.de (Piers Uso Walter) Subject: Q: How to load submenus from nibs Message-ID: <E619CF.Ep5@mediahaus.de> Sender: news@mediahaus.de (News System) Organization: Mediahaus Stroebel in Duesseldorf (Germany) Date: Sun, 23 Feb 1997 01:55:27 GMT I'm working on an old 3.3 application that has not yet been converted to Openstep and would like to dynamically attach submenus loaded from a nib file. I've experimented with Menu's setSubmenu:forItem: method which seems to work OK if I programmatically create the new submenu. I want to create the submenu in InterfaceBuilder and load it from a nib file, however. I thought of two ways how to try to do this: - use a "second" menu from the main nib file - use the "main" menu of a second nib file I cannot get the first way to work as there seems to be no way to create a "second" menu in InterfaceBuilder. While trying the second way I run into a different problem: apparently loading the second nib file (containing a "main" menu) will set this nib file's menu to be the main menu of my application (which I don't want). Is there a way to prevent this? If anybody knows of a way to do this (dynamically attach an IB-generated submenu), please let me know. Piers -- -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=- "I think people are happy using Windows, and that's an extremely depressing thought." -= Steve Jobs, 1/96 =- Piers Uso Walter ilink GmbH piers@ilink.de -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-
Newsgroups: comp.sys.next.programmer From: piers@ilink.de (Piers Uso Walter) Subject: Re: Q: How to load submenus from nibs Message-ID: <E61FIJ.Go9@mediahaus.de> Sender: news@mediahaus.de (News System) Organization: Mediahaus Stroebel in Duesseldorf (Germany) References: <E619CF.Ep5@mediahaus.de> Date: Sun, 23 Feb 1997 04:08:42 GMT In article <E619CF.Ep5@mediahaus.de> I wrote: > > I'm working on an old 3.3 application that has not yet been converted > to Openstep and would like to dynamically attach submenus loaded from > a nib file. I've experimented with Menu's setSubmenu:forItem: method > which seems to work OK if I programmatically create the new submenu. > > I want to create the submenu in InterfaceBuilder and load it from a > nib file, however. I thought of two ways how to try to do this: > - use a "second" menu from the main nib file > - use the "main" menu of a second nib file > > I cannot get the first way to work as there seems to be no way to > create a "second" menu in InterfaceBuilder. > > While trying the second way I run into a different problem: > apparently loading the second nib file (containing a "main" menu) > will set this nib file's menu to be the main menu of my application > (which I don't want). Is there a way to prevent this? > > If anybody knows of a way to do this (dynamically attach an > IB-generated submenu), please let me know. I found a working solution (albeit a very clumsy one): In IB I set up the new menu A as a submenu of an existing submenu B (effectively hiding menu A upon startup). Now I can do all menu shuffling that I want without having to create menu A in Objective-C. As long as I make sure that menu A is removed from menu B before menu B is opened, no harm is done by "temporarily storing" menu A in menu B. Piers -- -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=- "I think people are happy using Windows, and that's an extremely depressing thought." -= Steve Jobs, 1/96 =- piers@iqweb.de -=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-=+=-
From: Erik Doernenburg <erik@object-factory.com> Newsgroups: comp.sys.next.advocacy,comp.sys.next.misc,comp.sys.next.programmer Subject: Re: Bring back List, HashTable classes and string datatype! Date: 24 Feb 1997 10:15:36 GMT Organization: Object Factory GmbH (Germany) Message-ID: <5erpo8$89j@leonie.object-factory.com> References: <5eagds$niv$1@newsserver.dircon.co.uk> <5eq05f$grn@castor.cca.rockwell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit embuck@palmer.cca.rockwell.com (Erik M. Buck) wrote: > > [...] > > While I'm at it lets keep strings as a data type rather than a class. > > A char * can go along using dodgy features like a reference count at > > (char *)string[-1]. EOF would be a good deal simpler and faster if > > NSString hadn't been invented. Dates have loads of complex behaviour > > and justify being a class strings are better kept as a datatype. > > Strings have loads of complex behavior and justify being a class. I can only second that. Just a simple example: Suppose you have a string which contains 50k characters. Say you want to insert 10 characters in the middle. How effeciently can you do that using C-Strings? Using a string class and some clever memory management you can do that in O(1) whithout even having to copy anything! Okay, this is just an example, but I can say that I've used NeXT's String and Data classes in a couple of projects involving biggish amounts of data and I was always positively suprised about the speed and the amount of optimisation that takes place behind the scenes. regards, erik -- Erik Dörnenburg OBJECT FACTORY Gesellschaft für Informatik und Datenverarbeitung mbH http://www.object-factory.com
From: doug@qnx.com (Doug Santry) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 24 Feb 1997 09:23:30 -0500 Organization: QNX Software Systems Message-ID: <5es892$um@qnx.com> References: <jm041536-1702972018170001@mencjo.apple.com> <Pine.SOL.3.91.970222111455.24705D-100000@ux8.cso.uiuc.edu> <5eodgh$ors@lynx.dac.neu.edu> <Pine.SOL.3.91.970222232011.23885A-100000@ux8.cso.uiuc.edu> In article <Pine.SOL.3.91.970222232011.23885A-100000@ux8.cso.uiuc.edu>, Ryan Tokarek <tokarek@students.uiuc.edu> wrote: >On 22 Feb 1997, Michael Kagalenko wrote: > >> Ryan Tokarek (tokarek@students.uiuc.edu) wrote >> ]<small snip> >> ]> <> Open Transport >> ] >> ]What's wrong with OpenTransport? Do you understand its primary purpose? >> >> I don't. Perhpas, you could explain ? Is it yet another proprietary >> standard ? > >As I understand it (and I do not know the details so people with more >knowledge of OT step in here), OpenTransport provides a network-neutral >API. Programs can use the various OT APIs to deal with networking, and >they won't need to know which networking standard is being used (TCP/IP, >IPX, AppleTalk, whatever). It adds a layer of abstraction that can be >used to send infromation over any network with the app having to know >the nature or details of the network. > >You can use OpenTransport to deal with specific details of a certain >network protocol, but OpenTransport provides the tools to deal with any >network (that OpenTransport is configured for) without the app having to >know which one. > >Taking a look at the info on TCP for OpenTransport (in the Control >Panel), it appears to be based on "Mentat Portable Streams" and >"Mentat TCP"... if that's meaningful to you (it isn't to me). > >I don't know whether there is an equivalent in NeXTStep, but that's >roughly what OpenTransport does. I don't know whether it would be >advantageous to port it over to Rhapsody, but it it's the Mac's current >networking API. Why not the socket API? Would make porting lots 'o stuff easier and it is well known/documented. DJS
From: cb@guinan.mm.se (Christian Brunschen) Newsgroups: comp.sys.next.programmer Subject: File System - a thought Date: 24 Feb 1997 14:38:58 GMT Organization: - Message-ID: <5es962$1l2@mn5.swip.net> On the subject of File Systems. I am an owner/user of a 25MHz 68040 NeXTcube, and a sometime-user of a variety of different Macintoshen (plus an assortment of different unices, Linux, etc). I Have looked with great interest upon the BeBox, but decided that one piece of obsolete hardware was enough for me :) Now, in Unix, and thus in the Unix-based NEXTSTEP and OpenStep, a file is a file, with only one 'fork', which simply contains the data of the file. In order to group several different, distinct, chunks of data together, we place all these chunks in a directory, which is presented to the user as if it were in fact a single file -- this is what is known as a 'Wrapper'. Macintoshen on the other hand let each file contain two different forks: one for that data of the file itself, and one for 'resources' -- i.e., other chunks of data which are not the _main_ data of the file, but still somehow connected _to_ the file. One thing that is put here is the Creator / Type information -- where Creator and Type are 'codes' of 32 bits each. Problems with the Mac approach: * The Creator and Type codes are limited in range, and incompatible with the NIME type system that is getting more and more accepted with the spreading of the WWW. * Accessing resources ('data chunks' in the resource fork) requires an API beyond that of 'normal' file manipulation; this also means that Creator and Type information are only accessible through specialized software (which is, admittedly, extremely prevalent) * storing a file that has a resource fork on a file system that does not support such, requires interesting convolutions, such as AppleSingle or AppleDouble. They work, though. Problems with the NeXT approach: * File type information is stored in the name of the file -- which is the wrong place to store filetype information. Also, this info is, again, not compatible with MIME types. * If I want to add out-of-band information to a file which is not already in a wrapper, I have to _create_ a wrapper, move the file into it, and add the additional o-o-b info there. This means that I must transform a file into a directory -- not _really_ an intuitive thing to do. Now, I must confess that my bias makes me lean towards the 'Wrapper' approach, as it has less problems, and is more extensible, and uses fewer different API:s, than the 'multiple fork' approach. But what still bugs me is that, unlike on Macintoshen, there is no easy way to add metadata or whatever to a file, without rather violently modifying the way that file is stored. Basically, I think that the Unix:y distinction between Files and Directories should go away. In this way, a file would indeed have two 'forks' -- one 'data' fork, and one 'directory' fork. The 'data' part gets accessed with the usual file API -- open(), lseek(), read(), write(), close(). The 'directory' part has its own, pre-existing API -- opendir(), readdir(), seekdir(), closedir(). All Unix:y programs that deal with files & directories still work _almost_ the same way; except those that differentiate between files and directories would have to be rewritten to take into account the case where a file is _both_. This gets rid of the problem of adding o-o-b data to a file -- each file is, in this scheme, its own wrapper. The UI would store any information it feels like in a pre-determined file inside the wrapper -- like it is done today under NEXTSTEP. However, we gain the problem of backwards-compatibility with standard Unix filesystems, that most certainly do _not_ implement this. Here, we would have to go through much smaller convolutions than for AppleSingle or AppleDouble, however: we 'simply' put the 'data fork' inside the wrapper, with some reserved name -- the way we already do today under NEXTSTEP when we put a file in a wrapper, so this would actually be backwards-compatible. File type / creator / whatever information would now be placed where it should be, in a 'resource' inside the wrapper for each file. Those files that don't _need_ such information, also don't have to carry it around with them. And each resource is quite accessible through the usual File / Directory API:s, and quite obviously the usual File System browsing techniques as well -- be they a Browser, a bunch of windows, a CLI, or whatever. Also, this way, resources can be symlinked -- so we can save space by sharing resources between different files. I'm afraid my ramblings will bring down the wrath of Those Who Know(TM) upon me, and I am sorry my mind is such a mess and my writing so bad, but I hope this can be, at least, an inspiration for continuing constructive discussion :) Best regards, // Christian Brunschen -- -- Christian Brunschen cb@mm.se
From: yannick buisson (université de La Rochelle) Newsgroups: comp.sys.next.programmer Subject: EOModeler 2.0 .... Date: 24 Feb 1997 15:44:04 GMT Organization: Universite de La Rochelle Message-ID: <5esd04$gll@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, I try to use EOMOdeler with EOF2.0. Lots of thing have been modified (compare with EOF1.0) but i can't find how, to do actions than i did before with EOF1.0 !! 1. I don't see the synonyms and views ? 2. If i remove a table of my model, how can i import it back in my model ? Thanks for your help YANNICK -- //// (. .) ----oOO--(_)--OOo-------------------------------------------- Yannick BUISSON Centre de Ressources Informatiques Université de La Rochelle tel prof. : 46 45 82 14. fax prof. : 46 45 82 45. yannick@cri.univ-lr.fr
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Followup-To: comp.sys.next.advocacy, comp.sys.mac.advocacy Date: Mon, 24 Feb 1997 12:11:14 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <An4Qima00iUx821IJM@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <3308EBD5.61F7@acm.org> <0n2UBZ600iWk05nyw0@andrew.cmu.edu> <3310D562.2A8F@acm.org> In-Reply-To: <3310D562.2A8F@acm.org> [ ...followups redirected, some programming groups snipped... ] Excerpts from netnews.comp.sys.next.programmer: 24-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org > If you are bored of seeing the same thing go round and round, please > skip this now. Charles really has nothing new to say, but in the > interests of trying to give him an answer, here we go again... "Crude and slow, clansman. Your attack was no better than that of a clumsy child...." Do you really think that you're going to fool anyone with this kind of stuff, Ian? Even if you refuse to grant me any credit at all, don't you think the other readers on these newsgroups can see through this gauche little ploy of yours? C'mon. [ ... ] >>>> The operating system does not have the decision-making powers of a >>>> human, and it cannot make a decision between the alternatives you've >>>> listed-- it will only do what it's programmed to do. Therefore, you've >>>> either got to pick _one_ of the alternatives, or else provide a >>>> deterministic and decidable algorithm that the OS can use to select an >>>> alternative. >>> >>> I think we are saying the same thing now. That is exactly what I am >>> saying, to OS should in many situations consult a human. >> >> I completely disagree. With the exception of severe errors due to >> external reasons like hardware failure, the OS should never have to >> consult a human when an error condition occurs; instead, the OS should >> report the error to the process, and let the process decide for itself >> whether human intervention is required. > > Let's go back to one of the original examples. You are writing a modest > amount of information to a file, and some other process is chewing up > disk space so that you run out of disk. Quite a few processes could get > hung up on this, so are you going to return an exception to them all? Yes. > This is an operations problem, so should be dealt with at that level. > Let's see "operations" ---> "operating system"... get it! I hate to break up such a nice connection, but it refers to a period back in the 60's and 70's where computers required full-time operators in order to keep feeding them Hollerith punched cards. The majority of computers have been designed to run without continuous human attendence for almost 20 years now. Your whole theory is based off of the assumption that a human will always be around to tell the machine what to do when it encounters a problem. Current operating systems are designed to not require human intervention for normal processing and minor errors. There are lots of machines running unattended nowadays, and any general purpose operating system has to be able to run such an unattended system. >> This allows processes to continue running if the process determines for >> itself that it knows how to proceed after encountering whatever error >> condition happened, instead of always blocking. > > You have already solved this problem by suggesting non-blocking > operation. So you do acknowledge that I was the first to bring up the issue of non-blocking I/O. > In the above case a non-blocking write. In that case the application has > told the OS to "go do this, I'm going onto other things." So in this > case it makes more sense if the disk runs out of space for the OS to get > operators involved to solve the space problem. This saves a lot of > effort in applications programming. There's that false assumption that 'there will always be an operator' again. >> The OS should report severe errors when they occur, and the OS may >> require human intervention in the face of hardware failure or other >> exceptional conditions, but it is completely inappropriate for the OS to >> require human intervention when an open() call fails because the file >> wasn't found. > > Absolutely wrong! It is not "completely inappropriate." As I have said > the file might not be present because of some operations error. Or > the program might have used some file name that is not the right > one. So the operators should be able to make the file present, or > redirect input. Your assertion is "completely inappropriate", I > have disproved your assertion by counter-example. No, you have proved that you didn't understand my assertion. Read what I said again, and pay close attention to the word "require". I did _not_ say that having the OS ask for human intervention is inappropriate for all circumstances. However, the example of an unattended server machine is one example where where the OS should never ask for human intervention because an open() call failed. Having the OS be _required_ to ask for human intervention is completely inappropriate in the case of an unattended server. Furthermore, I assert that general purpose operating systems should be designed to not perform completely inappropriate responses to common situations. >> Your design suggestion that the OS should always consult a human >> operator even when minor, correctable error conditions occur instead of >> passing errors to the process is completely flawed. > > No, I did not say "always." The operating system does not have judgement. Either it's programmed to ask for human intervention, or it's not. Regardless of how complex an error handling behavior you design into the OS, there will still exist applications which will want different behavior from what the OS will do, and will therefore have to implement their own error handling themselves. Rather than design an error handling mechanism into an OS which is completely inappropriate for some common tasks, modern operating systems are designed to perform the greatest common subset of error handling behavior which is appropriate for all tasks. For an example, the OS should be designed to retry I/O operations several times when a "soft" drive error occurs without raising an error, since this is appropriate for all tasks. [ ... ] > Simply put, it is the job of the OS and the operators to keep the > system running. Unattended machines do not have operators! An OS which is required to rely on the availability of a human operator is not a general-purpose OS. >> Proof by induction: >> >> I can design a simple program which does some operation (like an open()) >> and is capabable of handling one error which might occur before the >> process decides to give up and terminate. >> >> Assuming I have a program which handles n error conditions, I can write >> a program which handles n+1 error conditions by adding one operation >> surrounded by an error handler before the program code for the program >> which handles n error conditions. >> >> If you really want, I can even demonstrate C code for the above, but it >> should be obvious how to implement that. > > This proves nothing! (except that you are full of bluster). This _is_ rich. First, you make a claim without providing any shred of justification-- "proof by assertion" again, and then you claim that _I'm_ "full of bluster". Sorry, but you're wrong on both counts. I just proved that I can design a process which will require a form of error handling which the OS cannot possibly perform by itself. There will be always be tasks which have to perform their own error handling because it is impossible to write an OS in finite time or space that could handle all error conditions without interacting with the process which encountered the error. >> So you've been claiming. Your attempts to demonstrate why this is true >> so far have come down to the suggestion that the OS block waiting on >> human intervention. Try again. > > You have completely misunderstood what I have said. At no point > have I said that the OS blocks. How quickly you've managed to forget my real world example of how having the OS ask for user input can lead to deadlock! Remember the case of DPS encountering an error, and therefore being unable to display the alert panel required to obtain user feedback. No doubt you've love to forget anything and everything that could possibly contradict your precious assertions, but you're not going to win any arguments that way..... >> Your bigotry is leading you to make patently false claims-- the Unix >> aspects of NEXTSTEP require less disk space than some GUI applications, >> and an order of magnitude less disk space than Microsoft's latest office >> suite. > > "False claims"? Where did I say that Nextstep requires more disk space > than some GUI applications and Microsoft's office suite? You said "Unix is bloated". That is a false claim. In order to refute your false claim, I showed the actual size that Unix takes up, and I compared that size with the size of various common GUI applications, and that of M$'s office suite. I didn't say that you said anything about the size of GUI applications or M$'s office suite. > Stop making things up. I have made absolutely no false claims. Except for claiming that "Unix is bloated"? Are you now going to retract this false claim in the face of real-world evidence? I haven't seen you state that "I was wrong to claim that Unix is bloated", so it appears that not only did you make a false claim, that you continue to assert it, too. [ ... ] >> Because application programs should decide for themselves how to handle >> those problems, because they may decide to do different things depending >> on complex state behavior that is not readily available to the operating >> system itself. > > In fact it is the other way around. That depends on the application, now doesn't it? >> I was the primary author of a popular NEXTSTEP product called >> CrashCatcher, which only required the addition of one line to the >> original source code in order to augment an Objective-C program with >> quite sophisticated error handling functionality. Of course, the >> developer could add a little more code and be able to perform >> arbitrarily complex error handling behavior within a framework that was >> well-debugged, modular, and extensible. > > So does this mean you have biases? Yep-- for example, I'm biased about CrashCatcher. It would be impossible for me to provide a completely unbiased description of CrashCatcher's merits. I can describe a lot of good things about the product, and I can try to give an honest description of it's problems; other people can look at how I describe CrashCatcher, and being aware of the fact that I wrote much of it, can form their own opinions. C> Nonsense. The only errors that must be handled between the OS and the C> operator are severe errors like hardware failure, and they generally C> require human intervention for the simple and practical reason that C> there is no way for any layer of software (whether it be the process or C> the kernel) to recover. > > You are yet again repeating yourself. You say "only errors are hardware > errors". I do not see that phrase of 5 words anywhere in the paragraph quoted by "C>". Why are you misattributing that phrase to me when I didn't write those words? > I have said that file not present is an operational error, > depending on how the application has asked for it. Operational > errors should clearly be handled between OS, and operator. There's your assumption that 'there will always be an operator' again. Your assertions fail to be true when you consider an unattended machine like a web server. A "file-not-found" error is not an operational error, nor should that error be handled "between OS, and operator". There aren't any operators available to an unattended machine! -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Konstantin Wiesel <kwiesel@pollux.jura.uni-bonn.de> Newsgroups: comp.sys.next.programmer Subject: Return-key image in IB of OS4.1? Date: Mon, 24 Feb 1997 16:52:18 +0000 Organization: RHRZ - University of Bonn (Germany) Message-ID: <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Does the Return key image no longer exist in OS4.1 Interface Builder? Also i would like to know if it is the normal procedure of the new PB to build two nib one beginning with NextStep_... and the ohter with Windows_... --- Konstantin Wiesel Email:kwiesel@jura.uni-bonn.de
From: tgritton@sprynet.com (Terry Gritton) Newsgroups: comp.sys.next.programmer Subject: Re: NS 3.0 Date: Mon, 24 Feb 1997 08:52:52 -0800 Organization: ^self -> (CompSci/MolBiol) Message-ID: <tgritton-ya023180002402970852520001@news.sprynet.com> References: <engelhar-2202971530310001@p14.ts1.newbr.nj.tiac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <engelhar-2202971530310001@p14.ts1.newbr.nj.tiac.com>, engelhar@dreamscape-solutions.com (Michael Engelhart) wrote: >Hello all- > >I'm thinking of buying an old 33MhZ NeXT Station turbo for pretty cheap. >It comes with NS 3.0 user/developer installed. Is this worth learning >NeXT development on? I currently develop for the Mac and couldn't find >any info about versions of NS previous to 3.3 on their site. Also, can >you upgrade relatively easily to 3.3? I'm just trying to get a head start >on Rhapsody. I will be interested in answers to your question as I am in a similar situation. I have an 25Mhz slab and NS3.0 User&Developer which I am using to learn Objective-C. It would be nice to have clear and concise diffs for 3.0->3.3 and 3.3->4.x. You have probably seen at the Next site >>>> OpenStep Journal, Spring 1995 (Volume 1, Issue 1). The Same, Yet Different: NEXTSTEP and OpenStep Written by Jean Ostrem <<<< > Also, are there any good tech references out in publication >on NeXTStep?....any info would be greatly appreciated. NextStep 3.0 Developer has lots of good documentation and a nice system for accessing it ( Digital Librarian and HeaderViewer apps). For learning NS3.0 here is what somebody else posted to the net and so far I agree ( except that the Mahoney book really should have had more info on using the debugger). >>>>>> The Garfinkel/Mahoney book was very good. The title is NeXSTEP Programming: STEP ONE: Object-Oriented Applications Springer-Verlag (TELOS imprint) ISBN 0-387-97884-4 or ISBN 3-540-97884-4 As Greg says, it is for an older version of NeXTSTEP. The ideas are useful, but the newer OpenStep API is a bit different, and even the InterfaceBuilder looks a bit different than is shown in this book. Still, it is a very good book for anyone who just decided to dusting off a NeXTSTEP 3.x system after hearing this news. Certainly learning NeXTSTEP 3.x would be more informative than sitting around reading usenet articles from everyone... >>>> -- -- Terry Gritton "Glycobiology - the new frontier of biosemiotics" tgritton@sprynet.com
From: rog@ohm.york.ac.uk (Roger Peppe) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 24 Feb 1997 17:19:24 GMT Organization: Department of Electronics, University of York, UK. Message-ID: <5esiis$ck4@netty.york.ac.uk> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi <slrn45ghfmn.oqs.campbejr@phu989.um.us.sbphrd.com> On 17 Feb 1997 20:29:15 GMT, John R. Campbell <campbejr@phu989.mms.sbphrd.com> wrote: > Your correction is understood, but remember the context. The ctime > isn't changed all that often; It's changed when the inode *itself* > has been manipulated rather than the file it refers to. > > For instance, once a file's created, how often do *you* think the > permission bits need to be manipulated, hmmm??? from the man page for stat(2): st_ctime Time when file status was last changed. It is set both both by writing and changing the i- node. Changed by the following system calls: chmod(2) chown(2), link(2), mknod(2), rename(2), unlink(2), utimes(2), write(2). the ctime field is actually remarkably useless (apart from the fact that the modified time may be set arbitrarily by the user, but doing so updates this field, and so prevents a user from hiding all record of a change to a file) rog. (a superuser can of course trivially change the ctime *and* the mtime of a file however)
From: John Kheit <jkheit@cnj.digex.net> Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 24 Feb 1997 18:28:45 GMT Organization: monoChrome, Inc., NJ, USA Message-ID: <5esmkt$8db@news4.digex.net> References: <5ejfuf$ae2@news4.digex.net> <AF33668D-114FF@198.68.42.182> "Lawson English" <english@primenet.com> wrote: > John Kheit <jkheit@cnj.digex.net> said: > [on my citing Webster's 3rd International] > >In the states, the authority is likely to be the 9th or newer > >version. > yar, but I picked up the entire 3 volume set for $25, so I'm > willing to put up with a few obsolete definitions... :) Good enough reason for me :) -- Thanks, be well, take care, later, John Kheit; Self expressed... 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 | Ja tallar ente svenska )^> %^) =^)
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: Mon, 24 Feb 1997 13:06:10 -0500 Organization: SoftArc Inc. Message-ID: <maury-2402971306260001@199.166.204.230> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> <7fafow55ed.thoron@argo.patnet.caltech.edu> <5eqfe8$pfr@news.platinum.com> <markeaton_-2302971518520001@ip124.santa-clara7.ca.pub-ip.psi.net> <5eqmvc$pfr@news.platinum.com> In article <5eqmvc$pfr@news.platinum.com>, gary-nospam-@screaming.org (Gary W. Longsine) wrote: > This really is a bummer, and I hadn't thought of the implications of the > Office suite on the OS design. You are right, of course. Micro$oft, of > course, could always decline to migrate the popular Office applications to a > new MacOS Mmm, I dunno. Contrary to what people seem to believe here, MS is indeed a customer driven company. They would have done office for a new Mac OS, they'd have to or face the screams of every Mac owner, and the feds along with them. Apple does have some power to wield here, in the form of "MS isn't support changes to our OS in an attempt to drive people off of it". > OpenStep has changed all that, though. Rhapsody might wind up producing > applications that are so cool that nobody *cares* if Office is available on > the PowerMac or not. The ones to convince are the MIS types who are completely convinced that if they load the same software onto the same machines and allow no others on their entire network, everything will just magically work and they'll know how to fix it when it breaks. This is of course a flawed theory, because OS's and applications are so immense today that it's impossible to learn everything there is to know about _two_ items in a lifetime, let alone the lifetime of the software/hardware which continues to shrink. So magnifying the issue with multiple platforms does basically nothing to the problem, but not doing so has serious repercussions on user efficiency (I believe it to be a truism that people should use the machine they get the most work done on) and flexibility (evolutionary theory). > Yes, I think it's most likely that many of the advanced features from NeXT, > Copland, and other Apple and NeXT research will be incorporated into a new > Rhapsody GUI that is wonderful and happy. It will have so many compelling > cool things that it will be attractive to MacOS, NeXTSTEP, OS/2, Windows and > Windows95 users. That is the cool part of all this. We all get a modern OS > with lots of cool new toys that isn't crushed under the M$ hegemony. And one that is already in use. Let us not forget the BeOS people, they are trying hard and I wish them the best of luck and fortunes. Maury
Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs From: Fabien_Roy@free.fdn.org Subject: Re: OPENSTEP/MACH 4.1 -- printf %g still broken (possible solution) Message-ID: <E64Cw1.BI@free.fdn.fr> Sender: news@free.fdn.fr Organization: Fabien Roy Consultant. References: <5ecoph$74i@tribune.usask.ca> <01bc1f41$4bafa9b0$c6a63bc6@hyperion> Date: Mon, 24 Feb 1997 18:04:48 GMT Openstep 4.1 for Mach uses gcc 2.5.8 and Openstep 4.1 for NT uses gcc 2.7.2 -- 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: Koplien@vnet.IBM.com Newsgroups: comp.sys.next.programmer Subject: Re: cc++ question Date: Mon, 24 Feb 97 13:05:44 Organization: IBM Zurich Research Laboratory Message-ID: <5es079$kg0@grimsel.zurich.ibm.com> References: <E5nw3F.GD@xombi.wizard.net> I edited the cc++ script and add -lg++. BTW, the error disappear if you have any "cout" code in your main program, too. Henry
From: aa056@chebucto.ns.ca (George White) Newsgroups: comp.sys.next.programmer Subject: [Q] How to control which f.p. errors signal on black NS 3.0? Date: 24 Feb 1997 21:13:43 GMT Organization: Chebucto Community Net Message-ID: <5et0a7$jvu@News.Dal.Ca> I would like to have some f.p. exceptions that currently generate NaN's raise SIG_FPE. I would also like to be able to produce an error message that provides some indication of the type of error (e.g., division by zero). This needs to work on black hardware with NS 3.0, using C. -- -- George White <aa056@chebucto.ns.ca> <gwhite@bionet.bio.dfo.ca>
From: Chuck_Esterbrook@orcacomputer.com Newsgroups: comp.sys.next.programmer Subject: Re: Dynamic flag in 4.0 and 4.1 Date: 24 Feb 1997 21:12:07 GMT Organization: Virginia Tech, Blacksburg, Virginia Message-ID: <5et077$4bi$1@solaris.cc.vt.edu> References: <5els0h$agc@newsread.onramp.net> <5enogq$d9@mpaque.mpaque> mpaque@wco.com (Mike Paquette) wrote: > In article <5els0h$agc@newsread.onramp.net> Jim_Miller@suite.com writes: > > mpaque@next.com (Mike Paquette) wrote: > > > > >The assorted DYLD environment variables are strictly for debugging > > >purposes. They aren't available to apps running from the Workspace, > > >or when running as the superuser (root) for obvious reasons. > > > > This is bad. We sell a product that consists of a bunch of > > executables (that run in the background), a couple of OpenStep > > applications (launched from the Workspace), and a dynamic library. > > The executables and OpenStep applications are linked with the dynamic > > library, and our customers will link their OpenStep apps with the > > dynamic library. > > Non-NeXT frameworks that third parties are expected to link with should be > installed in /LocalLibrary/Frameworks in the current Mach based products. [...] > -- > I don't speak for my employer, whoever it is, and they don't speak for me. > mpaque@next.com Official business only NeXT Mail OK > mpaque@wco.com Non-business or personal mail NeXT mail OK > I agree with Jim Miller. It's ridiculous that frameworks can't be dynamically located like bundles can. Here at Orca we have augmented the system makefiles so that a .o file is created in every framework and when we link our app, the framework's .o's get linked in and their resources copied (we have to be careful with names to ensure that resources don't clobber each other). During development we use frameworks in the typical fashion, but then upon delivery we set a flag so that this static linking and resource copying occurs. As far as requiring users to install frameworks in /LocalLibrary/Frameworks goes, there are two problems. One is that not all users have permission to put files there. Another is that my application's frameworks might clobber yours. Jim, I suggest you either modify the system to let you "absorb" the frameworks into your application (you could write a separate shell script or modify the makefiles) or switch to using bundles which can be located anywhere. Good luck. -- Chuck Esterbrook, Software Eng. http://www.orcacomputer.com/~chuck --------------------------------------------------------------------- chuck_esterbrook@orcacomputer.com / vo 540 231-3475 / fx 540 231-3480 Orca Computer, Inc. / 1800 Kraft Dr. Suite 111 / Blacksburg, VA 24060
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: EOModeler 2.0 .... Date: 24 Feb 1997 21:31:38 GMT Organization: Digital Fix Development Message-ID: <5et1bq$e6h@news.digifix.com> References: <5esd04$gll@hpuniv.univ-lr.fr> In-Reply-To: <5esd04$gll@hpuniv.univ-lr.fr> On 02/24/97, université de La Rochelle wrote: >Hi all, > >I try to use EOMOdeler with EOF2.0. >Lots of thing have been modified (compare with EOF1.0) but i can't find how, >to do actions than i did before with EOF1.0 !! > >1. I don't see the synonyms and views ? I'm not sure what you mean here. >2. If i remove a table of my model, how can i import it back in my model ? > >Thanks for your help > In this case, this is something that was left out of EOModeler 2.0 in error (so it has been said on the EOF mailing list) and will be put back in for EOF 2.1. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
Newsgroups: comp.sys.next.programmer Subject: C++ Syntax Highlighting Message-ID: <1997Feb24.144238.26278@roper.uwyo.edu> From: nor@panoramix.uwyo.edu (norbert pirzkal) Date: 24 Feb 97 14:42:38 MST Distribution: world Is there a freeware editor for NeXTSTEP that supports syntax highlighting? Thanks -- Norbert Pirzkal http://faraday.uwyo.edu/grads/npirzkal P.O. Box 3905 Physics & Astronomy Department University Station Laramie, WY, 82071
Newsgroups: comp.sys.next.programmer From: dfevans@bbcr.uwaterloo.ca (David Evans) Subject: Re: Return-key image in IB of OS4.1? Sender: news@novice.uwaterloo.ca (Mr. News) Message-ID: <E64pKz.4Dt@novice.uwaterloo.ca> Date: Mon, 24 Feb 1997 22:38:59 GMT References: <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de> Organization: University of Waterloo In article <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de>, Konstantin Wiesel <kwiesel@pollux.jura.uni-bonn.de> wrote: > >Does the Return key image no longer exist in OS4.1 Interface Builder? > It is apparently gone. The New Way(TM) is to use a heavy line, just like they do in Windows. I've never see OS/Mach, so I can't comment on how well this works. To me it sounds ugly. -- David Evans (NeXTMail OK) dfevans@bbcr.uwaterloo.ca Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual
From: jimmord@mindspring.com (John Immordino) Newsgroups: comp.sys.next.programmer Subject: Re: SVGA display drivers and Vertical refresh interrupts... Date: Tue, 25 Feb 1997 01:22:44 GMT Organization: MindSpring Enterprises Message-ID: <331231e0.277699468@news.mindspring.com> References: <3312255C.1E0F@cadvision.com> On Mon, 24 Feb 1997 16:33:48 -0700, Ed Vanwieren <vanwiere@cadvision.com> wrote: >I'm hoping someone has written a display driver before... here is what >I'd like to "IDEALLY" accomplish: > >Write a special display driver that handles "standard" SVGA allowing >access to the vertical refresh interrupt for synchronizing video >display. I think a common low resolution display [e.g. 640x480 @ 60hz, >256 colors] would work for most [if not all] graphics cards. > Possibly so, but in this card the card is not the limiting factor. NEXT's display architecture is designed around a linear frame buffer, ie. if your display adaptor has 2M of memory the operating system presents this memory to NEXT's window server as a contiguous block. The SVGA standard is an extension of VGA, which is limited to a very small memory buffer. To work around the limit, SVGA uses this VGA buffer as a "window" into a larger memory buffer, mapping segments of that larger buffer into the VGA memory area as they're needed. The gain is higher resolution and pixel depth at the cost of performance. NEXT had to jump through hoops to make SVGA work at a depth of 2 bits per pixel. I vaguely recall discusions of the window server implementing an exception handler to deal with page faults by calling the SVGA driver routine to map in the correct segment and making the proper OS calls to fix up the physical-to-virtual memory mapping - makes me shudder just thinking about it. Anyway, my point is that if 8-bit (256 color) pixel depth performed adequately NEXT would have included it in their SVGA implementation. Of course, this decision was made before Intel clean room technicians started dancing to "Play That Funky Music" and "installing" MMX (more money extracted) technology in their chips. Maybe today's Pentium can handle the load, but I'd bet against being able to implement 8-bit depth in a subclass of IOSVGADisplay. >Reading the IOSVGA and IOFrameBuffer classes, it would appear that I >need a fair bit of register addresses and constants to allow me to do >this. > Yep. You need a working knowledge of VGA and SVGA. >So.... What is the 'standard' SVGA that would work with most graphics >card? Where can this 'standard' be found? Try "The Programmer's Guide to EGA, VGA, and Super VGA Cards" by Ferraro (Addison-Wesley, ISBN 0201624907) >Is the vertical refresh >interrupt already accessable within the existing NeXT drivers? The current crop of drivers do not make use of the vertical refresh interrupt. You can write a driver which configures the adapter hardware to interrupt, but it's likely that configuration is vendor-specific. You might be able to write a driver that configures and handles the vertical refresh interrupt for a given adaptor and co-exists with the NEXTSTEP display driver, but I wouldn't recommend it. >Where can >I get specific chipset information if I had to implement a driver for a >specific card(s)??? From the vendor, if they choose to give it to you. Sometimes this requires a non-disclosure agreement, in which case you need to convince them that there's money in it for them. Sometimes they'll just give you the spec. It always takes several phone calls to find the right contact (try marketing rather than technical support) and several phone calls after that to get the spec. I haven't painted a very bright picture, but I can't categorically rule out the possibility of success, either. Take a look at the Ferraro book to get an idea of the hardware and SVGA programming involved. If that doesn't intimidate you, see if you can subclass IOSVGA display and implement 8-bit depth. Also, find out if SVGA includes a standard access mechanism to map and enable the vertical refresh interrupt. If you can get there, you're halfway home. The other half is efficiently notifying whichever process is looking for that interrupt, but that's another story. - John
From: Ed Vanwieren <vanwiere@cadvision.com> Newsgroups: comp.sys.next.programmer Subject: SVGA display drivers and Vertical refresh interrupts... Date: Mon, 24 Feb 1997 16:33:48 -0700 Organization: Zokero Inc. Message-ID: <3312255C.1E0F@cadvision.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I'm hoping someone has written a display driver before... here is what I'd like to "IDEALLY" accomplish: Write a special display driver that handles "standard" SVGA allowing access to the vertical refresh interrupt for synchronizing video display. I think a common low resolution display [e.g. 640x480 @ 60hz, 256 colors] would work for most [if not all] graphics cards. Reading the IOSVGA and IOFrameBuffer classes, it would appear that I need a fair bit of register addresses and constants to allow me to do this. So.... What is the 'standard' SVGA that would work with most graphics card? Where can this 'standard' be found? Is the vertical refresh interrupt already accessable within the existing NeXT drivers? Where can I get specific chipset information if I had to implement a driver for a specific card(s)??? Ed Vanwieren vanwiere@cadvision.com Nexar Research Inc.
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 00:24:40 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eiq08$h3n@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <wharris-ya023080001702970658310001@news.iadfw.net> <5eepmi$r6e@horus.ecmwf.int> syy@ecmwf.int (Mike Connally) wrote: > > There's a tendency in the NeXT community not to grok the utility > of MacOS features like file type & creator codes, Macintosh Easy > Open, and full drag-and-drop capability. There is a tendency in the MacOS advocate community to make the assumption that NeXTSTEP advocates don't know what a Mac is. However, the fact that I am quite happy with the NeXTSTEP user interface does not change the fact that my main job responsibility here at RPI has been Macintosh support. This has been true for several years now, and I'm pretty damn close to the top Macintosh expert on campus. I'm regularly at Apple Support Coordinator meetings (put on by apple, including non-disclosure information at times). Chances are mighty good that I've "groked" MacOS features before you even heard about them. It is annoying to see Mac advocates who are so puffed up with their own system that they are convinced that anyone who disagrees with them must "not understand" what is going on. > NeXTfreaks might say: > |> > Among the data stored in the application segments ... are the > |> > information on which kind of document (file extension) one given > |> > app can open. For example, PhotoShop.app could open ".tiff", > |> > ".eps", ".gif"..., IconBuilder.app could open ".tiff" documents > |> > only. The user can choose a default application (among those > |> > able) to open a given kind of document. This is a user's > |> > preference. > > This is a Mac user's preference too. The file TYPE code is > analogous to a filename extension (but unintrusive). An app > knows which file types it can handle. The file CREATOR code > simply indicates which app created the file. Double-clicking a > file tries to launch that app. If the app isn't found, Macintosh > Easy Open launches to ask the user to nominate a substitute app > which can handle that file type. Easy. From then on, that app > becomes that user's preferred launch. This is not the same as what NeXTSTEP advocates are talking about. It is not flexible in the same way that NeXTSTEP is. Note that Macintosh Easy Open only gives you this option if you do not have the application which a given document was created in. If you *have* the application, but happen to prefer to use some other application for a given file type, then Macintosh Easy Open does not even come into play. The Mac user, in this situation, will have no option to set a preference. Futhermore, when you do *not* have the application which created the document, Macintosh Easy Open only lets you set the preference once. You have no easy way to change that preference. Thus, your statement that "This is a Mac user's preference" shows that you don't understand what the NeXTSTEP user has for preferences. Now, one can argue whether the Macintosh method is better or worse than the NeXTSTEP method, and that is a merely stupid religious war. In your case you are stating that the Macintosh user has the *same* options, and in fact they do not. You only think they do because you are not familiar with NeXTSTEP. I work on a daily basis with *both* NeXTSTEP and MacOS, but I guess that's irrelevent when it comes to comparing the features of both. It's much better to have someone who only knows one system do the comparison of two systems. It saves so much time. > And for further user flexibility, there's drag-and-drop. Guess what. NeXTSTEP has pretty much the same feature, and has had it for many years. The Mac implementation is a little nicer, but all of the differences are just minor design decisions which could be easily changed. Those differences were based on some historical baggage of earlier NeXTSTEP applications, and certainly I'd prefer that drag-and-drop in Rhapsody be exactly like MacOS. Note that drag-and-drop in the NeXTSTEP file viewer is so similar to drag-and-drop in the MacOS that I'd expect the changes (at the coding level) would be extremely trivial to do. (I'm not sure if MacOS had this drag-and-drop feature in the finder before NeXTSTEP had it in the file viewer, or if NeXTSTEP had it first. In any case, you're not talking about anything that will impress a NeXTSTEP advocate) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: altenber@acpub.duke.edu (Lee Altenberg) Newsgroups: comp.sys.next.programmer Subject: Re: Return-key image in IB of OS4.1? Date: 25 Feb 1997 02:52:24 GMT Organization: MHPCC Message-ID: <5etk58$cos@kaopala.mhpcc.edu> References: <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de> <E64pKz.4Dt@novice.uwaterloo.ca> Cc: dfevans@bbcr.uwaterloo.ca In <E64pKz.4Dt@novice.uwaterloo.ca> David Evans wrote: > In article <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de>, > Konstantin Wiesel <kwiesel@pollux.jura.uni-bonn.de> wrote: > > > >Does the Return key image no longer exist in OS4.1 Interface Builder? > > > > It is apparently gone. The New Way(TM) is to use a heavy line, just like > they do in Windows. > I've never see OS/Mach, so I can't comment on how well this works. To me it > sounds ugly. > > The demise of the Return key icon was evidence that severe "Windows Envy" had taken over NeXT. Other signs were the window setup of the OpenStep 4.0 pre release GUI, where the miniaturize button was placed on the right, next to the close button, JUST LIKE WINDOWS95. And NeXT had reportedly shifted internally to running NT. I hope that the Apple purchase has stanched this slide into perversity and depravity within the NeXT team. Maybe the return of Jobs will presage the Return of the Return! -- ======================================================================= 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.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 01:16:32 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eit1g$h3n@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <cuahb-1502971610510001@eiuts15.eiu.edu> <01bc1cb9$37d896c0$2510c00a@olivier> <5eans2$8jq@nyheter.chalmers.se> <SHESS.97Feb17224036@slave.one.net> shess@one.net (Scott Hess) wrote: > John Hornkvist writes: > Resource forks is only a way to reimplement directories > inside a file. > > Which brings up an interesting question ... can anyone tell me > if there's a limit on the number of files you can have on HFS? > It just occurred to me that perhaps forks are a means of effectively > doubling the number of files without requiring more metadata > overhead. Close, but you're misunderstanding where the savings is. For all practical purposes, the two forks of a Macintosh file are a two separate files. So, the savings is not because the resource fork is somehow not a file. You are not effectively doubling the number of files. The savings is that everything *inside* the resource fork is *not* another file. A resource fork can hold multiple icons, just like an appwrapper can. However, in an app wrapper each one of those icons is another file (another inode, etc). All of the icons, plus all the other resources for a file, are only a single file ("the resource fork file") on a Mac. Note that this means your savings is much more than merely doubling the number of files. > [I'm making two assumptions, here. One is that Way Back When, > Mac had small disks, and for every file which needed a resource > fork, you'd have needed twice as much metadata overhead. If a file has both a data fork and a resource fork, then I'm pretty sure it will have twice as much metadata overhead as if it only has one fork (note that a Mac file can also be *just* a resource fork, with no data fork). However, I believe that metadata is basically stored as if it were two files, so I don't think there's any particular savings there. > Furthermore, files may have been referred to with small integers > to save space in the metadata.] > > Now, in Unix a directory is a file. A file with names and > pointers to other files. Making the OS aware that some > directories are not really directories but a special sort > of file should be simple enough. This could be done using > extensions, or by modifying the file system to add a "bundle" > bit. However, I think things work well the way they are... > > They do work reasonably the way they are, but I think it would > be perfectly appropriate to have a bundle bit. OTOH, I'm not > sure quite where it could go without conflicting with directory > handling code. For instance, you could use the sticky bit (but > it's already used for directories), or a setuid/setgid bit to > indicate something special about a directory. I'm not a fan of the bundle bit in the MacOS, mainly because it screws everything up when it's set wrong... :-) --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: michal@gortel.phys.ualberta.ca (Michal Jaegermann) Newsgroups: comp.sys.next.programmer,comp.sys.next.bugs Subject: Re: OPENSTEP/MACH 4.1 -- printf %g still broken (possible solution) Followup-To: comp.sys.next.programmer,comp.sys.next.bugs Date: 25 Feb 1997 04:17:13 GMT Organization: Disorganized Bits Message-ID: <5etp49$145q@pulp.ucs.ualberta.ca> References: <5ecoph$74i@tribune.usask.ca> <01bc1f41$4bafa9b0$c6a63bc6@hyperion> <E64Cw1.BI@free.fdn.fr> Fabien_Roy@free.fdn.org wrote: : Openstep 4.1 for Mach uses gcc 2.5.8 : and : Openstep 4.1 for NT uses gcc 2.7.2 So what??? This is not a compiler bug but a library bug. These do not have very much in common. --mj
From: stefanos@Vir.com (Stefanos Kiakas) Newsgroups: comp.sys.next.programmer Subject: WebObjects and access control. Date: 24 Feb 1997 15:50:00 -0500 Organization: Hookup Montreal, Internet Access Montreal. Message-ID: <5esuto$p7@Vir.com> Hello all, What is the best way to implement user authentication with WebObjects lite and Apache? I tried using .htaccess with Apache, but the Web script got executed anyway. Is it possible to use just .htaccess or do I have to create a separate access control method for WebObjects? Thank you for any help, stef
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 06:56:16 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5ejgug$oij@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <peterm.856265782@ulfrun> <SHESS.97Feb19093610@howard.one.net> shess@one.net (Scott Hess) wrote: > It's the latency that's important. If an inode has 96 bytes of > information, you can fit 10 inodes in a 1k fragment. If an inode > has 128 bytes, you can only fit 8, if it has 160 bytes, you can > only fit 6. I do not buy the argument that there will be a significant (obvious-to-the-user) performance penalty if someone decided that the catalog information of a file should hold a few more bytes of information. There are other reasons to shy away from such a proposal, but I can not believe that performance is going to take a nose-dive due to the proposed additions. The overhead should only come when opening files, and it isn't going to be all *that* much different. The current Unix file system was designed for processors (and disks) which were much slower than the systems we have now. It's a bit much to wring our hands over the awful overhead of a few more bytes in the catalog information. Perhaps I'm a bit biased because I worked on a mainframe OS that *did* keep this kind of information (and we did it on 1970-era computers), and somehow we managed quite well (performance-wise) despite that "massive drain" of having a few extra bytes of catalog information around. And yes, we had lots of files on the system, and lots of simultaneous users (it was a timesharing system, after all). By "lots" I mean over two hundred simultaneous users. Based on that, I find it preposerous that a single user system is going to suffer serious performance degradation if someone were to have the audacity to add a few extra bytes to the catalog information. I just do not believe it. > In essence, that's what this thread is about - the creation > timestamp is one more bit of info helpful to the user. I'm > arguing that this bit is very seldom used, and though it might > be useful periodically, it's not useful frequently enough to be > worth hazarding throughput. If you make the things the user does > hundreds of times a day fast, it's not too painful if you make > the things they do once a week a bit slower. Note that if one uses a resource-fork approach to storing little bits of info, then you have fewer catalog lookups to do (which is to say, the application is doing fewer file-open operations). I think it would be inconsistent to wail and moan about adding a tiny bit of overhead to a file-open, but then be quite comfortable and gung-ho about organizing information in such a way that greatly increases the number of file-open's which are done every time an application is launched or a document is opened. If file opens are so expensive in the first case, then we should not be so calm about them in the second case. At the end of the day, I probably wind up with many of the same conclusions as Scott does, but for entirely different reasons. To me the most important issue for Rhapsody is getting it available to end users. I am uneasy about any big projects to "make things better", the key work there being "big". If some project delays the release of Rhapsody by six months, then it should be avoided unless it is a *great* idea. Playing around with the invention of some new file system (along with the work to rewrite all utilities to behave well in that new system) sounds to me like too much of a delay for too little of a payback. --- 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.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 00:32:09 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5eiqe9$h3n@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> <Mike.Connally-ya023680001902972331330001@news.dial.pipex.com> Mike.Connally@dial.pipex.com (Mike Connally) wrote: > jrudd@cygnus.com wrote: [about the Mac] > > > > That's kind of what I meant.. You can't choose to open by file > > type _OVER_ file creator. If the file creator data is there, > > and the file creator app exists on that machine, you MUST use > > it. You cannot choose a file type application OVER that creator > > app. I didn't say you can't open by file type at all. I simply > > said the Mac doesn't give you a choice between the two if > > creator exists you use it, otherwise you use type... no choice. > > Wrong. You can either drag-and-drop any file of a compatible > type onto any app (easy) or you can launch the app and the use > the File Open dialog to open any document of a compatible type > (fiddly, but Windows people seem to like it). He is not wrong. You are changing the question, and thus pretending that your answer is correct. You can drag-and-drop on NeXTSTEP too. You can use the "open" menu item on NeXTSTEP too. However, that is not what he's talking about. It's also not what you were talking about, when you brought up Macintosh Easy Open. Certainly that has nothing to do with drag-and-drop or the "open" menu item. The topic here is discussing what action takes place when you double-click on a document. If you have a lot of applications on a Mac, then using drag-and-drop to open a document is certainly less convenient than double-clicking on the document. You either waste time trying to open up the folder which has the document you want, or you end up with all kinds of aliases somewhere (probably on the desktop) just so you can use drag-and-drop. The first one is not convenient, and the second one is somewhat silly. --- 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.advocacy,comp.sys.mac.programmer.misc,comp.sys.powerpc.advocacy,comp.sys.next.advocacy,comp.sys.next.programmer,comp.sys.next.misc,comp.unix.machten,comp.unix.osf.misc,comp.os.mach,comp.os.ms-windows.nt.advocacy Subject: Re: Apple Mach IS NOT a microkernel!!!!! Date: 25 Feb 1997 06:24:10 GMT Organization: Squonk-Net, Loudonville, NY 12211 Message-ID: <5eu0ia$d69@duke.squonk.net> References: <jm041536-1702972018170001@mencjo.apple.com> <5ebg1m$1en@news3.digex.net> <SHESS.97Feb18074753@howard.one.net> <5eeu62$76s@qnx.com> <SHESS.97Feb20085428@howard.one.net> <jm041536-2102971103330001@mencjo.apple.com> <5eldq2$kj@news.platinum.com> <markeaton_-ya02408000R2102972132110001@news.mindspring.com> <5enmc3$bra@news.platinum.com> gary-nospam-@screaming.org (Gary W. Longsine) wrote: > I just don't understand why anyone would spend almost half a > billion dollars, and over 5 years on OS research (Pink, Taligent, > Copland) and fail to grok something so basic as a rational > protected memory scheme. A few details you are overlooking. Pink = Taligent = a brand new system from the ground up. You can do things in a new system which you might shy away from in a current production system. From all I've ever seen about Taligent, it understands protected memory quite well. That understanding is irrelevent to the work done for Copland, as they are projects with completely different constraints. > (I also don't understand why people are so infatuated with a > research kernel (Copland's NuKernel) that's never seen the > production light of day and doesn't offer an improvement over > kernels that I've been using for years... but that's another > topic.) It does offer some improvements. > In the strictest technical sense, perhaps I was too harsh on the > poor, defenseless little NuKernel, Yes, you were. Not that it's defenseless, but you made a number of assumptions which are not correct. > Anyway, nobody has yet offered proof that my general claim is > incorrect. The designers of Copland wandered very far down an > expensive and pointless track. They should have had their leashes > jerked back long, long ago. If they had presented me with such > a kludge two years ago, after hundreds of millions of dollars > and three years wasted on Pink and Taligent, I would have fired > them as being fundamentally incompetent. Period. > > Copland + NuKernel = No protected memory for ordinary applications. Forget the NuKernel in this equation. It's Copland = No protected memory for ordinary (GUI) applications I would say your general claim is correct, but I understand how it could have happened from Apple's side. The main problem with Copland is that it took much too long to do. If they could have done Copland in a year, then it probably would have been a perfectly reasonable idea. The real goal was Gershwin, which was intended to be the follow-on to Copland. Nobody nowhere at no time said that Copland was going to be the nirvana of operating systems. It was only meant to be an interim transition between MacOS and a new, modern, and heavy-duty operating system. Also, completely forget about Pink/Taligent for this discussion. Completely. Don't even mention it. It is not relevent to the decisions made for Copland/Gershwin, and given the size of Taligent this is probably just as well. Even with the recent dramatic decrease in RAM prices, Taligent could have required more RAM than Mac users would want to buy for a PowerMac. Besides, the people who worked on Taligent *moved* to the company named Taligent. They are not the people at Apple who worked on Copland/Gershwin ideas. > Under Copland, developers must take special steps to arrange for > protected memory for "applications that could benefit" from it. > The first, and very, very special, step is that one must hack > the user interface out of the app. > > That means that all the problems Mac users have with the average > user apps taking down other apps would still exist in Copland, > with the minor enhancement that your kernel would still be running > after your entire workspace crashes. As a user of a UNIX based > OS, I don't have this problem. And as a developer for Unix, you have hardly any customers compared to the MacOS. You don't have to worry about disrupting millions of customers, because you don't have them. Your operating system started on hardware which cost tens of thousands of dollars at the time, and thus it could afford the overhead of doing things right. The Mac was targetted for normal people with relatively normal budgets, and as such the initial hardware was fairly toyish. However, the Mac (and PC) brought computing to the masses, a claim which Unix can certainly never make in it's wildest dreams. Once Apple had made the transition to beefier hardware, it had to come up with a smooth transition of it's operating system. The Copland/Gershwin combination looked good on paper, and I don't see why you're so worked up about it. What good is done by all your ranting and raving about it? Apple greatly underestimated the difficulty of making this major a switch, and that is hardly news in the computer industry. In the lofty world of Unix, ask Sun how long it took to make their transition from BSD to SysV unix. I don't think Apple could afford a transition as painful (or as drawn-out) as that one has been. Now, as good as Copland/Gershwin may have initially looked, I do agree that Apple should have woken up to the problems a bit sooner than they did. Personally I think the problem was that upper management at the time was too busy trying to get someone like Sun to buy Apple (thus setting themselves up for big paydays), and were not paying attention to Apple itself. Either they didn't know or didn't care that this plan was dragging on much longer than it should have, or maybe they didn't think the changes were all that important. They might have thought, "sure this is late, but so what?". In any case, whatever the problem was, I do agree that Apple should have noticed it much sooner than they did. --- 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.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 21 Feb 1997 05:38:44 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5ejcd4$oij@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5ecefl$5d1@kwek.omroep.nl> <peterm.856338754@ulfrun> peterm@dna.lth.se (Peter Moller) wrote: > >: While the Mac users abhorance of file extensions is largely > >: religious, it will probably need to be honored for the sake > >: of a smooth migration path. > > I wouldn't call it religous, it's practical, logical etc. Most proponents of a given religion will say that their religion is practical, logical, etc. I do for mine. That doesn't change the nature of debates over it... :-) > WHY should the user have to spend mental time and energy trying > to remember extensions?? WHY? It's stupid. The application knows > it and that suffices. There is no good reason that the user would spend any time or energy remembering extensions. And, in fact, they don't under NeXTSTEP. The operating system knows the mapping from extensions to applications, it isn't something that the user has to "remember". All the user has to do is leave the extension alone. This is not a hard task. When creating a new document, the application itself selects the extension that's appropriate. > An example: the extension "DOC" in the WIntel world meand "Micro$oft > Word Document" and only that. It does not tell you what version > of messy word it is. And the exact same thing is true under the MacOS. The creator/type pair just tell you want application to launch. It doesn't tell you what version of an application created the document. > And the named word processor can handle a lot of other file types > (from the BNDL-resource of Word 5.1): TEXT, WDBN, GLOS, WHLP, > WPRD, sDBN, edtt, WDIC, WDEC, WDPC, SITD - and this is just one > application!! Wow. Are we impressed. Such a studly application. Just how stupid are you? Do you think NeXTSTEP applications are limited to a single file type? Let's see, almost every application I have on my NeXT opens more than one file type, and some of them open a dozen or more. What a silly topic to bring up. > One difference of the typical Macintosh user and users of other > computer systems is that the Mac user generaly uses more > applications than other users. This comment is based on studies of Mac users vs Windows users. The same kind of studies have not been done for Mac vs NeXTSTEP users. Since I'm not aware of any such studies, I can't say what the results would be. My guess is that you can't say either. > Having to know information which there is no rational reason > whatsoever to know would, I'm sure, stifle that using habit. Give > me one rational reason to remember extensions! I won't. I don't think you should. What's you're point? > With the Mac scheme of creator/file type, I can easily have both > FreeHand 5.5 and FreeHand 7.0 on my hard disk at the same time > and use the newer application until I know I really want to have > it. And when I throw the old one out, the new one knows directly > when I open an old document exactly what kind of document it is > and how it should treat it - all without looking at the content > of the file (which takes time - at least more time than to look > at the file type). The same thing could happen on NeXTSTEP. There isn't a single thing preventing it. And if you're opening the file to *READ* it, then it's pretty damn silly to talk about the "overhead" of looking at the content. The application has to read the content anyway, so who cares if the information is in the document? (however, note that NeXTSTEP does not *require* version information to be handled as part of the content of the file, I am merely commenting on how stupid it is to brag about not having to look at the content of a file when the application is opening the stupid file anyway). > And to have extensions but hide it in the Finder - sweeet jesus... Well, I do agree with you that I'm not much of a fan of that idea. If an operating system uses a filename extension, then I'd like the file viewer to show those extensions. For that matter, I'm inclined to think it is better to have the type information in a separate field (instead of the filename), instead as an extension to the filename. I've always thought that, but even with this bias I must admit that the way NeXTSTEP handles extensions has not in fact been a problem for me. I don't think the creator field is as important as some Mac people might suspect. It is somewhat useful to have a second field in addition to the type, but I wouldn't implement it quite the way that the MacOS implements it. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: yannick buisson (université de La Rochelle) Newsgroups: comp.sys.next.programmer Subject: Views and Synonyms Date: 25 Feb 1997 09:30:32 GMT Organization: Universite de La Rochelle Message-ID: <5eubfo$hok@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, Is there a specific dwrite for EOF2.0 on OpenStep4.0 to work with synonyms and views in EOMOdeler. For EOF1.0 you need to have a dwrite whiwh owner was Oracle7Adaptor ! Is there the same thing for EOF2.0 ?? Thanks for your answer YANNICK -- //// (. .) ----oOO--(_)--OOo-------------------------------------------- Yannick BUISSON Centre de Ressources Informatiques Université de La Rochelle tel prof. : 46 45 82 14. fax prof. : 46 45 82 45. yannick@cri.univ-lr.fr
From: yannick buisson (université de La Rochelle) Newsgroups: comp.sys.next.programmer Subject: fetch and qualifier with EOF2.0 and OpenStep 4.0 Date: 25 Feb 1997 09:32:11 GMT Organization: Universite de La Rochelle Message-ID: <5eubir$hok@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, just a little question about fetch and qualifier with EOF2.0 ! Can someone give me an example where i can find a qualifier and a fetch !!! Thanks for your help YANNICK -- //// (. .) ----oOO--(_)--OOo-------------------------------------------- Yannick BUISSON Centre de Ressources Informatiques Université de La Rochelle tel prof. : 46 45 82 14. fax prof. : 46 45 82 45. yannick@cri.univ-lr.fr
From: (Izidor Jerebic) Newsgroups: comp.sys.next.programmer Subject: How to make documentation for custom frameworks visible in PB? Date: 25 Feb 1997 10:23:26 GMT Organization: Select Technology Message-ID: <5eueiv$aj1@lazar.select-tech.si> Keywords: documentation, frameworks, ProjectBuilder The documentation for NeXT frameworks can be accessed from within ProjectBuilder with Cmd-9 (find definitions). The result panel shows lines with little book icons and by double click-ing on the book icon the documentation file is opened. Now, what about custom frameworks? When trying to find the definition of one of classes from our custom framework, the following messages are seen on the console: Feb 25 11:12:15 ProjectBuilder[8319] No documentation index found for: /UserDisk/Users/izidor/Library/Frameworks/STFoundation.framework/Documenta tion/Reference/.PB.index Feb 25 11:12:15 ProjectBuilder[8319] Starting documentation indexer on: /UserDisk/Users/izidor/Library/Frameworks/STFoundation.framework/Documenta tion/Reference So, I have created the Documentation/Reference/Classes folder within the framework folder, and put there all the documentation files (with names <Class>.rtf). Everything writable for world (just in case). Nothing happened, at least no change in the result panel - no book icon. I only get to see header file... What am I doing wrong? How should the documentation folders/files be set-up for the project builder to recognize and use them? TIA, izidor
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 25 Feb 1997 15:09:19 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45h5vv0.v1f.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi <slrn45ghfmn.oqs.campbejr@phu989.um.us.sbphrd.com> <5esiis$ck4@netty.york.ac.uk> On 24 Feb 1997 17:19:24 GMT, Roger Peppe <rog@ohm.york.ac.uk> wrote: >On 17 Feb 1997 20:29:15 GMT, John R. Campbell <campbejr@phu989.mms.sbphrd.com> wrote: >> Your correction is understood, but remember the context. The ctime >> isn't changed all that often; It's changed when the inode *itself* >> has been manipulated rather than the file it refers to. >> >> For instance, once a file's created, how often do *you* think the >> permission bits need to be manipulated, hmmm??? > >from the man page for stat(2): > st_ctime Time when file status was last changed. It is > set both both by writing and changing the i- > node. Changed by the following system calls: > chmod(2) chown(2), link(2), mknod(2), rename(2), > unlink(2), utimes(2), write(2). > >the ctime field is actually remarkably useless (apart from the fact >that the modified time may be set arbitrarily by the user, but doing so >updates this field, and so prevents a user from hiding all record of a >change to a file) > chmod changes permissions- not that common chown changes the file's ownership- uncommon on single abuser box link changes the use (reference) count in the i-node - OK, this is *much* more common mknod *is* a creation event; You're making an inode that refers to a device (via the major/minor numbers; the permissions specify whether it's a chardev, blkdev, a FIFO or whatever) rename this used to be done via a link and unlink but some Unix systems like to have a direct call that does this. It could've been done by just altering the name within the directory, you know... unlink Well, if the use count > 1, this *does* change the inode's use counter utimes *THIS* is an explicit effort to modify these fields within the inode; Usually used by touch(1). Somehow I don't see folks doing this by hand... write Whoops-- I did some digging on this one, and, yes, it *does* render st_ctime unusable. Of course, does anybody know if this *always* happens or when the file's length is changed? I suspect an open() w/ O_TRUNC will change the ctime as well... *SIGH* Sounds to me like we need enhnancements to inode structures. I've thought, BTW, that the first 512bytes of the file could be invisible (all lseek() calls assume an offset unless a fcntl() flag get set to maximize visibility). With an extra 1/2K of control information, all kinds of stuff can be hidden out-of- band to all the "normal" utilities... This'd have to apply to devices and directories... Is 512 bytes enough? >(a superuser can of course trivially change the ctime *and* the mtime of >a file however) Using the "touch" command which calls utimes(). Boy, was *I* an opimist. -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: edream@mailbag.com (Edward K. Ream) Newsgroups: comp.sys.next.programmer Subject: Outline classes in OpenStep? Date: Tue, 25 Feb 1997 09:33:48 -0600 Organization: Berbee Information Networks Corporation Message-ID: <edream-2502970933480001@msn-9-1.binc.net> Hi, I'm a Mac programmer who is busy studing the OpenStep development environment. Are there a set of generally available classes that implement outline views, such as the outline view of a finder window on the Mac? I'm a bit surprised that something so fundamental and useful for a user interface isn't in the App Toolkit. Thanks. -- Edward K. Ream edream@mailbag.com Owner, Sherlock Software
From: edream@mailbag.com (Edward K. Ream) Newsgroups: comp.sys.next.programmer Subject: OpenStep: what does the term mean? Date: Tue, 25 Feb 1997 09:35:37 -0600 Organization: Berbee Information Networks Corporation Message-ID: <edream-2502970935370001@msn-9-1.binc.net> Hi, I'm confused by the term "OpenStep" (or OPENSTEP). Does it mean the (Next?) OS or the development environment (Foundation kit and App kit) or both? Thanks. Edward -- Edward K. Ream edream@mailbag.com Owner, Sherlock Software
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: Outline classes in OpenStep? Date: 25 Feb 1997 16:49:25 GMT Organization: Global Objects Inc. Message-ID: <5ev56l$ilr$1@news.xmission.com> References: <edream-2502970933480001@msn-9-1.binc.net> edream@mailbag.com (Edward K. Ream) wrote: > Are there a set of generally available classes that > implement outline views, > such as the outline view of a finder window on the Mac? There's one under development in the MiscKit. The look mimics that of the outline views in OmniWeb's bookmarks, or in the Class inspector of the "new" InterfaceBuilder (new as of 3.3, that is). > I'm a bit surprised that something so fundamental and useful for a user > interface > isn't in the App Toolkit. So are we. That's why we're writing one. :-) The MiscKit has a long history of this; many of the things we've created have eventually found their way into the Foundation or App Kits...so I suppose that means the main reason they aren't in the environment yet boils down to (a) NeXT doesn't have enough manpower to do everything, so the "less important" things were left by the wayside or (b) they just didn't think of it yet. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: dave@siqin.feinberg.nwu.edu Newsgroups: comp.sys.next.software,comp.sys.next.sysadmin,comp.sys.next.misc,comp.sys.next.marketplace,comp.sys.next.programmer Subject: NoteBook.app, how can I get a license? Date: 25 Feb 1997 17:50:22 GMT Organization: Northwestern University, Evanston, IL, US Distribution: world Message-ID: <5ev8ou$e93@news.acns.nwu.edu> I tried NoteBook.app and I like it. I'd like to purchase a license but I haven't been able to contact the authors. Here is what I know (from there info panel), it is written by Millennium Software Labs, Inc. 1010 El Camino Real, Suite 300 · Menlo Park, CA 94025 · USA (415) 321-3720 · (415) 321-3650 Fax · info@millennium.com Call (415) 321-3720 to order products But there phone is disconnected and has no forwarding information. Can anyone tell me now to contact them? Thank's in advance, David A. Johnson
From: kcd@babylon5.jumpgate.com (Kenneth C. Dyke) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep: what does the term mean? Date: 25 Feb 1997 18:56:38 GMT Message-ID: <5evcl6$hbg$1@nntp2.ba.best.com> References: <edream-2502970935370001@msn-9-1.binc.net> <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> In-Reply-To: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> On 02/25/97, David Herren wrote: ><bold>edream@mailbag.com,UseNet writes:</bold> > >>I'm confused by the term "OpenStep" (or OPENSTEP). > > >>Does it mean the (Next?) OS or the development environment > >>(Foundation kit and App kit) or both? > > >OPENSTEP is the abstracted API which runs on multiple OSs. OpenStep is >the operating system itself. Confusing, isn't it? Actually, I believe that's backwards. From NeXT's web site: ------- OpenStep is a public standard for an API used to develop and deploy dynamic multi-tier applications across diverse operating systems. Products currently exist for deploying applications on Windows NT, Solaris, and Mach. The OpenStep API includes a set of object frameworks and a dynamic object runtime that makes applications easy to scale and customize. It includes: + Application framework with GUI controls and support for event management + Foundation framework that provides standard low-level services such as internationalization + Distributed objects framework, providing support for communication between local and remote objects + Display PostScript + Dynamic object runtime, where objects communicate dynamically at run time rather than being hardwired beforehand -------- "OPENSTEP" is used to refer to one of NeXT's implementations of the OpenStep API, such as OPENSTEP Enterprise or OPENSTEP/Mach. Development tools such as Interface Builder and Project Builder aren't defined by the OpenStep specification AFAIK. -Ken
From: herren@flannet.middlebury.edu (David Herren) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep: what does the term mean? Date: Tue, 25 Feb 1997 12:46:37 -0500 Organization: Language Schools of Middlebury College Sender: herren@flannet.middlebury.edu Message-ID: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> References: <edream-2502970935370001@msn-9-1.binc.net> Mime-Version: 1.0 Content-Type: text/enriched; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: <msg37701.thr-34dc7b90.54c5638.part0@flannet.middlebury.edu> <bold>edream@mailbag.com,UseNet writes:</bold> >I'm confused by the term "OpenStep" (or OPENSTEP). >Does it mean the (Next?) OS or the development environment >(Foundation kit and App kit) or both? OPENSTEP is the abstracted API which runs on multiple OSs. OpenStep is the operating system itself. Confusing, isn't it? -- David Herren -------------------------------------------------- Web: http://www.middlebury.edu/~herren/ General: herren@flannet.middlebury.edu NeXTMail only: herren@barcelona.middlebury.edu
From: herren@flannet.middlebury.edu (David Herren) Newsgroups: comp.sys.next.programmer Subject: Re: Outline classes in OpenStep? Date: Tue, 25 Feb 1997 12:45:22 -0500 Organization: Language Schools of Middlebury College Sender: herren@flannet.middlebury.edu Message-ID: <msg37700.thr-2ec2a954.54c5638@flannet.middlebury.edu> References: <edream-2502970933480001@msn-9-1.binc.net> Mime-Version: 1.0 Content-Type: text/enriched; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: <msg37700.thr-2ec2a954.54c5638.part0@flannet.middlebury.edu> <bold>edream@mailbag.com,UseNet writes:</bold> >Are there a set of generally available classes that implement outline >views, >such as the outline view of a finder window on the Mac? >I'm a bit surprised that something so fundamental and useful for a user >interface >isn't in the App Toolkit. Isn't the browser view essentially what you want? Remember that this is the Openstep interface and not the Mac--the browser view is how one would navigate an "outline" view of the file system. -- David Herren -------------------------------------------------- Web: http://www.middlebury.edu/~herren/ General: herren@flannet.middlebury.edu NeXTMail only: herren@barcelona.middlebury.edu
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: File System Date: 25 Feb 97 12:55:00 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb25125500@howard.one.net> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <peterm.856265782@ulfrun> <SHESS.97Feb19093610@howard.one.net> <5ejgug$oij@usenet.rpi.edu> In-reply-to: Garance A Drosehn's message of 21 Feb 1997 06:56:16 GMT In article <5ejgug$oij@usenet.rpi.edu>, Garance A Drosehn <gad@eclipse.its.rpi.edu> writes: shess@one.net (Scott Hess) wrote: > It's the latency that's important. If an inode has 96 bytes of > information, you can fit 10 inodes in a 1k fragment. If an inode > has 128 bytes, you can only fit 8, if it has 160 bytes, you can > only fit 6. I do not buy the argument that there will be a significant (obvious-to-the-user) performance penalty ... <snip> The overhead should only come when opening files, and it isn't going to be all *that* much different. Well, I'm not really arguing that adding a couple bits to the structures is going to affect anything in a truly user-visible fashion. I'm concerned with the drawing of the line - if we're going to add such-and-such bits, well, lets also add these other bits, too. Also, I'm arguing that there are trivial bits and there are important bits. If we fill out the filesystem structures with trivial bits, we might restrict later addition of important bits. > In essence, that's what this thread is about - the creation > timestamp is one more bit of info helpful to the user. I'm > arguing that this bit is very seldom used, and though it might be > useful periodically, it's not useful frequently enough to be > worth hazarding throughput. If you make the things the user does > hundreds of times a day fast, it's not too painful if you make > the things they do once a week a bit slower. Note that if one uses a resource-fork approach to storing little bits of info, then you have fewer catalog lookups to do (which is to say, the application is doing fewer file-open operations). I think it would be inconsistent to wail and moan about adding a tiny bit of overhead to a file-open, but then be quite comfortable and gung-ho about organizing information in such a way that greatly increases the number of file-open's which are done every time an application is launched or a document is opened. If file opens are so expensive in the first case, then we should not be so calm about them in the second case. Hold on! If you make the arbitrary assumption that _all_ files have two forks, then indeed introducing a wrapper is problematic. Now you've got an additional level of manipulation, without any gain. But, in my experience with NeXTSTEP (and also personal computers in general), files as wrappers tend to be the minority. Most files tend to be just what they appear, a plain old file. [I'll easily grant that these may be files you aren't very interested in, though. Of course, you usually aren't interested in the vast majority of files on your filesystem, or at least you hope not :-).] Furthermore, my experience indicates that files with more than one fork generally tend to want an arbitrary number of forks. The number of files with exactly two forks would be in a very small minority. Granted, you can add a structured file format of some sort which overlays file structure to allow condensing multiple forks into fewer forks. But if you're going to do that, why stop at two forks? Why not condense it all the way down to one fork? Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
Newsgroups: comp.sys.next.programmer Subject: Re: Outline classes in OpenStep? Message-ID: <33135072.48D0@running-start.com> From: Ralph Zazula <zazula@running-start.com> Date: Tue, 25 Feb 1997 12:49:54 -0800 References: <edream-2502970933480001@msn-9-1.binc.net> <5ev56l$ilr$1@news.xmission.com> Organization: Running Start, Inc. MIME-Version: 1.0 CC: edream@mailbag.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi - edream@mailbag.com (Edward K. Ream) wrote: > Are there a set of generally available classes that > implement outline views, > such as the outline view of a finder window on the Mac? > Running Start has developed a framework for doing outline views. An interesting thing about it is that the UI layer has been abstracted such that we can display both AppKit and WebObjects visualizations of the same underlying data. Let me know if you are interested in evaluating the framework... Ralph -- Ralph Zazula Running Start, Inc. zazula@running-start.com 520/760-4890 (4891 FAX) http://www.running-start.com
From: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: Return-key image in IB of OS4.1? Date: 25 Feb 1997 20:09:58 GMT Organization: NeXT Software, Inc. Message-ID: <5evgum$7mk@news.next.com> References: <5etk58$cos@kaopala.mhpcc.edu> Lee Altenberg writes > The demise of the Return key icon was evidence that severe "Windows > Envy" had taken over NeXT. .. > I hope that the Apple purchase has stanched this slide into > perversity and depravity within the NeXT team. Maybe the return of Jobs > will presage the Return of the Return! I hate to point this out, but...The MacOS uses a heavy border around the default button, as well. The arrow icon wouldn't make much sense since Apple's keyboards don't have arrows on the return key (or the tab key, for that matter). -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
From: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep: what does the term mean? Date: 25 Feb 1997 20:04:25 GMT Organization: NeXT Software, Inc. Message-ID: <5evgk9$7m4@news.next.com> References: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> David Herren writes > OPENSTEP is the abstracted API which runs on multiple OSs. OpenStep is > the operating system itself. Confusing, isn't it? Apparently confusing enough for you to get that exactly wrong :-) OPENSTEP (all caps) is Apple's name for their implementation of the OpenStep specification. More specifically, Apple sells: OPENSTEP for Mach OPENSTEP Enterprise for Windows NT Which both implement the OpenStep API on different operating systems. OPENSTEP for Mach also includes our Mach operating system for NeXT computers, Intel PC's, and Sparc workstations. (I just noticed that the "OpenStep compliant" logo uses the wrong capitalization, though. I guess even we don't get it right every time.) -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
From: mmalcolm crawford <m.crawford@shef.ac.uk> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.programmer,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 25 Feb 1997 19:07:19 GMT Organization: University of Sheffield, UK Message-ID: <5evd97$nen@bignews.shef.ac.uk> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <cn0kPX200iWp02=5g0@andrew.cmu.edu> <3303B296.6C6@acm.org> <An1TTE_00iVCE1ZmAF@andrew.cmu.edu> <3307DFEA.2FB0@acm.org> <cn2=AO200iV7E5aK9A@andrew.cmu.edu> <3308EBD5.61F7@acm.org> <0n2UBZ600iWk05nyw0@andrew.cmu.edu> <3310D562.2A8F@acm.org> In-Reply-To: <3310D562.2A8F@acm.org> On 02/23/97, Ian Joyner wrote: > If you are bored of seeing the same thing go round and round, please > skip this now. Charles really has nothing new to say, but in the > interests of trying to give him an answer, here we go again... > One of the things I *am* fed up of seeing is ad hominem attacks from you... Chuck is not known for "bluster", and whilst sometimes rather direct, generally refrains from gratuitous insult. You do not further your arguments by making false assertions that he is simply being rude. Best wishes, mmalc. --
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.programmer,comp.sys.mac.oop.powerplant,comp.sys.next.programmer,comp.sys.mac.system,comp.sys.mac.programmer.codewarrior Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 26 Feb 1997 11:36:13 +1100 Organization: Unisys Message-ID: <3313857C.6A3F@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <slrn45fuv15.nv0.campbejr@phu989.um.us.sbphrd.com> <33011DDB.4B1A@acm.org> <0n0OxoO00iWp023GQ0@andrew.cmu.edu> <33026799.D07@acm.org> <5e04nv$eqt@spool.cs.wisc.edu> <33079938.783E@acm.org> <5ean3v$3l5@spool.cs.wisc.edu> <33091DD2.61FA@acm.org> <0n2TR_y00iWk05nyQ0@andrew.cmu.edu> <330A8B29.1D5A@acm.org> <8n2mO2O00iWl05_J00@andrew.cmu.edu> <330B8D60.74C1@acm.org> <kn36aXu00iWm02vRk0@andrew.cmu.edu> <330CE9E4.60AB@acm.org> <Mn3R_bK00iVCM22gol@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Here we go again. Sorry this is so repetetive and boring.... Charles William Swiger wrote: > > [ ...followups redirected out of the programmer groups... ] > > Excerpts from netnews.comp.sys.next.programmer: 21-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > > Well, unfortunately because of the way you have pursued the argument of > > this thing, this would become a you're dodging the question... no you're > > dodging the question match. > > Respond to the original comment which I've placed below quoted by "C>" > and explain how I misread your comments: > > C> Blocking a process because the kernel is waiting for an operator to tell > C> it how to proceed when some form of error occurs is the opposite of > C> robust! You can easily deadlock every runnable process if some crucial > C> system resource like inetd (*), named, lookupd, or the swapper > C> encounters a minor problem and must block until a human informs the OS > C> of what to do when that error condition could otherwise be handled > C> within the process. > > ...with specific examples, or do not respond. You are going around in circles. I already addressed where you were wrong in the above. (Hint: robustness) > > To get a more reasonable line, you should stop accusing others in these > > groups of doing exactly what it is that you are doing. > > Precisely what is it that I am doing that I have accused other of doing? This has also been addressed time and again. > Be sure to provide specific examples that include direct and uneditted > quotes from me that also include adequate context. No you didn't get it the first time, second time, or nth time. By mathematical induction restating for the n+1 time is not going to enlighten you any better. > > From your first response to what I said, you jumped straight in and > > responded as if I was some kind of biased idiot. > > If you wish to demonstrate that you are actually not, in own your words, > a 'biased idiot': The bias accusation you made, and it is just plain wrong, and shows bad manners along with an inability to argue your point. > Address the issue of whether "Unix is bloated" by reconciling your > statement with the demonstrable facts of the size of Unix as provided by > the 'du' command. You are setting false rules here. Why the du command? Unix has now got very big and complex. Even the inventors of Unix think that: they are doing Plan 9. > [ ... ] > >> If the OS itself blocks the process which asked for some service and > >> waits for the user to tell it what to do when an error occurs, then > >> neither the process being blocked nor any other process which depend on > >> that blocked process to make progress will be able to do anything. > > > > The process is blocked because the OS has not been able to service its > > request for a resource. > > Correct. > > > That is it. > > Incorrect. > > That single process may hold other resources which cannot be released > while it's blocked, or that single process may generate information > which other processes require. Blocking one process may impact many > other processes, or even the entire operating system. This statement is not false, but you still need to go back to class on deadlock, because this is not deadlock. Deadlock occurs when two or more processes mutually lock each other out. > > If the programmer does not want the process to block on a currently > > unavailable resource, I have already told you how to cater for that > > situation. > > This claim is untrue. How can that be untrue? I have already told you how to deal with that situation. > I was the first person to bring up the concept of > non-blocking I/O into this argument, as a scan through prior articles > will demonstrate. Yes you were, but the solution did not have to do with non-blocking IO. You are getting more and more confused. > > Processes do not block on each other. > > Processes most certainly can block on each other. The producer-consumer > paradigm is one of the most basic examples of using remote procedure > calls for IPC. No they do not block on each other, they block on resources. In the producer-consumer paradigm, one process is producing a resource that the consumer is using. The consumer is not blocking on the producer process. You also get something else very mixed up here. Producer-consumer is not an example of RPC. These are separate concepts. > > Processes block on resources. Deadlock occurs because one process locks a > > resource, and a second process locks another resource. Then both processes > > try to lock the resource that the other process already has locked. > > That's the simplest example of the necessary conditions for deadlock. > There are many, mnay other ways of creating deadlock. Again, you must go back to class on this one, and learn the definition. > > Your previous example was if one resource is unavailable, then all > > processes will block on it. > > There were two resources in my example-- the feedback from the user is > also a resource, albeit one that is not part of the computer and > therefore is not under the control of the operating system. > > _That_ is the primary reason why having the OS block a process and wait > for the user to tell it what to do is such a bad idea! The OS cannot > determine or control when it will actually get a response, because it > involves a resource which the OS does not control. Carrying this to its logical conclusion, we should not have human input at all. Any dialog which asks the human for something will block a process, and this might block other processes, so the whole system might lock up. It makes no difference whether the dialog comes from the process asking for an input, or from the OS asking for some system resource that the OS manages and the process has requested. > > What I am saying is if resources under the control of a resource > > manager are unavailable, it is the resource managers responsibility > > to ensure availability, and to resolve contention on the resource. > > Deadlock prevention, and/or deadlock detection and resolution are very > difficult issues that do not have graceful solutions. Either you > require processes to request all of the resources they will need before > reserving any resources (which is hard to do especially when the process > may not be able to figure out what it will need), or you have to do > antisocial things like killing off lots of processes when they do become > deadlocked. Both solutions impose a lot of overhead and generally make > the system less efficient because resources will be used less > efficiently. > > It's why most operating systems ignore the issue of deadlock entirely > and simply try to make sure they can provide enough resources so that > deadlock doesn't happen very often. But OSs can detect deadlock, and this is exactly where they should ask an operator for help in arbitrating, unless some automatic policy gives the OS some heuristic to go forward on. The last part of your statement is wrong. Providing extra resources is not going to prevent deadlock. > > It is bad policy for a resource manager just to hand an error back > > to a running process. > > That is incorrect. There are plenty of circumstances where having the > resource manager just hand errors back is the best policy that could be > followed. No, you are just being contradictory. Your position has been that you believe that application programs should be responsible for exceptions and that resource problems that the OS manages should not be taken care of by the OS but passed onto the application. You program that way, so everybody else has to program that way. This is a very Procrustean attitude. Although I am convinced by the mathematical induction on your thought processes that stating something for the n+1th time won't make any difference: passing back exceptions to applications considerably complicates application code with systems level problems, when applications are written to implement end user problems. > While you've claimed to understand non-blocking I/O, Ian, you obviously > don't understand that when the data isn't available yet, the OS "just > hand[s] an error back to a running process"-- namely, EWOULDBLOCK. You are talking implementation specifics. In abstract terms, the IO buffer is a resource. If it is a write operation, the buffer is locked until the IO handler has completed the write. If the process does some processing and then is ready to put the data in the buffer, it must then wait until the buffer is available. It could use alternative buffers of course. On a read, you have a similar situation, the application can invoke the read operation do some other things and then return for the buffer. This is producer consumer, again nothing to do with RPC, as you said above. So what is so obvious that I don't understand? > If you actually understood non-blocking I/O then you would realize that > the central concept represents a direct contradiction of your assertion > that it's "a bad policy for a resource manager...." > > I'm not going to bother with the rest of this noise-- somehow, I simply > don't feel a need to refute more of Ian's assertions that I don't > understand deadlock. No you don't need to refute the claims, because from what you say you don't understand deadlock. I requote you from above: > It's why most operating systems ignore the issue of deadlock entirely > and simply try to make sure they can provide enough resources so that > deadlock doesn't happen very often. Deadlock has nothing to do with providing enough resources. That is why when you brought up deadlock it was irrelevant in the first place, but you thought you were being very clever. Similar thing about your argument by mathematical induction, clever, but irrelevant. But then mathematical induction does show, you will probably not want to listen or understand for the n+1th time. ------------------------------------------------------------------------ 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: allman@pat.mdc.com (Mark Allman ) Newsgroups: comp.sys.next.programmer Subject: Anybody tried building Perl using OpenStep 4.1? Date: 26 Feb 1997 00:23:54 GMT Organization: McDonnell Douglas, Houston Division Message-ID: <5evvqq$hif@cisu2.jsc.nasa.gov> If you succeeded, please drop me a line. -- Mark Allman -- Sr. Engineer, McDonnell Douglas Aerospace, allman@pat.mdc.com -- Software consulting (Perl, C, Python, ...), ghost@ghost.neosoft.com -- (see: http://pup.princeton.edu/titles/5857.html)
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 24 Feb 1997 06:26:17 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5erca9$m2@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <5ek5is$3d9@crl9.crl.com> van@crl.com (Van C. Bagnol) wrote: > Hmmm...Let's say I want to change the preferences for several > applications, each having a disparate set of preference parameters. > Who/what knows which file goes to which application? Every one > of the files is of type 'pref'. For this particular example, you wouldn't. Under NeXTSTEP, most application preferences are kept in something called the "defaults database". It's one database for all defaults for the user. You don't have lots of "prefs" files. Due to this, you *can* write one application which manipulated the preferences of many other applications. Not sure how this effects your point, but as an aside I do think the "defaults database" of NeXTSTEP works better than having every application have it's own preference file... --- 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.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 24 Feb 1997 06:45:18 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5erddu$m2@usenet.rpi.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> <19970221004435207619@roxboro-184.interpath.net> <nspace-2302971928400001@nspace2.cts.com> nspace@cts.com (Jerry Stratton) wrote: > phenix@interpath.com (John Moreno) wrote: > >] That's kind of what I meant.. You can't choose to open by > >] file type _OVER_ file creator. If the file creator data is > >] there, and the file creator app exists on that machine, you > >] MUST use it. > > Well, it does give you a choice. If the application you want is > visible, and that application tells the operating system it can > handle that file type, you can drag & drop onto that application. > This works regardless of whether or not the owning application > exists. We're all aware of drag-and-drop to open a file, which exists on both operating systems (it's in a slightly different form on NeXTSTEP, but it's there). For purposes of this discussion, "open by file type" should be thought of as "change the behavior seen when double-clicking on a document of a given type". As has been noted elsewhere in this thread, you can also go into the application and select "Open...". This is also available on both platforms. The main difference between the two platforms is the way that a document is opened when you double-click on it. Yes, I can drag- and-drop to "open by file type", but when I am opening a document I'm not always eager to go hunting for the application I want to use (particularly since there are many different places that I get applications from, when I'm on my Mac. File servers, etc). > Perhaps it would be nice to have an additional "File" menu item > which forces Easy Open to query the operating system for all apps > that claim to handle the file type. I'm not sure that would work well (I'm having trouble envisioning how it would work). I think I'd rather have something like "AppSizer" (a control panel available for the Mac), except that it'd list the applications matching the document (instead of showing the memory size) based on some special command-key at launch. Hmm. That paragraph might not make sense unless you know what I mean by AppSizer... > On the other hand, I can't honestly think of a time when I wanted > to open a file by other than the creator when the desired app > wasn't already visible, generally in the launcher. Happens to me fairly often on my Macs, but then I have no desire to setup the launcher. Some of the appleshare servers I use are not under my control, and I don't want to spend time trying to recreate the filesystem in some launcher setup. Using the launcher would probably work fine on my Mac at home, but it would not work well on the Mac in my office, or for the Macs in public labs. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.mac.programmer,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Wed, 26 Feb 1997 12:00:21 +1100 Organization: Unisys Message-ID: <33138B25.B5F@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> <Un3Q9l_00iVC022esD@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > > [ ...Followups redirected out of the programmer groups... ] > > Excerpts from netnews.comp.sys.next.programmer: 21-Feb-97 Re: Mac/NeXT & > Unix: You're.. by Ian Joyner@acm.org > >> If you understand the difference, why did you claim that "your process > >> would probably suspend..." when a process using non-blocking I/O will > >> not suspend? > >> > >> Contradiction detected. > > > > Do you understand the meaning of the word probably? > > Yes. In this context it would mean that some task has non-deterministic > behavior which is being described by probabilities as to whether the > process would block or not. No, the use of probably had nothing to do with non-deterministic behaviour. You're just throwing in another red herring. Probably referred to most applications will "probably" use blocking IO. There is a "possibility: that they might want more control over concurrency and therefore non-block. Neither this nor concurrency has to do with determinism. > However, whether a process will suspend or not is deterministic-- either > it will or it won't depending on whether it used blocking or > non-blocking I/O. > > Therefore, "probably" is an inappropriate term to use. > > [ ... ] > >> According to what you've said, if I find Unix a better solution for some > >> task, then I can't be a "real user of computers"? > >> > >> What nonsense.... > > > > You are correct, your previous statement was nonsense. Please stop > > putting words in my mouth, and then arguing as if I said them. > > Isn't it odd how you deleted your words which I was responding to? > Here's what you said: > > > Good, but my exact point is that there is still much progress to be made > > in the OS area. And certainly if you talk to real users of computers, > > they find other non-Unix solutions better alternatives More boring bandying about of words. Sorry I'm not going to waste more time on this. > My comment was fully justified by this statement of yours, which in your > own words was "real users of computers" "find other non-Unix solutions > better alternatives". > > I have good reason to question both this overgeneralization and the > reason why you would make an association between "real computer users" > and "non-Unix solutions". > > > And you are the first to accuse others of the strawman tactic! > > A strawman argument is an attempt to distort someone's argument until it > says something untrue and then refute this untruth as if you were > responding to the original argument. > > I didn't distort your words in the above exchange-- the question I asked > was an obvious way of refuting your overgeneralized claim. Futhermore, > I made sure that I quoted everything you'd said instead of snipping off > the relevant context the way you did. You cannot accuse me of > distorting your words when I quoted exactly what you said. Gee.. distortions on distortions... > I don't resort to strawman arguments. I don't need to. > > On the other hand, it's a fact that you did resort to strawman arguments > when you repeatedly claimed that I haven't used other operating systems > aside from Unix sufficiently. It's also a fact that you were wrong to > claim that "Unix is bloated". And your opening response to me accused me of bias. You have consistently been incorrect and fairly rude with it. You are quick to accuse others of not understanding things when it is you who do not understand. > I believe you were lying when you claimed that you wanted to have a > technical discussion, Ian. I challenge you to disprove my belief by > addressing the technical points that I have made. Start by addressing > your claims about the size of Unix as compared to on the observable > facts from using the 'du' command. > > Judging from your past and current behavior, however, you'll snip this > whole section instead of responding to it or admitting the truth. OK, I won't snip it, but it is off the point, and wasting time. There are many other metrics apart from du. Don't start me on that, I'm not interested. > >>>> That's why people write software layers on top of the OS, such as > >>>> OPENSTEP, which provide higher level abstractions which use the more > >>>> primitive functionality provided by the OS. And that's where those > >>>> high-level abstractions belong-- not in the kernel.... > >>> > >>> Right, but as far as an application is concerned that is the OS. > >> > >> You have one of the most bizzare viewpoints I've ever seen. > > > > Not at all. From the applications viewpoint, when it calls a system > > level service for a resource, it is calling the OS. > > That's a tautology-- if you're calling a "SYSTEM level service", > obviously you're involving the "operating SYSTEM". However, you can do > lots of things with OPENSTEP that do not involve system level resources > and the OS at all. Tautology? No its abstraction. Really, it doesn't matter whether the application programmer thinks they are calling the OS or not, or whether the request is serviced by the OS or not. The applications programmer wants to know what to provide the service and what they will get in return. This comes back to design-by-contract, and the original point that services should be better designed. But you still haven't got that point. > >> OPENSTEP is not an operating system; it's an software layer that > >> provides an abstraction _away_ from the specific OS that the application > >> runs on, so that the app can do useful things without having to be > >> written using non-portable, operating-system-specific functionality. > > > > Well, I think we're actually saying the same thing here, > > so I can't see why you were picking an argument above. > > No, we're not-- I'm saying there is a distinction between an OS and > software components not in the OS which provide useful functionality to > application. Well you are throwing in irrelevancies again. You are thinking about how this is implemented. As I said an application calls a service. It should not be able to tell at what level of the OS, or in a user library that service is implemented. That is abstraction to the program. > > As I said, to the application, that abstraction you are talking about is > > the OS. If the application can tell any different, then it's not an > > abstraction! > > But OPENSTEP provides functionality which does not have any analogue at > the operating-system level. It can't possibly provide an abstraction > for something which does not exist! Your confused again, thinking of how things are implemented, rather than the abstraction at an interface. ------------------------------------------------------------------------ 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: herren@flannet.middlebury.edu (David Herren) Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep: what does the term mean? Date: Tue, 25 Feb 1997 21:16:08 -0500 Organization: Language Schools of Middlebury College Sender: herren@flannet.middlebury.edu Message-ID: <msg37822.thr-34867b00.54c5638@flannet.middlebury.edu> References: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> <5evgk9$7m4@news.next.com> Mime-Version: 1.0 Content-Type: text/enriched; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-ID: <msg37822.thr-34867b00.54c5638.part0@flannet.middlebury.edu> <bold>MaRK_BeSSeY@NeXT.CoM,UseNet writes: ></bold>> OPENSTEP is the abstracted API which runs on multiple OSs. OpenStep is >> the operating system itself. Confusing, isn't it? >Apparently confusing enough for you to get that exactly wrong :-) Blushingly, I stand corrected. I did have it exactly backwards. >OPENSTEP (all caps) is Apple's name for their implementation of the >OpenStep specification. More specifically, Apple sells: > OPENSTEP for Mach > OPENSTEP Enterprise for Windows NT >Which both implement the OpenStep API on different operating systems. >OPENSTEP for Mach also includes our Mach operating system for NeXT >computers, Intel PC's, and Sparc workstations. >(I just noticed that the "OpenStep compliant" logo uses the wrong >capitalization, though. I guess even we don't get it right every time.) It's interesting the the manuals that come with the developer kit have OPENSTEP (all caps) on the cover when they refer not the the OS but to programming the API... -- David Herren -------------------------------------------------- Web: http://www.middlebury.edu/~herren/ General: herren@flannet.middlebury.edu NeXTMail only: herren@barcelona.middlebury.edu
From: no.spam@no.where (Pascal Bourguignon) Newsgroups: comp.sys.next.programmer Subject: Re: SVGA display drivers and Vertical refresh interrupts... Date: 26 Feb 1997 03:03:32 GMT Organization: ImagiNET Message-ID: <5f0964$62j@belzebul.imaginet.fr> References: <331231e0.277699468@news.mindspring.com> In comp.sys.next.programmer article <331231e0.277699468@news.mindspring.com> you wrote: [...] > Possibly so, but in this card the card is not the limiting factor. > NEXT's display architecture is designed around a linear frame buffer, > ie. if your display adaptor has 2M of memory the operating system > presents this memory to NEXT's window server as a contiguous block. > > The SVGA standard is an extension of VGA, which is limited to a very > small memory buffer. To work around the limit, SVGA uses this VGA > buffer as a "window" into a larger memory buffer, mapping segments of > that larger buffer into the VGA memory area as they're needed. The > gain is higher resolution and pixel depth at the cost of performance. > > NEXT had to jump through hoops to make SVGA work at a depth of 2 bits > per pixel. I vaguely recall discusions of the window server > implementing an exception handler to deal with page faults by calling > the SVGA driver routine to map in the correct segment and making the > proper OS calls to fix up the physical-to-virtual memory mapping - > makes me shudder just thinking about it. > > NEXT had to jump through hoops to make SVGA work at a depth of 2 bits > per pixel. I vaguely recall discusions of the window server > implementing an exception handler to deal with page faults by calling > the SVGA driver routine to map in the correct segment and making the > proper OS calls to fix up the physical-to-virtual memory mapping - > makes me shudder just thinking about it. > > Anyway, my point is that if 8-bit (256 color) pixel depth performed > adequately NEXT would have included it in their SVGA implementation. > Of course, this decision was made before Intel clean room technicians > started dancing to "Play That Funky Music" and "installing" MMX (more > money extracted) technology in their chips. Maybe today's Pentium > can handle the load, but I'd bet against being able to implement 8-bit > depth in a subclass of IOSVGADisplay. [...] I'm in the process of adapting the CirrusLogicGD542X driver to CirrusLogicGD754X to manager at least 800*600*2 and indeed I have some problems: The display is correctly set to 800*600, and in the inialization code, I can access all the video memory to set it to some pattern. But DPS does not seem to access the lower part of the screen; it displays only 800*512. But when I do a screen grab, I get the full 800*600 (it must maintain some back store for the screen memory). I have the documentation of the CL-GD7548, and it seems that I could map the video memory linerarly to a continuous range of memory. I intend to implement also 800*600*BW:8 and 800*600*RGB:555. Would you say that I should forget the IOSVGADisplay super class, and implement my driver as a mere IODisplay subclass? Do you have any idea about why it displays only on 800*512? __Pascal Bourguignon__
Date: Tue, 25 Feb 1997 22:21:13 -0600 From: mark@oaai.com Subject: Re: Objective C? Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.lang.objective-c Message-ID: <856930544.19004@dejanews.com> Organization: Deja News Usenet Posting Service References: <330E54AC.167E@innosys.com> <petrichE5zqx1.LCv@netcom.com> <5eo65r$53l@lal.interserv.com> <petrichE61n5I.DoK@netcom.com> <856715712.25573@dejanews.com> <5eqq6n$s7s@lal.interserv.com> <856776663.22260@dejanews.com> <5etptl$2tb@lal.interserv.com> In article <5etptl$2tb@lal.interserv.com>, JamesCurran@CIS.CompuServe.com (James M. Curran) wrote: >This part interests me, since so far I've only been able to come up >with a couple pathological/textbook examples where the Objective C >method would be better than the C++ way. > >Could you (briefly) describe a example real-world problem where you >would choice Objective C over C++??? A few come to mind immediately: I'd use Objective C over C++ in implementing business object models in, say, a custom trading application (which represents most of my business these days). The reason here is that while ideally you enter into these sorts of projects with a complete analysis and design in hand, in reality it's hard to get the model right the first time - traders are interested in trading, and completely disinterested in participating in system design sessions :-) So building such a system means frequent updates to the object model. Frequent changes mean frequent recompiles, which under C++ because of the fragile base-class problem often means all too frequent recompiles of the world, or if you're not careful, mysterious crashes at unexpected points in the program. This can slow software development substantially. C++ is not an ideal language for applications that call for iterative design. On the other hand [and to illustrate my point that each language has its strengths] I wouldn't hesitate a second to make use of C++-based financial calc. libraries *within the same trading system*. Here you need the speed, your problem domain is well-defined, and the added expressivity of operator overloading simplifies code and makes it more readable. Another area I'd use Objective C over C++ is in the design of graphical user interfaces and related reusable components. I can think of two projects where this course of action saved months of work and tens of thousands of lines of mostly uninteresting and error-prone code. The first project was one I'd engaged in with a prominent U.S. telecommunications firm [which shall remain nameless]. They had spend two years working on a system implemented in C++. Their interface, factored in the Model-View-Controller style, was full of code like this: FooController::populateInterface() { textfield1.setValue(myObject.attrib1); slider2.setValue(myObject.attrib2); .... } FooController::depopulateInterface() { myObject.getAttrib1(textfield1.value()); myObject.getAttrib2(textfield2.value()); .... } So despite the factoring, the interface and objects were completely coupled. If the business object model changed and an attribute was added, removed, or moved from one class to another, developers would have to dig around reams of controller code to remove all references to said object's attribute. When we implemented our interface for a related system, I proposed that business objects should be wrapped in Objective C object wrappers and that we should take advantage of the Objective C runtime to create generic controller objects which would map arbitrary objects to arbitrary UI elements. The end result was that we spent a month developing an automatic wrapper generator in Perl, and an object framework which would visually allow a developer to drag-and-drop links between UI widgets and a business object "container" which would perform our UI mapping. Taking advantage of the built-in Objective C runtime and its introspection facilities allowed us to build a robust system in virtually no time. The same framework has been used now in several projects spanning several industries - it is imminently reusable because it makes no assumptions whatsoever about the objects it is meant to work with - *any* Objective C object will do. You just drop it in and it works. So these are a few specific examples. But perhaps approaching the question from a slightly different angle might elucidate things further. As I say, I've worked in mixed environments of Objective C and C++, and have worked with exceptionally strong developers in both environments. For many C++ developers, these projects are the first in which they're exposed to Objective C largely through a database access product called the Enterprise Objects Framework - a tool which presents standard relational databases as though they were OODBMSes. A common exercise I see a lot of C++ developers engage in after working in the environment for a month or so is to start to explore how the same framework would be written in C++. Often they can come up with one mechanism or another in C++ to perform a particular function of the Objective C -based framework. For instance: * in Objective C, relationships are "faulted" so that they fill memory in a "just-in-time" fashion. This behaviour is trivially implemented in Objective C through the built in message forwarding mechanism. In C++ something similar can be accomplished through the clever use of smart-pointers. * in Objective C, qualifiers can be performed in-memory on arbitrary objects as well as on the database. This behaviour is again trivially implemented in Objective C through object reflection. In C++ a runtime can be invented for objects to provide this functionality. * In Objective C, the framework provides in-memory support for transactions as well as transparent undo and redo of all business object operations (ie. no extra coding required). In C++, a combination of a hand-rolled runtime and notification mechanism can provide this functionality. ....and the list goes on. Ultimately however as the feature list grows, the developers come to realize that the whole package as implemented in C++ becomes hoplelessly complex. The language requires you to write too many lines of code to get the job done. I summed it up once when discussing my philosophy of programming with a colleague at a US brokerage [again, nameless :-)] who seemed to focus on all the wrong things in software development: "The software crisis isn't that we can't write programs that run fast enough, rather it's that we can't write programs quickly enough to satisfy the ever-increasing demand." I'd say that there exists a large class of problems where Objective C more properly addresses this "software crisis" than does C++, and its for these problems that I'd sooner use Objective C as a solution than C++. Cheers, Mark ps. [phew! thanks for hanging in and reading this far - I guess I wasn't as brief as I'd hoped to be!] --- M. Onyschuk and Associates Inc. Software Systems for the U.S. and Canadian Financial Industries. 15 La Rose Ave. Suite 702, Weston Ontario M9P 1A7 (416)241-3076 -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Tue, 25 Feb 1997 23:54:20 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Mn4w7wm00iVCIHHMVm@andrew.cmu.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> <Un3Q9l_00iVC022esD@andrew.cmu.edu> <33138B25.B5F@acm.org> In-Reply-To: <33138B25.B5F@acm.org> Excerpts from netnews.comp.sys.next.programmer: 26-Feb-97 Re: Mac/NeXT & Unix: You're.. by Ian Joyner@acm.org >> I believe you were lying when you claimed that you wanted to have a >> technical discussion, Ian. I challenge you to disprove my belief by >> addressing the technical points that I have made. Start by addressing >> your claims about the size of Unix as compared to on the observable >> facts from using the 'du' command. >> >> Judging from your past and current behavior, however, you'll snip this >> whole section instead of responding to it or admitting the truth. > > OK, I won't snip it, but it is off the point, and wasting time. The fact that you were wrong and refuse to acknowledge it is most certainly relevant. When I demand that you prove your claims with specific responses, you dodge the question again and again. When I make a point, you claim that I'm wrong without providing any shred of evidence to back up your assertions-- and then when I then prove that point, you then claim that it somehow wasn't relevant. > There are many other metrics apart from du. What precisely does _that_ mean? Sure, there are lots of tools that compute the size of a set of files, and all of them would report the same value for the disk space being used. This is a red herring of the first order. > Don't start me on that, I'm not interested. You have demonstrated that you are completely unable to hold a rational discussion. I don't see any point to discussing this further. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Tom Johnstone <johnston@fapse.unige.ch> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 14:26:57 +0800 Organization: University of Geneva Message-ID: <3313D7B1.639F@fapse.unige.ch> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <32FB9565.5193@subsequent.com> <5e2rne$d5e@geraldo.cc.utexas.edu> <5ecefl$5d1@kwek.omroep.nl> <peterm.856338754@ulfrun> <5ejcd4$oij@usenet.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Garance A Drosehn <gad@eclipse.its.rpi.edu> Garance A Drosehn wrote: > There is no good reason that the user would spend any time or energy > remembering extensions. And, in fact, they don't under NeXTSTEP. > The operating system knows the mapping from extensions to applications, > it isn't something that the user has to "remember". All the user has > to do is leave the extension alone. This is not a hard task. > Not a hard task, but one that many many users can't (or don't) master. People make mistakes, mess around with things, and just generally stuff things up all the time. It has to be idiot proof - don't let users change the type information unless they know what they're doing (i.e. use a special manu item/dialog box to do this). Just 5c worth from someone who spends many hours fixing other users' stuff-ups. Tom Johnstone University of Geneva
From: wef@ct2.nai.net Newsgroups: comp.sys.next.programmer Subject: C++ or JAVA which is best??? Date: Wed, 26 Feb 1997 06:32:44 GMT Organization: North American Internet Message-ID: <331ad8fe.1061430@news.nai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am interested in knowing what the unbiased opinion it out there... I am considering pouring alot of my resources into a programming education and career. In order to maximize the world of programming these days, one must weigh the difference between C++ and Java. Please choose you pick and tell me why you think it is the way to go. Thanks in advance, Bill
From: nouser@nohost.nodomain (Thomas) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.lang.objective-c Subject: Re: Objective C? Date: 25 Feb 1997 23:34:48 -0800 Organization: home Message-ID: <tz8k9nwuijr.fsf@aimnet.com> References: <330E54AC.167E@innosys.com> <petrichE5zqx1.LCv@netcom.com> <5eo65r$53l@lal.interserv.com> <petrichE61n5I.DoK@netcom.com> <856715712.25573@dejanews.com> <5eqq6n$s7s@lal.interserv.com> <856776663.22260@dejanews.com> <5etptl$2tb@lal.interserv.com> <856930544.19004@dejanews.com> In-reply-to: mark@oaai.com's message of Tue, 25 Feb 1997 22:21:13 -0600 Fcc: /u6/users/tmb/mail/x-nout In article <856930544.19004@dejanews.com> mark@oaai.com writes: [lots of good points about how Objective C and languages like it allow rapid, iterative design and why this is often the better approach for real-world applications] Often [C++ developers exposed to Objective-C] can come up with one mechanism or another in C++ to perform a particular function of the Objective C -based framework. [...] Ultimately however as the feature list grows, the developers come to realize that the whole package as implemented in C++ becomes hoplelessly complex. I think this is what we are seeing with COM/OLE/ActiveX. It is an attempt to provide in C++ dynamic features as found in Objective-C and Java. The irony is that the IDL specifications for ActiveX themselves are already more complicated than the complete set of extensions Objective-C makes to C. Maybe Objective-C would gain wider acceptance if it were marketed not as a new programming language but simply as an IDL for C and C++. On that note, do people know of any packages that interface Objective-C to COM/OLE/ActiveX? Thomas.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Date: 26 Feb 1997 08:48:56 GMT Organization: Global Objects Inc. Message-ID: <5f0tdo$73u$1@news.xmission.com> References: <331ad8fe.1061430@news.nai.net> wef@ct2.nai.net wrote: > I am interested in knowing what the unbiased opinion it out there... > I am considering pouring alot of my resources into a programming > education and career. In order to maximize the world of programming > these days, one must weigh the difference between C++ and Java. > Please choose you pick and tell me why you think it is the way to go. Boy will this start a holy war... Well, here's my $0.02, all IMHO of course: First, since you posted to a NeXT group, I'd say "learn Objective-C". :-) If you must pick between those other two, learn Java first. There are enough similaries between the languages that you can actually jump from one to the other pretty easily once you've mastered the underlying concepts. So, to master OOP, IMHO go with Objective-C, Java, and C++ is the order of ease--with C++ it is too easy to get bogged down in details and lose the OO perspective. Java is pretty much middle ground. (Oversimplified, it is C++ syntax with Objective-C semantics underneath) I think that you'll find that same order is also easiest->hardest for learning the syntax and getting a grip on the class libraries used in the respective environments. But, politically, the "hot" order would be Java, C++, and Objective-C, though a conservative person would go C++, Java, Objective-C since C++ is so entrenched...and is likely to live a long time, as the Cobol of the 90s. Then again, it is pretty easy right now to get a job doing Java or Objective-C because so few people know the technologies. :-) So I guess you have to decide what factors matter most to you--value of the skill, conservative security, "hot" factor, ease of learning, etc. My skills went Basic -> Assembly (6502)-> Pascal -> C -> Objective-C -> C++ -> Java (with 680x0 and x86 assembly thrown in for good measure somewhere) The biggest jumps conceptually were to assembly and Objective-C, as far as the underlying concepts go. I glad I did the OO jump with Objective-C and not C++, or I would have not learned OO very well, I suspect. Syntax wise, C++ is still a bitch and I hate using it. Java is a cakewalk with the others as a background. I don't see any reason why you should have to limit yourself to a single language, though. Grab a few good books and just dive on in. The more languages you know, the more marketable you are, because your ability won't be tied to a single language's quirks; you'll understand the "big picture" better and be a better programmer for it. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: kluev@macsimum.gamma.ru (Michael Kluev) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 15:19:00 +0300 Organization: MACsimum Ltd. Message-ID: <kluev-2602971519000001@kluev.macsimum.gamma.ru> References: <5ddp66$jpc@news.bu.edu> <5de4gb$np2@news.bu.edu> <32FB7FCA.4D15@mcs.com> <qdohdwi3xe.fsf@blues.cygnus.com> <peterm.855560581@ulfrun> <qdafpcigu6.fsf@blues.cygnus.com> <peterm.855734840@ulfrun> <Yn0RG7q00iWQI1qLIH@andrew.cmu.edu> <peterm.855825088@ulfrun> <SHESS.97Feb13094615@howard.one.net> <peterm.855919020@ulfrun> <SHESS.97Feb14103937@howard.one.net> <peterm.856170937@ulfrun> <SHESS.97Feb17161830@howard.one.net> <peterm.856265782@ulfrun> <SHESS.97Feb19093610@howard.one.net> <5ejgug$oij@usenet.rpi.edu> <SHESS.97Feb25125500@howard.one.net> In article <SHESS.97Feb25125500@howard.one.net>, shess@one.net (Scott Hess) wrote: >In article <5ejgug$oij@usenet.rpi.edu>, > Garance A Drosehn <gad@eclipse.its.rpi.edu> writes: > shess@one.net (Scott Hess) wrote: > > It's the latency that's important. If an inode has 96 bytes of > > information, you can fit 10 inodes in a 1k fragment. If an inode > > has 128 bytes, you can only fit 8, if it has 160 bytes, you can > > only fit 6. > > I do not buy the argument that there will be a significant > (obvious-to-the-user) performance penalty ... ><snip> > The overhead should only come when opening files, and it isn't > going to be all *that* much different. > >Well, I'm not really arguing that adding a couple bits to the >structures is going to affect anything in a truly user-visible >fashion. I'm concerned with the drawing of the line - if we're going >to add such-and-such bits, well, lets also add these other bits, too. >Also, I'm arguing that there are trivial bits and there are important >bits. If we fill out the filesystem structures with trivial bits, we >might restrict later addition of important bits. > > > In essence, that's what this thread is about - the creation > > timestamp is one more bit of info helpful to the user. I'm > > arguing that this bit is very seldom used, and though it might be > > useful periodically, it's not useful frequently enough to be > > worth hazarding throughput. If you make the things the user does > > hundreds of times a day fast, it's not too painful if you make > > the things they do once a week a bit slower. > > Note that if one uses a resource-fork approach to storing little > bits of info, then you have fewer catalog lookups to do (which is > to say, the application is doing fewer file-open operations). I > think it would be inconsistent to wail and moan about adding a tiny > bit of overhead to a file-open, but then be quite comfortable and > gung-ho about organizing information in such a way that greatly > increases the number of file-open's which are done every time an > application is launched or a document is opened. If file opens are > so expensive in the first case, then we should not be so calm about > them in the second case. > >Hold on! If you make the arbitrary assumption that _all_ files have .... Finder Information. People, remember, that HFS maintains other useful information (called user or Finder info). I am talking about current scroll position for directories, icon position for items, etc. If there are methods to hide this information in wrappers w/o speed penalty, I'll go for it. But, I really doubt, that showing window full of icons that will do openfile operations on each file (to get icon position) would be comparably fast with showing window full of icons that will do GetCatInfo/stat operation to get icon position. (This is about generic, not custom icons. (Exercise: why?)) The same reasoning (speed penalty) is applied as well to things like color labels, file types, etc. Last access time. Speaking about "... doesn't work well in multiuser environment". If you buy this argument (and I do to some extent), than you should buy the following: the field that holds "last access time" in the file information doesn't work well on read only media. (In fact it doesn't work at all on read only media.) Current (future?) Mac users do encounter "read only media" much often than "multiuser environment". Thus this field should be stripped. Symbolic links. Traditional symbolic links don't work for Mac users. Mac users are creatures that like to drag things around as paper clips on their desk, screwing up paths in symbolic links. BTW, HFS aliases include path information as a subset. Parent IDs in aliases make it possible to find files even if they were moved. Some questions. 1. What file/directory management API is there in the Next? Is it path based? Is it like: "open("dir/subdir1/subdir2/subdir3/subdir4/file"? Or more like HFS way: "open(parID, "file")" where parID is the id of "subdir4"? 2. Is Next File system crash-safe? (Crash = turning power off here.) PS. "comp.sys.mac.programmer.codewarrior" was removed from this article's header. ---------------------------------------------------------------- Michael Kluev kluev@macsimum.gamma.ru Macintosh Programmer Physics Grad, MSU MACsimum Ltd. Moscow, Russia ----------------------------------------------------------------
From: spamwall~mouser@zercom.net (Martiin-Gilles Lavoie) Newsgroups: comp.sys.next.programmer Subject: Librarian book on Display PostScript? Date: Wed, 26 Feb 1997 08:27:02 -0500 Organization: Internet-Login Message-ID: <spamwall~mouser-2602970827020001@204.191.6.123> I have recently aquired a NeXT Station Color system in order to get ahead for Apple's upcomming Rhapsody. I have found the Librarian tool quite helpfull, and it's documentation next to being complete (pin-outs included). However, I was wondering is a Librarian book on Display PostScript (and PostScript in general) is available? MGL (And I _do_ have the Reg, Green and blue books, among others...I'm just looking for an on-line version). Please reply my e-mail as well. <mailto:mouser@zercom.net>
From: phenix@interpath.com (John Moreno) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 09:13:31 -0500 Organization: phenix@interpath.com Message-ID: <1997022609133112530052@roxboro-186.interpath.net> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <5dts78$bot$1@majipoor.cygnus.com> <1997021716472829510259@roxboro-170.interpath.net> <5ecund$rcn$1@majipoor.cygnus.com> <19970221004435207619@roxboro-184.interpath.net> <nspace-2302971928400001@nspace2.cts.com> <5erddu$m2@usenet.rpi.edu> Garance A Drosehn <gad@eclipse.its.rpi.edu> wrote: -snip- ] ] The main difference between the two platforms is the way that a ] document is opened when you double-click on it. Yes, I can drag- ] and-drop to "open by file type", but when I am opening a document ] I'm not always eager to go hunting for the application I want to ] use (particularly since there are many different places that I get ] applications from, when I'm on my Mac. File servers, etc). ] ] > Perhaps it would be nice to have an additional "File" menu item ] > which forces Easy Open to query the operating system for all apps ] > that claim to handle the file type. ] ] I'm not sure that would work well (I'm having trouble envisioning ] how it would work). I think I'd rather have something like "AppSizer" ] (a control panel available for the Mac), except that it'd list the ] applications matching the document (instead of showing the memory ] size) based on some special command-key at launch. I'm fairly sure that what he means is that they should add a "Open Via MEO..." menu in the finders File Menu, a bad idea in my opinion - although doing the same thing with a command-click does seem viable. Which is strange since I usually object to having "hidden" commands. ] Hmm. That paragraph might not make sense unless you know what I ] mean by AppSizer... ] ] > On the other hand, I can't honestly think of a time when I wanted ] > to open a file by other than the creator when the desired app ] > wasn't already visible, generally in the launcher. ] ] Happens to me fairly often on my Macs, but then I have no desire ] to setup the launcher. Some of the appleshare servers I use are ] not under my control, and I don't want to spend time trying to ] recreate the filesystem in some launcher setup. Using the launcher ] would probably work fine on my Mac at home, but it would not work ] well on the Mac in my office, or for the Macs in public labs. If this happens to you fairly often I'd recommend that you get a shareware program called "The Tilery". The default action of the program is to put a tile - a shadowed box with the file/applications name in it - along the left edge. I have mine configured to put the tiles at the right and moving left. You can drag and drop any file on any application that supports that file type. -- John Moreno
From: tbutler@tfs.net (Travis Butler) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 08:16:23 -0600 Organization: The Wandering Powerbook... Message-ID: <AF39A1D79668E697E@pm3-p20.tfs.net> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> In article <5eb9r5$iv2@csugrad.cs.vt.edu>, nurban@csugrad.cs.vt.edu (Nathan M. Urban) wrote: >In article <AF2E42E196681EFC18@node50.tfs.net>, tbutler@tfs.net (Travis Butler) >wrote: > >> I'm blathering on about this because it seems like a large number of the >> arguments by NeXT partisans boil down to 'it has to be this way if you're >> on a multiuser system.' Well, as I said, I don't WANT a multiuser system; > >Well I'm sorry, but too bad. Apple is not going to redesign the entire >filesystem to make single users a little happier when it means >sacrificing multiuser capability and returning to 80's technology. Really. My congratulations on your 'inside source,' then, because nothing I've seen anywhere else suggests that Apple has made such a decision, or even made a decision at all yet. Many NeXT partisans keep speaking as if the MacOS isn't a valid OS in its own right, and any use of MacOS features or system design in Rhapsody constitutes a 'redesign' or 'crippling' of NeXTStep. This is REALLY beginning to irritate me. Well, let me give them a clue: while Apple is still vague on many technical details of Rhapsody, they have stated from the beginning that Rhapsody is going to be a *merger* of the best elements of MacOS and NeXTStep, not NeXTStep thinly papered over. NeXTStep is going to be redesigned to some degree, just as MacOS will be redesigned to some degree. Get used to it. And if we're going to talk about '80's technology', then what about the antiquated directory hierarchy of Unix's *1970's* technology? Technology should move forward, not back, and I think the Mac made some real innovations in the way files were handled -- handicapped in later years by implementation decisions that weren't forward-thinking enough, like the allocation block limit. IMHO, the resource fork was a major innovation -- a method that allowed customizable elements of an application to be seperated out for easy editing, or attatching meta-data (like high-level formatting or window-positioning information) to a straight datafile -- while still keeping the file as one coherent unit in the filesystem, that can be easily moved from location to location without worrying about losing any of the bits. That's the major objection I have to the 'wrapper' concept: it forces the filesystem* to deal with organizing all the various parts of an application or datafile with meta-data -- when IMHO this should be handled at a higher level of the OS, the part that actually runs the application or uses the meta-data. The filesystem shouldn't have to keep track of these issues -- that should be the responsibility of the code that actually uses all the different parts. *(And, by extension, any operation that deals with the *real* filesystem at the file-by-file level, instead of the abstraction of the wrapper level -- such as duplicating applications or files, running applications over a network, or transmitting files to a remote location. Not to mention file searching utilities, utilities for measuring and managing disk usage...) Separating file Type information from the filename, and adding Creator information, was another beneficial innovation. There are literally dozens of utilities that can be used to access and change them, but they're protected from accidental change. Also, removing extensions from the filename give users more freedom in naming files. I don't like the idea some suggest of leaving extensions in place but hiding them from the user: while I want some details abstracted from users, I *also* want the file browser (whether it's the Finder or the NeXTStep browser) to reflect the true state of the filesystem. (Another reason why I dislike the wrapper concept, by the by.) I also like the concept and general operation of the Finder's Desktop Database, based in large part on Type/Creator information, though the execution is not up to the concept. >You can go on all you want about Apple's targeted market, More on this below. >but it's a step backwards and Apple's not going to take it. Really. Again, moving from the 80's MacOS filesystem to the 70's Unix filesystem is a step forward in technology? Granted, the 80's technology has problems -- but the answer is to fix them, not go back to a more limiting concept. I find it interesting that one of the touted features of BeOS -- one of only a couple of 'designed-from-the-ground-up' personal computer OS's in this decade -- is an OS-level 'file database'. I haven't seen many details on it, but what I've heard sounds like something that moves even further in the direction pointed by the items I like about the MacOS. >HFS is one reason why Macs >are not considered seriously in server environments. Perhaps, but what *part* of HFS? I agree some of the underlying structural elements of HFS are crippling the MacOS filesystem, as I state above, and those things I want to see fixed. But I don't want to remove the good elements of the MacOS filesystem in the process. >> and in my experience, this holds true for the vast majority of machines >> outside of a lab environment. > >Actually, I know of quite a few machines both in work and home >environments which more than one person uses. I know a few used by multiple people in homes, granted -- but I only know of one who *wanted* multiuser login and security features, and his needs were handled by At Ease. In fact, that's exactly the model I think *should* be used for multiple users on a *personal* computer: make the OS optimized for individual users, who in my experience make up the majority of personal computer users, and make multiuser login/security features an OPTIONAL add-in for those who need it. In the places I've worked at (see below), with the exception of the computer labs -- once in a while someone will need to use someone else's machine, and trainees worked alongside their 'mentors' on their machines, but by and large everyone has their own computer. >And there are still good >reasons for having a multiuser machine even if only one person uses it. Why? Again, why cripple a single user's experience for multiuser support that is never used? >> I don't mind having things in there for the >> benefit of multiuser setups, as long as they don't get in the way of >> ordinary single-user operation; but if there's a conflict, I think >> multiuser features have to take a back seat to convenience features for >> single users. > >There really are not very many instances where having a multiuser >filesystem seriously inconveniences single users, your opinions >notwithstanding. Then why does your side of the argument keep bringing up reasons that things can't be done the 'Mac way' because they interfere with multiuser operation? >> To the point at hand: I think it makes a lot more sense for the default to >> be the application that created a file. > >I don't. I've used Macs and I've used NEXTSTEP and I like the NEXTSTEP >way far better. I don't want to get a file from somebody and have it >open in whatever _they_ like to use. I want all GIFs to open in my >preferred GIF viewer, etc. Your preference -- and the Mac system doesn't preclude this, as there are utilities that make the Mac operate the way you want things to work. (Not to mention the drag-and-drop method, which is actually simpler on a Mac as there's no need to hold down a modifier key.) But while the Mac way doesn't preclude *your* preferred operation style, NeXTStep's system *does* preclude *my* preferred style. I want to associate certain documents of a type with one application, and other documents of that type with another application, and from everything I've seen in these threads, NeXTStep won't let you do that. If your style of operation is still possible, why do you object to the possibility of my style of operation? >> Again based on my experience, >> people generally create a file with the application they want to use to >> work with it. > >They may create it with one application, and then prefer to view it >from then on using another. Fine. Create it in the first application, then open it in the second application and do a Save As. But again, from a common-sense standpoint: Why create it in one application instead of a second, unless the first has options the second doesn't that apply to that particular file? And in that case, doesn't it make more sense to keep opening it in the application with those options, as long as you actually keep editing that file? Or you might start primarily needing options in the second app, in which case you're probably going to want the default to be the second app, and you'd do a Save As from that app. Or you need to use options from both programs, in which case you're better off using drag-and-drop under either OS. Note that I'm talking about files that you *work* with, not files intended primarily for viewing, which IMHO are a special case. >Or they may prefer to view a document >someone sends them with one viewer application rather than a full-blown >editor. Files intended primarily for viewing are the other major exception (besides data acquisition) that I can think of to the rule above. But I don't find this exception justifies the use of a single-app-for-all-files utility (which, as I said, are available for the Mac). 90%+ of these view-only files that I see come off the Internet or other on-line services; and InternetConfig allows you to assign default type/creator information for incoming files, via MIME type or file extension, so that isn't a problem. Using drag-and-drop on the few remaining files is not any particular hassle for me. >But that's the point you just made below. Not at all. I was talking about data acquisition, which is a completely different kettle of fish from file viewing. In data acquisition, you use a program to get data from a specialized source -- like LabView, or an OCR program, or a custom scanner application for scanners that don't use a Photoshop plug-in. But once you've acquired the data, you're not going to use the acquisition program to do further editing, so it makes sense to change the creator app for that file by using Save As from within your editing app. The case of pulling up a file in a quick viewer app is completely different. In this case, you're using a viewer to pull up a file for a quick look, but it's not what you'd use to edit a file; here, setting the default to the editing app, and using drag-and-drop to open it in the viewer, makes more sense. Unless the file is intended primarily for viewing, which I cover above. >There are a _lot_ >of exceptions though, at least with the files I typically work with. Obviously, we have different working environments and different working styles, which is fine. However, one thing that keeps getting me to post in this thread is the way NeXT users seem to think it's fine if Mac users get forced into their way of doing things, even if it's not vice-versa. Take this example - the Mac lets you do things your preferred way *and* mine, NeXTStep only lets you do things your way, yet you seem to feel opening up both possibilities is an imposition on you. Or take the OS directory structure: Macs let you organize your applications any way you want, including a Unix-style application tree; NeXTStep locks you into the Unix directory straightjacket. Yet someone I responded to a couple of weeks ago was saying that Mac users should not be allowed to organize things their way, even if it didn't keep him from organizing things his way. >And the documents that I both create and view with the same application >are usually with an application that has its own document format, so >opening by type doesn't make any difference anyway. I think part of this gets back to the idea of meta-data and a resource fork. On the Mac, it's quite possible to create files in a standard file format where another platform might require a custom file format, because the application's custom data can be stored in the resource fork. Nisus Writer is an example of this. It's a full-fledged word processor, with extensive formatting options; but it stores its files in plain ASCII format in the data fork, because all the formatting information is stored in the resource fork. Obviously, you'd prefer to edit and view the file in Nisus Writer; however, if you need to get at just the text data in the file, you can view and access it from any application that can read text files. Wouldn't you say this is a better solution than using a custom word processing file format? A different example is TIFF files; they can be recognized and edited by both Photoshop and Fractal Design Painter, but each program can do *very* different things with those files. Or take some 'custom' formats that have been around long enough, and are prevalent enough, that many different programs can read them: WKS files from 1-2-3, for example, or MacWrite documents. All of these are examples of files that can be opened and even edited in multiple applications, but where there can be distinct advantages in opening some files of that type in one application, and some in another. >> The exceptions I see are usually data-acquisition situations >> (including working with scanned images), where you use one program to get >> the file, and a second program to manipulate it. > >> In this situation, it >> makes far more sense to have a file-by-file preference, allowing styled >> text files to open in SimpleText by default, and other text files in >> BBEdit. > >In practice, I think Apple will probably add something like this, >probably in the form of a user-level database of file->app associations. A user-level database that *makes* a user specify preferences file-by-file, instead of letting the Type/Creator system handle it automatically? A system-level database that maintains an entire file-by-file list of exceptions, *on top of* the filesystem? Gaaaah. A Creator field would be much simpler, IMHO. >> >It's very easy for a multiuser OS to act like a single-user OS, as >> >NEXTSTEP did with the default 'me' user. The reverse is not true, and > >> I'm afraid it's your premise that's not true, as you and other NeXT users >> prove every time you use 'it can't be done that way on a multiuser OS' as >> an argument -- as you just did above. > >It's easy to do, within _reasonable_ constraints. The 'me' account is >quite good at fooling people into thinking the machine is a single-user >one. But once you start doing idiotic things like writing >information about which application should open a document directly into >the filesystem, Again, I think your prejudices towards a multiuser system are showing. It's only 'idiotic' -- not that I think it's even that -- in a multiuser setting, and IMHO makes a heckuva lot of sense in a single-user setting. This is exactly the sort of thing I was talking about, where a multiuser capacity that few will use should take second fiddle to making it better for single users. And really, it isn't even doing much to the *filesystem* -- just adding an extra field to a file record for holding creator information, which can then be used by the higher-level OS for anything you want. >then there's no hope of a multiuser system remaining a >multiuser system. If you put that kind of information in a _per-user_ >database, where it belongs, then things work perfectly fine and the user >is none the wiser. I see that as adding additional layers of complexity, which isn't even necessary for those people in a single-user situation. >> If many of the conveniences and >> operating methods that Mac users are used to can't be done on a multiuser >> OS, then it's obvious that a multiuser OS can't act like the Mac >> single-user OS. > >It's all a matter of efficiency. A multiuser OS can emulate a >single-user one just fine. Perhaps 'a' single-user one. But again, your own statements say that some things that I, at least, find beneficial in a single-user system can't be done in a multiuser system. You're sidestepping the issue: Can you do everything in a multiuser OS that Mac users can currently do in its single-user OS, without adding Byzantine levels of complexity? From what I'm seeing, the answer appears to be No. >> Not if it compromises Apple's traditional ease of use, and especially not >> if it's for a minority of users. > >And another thing. Stop pretending you speak for the majority. OK, this really annoys me. I'm not trying to get into a credentials duel here, but let me state where I'm coming from. I've been using Macs since 1984, and helped found the Kansas City Mac user's group. I worked for three years in the CS labs when I was going to college. After graduation, I spent two years doing computer graphics at a sillkscreening shop; after that, two years working phone tech support at APS Technologies, the hard drive company, which involved working with a *lot* of users from all across the board. I'm currently the computer specialist for a small Midwestern distributor, and do some part-time Mac support for a local ISP. I've worked with Macs a lot, obviously; I've also worked some with Windows machines, Unix machines, and even with a NeXT cube around 1990-91. I'd like to think that gives me a fairly broad base of experience, with the exception of large corporate settings; though I know it also brings in its own set of biases. Apologies for being blunt: The ONLY place I've seen prevalent attitudes similar to yours and other Unix/NeXT partisans was at the university, and among the technical staff at the ISP. They may be present in the corporate environments that I've had little experience with. But I have yet to see them held commonly, let alone as a majority, among individual/small business users or among the users I've done support for over the years. I'm not trying to be insulting, but how much experience have *you* had working with average users -- not in a university environment, and not computer specialists? >Mac users probably prefer the Mac way because it's the only thing they >know. Obviously false in my case, though admittedly I haven't used later versions of NeXTStep. >NEXTSTEP users generally have used NEXTSTEP _and_ Macs (or >something else). The fact that they still prefer the NEXTSETP way says >something. I don't have a very broad base to draw on, admittedly, because there is little or no NeXTStep presence in this region. <wry g> However, in response to a post a few weeks ago, I talked to someone who's as you describe. He said much the same thing, and that he picked up using the NeXT as a novice user -- but he also said that he was interested in the inner workings of the OS and in learning Unix when he started. My suspicion (based, I admit, mainly on the attitudes of NeXT partisans in these threads) is that the average NeXTStep user is technically proficient or is willing to become so, has an interest in computers beyond what it takes to get his job done (or has a job where interest in computers is the primary factor <g>), does not mind (or even prefers) using the CLI for some operations, and often runs high-end networking and/or server operations. How many of the people who "generally have used NEXTSTEP _and_ Macs" and prefer NeXTStep fit this profile? As I said above, the only places I've really seen this profile are in the university environment and in the tech staff at the ISP; it certainly doesn't fit the majority of users I've worked with on the support line. While I'm trying to keep an open mind, I'm afraid the technical bent of the NeXT proponents may be blinding them to the issues of working with Joe Average User. I've spent years doing support for Joe Average User, and I'm afraid he'll balk at some of the things NeXTStep users take for granted; moreover, I don't like the ideas of simply hiding the complexities of Unix under a GUI hood that have been tossed around, because my fear (fueled, admittedly, by occasional experiences in supporting Windows users) is that you can't hide them forever, and at some point Joe Average User is going to have to deal with them. <I know I'm probably gonna get objections from some other people who've done support; all I can say is that it's my experiences doing 2 years of hard drive support (which often includes a lot of OS support), occasional intra-company Windows support, and a year of part-time Internet support.> 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: younghoon KIL <ppai@soback.kornet.nm.kr> Newsgroups: comp.sys.next.hardware,comp.sys.next.programmer,comp.sys.next.software Subject: Re: bifrostworks link doesn't work... Date: Thu, 27 Feb 1997 00:57:33 +0900 Organization: KORNET Message-ID: <33145CF4.58C9@soback.kornet.nm.kr> References: <ndaniel1-1702971324350001@p9.ts15.metro.ma.tiac.com> <331062A4.2A19@soback.kornet.nm.kr> <ndaniel1-2302971814540001@p0.ts24.metro.ma.tiac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 7bit To: "Noah M. Daniels" <ndaniel1@swarthmore.edu> Noah M. Daniels wrote: >However, the bifrostworks link doesn't work... the domain does not > exist. I also tried bitfrostworks.com, in case you made a typo, but that > didn't work either. Any ideas? http://www.bifrostworks.com/ Now, They work. Please vist their web-site. younghoon KIL ppai@soback.kornet.nm.kr http://soback.kornet.nm.kr/~ppai (NEXTSTEP, OPENSTEP Q&A & Info Board written in Korean)
From: TH Fanning <fanning@ra.anl.gov> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 09:31:52 -0600 Organization: Argonne National Laboratory Message-ID: <33145768.42D7@ra.anl.gov> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <5ek5is$3d9@crl9.crl.com> <5erca9$m2@usenet.rpi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garance A Drosehn wrote: > [...] > Not sure how this effects your point, but as an aside I do think > the "defaults database" of NeXTSTEP works better than having every > application have it's own preference file... I completely disagree with this. What if I try tons of software, each one adding to my "defaults database", but then I delete these apps from my system. Wouldn't the database slowly grow over time? How do I "clean" it out? With separate files, I can just trash them. -- Tom Fanning mailto:fanning@ra.anl.gov ------------------------------------------------------------- Money can't buy happiness -- then again, neither can poverty.
From: melissab@shamu.mtn.ncahec.org Newsgroups: comp.sys.next.programmer Subject: objective c Date: Wed, 26 Feb 1997 10:50:13 -0500 Organization: Mountain AHEC Message-ID: <33145BB5.5F20@shamu.mtn.ncahec.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am a student researching object oriented languages, specifically objective c. I need some input from real world users! How you use objective c , which compiler, your opinion of the languages (like,dislike) , ease of use, and what application you are using it for etc...Per your permission I will use your name and affiliation in my paper plus your opinion of the product. Much thanks in advance! Melissa Boring
From: Joseph Panico <jpanico@online.disney.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.lang.objective-c Subject: Re: Objective C? Date: Wed, 26 Feb 1997 09:58:26 -0500 Organization: Disney Online Message-ID: <33144F92.4095@online.disney.com> References: <330E54AC.167E@innosys.com> <petrichE5zqx1.LCv@netcom.com> <5eo65r$53l@lal.interserv.com> <petrichE61n5I.DoK@netcom.com> <856715712.25573@dejanews.com> <5eqq6n$s7s@lal.interserv.com> <856776663.22260@dejanews.com> <5etptl$2tb@lal.interserv.com> <856930544.19004@dejanews.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit mark@oaai.com wrote: X-Article-Creation-Date: Wed Feb 26 04:15:44 1997 GMT X-Originating-IP-Addr: 199.166.28.100 (www.oaai.com) X-Http-User-Agent: Mozilla/2.0 (compatible; MSIE 3.01; Windows NT) X-Authenticated-Sender: mark@oaai.com Lines: 151 Xref: louie.disney.com comp.sys.mac.advocacy:190667 comp.sys.next.advocacy:54248 comp.sys.mac.programmer.misc:21543 comp.sys.next.programmer:27100 comp.lang.objective-c:5601 In article <5etptl$2tb@lal.interserv.com>, JamesCurran@CIS.CompuServe.com (James M. Curran) wrote: >This part interests me, since so far I've only been able to come up >with a couple pathological/textbook examples where the Objective C >method would be better than the C++ way. > >Could you (briefly) describe a example real-world problem where you >would choice Objective C over C++??? http://www.dejanews.com/ Search, Read, Post to Usenet I have a commercial c++ framework that handles and manipulates business objects. It passes and receives these objects in some type of container class that comes with the framework, let's call it Array. I want to customize the behaviour of that array with special types of sorting that are not supported out-of-the-box. I can't subclass Array, because it's already embedded in the framework and there are no hooks for telling the framework classes whiich container to use. Sooo... in c++ I have to perform the sorting external to the array. In other words, instead of myArray.elementsSortedByAlpha() I have to ask the array for all of its elements and then, somewhere in a controller like class, sort the array. So now I have code that operates on the state of the Array class living outside the Array class! How object oriented. Even better, when, in another app, I decide I need that same sorting behaviour on Array, since the sorting code didn't get added directly to Array, I now have to copy the sorting code into my next app. Reuse through cut-and-paste. In Obj-C, I can add methods to *existing* classes without subclassing. It's called Categories. I simply add the elementsSortedByAlpha method to the Array class, and then: [myArray elementsSortedByAlpha]. The sorting code is where it belongs, attached to the state on which it operates. Any time i use the the Array class I have access to it. This feature is very powerfull (and dangerous). By applying Categories to the root class, you can extend the behaviour of *all* objects in your system. In practice, this turns out to be immensely usefull (hardly pathological) and has allowed Next to cleanly and elegantly implement things that would be very messy in c++. Obj-C supports, IMHO, better design than c++. There are many other features of Obj-C that one could argue are superior to c++ (varying not only the receiver, but also the message, at run-time: dynamic method invocation/ a deep sense of introspection). I used Categories because it is the one extremely usefull feature that Obj-C has but Java is missing (though in the balance, I think Java wins). I wouldn't be inclined to compare a dynamic language like Obj-C to c++-- it's a difficult comparison. Compare it with other dynamic languages like Java. -- Joe Panico Disney Online jpanico@online.disney.com
From: Joseph Panico <jpanico@online.disney.com> Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Date: Wed, 26 Feb 1997 10:05:02 -0500 Organization: Disney Online Message-ID: <3314511E.27F0@online.disney.com> References: <331ad8fe.1061430@news.nai.net> <5f0tdo$73u$1@news.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Don Yacktman wrote: wef@ct2.nai.net wrote: > I am interested in knowing what the unbiased opinion it out there... > I am considering pouring alot of my resources into a programming > education and career. In order to maximize the world of programming > these days, one must weigh the difference between C++ and Java. > Please choose you pick and tell me why you think it is the way to go. Boy will this start a holy war... Well, here's my $0.02, all IMHO of course: First, since you posted to a NeXT group, I'd say "learn Objective-C". :-) If you must pick between those other two, learn Java first. There are enough similaries between the languages that you can actually jump from one to the other pretty easily once you've mastered the underlying concepts. So, to master OOP, IMHO go with Objective-C, Java, and C++ is the order of ease--with C++ it is too easy to get bogged down in details and lose the OO perspective. Java is pretty much middle ground. (Oversimplified, it is C++ syntax with Objective-C semantics underneath) I think that you'll find that same order is also easiest->hardest for learning the syntax and getting a grip on the class libraries used in the respective environments. But, politically, the "hot" order would be Java, C++, and Objective-C, though a conservative person would go C++, Java, Objective-C since C++ is so entrenched...and is likely to live a long time, as the Cobol of the 90s. Then again, it is pretty easy right now to get a job doing Java or Objective-C because so few people know the technologies. :-) So I guess you have to decide what factors matter most to you--value of the skill, conservative security, "hot" factor, ease of learning, etc. My skills went Basic -> Assembly (6502)-> Pascal -> C -> Objective-C -> C++ -> Java (with 680x0 and x86 assembly thrown in for good measure somewhere) The biggest jumps conceptually were to assembly and Objective-C, as far as the underlying concepts go. I glad I did the OO jump with Objective-C and not C++, or I would have not learned OO very well, I suspect. Syntax wise, C++ is still a bitch and I hate using it. Java is a cakewalk with the others as a background. I don't see any reason why you should have to limit yourself to a single language, though. Grab a few good books and just dive on in. The more languages you know, the more marketable you are, because your ability won't be tied to a single language's quirks; you'll understand the "big picture" better and be a better programmer for it. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a> Explicit memory management (malloc,free,lack of gc,), non object structures (structs, unions, etc), pointers, name-space collisions. Don, I'm not sure why Obj-C would be a better paragon of OOP. I would certainly agree that Obj-C does a number of things better than Java, but one could easily argue that there are a larger number of things that Java does better than Obj-C. Of course, I fully agree with your primary assertion-- you shouldn't even bother comparing c++ with dynamic languages like Obj-C and Java. c++ isn't in that league. -- Joe Panico Disney Online jpanico@online.disney.com
From: Steve Barnet <"mailer-daemon"@[127.0.0.1]> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 11:09:34 -0600 Organization: UW-Madison Space Science and Engineering Message-ID: <5f1qoe$8dp@spool.cs.wisc.edu> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Travis Butler wrote: > [snip] > > I know a few used by multiple people in homes, granted -- but I only know > of one who *wanted* multiuser login and security features, and his needs > were handled by At Ease. In fact, that's exactly the model I think *should* > be used for multiple users on a *personal* computer: make the OS optimized > for individual users, who in my experience make up the majority of personal > computer users, and make multiuser login/security features an OPTIONAL > add-in for those who need it. > > In the places I've worked at (see below), with the exception of the > computer labs -- once in a while someone will need to use someone else's > machine, and trainees worked alongside their 'mentors' on their machines, > but by and large everyone has their own computer. > > >And there are still good > >reasons for having a multiuser machine even if only one person uses it. > > Why? Again, why cripple a single user's experience for multiuser support > that is never used? > [snip] It may be time to draw the distinction between multi-user and multi-tasker systems. I suspect that Travis is correct in his assupmtion that for most Mac users a multiple-user system is not a requirement or a necessity. I also suspect that if you ask the average Mac user whether they need preemptive multi-tasking they'll say no (after looking a bit confused). Same with memory protection. However, if you ask them whether they'd whether they'd like a more stable system with fewer chances of extensions conflicting or apps not playing nicely with each other they'd say yes. They don't particularly care that the mechanisms are PMT and memory protection. [snip] > Perhaps 'a' single-user one. But again, your own statements say that some > things that I, at least, find beneficial in a single-user system can't be > done in a multiuser system. You're sidestepping the issue: Can you do > everything in a multiuser OS that Mac users can currently do in its > single-user OS, without adding Byzantine levels of complexity? From what > I'm seeing, the answer appears to be No. > [snip] I don't think it's necessarily impossible, but it will be necessary to change some of the underlying assumptions in the system design. In some cases this may result in changes that are visible to the user. This is not necessarily a bad thing. If the advantages outweigh the disadvantages (in the eyes of the average user), such changes can be accepted with relatively little outcry. It seems to me that the real issues that must be addressed are related to interoperability. This is really the root of the ongoing filesystem flame war. If Apple is willing to relegate itself to the home user and nothing else, the file structure is irrelevant. They have only to remain consistent with themselves. If, on the other hand, they would like to penetrate corporate environments and grab an appreciable chunk of the server market, they will have to make some hard choices. UNIXish systems dominate the server market and Wintel pretty well has a hammer lock on the desktop. If they want to gain market share in those markets, they will have to play nicely with others even if the Mac offers superior solutions in certain places. In some cases, playing nicely may mean nothing more than a lot more work for Apple engineers (ie they have to write code to integrate the Mac way with that of the heathen unbelievers). Everyone's happy. In other cases, however, it may be necessary to change some fundamentals (ie two fork files may have to go the way of the dinosaur). Now the longtime Mac users are not happy because things changed visibly. So if you're Apple, what do you do? If you want to stay alive as a company you preserve as much as you can of your superior technology, but sacrifice where you have to to make interoperability painless. Those choices are not easy and it can be difficult to tell into which category a particular choice falls, but that is what it will boil down to in the end. My .02 monetary units Best, ---Steve -- Steve Barnet--System Administrator steve.barnet@ssec.wisc.edu UW-Madison Space Science and Engineering Center I'm not a rocket scientist, but I play one on TV (608)263-2268
From: yannick buisson (université de La Rochelle) Newsgroups: comp.sys.next.programmer Subject: access adaptor Date: 26 Feb 1997 17:19:47 GMT Organization: Universite de La Rochelle Message-ID: <5f1rbj$fsn@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi all, Just a little question about access adaptor .. With OpenStep, we have the possibility to make our applications running on NT. Does someone work on an access adaptor ? Does someone have any informations about that ? thanks for your answers ... YANNICK -- //// (. .) ----oOO--(_)--OOo-------------------------------------------- Yannick BUISSON Centre de Ressources Informatiques Université de La Rochelle tel prof. : 46 45 82 14. fax prof. : 46 45 82 45. yannick@cri.univ-lr.fr
From: nurban@sps1.phys.vt.edu (Nathan Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 26 Feb 1997 12:39:09 -0000 Organization: Virginia Polytechnic Institute and State University Message-ID: <5f1atd$tj@sps1.phys.vt.edu> References: <5ddp66$jpc@news.bu.edu> <peterm.856338754@ulfrun> <5ejcd4$oij@usenet.rpi.edu> <3313D7B1.639F@fapse.unige.ch> In article <3313D7B1.639F@fapse.unige.ch>, johnston@fapse.unige.ch wrote: > Garance A Drosehn wrote: > > There is no good reason that the user would spend any time or energy > > remembering extensions. > Not a hard task, but one that many many users can't (or don't) master. I think someone else may have already suggested this, but it shouldn't be hard to modify the File Viewer so that if you select a filename in order to change it, it only selects the non-extension portion and won't allow you to select any part of the extension. (Allowing you to change the extension could be lumped in the "Unix Expert" mode in Preferences or something.) -- -------------------------------------------------------------------------- Nathan Urban | Undergrad {CS,Physics,Math} | Virginia Tech nurban@vt.edu | {NeXT,MIME} mail welcome | http://nurban.campus.vt.edu/ --------------------------------------------------------------------------
From: yannick buisson (université de La Rochelle) Newsgroups: comp.sys.next.programmer Subject: PAScrollViewDeLuxe Date: 26 Feb 1997 17:26:41 GMT Organization: Universite de La Rochelle Message-ID: <5f1roh$fsn@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi, I am looking for the PAScrollViewDeLuxe palette. Does someone know where i can find it ?? Or can some send it to me by mail ... thanks for your help YANNICK -- //// (. .) ----oOO--(_)--OOo-------------------------------------------- Yannick BUISSON Centre de Ressources Informatiques Université de La Rochelle tel prof. : 46 45 82 14. fax prof. : 46 45 82 45. yannick@cri.univ-lr.fr
From: ians@cam-ani.co.uk (Ian Stephenson) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 16:50:03 GMT Organization: Cambridge Animation Systems Ltd Sender: news@cam-ani.co.uk Message-ID: <E67yrG.HD@cam-ani.co.uk> References: <33145768.42D7@ra.anl.gov> In article <33145768.42D7@ra.anl.gov> TH Fanning <fanning@ra.anl.gov> writes: > Garance A Drosehn wrote: > > > [...] > > Not sure how this effects your point, but as an aside I do think > > the "defaults database" of NeXTSTEP works better than having every > > application have it's own preference file... > > I completely disagree with this. What if I try tons of > software, each one adding to my "defaults database", but > then I delete these apps from my system. Wouldn't the > database slowly grow over time? How do I "clean" it > out? With separate files, I can just trash them. In practise this isn't a problem, as the entries that go in the defaults database are small (larger amounts of data tend to get created in ~/Library). They can be deleted (or edited) using Defaults.app. However thats not to say that the database couldn't or shouldn't be organised as a series of files - infact thats probably a good way of doing it. The important thing is the programmer api which manipulates the db. How the db s stored is not important. The trick is that theres a neat easy to use interface which stores the preferences in a manner which is standard, and largely hidden from the user (but available for manipulation by experiences users). As such it IS better than the Mac system where apps create files in system/Preferences, but not because of the file format it uses. $an
From: mpaque@wco.com (Mike Paquette) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 26 Feb 1997 10:18:23 -0800 Organization: Electronics Service Unit No. 16 Sender: mpaque@mpaque Distribution: world Message-ID: <5f1upf$e8@mpaque.mpaque> References: <SHESS.97Feb25125500@howard.one.net> [Much ado about inode changes deleted] Just a reminder. If you modify the Unix FS used on the local disk to add type/creator information to the inode, it's guaranteed that this information will not be expressed or preserved over industry standard networking mechanisms without inserting Mac-specific mechanisms. In effect, you would reproduce the current situation. While this might be OK for standalone use, network interoperability would require the use of Mac-specific tools and some 'special education' of IS staff to export and share Mac documents over the network, just as with the current Mac products. While Macintosh advocates can and do point out that such tools exist, IS management sees this as an additional support burden in hetrogenous networks, and may resist adaptation of the Macintosh platform. It's up to Apple's Engineering team to design a solution which preserves and enhances the Macintosh experience, while removing the perceived barriers to using the Mac in hetrogenous networks. -- I don't speak for my employer, whoever it is, and they don't speak for me. mpaque@next.com Official business only NeXT Mail OK mpaque@wco.com Non-business or personal mail NeXT mail OK
From: nurban@sps1.phys.vt.edu (Nathan Urban) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 26 Feb 1997 12:50:09 -0000 Organization: Virginia Polytechnic Institute and State University Message-ID: <5f1bi1$105@sps1.phys.vt.edu> References: <5ddp66$jpc@news.bu.edu> <5ejgug$oij@usenet.rpi.edu> < <kluev-2602971519000001@kluev.macsimum.gamma.ru> In article <kluev-2602971519000001@kluev.macsimum.gamma.ru>, kluev@macsimum.gamma.ru (Michael Kluev) wrote: > People, remember, that HFS maintains other useful information > (called user or Finder info). I am talking about current scroll > position for directories, icon position for items, etc. The NEXTSTEP Workspace maintains this information in a user database, as they are not things that should really be directly associated with the files right in the filesystem -- they pertain to _visual representations_ of the files. > Speaking about "... doesn't work well in multiuser environment". > If you buy this argument (and I do to some extent), than you > should buy the following: the field that holds "last access time" > in the file information doesn't work well on read only media. > (In fact it doesn't work at all on read only media.) Current > (future?) Mac users do encounter "read only media" much often > than "multiuser environment". Thus this field should be stripped. No, that's silly. Then it wouldn't exist for nonremovable media, either. With removable media, the field can either be ignored, or you can use a different filesystem without that field. The point is that it is a bad idea to store information about which application with which to open a file directly in the filesystem with the file, as different users will have different preferences. However, the creator of a file is an absolute and does not depend on the user, so there is nothing intrinsically wrong with placing that information in the filesystem, even with in multiuser environment. What people are really objecting to, and may not be expressing themselves clearly over, is the restriction of opening files by creator, no matter what the user's individual preference is. I _don't_ want to open my JPEGs with whatever app someone used to create them, I want to use my JPEG viewer. > Traditional symbolic links don't work for Mac users. Mac users > are creatures that like to drag things around as paper clips on > their desk, screwing up paths in symbolic links. It wouldn't be hard to modify the move operation so that if you moved a file, it would leave a symbolic link to the new location in the old location. If you were so inclined. I happen to not like HFS's file-by-reference technique, I think that the filesystem has a namespace precisely as a mechanism for identifying files. The preferences of others may differ. > 1. What file/directory management API is there in the Next? > Is it path based? Is it like: > "open("dir/subdir1/subdir2/subdir3/subdir4/file"? Yes. > 2. Is Next File system crash-safe? (Crash = turning power off here.) No, thankfully. Unix caches a lot of file information in memory and gets much better effective I/O performance that way. If power is interrupted, it will fsck the disk at the next boot time and try to recover things, but some information may be lost. -- -------------------------------------------------------------------------- Nathan Urban | Undergrad {CS,Physics,Math} | Virginia Tech nurban@vt.edu | {NeXT,MIME} mail welcome | http://nurban.campus.vt.edu/ --------------------------------------------------------------------------
From: Gary Zhang <gzhang@ix.netcom.com> Newsgroups: comp.sys.next.programmer Subject: Kaffe Compile Problem Date: Wed, 26 Feb 1997 11:59:59 -0500 Organization: Bankers Trust Company Message-ID: <33146C0E.2F2D@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Has anyone successfully compiled Kaffe 0.8.1 on a 68K NeXT Station running User 3.3/ Developer 3.2? I already compiled the latest "gcc" but even with that I'm still getting an error during the build of Kaffe. Specifically it says can not find file called "external_native.h". I modified the make file and disabled the "NOSHARED_LIBRARY" (can't remember the exact name) so the compiler no longer looks for that header file. That fixed the problem but I later got tons of other error messages! I'd really appreciate any help on this one. Thanks. Oh, by the way, I downloaded a compiled version of Kaffe but it truns out to be the Intel version. Does any one have a version for the 68K? Thanks again.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Date: 26 Feb 1997 19:14:44 GMT Organization: Global Objects Inc. Message-ID: <5f2234$fge$1@news.xmission.com> References: <331ad8fe.1061430@news.nai.net> <5f0tdo$73u$1@news.xmission.com> <3314511E.27F0@online.disney.com> Joseph Panico <jpanico@online.disney.com> wrote: > Explicit memory management (malloc,free,lack of gc,), non object > structures (structs, unions, etc), pointers, name-space collisions. But how much of those do you use if you are using OPENSTEP? You have -retain/-release instead of GC, and there are arguments either way as to which is better; I prefer true GC myself. But the rest isn't touched _too_ often. And you're trading pure OO for efficiency/speed in most cases. If you just concentrate on the OO side, though, you do stand a good chance of learning good OO practices. > Don, > I'm not sure why Obj-C would be a better paragon of OOP. I would > certainly agree that Obj-C does a number of things better than Java, but > one could easily argue that there are a larger number of things that > Java does better than Obj-C. I think I feel this way because of the literature out there. I you want to learn about Obj-C you pretty much have to read the NeXT book. It teaches the OOP concepts in a good way, IMHO, and teaches you the benefits and uses of dynamism, so that you can use OOP _right_, right from the start. On the other hand, nearly all the books I've seen on Java take a static approach--obviously written by people entrenched in C++ that don't understand dynamism. The "examples" I've seen in the books--and I've read a LOT of them by know--for the most part are the crappiest examples of OOA/OOD that I've ever seen. The small amount of literature on Obj-C puts these books to shame. So, if you try to learn Java, you'll miss most of the beauty of the language because your "teacher" won't be qualified to do the job. If you go the Obj-C route, you'll learn OO right since the only teachers out there (few though they may be) will do the job right. We see the good in Java because we come from the dynamic point of view--people coming from C++ really miss half the beauty of that language because of a poor foundation. A "newbie" coming in and reading the Java books out there will get the (inferior) C++ point of view. Sure you can use the language as if it were static, but you lose half the elegance if you do. If there are any actually good Java books out there, then perhaps it could do better to start a person off on the OO path than Obj-C. The two languages have such similar semantics that which is better is probably shades of difference and opinion more than anything else. I guess if you *really* want to get OO concepts down right, though, you should go with SmallTalk. Going from there to Obj-C or Java shouldn't be hard at all, except for syntax differences, which can be learned quickly anyway. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 14:17:56 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <sn58lYu00iVC08QTQD@andrew.cmu.edu> References: <5ddp66$jpc@news.bu.edu> <32FAB1C7.3AE4@pharmacology.unimelb.edu.au> <5dqhrc$pm8@news.bu.edu> <3300D85D.2DC9@subsequent.com> <5dtpb5$h4t@news.bu.edu> <33029F59.5E8D@subsequent.com> <330324FB.E67@cygnus.com> <3302E06E.8D@subsequent.com> <5ek5is$3d9@crl9.crl.com> <5erca9$m2@usenet.rpi.edu> <33145768.42D7@ra.anl.gov> In-Reply-To: <33145768.42D7@ra.anl.gov> Excerpts from netnews.comp.sys.next.programmer: 26-Feb-97 Re: Mac/NeXT & Unix: File S.. by TH Fanning@ra.anl.gov > > Not sure how this effects your point, but as an aside I do think > > the "defaults database" of NeXTSTEP works better than having every > > application have it's own preference file... > > I completely disagree with this. What if I try tons of > software, each one adding to my "defaults database", but > then I delete these apps from my system. Wouldn't the > database slowly grow over time? Yes, it does. After about 5 years of owning a NeXT, my defaults database has roughly 1000 items in it. The entries are comprised of three elements: owner (ie, the application name), property, and value. > How do I "clean" it out? With separate files, I can just trash them. There are GUI tools like DefaultsMgr which allow you to easily remove all properties associated with a particular app. Most NeXT users never notice or care that there are unused entries. You don't have to worry about cleaning it out if you don't want to. There isn't enough information in the defaults DB that it's significant. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Coty Rosenblath <coty@pobox.com> Newsgroups: comp.sys.next.programmer Subject: Re: access adaptor Date: Wed, 26 Feb 1997 15:00:28 -0500 Organization: Solutions by Design Message-ID: <3314965C.35D0@pobox.com> References: <5f1rbj$fsn@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: université de La Rochelle <"\"yannick buisson\""@pobox.com> université de La Rochelle wrote: > > Hi all, > > Just a little question about access adaptor .. > > With OpenStep, we have the possibility to make our applications running on NT. > Does someone work on an access adaptor ? > > Does someone have any informations about that ? > > thanks for your answers ... > I use the ODBC adaptor to connect to Access databases under NT with some success. Cheers, -- Coty Rosenblath Solutions by Design Atlanta, GA <coty@pobox.com>
From: "Jeffrey S. Dutky" <dutky@wam.umd.edu> Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Date: Wed, 26 Feb 1997 15:34:30 -0500 Organization: University of Maryland Student Body Message-ID: <33149E1A.6D4A@wam.umd.edu> References: <331ad8fe.1061430@news.nai.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit wef@ct2.nai.net wrote: > > Hello, > > I am interested in knowing what the unbiased opinion it out there... > I am considering pouring alot of my resources into a programming > education and career. In order to maximize the world of programming > these days, one must weigh the difference between C++ and Java. > Please choose you pick and tell me why you think it is the way to go. > > Thanks in advance, > Bill As a student in computer science myself I would suggest that you learn C++ first. I am not saying that C++ is better than Java (or, since you have posted to a NeXT programming group, Objective-C) but that, as a student, you will find that C++ is the language of choice for most courses in colleges today. What it all comes down to, for me, is that the school I attend requires that I learn C++ in order to get the degree. Further, almost all universities and junior colleges offer courses in C++ but very few offer courses in Java or Objective-C. As a student you will find it very easy to enrol in a course on C++ while finding courses on the other languages will be much harder. As a final note, once you have learned C++ you should have a pretty reasonable grasp of C and Object-Oriented Programming (OOP) so that picking up Java or Objective-C (which are both based on C syntax) will be MUCH easier. -Jeff Dutky
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: 26 Feb 1997 21:46:37 GMT Organization: Global Objects Inc. Message-ID: <5f2avt$fge$2@news.xmission.com> References: <al.856919430@BIX.com> <nagleE66yn1.KA@netcom.com> <3313c6ab.20970787@news.alt.net> <petrichE67wqo.LA8@netcom.com> <maury-2602971618300001@199.166.204.230> maury@softarc.com (Maury Markowitz) wrote: > In article <petrichE67wqo.LA8@netcom.com>, petrich@netcom.com (Loren > Petrich) wrote: > > > Easier programming: the NeXT API makes it *very* easy to do GUI > > stuff; with the Interface Builder, one can attach GUI elements to various > > object methods -- for example, one can attach a button to calling some > > function or other by simply dragging and dropping. > > What exactly happens when you do this though? Does it do something like > put a function pointer into a field in the button object? Or is there a > layer of indirection between the two? Control classes have two instance variables, "target" and "selector", which are being affected in this case. The target is of type "id" and can point to any object. The selector is of type "SEL" and can sort of be thought of as analogous to a function pointer--but that isn't quite what it is. You can get a selector several ways; the most common is to use the compiler directive @selector like this: SEL aSel = @selector(makeKeyAndOrderFront:); Which sets it to the "makeKeyAndOrderFront:" method. When the button is clicked, it uses the -perform:with: method to send a message to the target, like this: [target perform:selector with:self]; Note that because of the runtime, the selector is NOT a function pointer because the function that will be called depends upon the class of the target of the message. Of course, InterfaeBuilder is allowing, via the connection mechanism, the editing of the selector and target instance variables. Because selectors are based on hashed unique strings within the runtime, it is possible to assign selectors to the button objects even if there is currently no object in the runtime that responds to that particular selector! This is what allows you to short-circuit the compile process with InterfaceBuilder. It also becomes incredibly useful when loading bundles, etc. The button class doesn't have to know *anything* at all about the target in order to send the message, and you can configure it to send any sort of message whatsoever. The only real way to approach this sort of ability in C++ is to either add your own runtime to it or use the Command pattern (which requires compilation of a special class for nearly every selector / target pair you plan to use). By the way, while target/action is nice for some things, it has a lot of limitations, too. MVC is much more general and IMHO is a better approach. Where Obj-C shines is in both simplifying and generalizing the "C" (controller) part of "MVC". EOF is a great practical example of this. -- 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.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: Wed, 26 Feb 1997 16:18:14 -0500 Organization: SoftArc Inc. Message-ID: <maury-2602971618300001@199.166.204.230> References: <al.856919430@BIX.com> <nagleE66yn1.KA@netcom.com> <3313c6ab.20970787@news.alt.net> <petrichE67wqo.LA8@netcom.com> In article <petrichE67wqo.LA8@netcom.com>, petrich@netcom.com (Loren Petrich) wrote: > Easier programming: the NeXT API makes it *very* easy to do GUI > stuff; with the Interface Builder, one can attach GUI elements to various > object methods -- for example, one can attach a button to calling some > function or other by simply dragging and dropping. What exactly happens when you do this though? Does it do something like put a function pointer into a field in the button object? Or is there a layer of indirection between the two? Maury
From: "zarf" <zarf@zarfism.com> Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer Subject: Yes Steve, I will have some Koolaid, thank you! Date: 26 Feb 1997 21:31:24 GMT Organization: zarfism Message-ID: <01bc242c$6ae6c1c0$a67797cd@metnews.hip.cam.org> So - what hurdles do I have to jump to be able to get the Rhapsody developer releaser coming this summer? I realize you must join some Apple developer program - but aren't there different levels - is it known who is entitled to get their hands on the Rhapsody developer release? And is that an additional cost - or does the developer registration cover that?
From: Eric_Noyau@next.com (Eric Noyau) Newsgroups: comp.sys.next.programmer Subject: Re: fetch and qualifier with EOF2.0 and OpenStep 4.0 Date: 26 Feb 1997 21:47:25 GMT Organization: NeXT Software, Inc. Message-ID: <5f2b1d$g7c@news.next.com> References: <5eubir$hok@hpuniv.univ-lr.fr> In article <5eubir$hok@hpuniv.univ-lr.fr> yannick buisson (universit de La Rochelle) writes: > > just a little question about fetch and qualifier with EOF2.0 ! > Can someone give me an example where i can find a qualifier and > a fetch !!! > /NextDeveloper/Examples/EnterpriseObjects -- Eric
From: "Lawson English" <english@primenet.com> Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: 26 Feb 1997 15:32:01 -0700 Organization: Primenet Services for the Internet Message-ID: <AF3A0B9D-182556@198.68.42.200> References: <5f2avt$fge$2@news.xmission.com> nntp://news.primenet.com/comp.sys.next.programmer Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Don Yacktman <don@globalobjects.com> said: >The only real way to approach this sort of ability in C++ is to >either add your own runtime to it or use the Command pattern (which requires >compilation of a special class for nearly every selector / target pair you >plan to use). Where do you get this last? The whole idea of a Command pattern would be to avoid needing a special class. In fact, such patterns are used extensively in PowerPlant, via a generic mix-in. ------------------------------------------------------------------------- Windows: Tumor-causing, teeth-staining, smelly, puking habit. -------------------------------------------------------------------------
From: "Carl A. Carlson" <ccarlson@primenet.com> Newsgroups: comp.sys.next.programmer Subject: Required reading for Mac programmer? Date: 26 Feb 1997 15:12:03 -0700 Organization: Primenet Services for the Internet Message-ID: <331453CE.28D2@primenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: I'm a Mac programmer. My NeXT station with OpenStep is due any day. I won't be getting any hard copy documentation. I understand there is lots of online doc. What should I read, and in what order should I read it to get up to speed on using the operating system and programming in OpenStep? Any recommended books? Thanks, Carl Carlson
From: frank@this.NO_SPAM.net (Frank M. Siegert) Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Date: 26 Feb 1997 22:58:53 GMT Organization: Frank's Area 51 Message-ID: <5f2f7d$19j@bias.ipc.uni-tuebingen.de> References: <331ad8fe.1061430@news.nai.net> <33149E1A.6D4A@wam.umd.edu> Cc: dutky@wam.umd.edu In <33149E1A.6D4A@wam.umd.edu> "Jeffrey S. Dutky" wrote: > ... > As a final note, once you have learned C++ you should have a pretty > reasonable grasp of C and Object-Oriented Programming (OOP) so that > picking up Java or Objective-C (which are both based on C syntax) > will be MUCH easier. > I don't think so. Go with Java is my advice. Much cleaner, a much better way to understand the foundation. -- * Frank M. Siegert [frank@this.net] - Home http://www.this.net * NeXTSTEP, Linux, BeOS & PostScript Guy * C++ is to C as lung cancer is to lung
From: Ian Joyner <i.joyner@acm.org> Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: Thu, 27 Feb 1997 08:38:48 +1100 Organization: Unisys Message-ID: <3314AD68.5B51@acm.org> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> <Un3Q9l_00iVC022esD@andrew.cmu.edu> <33138B25.B5F@acm.org> <Mn4w7wm00iVCIHHMVm@andrew.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles William Swiger wrote: > I don't see any point to discussing this further. The first sensible thing you have said in a long time. The reasons are though that you will never change your mind, you will keep introducing irrelevancies, you just keep arguing round in circles. You have brought internet exchanges to a new low. My suggestion that OS interfaces should be re-evaluated so that the OS was contracted to manage and provide resources, and rectify problems with the said resources before just handing exceptions back to applications, because this vastly simplifies application development, and that Unix does not generally do this, but I know a practical OS that does, was responded by you attacking me of being biased, bigoted and stupid. You then introduced many irrelevancies, like deadlock, showed you did not really understand these. You confused producer/consumer with RPC, introduced some very spurious mathematical induction, then threw in non-determinacy, and continued your insults at a very personal level, persisted in raw contradition. You inserted your own mistaken interpretation of my words and then saying my suggestions were flawed is completely obnoxious. For example: "Your design suggestion that the OS should always consult a human operator even when minor..." you gratuitously introduced "always". If you read what I was suggesting carefully, you would realise your interpretation was wrong, but then you argue against me on the basis of your mistaken interpretation. This has not been a pleasant internet exchange. But for all of it, you have failed to show that my original insight was wrong. End of thread. ------------------------------------------------------------------------ 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: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: Wed, 26 Feb 1997 18:36:21 -0500 Organization: SoftArc Inc. Message-ID: <maury-2602971836370001@199.166.204.230> References: <al.856919430@BIX.com> <nagleE66yn1.KA@netcom.com> <3313c6ab.20970787@news.alt.net> <petrichE67wqo.LA8@netcom.com> <maury-2602971618300001@199.166.204.230> <5f2avt$fge$2@news.xmission.com> In article <5f2avt$fge$2@news.xmission.com>, don@globalobjects.com wrote: > Note that because of the runtime, the selector is NOT a function pointer > because the function that will be called depends upon the class of the target > of the message. I think my next question comes in at this point or close to it: where does one wire in OSA to record these messages? It appears easy enough for OSA to send out events to the objects by maintaining a record of OSA keywords (like "Window") and the object methods to call, I'm sure OpenStep already has something like this for direct invocations in the programs themselves. But OSA also allows for the reverse, for applications to capture these events back out where they can be looked at as a script in any OSA scripting language (Perl or AppleScript for instance). Is this something the OpenStep system currently includes? Maury
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: 26 Feb 1997 23:09:50 GMT Organization: Global Objects Inc. Message-ID: <5f2fru$fge$3@news.xmission.com> References: <5f2avt$fge$2@news.xmission.com> <AF3A0B9D-182556@198.68.42.200> "Lawson English" <english@primenet.com> wrote: > Don Yacktman <don@globalobjects.com> said: > >The only real way to approach this sort of ability in C++ is to > >either add your own runtime to it or use the Command pattern (which > requires > >compilation of a special class for nearly every selector / target pair you > > >plan to use). > > Where do you get this last? > > The whole idea of a Command pattern would be to avoid needing a special > class. In fact, such patterns are used extensively in PowerPlant, via a > generic mix-in. When you're statically bound, you have to create a custom binding in code for each function you plan to call or else the linker will complain. They way around that is with a runtime. Most of the tools for C++ implement, to some degree, a primitive runtime. Without a runtime, you simply don't get the same mix of simplicity and flexibility. -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Required reading for Mac programmer? Date: Wed, 26 Feb 1997 19:28:52 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <8n5BJ4G00iV90EY5xq@andrew.cmu.edu> References: <331453CE.28D2@primenet.com> In-Reply-To: <331453CE.28D2@primenet.com> Excerpts from netnews.comp.sys.next.programmer: 26-Feb-97 Required reading for Mac pr.. by "Carl A. Carlson"@primen > I'm a Mac programmer. My NeXT station with OpenStep is due any day. I > won't be getting any hard copy documentation. I understand there is > lots of online doc. What should I read, and in what order should I read > it to get up to speed on using the operating system and programming in > OpenStep? Any recommended books? The tool of choice is NeXT's Librarian.app. It has a variety of default bookshelves for various user types including developers and sysadmins. You'll probably want to read most of what's in the Concepts target (don't bother with the DatabaseKit until later, though) and Foundation. After that, the Developer Release Notes are good to scan through, and the User Interface guidelines might give you another perspective on how to design good user interfaces that should combine with your knowledge of the Mac style guidelines. Run through the IB tutorials, take a look at the various examples in /NextDeveloper/Examples, and use the General Reference target while searching to see what various object classes are. Definitely read the docs for Object and NSObject. -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: font@MCS.COM (Font) Newsgroups: comp.sys.next.programmer Subject: Re: Kaffe Compile Problem Date: 26 Feb 1997 18:50:48 -0600 Organization: MCSNet Services Message-ID: <5f2lp8$bpi$1@Venus.mcs.net> References: <33146C0E.2F2D@ix.netcom.com> Gary Zhang <gzhang@ix.netcom.com> writes: >Has anyone successfully compiled Kaffe 0.8.1 on a 68K NeXT Station >running User 3.3/ Developer 3.2? I already compiled the latest "gcc" but >even with that I'm still getting an error during the build of Kaffe. >Specifically it says can not find file called "external_native.h". I >modified the make file and disabled the "NOSHARED_LIBRARY" (can't >remember the exact name) so the compiler no longer looks for that header >file. That fixed the problem but I later got tons of other error >messages! I'd really appreciate any help on this one. Thanks. >Oh, by the way, I downloaded a compiled version of Kaffe but it truns >out to be the Intel version. Does any one have a version for the 68K? >Thanks again. An identical error message results from attempts to compile kaffe out of the box on i386 as well. Some discussion of this (with no solutions) appeared in comp.sys.next.software recently with "Java" in the subject line. In sum, kaffe's NEXTSTEP support is broken, but it's probably the case that the author doesn't have a machine to test things out on. -- font@mcs.net Wishes are like dishes.
From: mkagalen@lynx.dac.neu.edu (Michael Kagalenko) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.advocacy,comp.sys.mac.programmer.misc,comp.sys.next.programmer,comp.lang.objective-c Subject: Re: Objective C? Date: 26 Feb 1997 14:56:42 -0500 Organization: Northeastern University, Boston, MA. 02115, USA Message-ID: <5f24hq$ba6@lynx.dac.neu.edu> References: <330E54AC.167E@innosys.com> <5etptl$2tb@lal.interserv.com> <856930544.19004@dejanews.com> <tz8k9nwuijr.fsf@aimnet.com> Content-Type: text/html Thomas (nouser@nohost.nodomain) wrote in article <tz8k9nwuijr.fsf@aimnet.com> <pre><blink> ]On that note, do people know of any packages that interface ]Objective-C to COM/OLE/ActiveX? D'OLE comes with OPENSTEP 4.1 -- ABILITY,n. The natural equipment to accomplish some small part of the meaner ambitions distinguishing able men from dead ones. -- Ambrose Bierce, "The Devil's Dictionary"
From: mkagalen@lynx.dac.neu.edu (Michael Kagalenko) Newsgroups: comp.sys.next.programmer,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Date: 26 Feb 1997 15:03:14 -0500 Organization: Northeastern University, Boston, MA. 02115, USA Message-ID: <5f24u2$ri5@lynx.dac.neu.edu> References: <5ddp66$jpc@news.bu.edu> < <kluev-2602971519000001@kluev.macsimum.gamma.ru> <5f1bi1$105@sps1.phys.vt.edu> Content-Type: text/html Nathan Urban (nurban@vt.edu) wrote in article <5f1bi1$105@sps1.phys.vt.edu> <pre><blink> ]In article <kluev-2602971519000001@kluev.macsimum.gamma.ru>, kluev@macsimum.gamma.ru (Michael Kluev) wrote: ] ]> 2. Is Next File system crash-safe? (Crash = turning power off here.) ] ]No, thankfully. I don't think "thankfully" is the appropriate word here. ] Unix caches a lot of file information in memory and ]gets much better effective I/O performance that way. If power is ]interrupted, it will fsck the disk at the next boot time and try to ]recover things, but some information may be lost. It is incorrect to state this as true for all flavours of UNIX filesystems. -- ABILITY,n. The natural equipment to accomplish some small part of the meaner ambitions distinguishing able men from dead ones. -- Ambrose Bierce, "The Devil's Dictionary"
From: nurban@sps1.phys.vt.edu (Nathan Urban) Newsgroups: comp.sys.next.programmer Subject: Re: C++ or JAVA which is best??? Followup-To: comp.lang.objective-c Date: 26 Feb 1997 20:33:16 -0000 Organization: Virginia Polytechnic Institute and State University Message-ID: <5f26mc$3r2@sps1.phys.vt.edu> References: <331ad8fe.1061430@news.nai.net> <33149E1A.6D4A@wam.umd.edu> In article <33149E1A.6D4A@wam.umd.edu>, dutky@wam.umd.edu wrote: > As a final note, once you have learned C++ you should have a pretty > reasonable grasp of C and Object-Oriented Programming (OOP) so that > picking up Java or Objective-C (which are both based on C syntax) > will be MUCH easier. I disagree. Learning C++ doesn't tend to give you a wonderful grasp of OOP. It just gives you a lot of bad habits. Object-oriented design is a lot cleaner and simpler in dynamic languages like Java and Objective-C. Things like dynamic messaging, categories, protocols, forwarding; those are the things that really make object-oriented design shine. In C++ you spend lots of time worrying about virtual member functions and templates and unnecessary junk like that. My recommendation: Learn Objective-C or Java (or Smalltalk) first, and then try learning C++. (Though as Don Yactkman has recently pointed out, if you try to learn Java you'll probably pick up all the wrong practices because the books tend to have a limited C++ viewpoint and do not show half the power of the language.) Then you'll see how many hoops you have to jump through to get things done in the latter. Followups to comp.lang.objective-c, as I don't really feel like waging a religious war on this. :) -- -------------------------------------------------------------------------- Nathan Urban | Undergrad {CS,Physics,Math} | Virginia Tech nurban@vt.edu | {NeXT,MIME} mail welcome | http://nurban.campus.vt.edu/ --------------------------------------------------------------------------
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 26 Feb 97 17:57:54 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb26175754@howard.one.net> References: <33145768.42D7@ra.anl.gov> <E67yrG.HD@cam-ani.co.uk> In-reply-to: ians@cam-ani.co.uk's message of Wed, 26 Feb 1997 16:50:03 GMT In article <E67yrG.HD@cam-ani.co.uk>, ians@cam-ani.co.uk (Ian Stephenson) writes: In article <33145768.42D7@ra.anl.gov>, TH Fanning <fanning@ra.anl.gov> writes: > Garance A Drosehn wrote: > > > [...] > > Not sure how this effects your point, but as an aside I do > > think the "defaults database" of NeXTSTEP works better than > > having every application have it's own preference file... > > I completely disagree with this. What if I try tons of software, > each one adding to my "defaults database", but then I delete > these apps from my system. Wouldn't the database slowly grow > over time? How do I "clean" it out? With separate files, I can > just trash them. How can you guarantee that you found them all? In practise this isn't a problem, as the entries that go in the defaults database are small (larger amounts of data tend to get created in ~/Library). They can be deleted (or edited) using Defaults.app. And don't forget the command-line utilities! You can easily enough write a little script to checkpoint the defaults database, or to insert/remove defaults for an arbitrary set of apps or names. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer From: dfevans@bbcr.uwaterloo.ca (David Evans) Subject: Re: Avie confirms Rhapsody on Intel too. Sender: news@novice.uwaterloo.ca (Mr. News) Message-ID: <E68Mwo.6yL@novice.uwaterloo.ca> Date: Thu, 27 Feb 1997 01:31:36 GMT References: <al.856919430@BIX.com> <3313c6ab.20970787@news.alt.net> <petrichE67wqo.LA8@netcom.com> <maury-2602971618300001@199.166.204.230> Organization: University of Waterloo In article <maury-2602971618300001@199.166.204.230>, Maury Markowitz <maury@softarc.com> wrote: >In article <petrichE67wqo.LA8@netcom.com>, petrich@netcom.com (Loren >Petrich) wrote: > >> Easier programming: the NeXT API makes it *very* easy to do GUI >> stuff; with the Interface Builder, one can attach GUI elements to various >> object methods -- for example, one can attach a button to calling some >> function or other by simply dragging and dropping. > > What exactly happens when you do this though? Does it do something like >put a function pointer into a field in the button object? Or is there a >layer of indirection between the two? > There's a layer of indirection--the Objective C runtime system. Too long to go through here, but you should be able for find sone juicy stuff on Deja News. -- David Evans (NeXTMail OK) dfevans@bbcr.uwaterloo.ca Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual
From: deniseh@nntp.best.com (Denise Howard) Newsgroups: comp.sys.next.programmer Subject: Dragging files onto app icon? Date: 27 Feb 1997 02:56:58 GMT Message-ID: <5f2t5q$2bd$1@nntp2.ba.best.com> In pre-3.0 days if you wanted to be able to drage files onto your running app's icon, you did something like this in your controller: - appDidInit:sender { unsigned int wn; id s = [NXApp appSpeaker]; NXConvertWinNumToGlobal([[NXApp appIcon] windowNum], &wn); [s setSendPort:NXPortFromName(NX_WORKSPACEREQUEST, NULL)]; [s registerWindow:wn toPort:[[NXApp appListener] listenPort]]; return self; } This is all considered obsolete now thanks to the dragging protocol that was introduced in NS 3.0. I'm trying to convert the above code to be post-3.0 style, but it seems as if the app icon is a second-class window which can't have a delegate! Here's the code I have in my controller now: - appDidInit:sender; { Window* appIconWindow = [NXApp appIcon]; [appIconWindow setDelegate:self]; [appIconWindow registerForDraggedTypes:&NXFilenamePboardType count:1]; return self; } Does anybody know how to make this work? I've also tried fiddling with the View which is the appIconWindow's contentView, but you can't set a delegate for a View. When I run with the above, my app totally ignores anything I drop onto it. BTW, my protocol methods are fine. I tested this by creating a separate window and making my controller _its_ delegate; worked like a charm. Apps like Edit allow dropping of files onto their icons so I know this is possible. But I don't have access to Edit's source as an example. :-) 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: MaRK_BeSSeY@NeXT.CoM (Mark Bessey) Newsgroups: comp.sys.next.programmer Subject: Re: Required reading for Mac programmer? Date: 27 Feb 1997 03:26:05 GMT Organization: NeXT Software, Inc. Message-ID: <5f2use$i3i@news.next.com> References: <331453CE.28D2@primenet.com> "Carl A. Carlson" <ccarlson@primenet.com> writes > I'm a Mac programmer. My NeXT station with OpenStep is due any day. I > won't be getting any hard copy documentation. I understand there is > lots of online doc. What should I read, and in what order should I read > it to get up to speed on using the operating system and programming in > OpenStep? Any recommended books? If you have OPENSTEP 4.1 or later, check out the Developer Tutorial, in /NextLibrary/Documentation/NetDev/TasksAndConcepts/DeveloperTutorial. It's also available on the www.next.com webpage. The tutorial goes step-by-step through creating a simple OPENSTEP application. That's a great place to start. -- Mark Bessey Apple Computer, Inc. -->I DON'T SPEAK FOR APPLE<--
Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system From: dfevans@bbcr.uwaterloo.ca (David Evans) Subject: Re: Mac/NeXT & Unix: File System Sender: news@novice.uwaterloo.ca (Mr. News) Message-ID: <E68Mv7.oK4@novice.uwaterloo.ca> Date: Thu, 27 Feb 1997 01:30:43 GMT References: <5ddp66$jpc@news.bu.edu> <5erca9$m2@usenet.rpi.edu> <33145768.42D7@ra.anl.gov> <sn58lYu00iVC08QTQD@andrew.cmu.edu> Organization: University of Waterloo In article <sn58lYu00iVC08QTQD@andrew.cmu.edu>, Charles William Swiger <cs4w+@andrew.cmu.edu> wrote: > >Yes, it does. After about 5 years of owning a NeXT, my defaults >database has roughly 1000 items in it. The entries are comprised of >three elements: owner (ie, the application name), property, and value. > Just for some concrete numbers, on my main account which has lived on this machine for about 3.5 years: gallifrey:/Users/dfevans> dread -l | wc 733 3082 27443 skonos:/Users/dfevans> ls -l .NeXT/defaults* -rw-r--r-- 1 dfevans 315 Sep 12 13:12 .NeXT/defaults.nibd -r--r--r-- 1 dfevans 138 Apr 3 1992 .NeXT/defaults3_0.wmd -rw-r--r-- 1 dfevans 2292 Feb 19 22:24 .NeXT/defaults3_1.wmd So, I have 733 defaults entries and they take up less than 3K of disk space. I'm not worried. And I never have to look at this database--the applications manage it themselves, although there are programs for mucking with it as others have mentioned. -- David Evans (NeXTMail OK) dfevans@bbcr.uwaterloo.ca Computer/Synth Junkie http://bbcr.uwaterloo.ca/~dfevans/ University of Waterloo "Default is the value selected by the composer Ontario, Canada overridden by your command." - Roland TR-707 Manual
From: blob@ricochet.NOSPAM.net Newsgroups: comp.sys.mac.programmer.misc,comp.sys.next.programmer Subject: Re: Yes Steve, I will have some Koolaid, thank you! Date: Wed, 26 Feb 1997 19:29:16 -0800 Message-ID: <blob-ya023680002602971929160001@news.ricochet.net> References: <01bc242c$6ae6c1c0$a67797cd@metnews.hip.cam.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <01bc242c$6ae6c1c0$a67797cd@metnews.hip.cam.org>, "zarf" <zarf@zarfism.com> wrote: > So - what hurdles do I have to jump to be able to get the Rhapsody > developer releaser coming this summer? I realize you must join some Apple > developer program - but aren't there different levels - is it known who is > entitled to get their hands on the Rhapsody developer release? And is that > an additional cost - or does the developer registration cover that? Apple hasn't released details, but I would strongly suspect that you'll be getting a copy of Rhapsody DR0 at any developer support level. For details of what the various programs are, see <http://devworld.apple.com>. Typically, seeding is covered by the cost of joining the developer program. -- (Pointers to other Mac programming web sites at <http://devworld.apple.com/dev/geeks.html>) To reply personally, remove the anti-spam "NOSPAM." from the email address in the header.
From: sanguish@digifix.com (Scott Anguish) Newsgroups: comp.sys.next.programmer Subject: Re: Required reading for Mac programmer? Date: 27 Feb 1997 04:31:23 GMT Organization: Digital Fix Development Message-ID: <5f32mr$58g@news.digifix.com> References: <331453CE.28D2@primenet.com> In-Reply-To: <331453CE.28D2@primenet.com> On 02/26/97, "Carl A. Carlson" wrote: >Hi: > >I'm a Mac programmer. My NeXT station with OpenStep is due any day. I >won't be getting any hard copy documentation. I understand there is >lots of online doc. What should I read, and in what order should I read >it to get up to speed on using the operating system and programming in >OpenStep? Any recommended books? > If you are looking for books, check out http://www.stepwise.com/Resources/Books citations for pretty much every OpenStep/NEXTSTEP book worth getting If you're looking for a ground-up in-a-nutshell book to start with, grab Designing Business Applications with OpenStep by Pete Clark and Nik Gervae. Excellent book on many levels, covers everything (although not in as much depth as the NeXT docs) and even points out shortcomings where appropriate. as well as http://www.next.com/OPENSTEP for their downloadable OpenStep docs.. -- Scott Anguish DBS Online - http://www.dbs-online.com/DBS sanguish@digifix.com Stepwise OpenStep WWW - http://www.stepwise.com
From: alanf@izzy.net (Alan Frabutt) Newsgroups: comp.sys.next.programmer Subject: IB: cannot open nib... Date: 26 Feb 1997 23:45:26 -0500 Organization: Isthmus Corporation Message-ID: <5f33h6$pgu@izzy4.izzy.net> I'm hoping this is an easy one... When I move my source (3.2 dev env) from one machine to another, I can't open the nib from IB. The message panel gives me a useless "cannot open" message; if I open the nib as a folder, and try to open the sub-nib(!?) I get a more specific error indicating it can't load a class. I can duplicate this situation by trying to open an arbitrary nib in a MiscKit example. Please cc: responses to alanf@izzy.net. TIA, Alan Frabutt
From: alanf@izzy.net (Alan Frabutt) Newsgroups: comp.sys.next.programmer Subject: MiscSubprocess question Date: 26 Feb 1997 23:52:39 -0500 Organization: Isthmus Corporation Message-ID: <5f33un$q6k@izzy4.izzy.net> Greetings ethereal composite mind. I'm trying to use MiscSubprocess (from MiscKit) to launch a shell script, and connect the stdin/out to text objects. I'm apparently botching something... is there an example laying around somewhere I might use? Please cc: responses to alanf@izzy.net. Regards, Alan Frabutt
From: goldwass@lifesci.lscf.ucsb.edu (Lloyd Goldwasser) Newsgroups: comp.sys.next.programmer Subject: Clipping path around a rotated image from an eps file Date: 27 Feb 1997 00:33:37 GMT Organization: University of California, Santa Barbara Message-ID: <5f2kp1$a04@ucsbuxb.ucsb.edu> I'm trying to look at a rotated image from an eps file, and I'm encountering some clipping path behavior that's puzzling (and undesirable). The following id epsImageRep=[topImage bestRepresentation]; [self rotate:topAngleInDegrees]; [epsImageRep draw]; [self rotate:-topAngleInDegrees]; draws the image with the specified rotation, but, for some reason, the clipping path doesn't seem to be aware of the rotation of this image. The upper wedge of the rotated image lops out of its view onto the rest of its window, which isn't, um, attractive behavior. Explicitly specifying a rectangular (horizontal) clipping path with something like PSnewpath(); PSmoveto(0.,0.); PSlineto(50.,0.); PSlineto(50.,20.); PSlineto(0.,20.); PSclosepath(); PSclip(); either before or after rotating, doesn't change things at all. PSviewclip() does very strange things that suggest that there's a missing lockFocus -- although putting one in doesn't help. This is with 3.2 on Black. I presume I'm just being ignorant of some simple way to do something that's not very esoteric -- but nothing further seems to leap out of the documentation. Anyone have any information or ideas? Thanks in advance! Lloyd Goldwasser goldwass@lifesci.lscf.ucsb.edu
From: nurban@sps1.phys.vt.edu (Nathan Urban) Newsgroups: comp.sys.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 26 Feb 1997 20:53:39 -0000 Organization: Virginia Polytechnic Institute and State University Message-ID: <5f27sj$3ub@sps1.phys.vt.edu> References: <5d8qta$6np@news.bu.edu> <33138B25.B5F@acm.org> <Mn4w7wm00iVCIHHMVm@andrew.cmu.edu> <3314AD68.5B51@acm.org> In article <3314AD68.5B51@acm.org>, i.joyner@acm.org wrote: > Charles William Swiger wrote: > > I don't see any point to discussing this further. > The first sensible thing you have said in a long time. The reasons are > though that you will never change your mind, you will keep > introducing irrelevancies, you just keep arguing round in > circles. No, the main reason is that your original suggestion was moronic. -- -------------------------------------------------------------------------- Nathan Urban | Undergrad {CS,Physics,Math} | Virginia Tech nurban@vt.edu | {NeXT,MIME} mail welcome | http://nurban.campus.vt.edu/ --------------------------------------------------------------------------
From: Stephen Peters <speters@cygnus.com> Newsgroups: comp.sys.next.programmer Subject: Re: OpenStep: what does the term mean? Date: 26 Feb 1997 19:13:05 -0800 Organization: Cygnus Solutions Message-ID: <qdiv3f2b7i.fsf@blues.cygnus.com> References: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> <5evgk9$7m4@news.next.com> MaRK_BeSSeY@NeXT.CoM (Mark Bessey) writes: > David Herren writes > > OPENSTEP is the abstracted API which runs on multiple OSs. OpenStep is > > the operating system itself. Confusing, isn't it? > > Apparently confusing enough for you to get that exactly wrong :-) > > OPENSTEP (all caps) is Apple's name for their implementation of the > OpenStep specification. More specifically, Apple sells: > OPENSTEP for Mach > OPENSTEP Enterprise for Windows NT > Which both implement the OpenStep API on different operating systems. > OPENSTEP for Mach also includes our Mach operating system for NeXT > computers, Intel PC's, and Sparc workstations. Once upon a time, NeXT had a problem with capitalization. They had one product, which was spelled, at various times from various sources, NeXTSTEP, NextStep, NeXTstep, Nextstep, NEXTSTEP, and I'm sure others that I've missed. This generated a small amount of confusion, but luckily you always knew what people were talking about, since it was all the same thing. NeXT (Apple) appears to have learned from this mistake. Now, they have two possible capitalizations of OpenStep (OPENSTEP?), but they've been very careful to make sure that they mean *different* things. That should avoid the confusion nicely. Oh, and just ignore that thumping sound. It's just me banging my head on the desk. -- 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: Stefano Pagiola <spagiola@worldbank.org> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Wed, 26 Feb 1997 10:54:40 -0500 Organization: World Bank Message-ID: <33145CC0.6C05@worldbank.org> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Travis Butler wrote: > My suspicion (based, I admit, mainly on the attitudes of NeXT partisans in > these threads) is that the average NeXTStep user is technically proficient > or is willing to become so, has an interest in computers beyond what it > takes to get his job done (or has a job where interest in computers is the > primary factor <g>), does not mind (or even prefers) using the CLI for some > operations, and often runs high-end networking and/or server operations. > How many of the people who "generally have used NEXTSTEP _and_ Macs" and > prefer NeXTStep fit this profile? Well, here's one counter-example. I've used a NeXT as my primary computer since 1991, and use a PowerBook on the road (which is quite a lot). So I'm quite familiar with both. But: (i) I do not code; (ii) in 5 years, i've used the Unix CLI in NeXTSTEP maybe a dozen times; (iii) I certainly do not run any high-end networking operation; in fact, my NeXT isn't even on the net. Oh, and I'm not in a university (though I used to be :-). I'm also pretty much completely ignorant of all the technical aspects of the increasingly abstruse discussions of filesystems I find here. Having said all that, and again speaking as someone who is a regular USER of both NeXTSTEP and MacOS, I far prefer NeXTSTEP. Not that it's perfect. But if I had to pick one it would undoubtedly be NeXTSTEP. Resource forks vs extensions? I don't care how the OS keeps track of which app to use when I double-click a file. But as someone who transfers files across multiple OSs all the time, I can testify that resource forks have proven an incredible pain in the a**. I cannot comment on whether resource forks are somehow technically superior (in the sense that Beta is supposed to be superior to VHS) but in a world where only MacOS knows how to handle resource forks, they are a royal pain. I want to be able to drag a file off a PC floppy onto my NeXT or Mac and be able to double-click on it. On NeXTSTEP, I generally can, and if I can't, fixing it is a simple matter of adding the correct extension. On my Mac, I usually have to go to the app, open the file, and save it. Which is easier? -- 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: stephane@lysis.ch (Stephane Corthesy) Newsgroups: comp.sys.next.programmer Subject: Re: SQL*Net and EOF Date: 27 Feb 97 15:10:33 GMT Organization: Lysis SA Message-ID: <3315a3e9.0@news.planet.ch> References: <3308FEBA.538E@us.oracle.com> Cc: jlincoln@us.oracle.com In <3308FEBA.538E@us.oracle.com> Jason Lincoln wrote: > I am trying to connect my NeXTstation to a test Oracle database using > SQL*Net v2. I have created a tnsnames.ora file with a description of > the database I am trying to connect to. When I try to connect in > EOModeler I get a ORA-6152 error. Is there a HOWTO which explains the > steps necessary to accomplish the SQL*Net connect from EOF? > > Thanks, > > Jason > Hi, I think you've got the same problem as we had. We resolved it like this (I don't remember who gave us the solution, thank you, whoever you are ;-)) In the Oracle login panel (or in the EOModel), enter (with Copy/Paste): ServerID: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myOracleServerName)(PORT=1521))(CONNECT_DATA=(SID=myOracleServerID))) with your own parameters. Sounds strange but it works. StĘphane
From: maury@softarc.com (Maury Markowitz) Newsgroups: comp.sys.mac.advocacy,comp.sys.next.programmer Subject: Re: Avie confirms Rhapsody on Intel too. Date: Thu, 27 Feb 1997 11:12:09 -0500 Organization: SoftArc Inc. Message-ID: <maury-2702971112240001@199.166.204.230> References: <al.856919430@BIX.com> <3313c6ab.20970787@news.alt.net> <petrichE67wqo.LA8@netcom.com> <maury-2602971618300001@199.166.204.230> <E68Mwo.6yL@novice.uwaterloo.ca> In article <E68Mwo.6yL@novice.uwaterloo.ca>, dfevans@bbcr.uwaterloo.ca (David Evans) wrote: > There's a layer of indirection--the Objective C runtime system. Too long to > go through here, but you should be able for find sone juicy stuff on Deja Cool. Maury
From: Mike Johnson <abgadmin@deskmedia.com> Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 27 Feb 1997 11:11:09 -0600 Organization: Alliance Benefit Group Message-ID: <3315C02D.1C61@deskmedia.com> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> <33145CC0.6C05@worldbank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stefano Pagiola wrote: > I want to be able to drag a file off a PC floppy onto my > NeXT or Mac and be able to double-click on it. On NeXTSTEP, I generally can, and > if I can't, fixing it is a simple matter of adding the correct extension. On > my Mac, I usually have to go to the app, open the file, and save it. Which is > easier? > > -- > 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 On a Mac you can use PC Exchange to relate a PC Extension to a Mac program. Isn't this what you are doing on your NeXt machine?
From: shess@one.net (Scott Hess) Newsgroups: comp.sys.next.programmer Subject: Re: Dragging files onto app icon? Date: 27 Feb 97 10:32:39 Organization: Is a sign of weakness Message-ID: <SHESS.97Feb27103239@howard.one.net> References: <5f2t5q$2bd$1@nntp2.ba.best.com> In-reply-to: deniseh@nntp.best.com's message of 27 Feb 1997 02:56:58 GMT In article <5f2t5q$2bd$1@nntp2.ba.best.com>, deniseh@nntp.best.com (Denise Howard) writes: This is all considered obsolete now thanks to the dragging protocol that was introduced in NS 3.0. I'm trying to convert the above code to be post-3.0 style, but it seems as if the app icon is a second-class window which can't have a delegate! Here's the code I have in my controller now: Note that appIcon is pretty special - if launched from Workspace, it's not really your window, if launched from a shell, it _is_ really your window. This doesn't really affect whether it has a delegate (or shouldn't), but it _does_ affect whether you ever see events for it. Apps like Edit allow dropping of files onto their icons so I know this is possible. But I don't have access to Edit's source as an example. :-) Nowadays you just provide the open-related stuff, when someone does a Command-drop over your appIcon, it gets sent to -appAcceptsAnotherFile:, -app:openFile:type: and related methods, as if you double-clicked on it. With the advantage that you don't have to register as the app for that filetype. Later, -- scott hess <shess@one.net> (606) 578-0412 http://w3.one.net/~shess/ <Favorite unused computer book title: The Idiots Guide to the Zen of Dummies in a Nutshell in Seven Days, Unleashed>
From: van@crl.com (Van C. Bagnol) Newsgroups: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Subject: Re: Mac/NeXT & Unix: File System Followup-To: comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.system Date: 27 Feb 1997 09:33:28 -0800 Organization: CRL Network Services (415) 705-6060 [Login: guest] Message-ID: <5f4gh8$7f4@crl.crl.com> References: <5ddp66$jpc@news.bu.edu> <5ddtsg$oba$1@majipoor.cygnus.com> <5ephtv$mac@news.tuwien.ac.at> Robert F Tobler (Robert F Tobler (rft@cg.tuwien.ac.at)) wrote: : In <5ejud7$2pk@crl9.crl.com> Van C. Bagnol wrote: : > To have _multiple_ users _each_ with a different mapping preference for : > individual files looks like it's a many-to-one correspondence. Seems : > that can get unwieldy to manage, or at least one that begins to parallel : > the filesystem for _each user_. (Everyone gets a Desktop database). I : > suppose they can inherit the global mapping and simply override. : > : Is it really that unwiedly to manage? You only need one database per user, : that is managed by the Workspace/Finder and opened when the user logs in. : It contains one entry for each file for which the user has overridden the : default mapping according to filetype. Since only a fraction of the files : of a user need such an entry, and each entry will be on the order of less : than 100 bytes (this is an estimate), the overhead for such a database : is negligible. : : Under Nextstep the database already exists for per application+user : preferences. It should be trivial to add the mapping tha maps files : to their opening application. As I said, I suppose the user would inherit a default mapping from some global (group?) setting and probably have an personal mapping to over- ride it. The potential problem is that the current NeXTSTEP user mapping goes by filename extension ("type") and to expand this scheme to individual files will increase the mapping by an order of magnitude; to expand out to a network or to the number of users on the network it increases by another order of magnitude, which increases the management of it all. What I'm not sure happens is when files are moved around the filesystem or network, or if the files or directories in the path to the file are renamed. Keeping a parallel structure of file entries synchronized with a filesystem is a lot more work than maintaining a list of just the files' types. Let alone keeping several such parallel structures. Van -- Van Bagnol / van@crl.com / Teatro ng Tanan / Windsurfing / Parachuting Hawksbill Capital Management / (707) 575-7077 / (707) 575-8334 fax "Parang lumalakad ako sa loob ng panaginip" "An Error is not a Mistake...until you refuse to correct it."
Newsgroups: comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: C++ Syntax Highlighting Message-ID: <E68Jz8.yB@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <1997Feb24.144238.26278@roper.uwyo.edu> Date: Thu, 27 Feb 1997 00:28:19 GMT nor@panoramix.uwyo.edu (norbert pirzkal) wrote: > Is there a freeware editor for NeXTSTEP that supports syntax highlighting? > > Thanks > Hmm. not really. Emacs might have a modul. Eval.app has some highlightinh and ClassEditor.app (which reuses Evals text object) does the same in a very basic fashion. Reportedly ProjectBuilder 4.2 (due to ship in the near future) will have syntax highlighting for C, ObjC, C++, and Java code. Aloha Tomi
Newsgroups: comp.sys.next.programmer From: tomi@shinto.nbg.sub.org (Thomas Engel) Subject: Re: Return-key image in IB of OS4.1? Message-ID: <E68KEu.z3@shinto.nbg.sub.org> Sender: news@shinto.nbg.sub.org Organization: STEPeople's home (A NUGI member) References: <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de> <E64pKz.4Dt@novice.uwaterloo.ca> <5etk58$cos@kaopala.mhpcc.edu> Date: Thu, 27 Feb 1997 00:37:42 GMT altenber@acpub.duke.edu (Lee Altenberg) wrote: > The demise of the Return key icon was evidence that severe "Windows Envy" had > taken over NeXT. Other signs were the window setup of the OpenStep 4.0 pre > release GUI, where the miniaturize button was placed on the right, next to the Sorry...but this is wrong IMHO. The "Return Sign" definitly had to leave with the advent of the keyboard UI control. You can argue if keyboard UI is nice looking or what...but it definitly is very useful for a lot of problems. Having a keyboard UI is good (while I would have loved to see it being an option one could turn off/on) The "return-sign" is bad from the UI design point of view once pressing "return" can cause a different button to get pressed. Which now is the case. > close button, JUST LIKE WINDOWS95. And NeXT had reportedly shifted internally > to running NT. I hope that the Apple purchase has stanched this slide into > perversity and depravity within the NeXT team. Maybe the return of Jobs will > presage the Return of the Return! > -- > As far as the window goes the story is a little tricky. Moving the closer and minimizer together is a bad thing since you can accidently click the wrong one. But keeping them where they are _and_ add the really great "drag-me-docu-icon" inside the titlebar causes some esthetical conflicts. It really looks a lot better if the doc icon is on the one side...and the buttons are on the other side. Apple has the icon and text centered...but this does not work once your try to put in the whole text of the docuemnts path...which absically will left-align your docu icon again. Hmm.can't have it all. Aloha Tomi
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: MiscSubprocess question Date: 27 Feb 1997 20:19:29 GMT Organization: Global Objects Inc. Message-ID: <5f4q8h$emo$2@news.xmission.com> References: <5f33un$q6k@izzy4.izzy.net> alanf@izzy.net (Alan Frabutt) wrote: > I'm trying to use MiscSubprocess (from MiscKit) to launch a shell script, > and connect the stdin/out to text objects. I'm apparently botching > something... is there an example laying around somewhere I might use? Have you looked at the MiscShell source code? It uses MiscSubprocess underneath to implement its magic... -- Later, -Don Yacktman don@misckit.com <a href="http://www.misckit.com/don.html">My home page</a>
From: Howard Berkey <hberkey@tenetwork.com> Newsgroups: comp.sys.next.programmer Subject: Re: C++ Syntax Highlighting Date: Thu, 27 Feb 1997 14:28:28 -0800 Organization: Total Entertainment Network Message-ID: <33160A8C.2867@tenetwork.com> References: <1997Feb24.144238.26278@roper.uwyo.edu> <E68Jz8.yB@shinto.nbg.sub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Emacs does quite nicely with the hilit-19 module. -H-
From: Jason Lincoln <jlincoln@us.oracle.com> Newsgroups: comp.sys.next.programmer Subject: Re: SQL*Net and EOF Date: Thu, 27 Feb 1997 04:01:28 +0000 Organization: Oracle Corp. Message-ID: <33150718.3EC2@us.oracle.com> References: <3308FEBA.538E@us.oracle.com> <3315a3e9.0@news.planet.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Stephane Corthesy wrote: > > In <3308FEBA.538E@us.oracle.com> Jason Lincoln wrote: > > I am trying to connect my NeXTstation to a test Oracle database using > > SQL*Net v2. I have created a tnsnames.ora file with a description of > > the database I am trying to connect to. When I try to connect in > > EOModeler I get a ORA-6152 error. Is there a HOWTO which explains the > > steps necessary to accomplish the SQL*Net connect from EOF? > > > > Thanks, > > > > Jason > > > > Hi, > > I think you've got the same problem as we had. We resolved it like this (I > don't remember who gave us the solution, thank you, whoever you are ;-)) > > In the Oracle login panel (or in the EOModel), enter (with Copy/Paste): > > ServerID: > (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myOracleServerName)(PORT=1521))(CONNECT_DATA=(SID=myOracleServerID))) > > with your own parameters. Sounds strange but it works. > > StĘphaneI got EOF to connect after I placed a good tnsnames.ora file into /etc. Thanks, Jason
From: tkimpton@mail2.maned.com (Thomas R. Kimpton) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Thu, 27 Feb 1997 17:45:26 -0500 Organization: Managing Editor, Inc. Message-ID: <tkimpton-ya023180002702971745260001@newsserver.epix.net> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> <33145CC0.6C05@worldbank.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Perhaps I've missed someone mentioning this, but: The only place where the file *name* (which is how a file is referenced in an open call) is associated with an inode, is the directory structure(entry). I think we could probably leave the inode structure alone, and put any (reasonable) amount of information in the directory table. After all, a directory is *actually* a file that contains directory entries. Thus in the directory structure you could point to any number of inodes: (This is from Solaris 2.5, /usr/include/sys/dirent.h, ymmv :-) -=-=-=-=-=- BEFORE -=-=-=-=-=- struct dirent { ino_t d_ino; /* "inode number" of entry */ off_t d_off; /* offset of disk directory entry */ unsigned short d_reclen; /* length of this record */ char d_name[1]; /* name of file */ }; -=-=-=-=-=- AFTER -=-=-=-=-=- #ifdef mac #define NFORKS 2 #else #error Hey you need to define how many forks to a file! #endif typedef struct { ino_t d_ino; /* "inode number" of this fork of the entry */ ForkType type; ForkCreator creator; } fileFork; struct dirent { fileFork d_forks[NFORKS]; off_t d_off; /* offset of disk directory entry */ unsigned short d_reclen; /* length of this record */ char d_name[1]; /* name of file */ }; -=-=-=-=-=- MORE COMMENTS :-) -=-=-=-=-=- I thought it would be more flexible if you put the type/creator information in the fileFork struct, than have only one type/creator for the "file". At the cost of more complexity, the d_forks could be a pointer to an area after the name, and add a d_forkoffset (to create the pointer), and a d_numforks, so you could have any (reasonable) number of forks. The current calls to manipulate files would use the 'DATA' fork. Additional calls could be added to access alternate forks: int forkopen(char *name, int oflag, int forkNum); int forkTypeToID(char *name, ForkType type); // returns the fork number of file name that has ForkType type :-) If we allowed arbitrary numbers of forks per file: int forkCreate(char *name, ForkType type,ForkCreator creator); For forks that have formatted data (resource for example) you would pass the refNum returned by forkopen to appropriate calls... Network exporting of this file system would involve some translation for folks not using this type of file system, but then, don't most machines' file systems require some translation to get them into NFS? (I'm pretty sure that BSD, SYSV4, SYSV<4, Linux and other unix variants all use incompatible dirent structures, haven't seen them in a long time, however.) Anyway, did someone already talk about this and I missed it, or, what do you think? Tom. -- This address may *not* be used for unsolicited commercial mailings. Help stamp out SPAM in this thread's lifetime.
From: campbejr@phu989.mms.sbphrd.com (John R. Campbell) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: 28 Feb 1997 15:49:03 GMT Organization: SmithKline Beecham Pharmaceuticals Research & Development Message-ID: <slrn45hdvdh.6p.campbejr@phu989.um.us.sbphrd.com> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> <33145CC0.6C05@worldbank.org> <tkimpton-ya023180002702971745260001@newsserver.epix.net> On Thu, 27 Feb 1997 17:45:26 -0500, Thomas R. Kimpton <tkimpton@mail2.maned.com> wrote: >Perhaps I've missed someone mentioning this, but: The only >place where the file *name* (which is how a file is referenced >in an open call) is associated with an inode, is the directory >structure(entry). I think we could probably leave the inode >structure alone, and put any (reasonable) amount of information in >the directory table. After all, a directory is *actually* a file >that contains directory entries. Somewhat more logical than some of my thoughts about placing the information within the inode and providing a hidden file prefix. As long as the directory is *always* handled by the library routines so that access can be "invisible" this can work; The main difficulty will be installing additional syscall()s to provide the directory entry manipulation (only the OS can manipulate the contents of a directory directly; You *can* read the contents, but you ain't allowed to *write* into a directory). > Thus in the directory structure >you could point to any number of inodes: > >(This is from Solaris 2.5, /usr/include/sys/dirent.h, ymmv :-) >-=-=-=-=-=- BEFORE -=-=-=-=-=- > >struct dirent { > ino_t d_ino; /* "inode number" of entry */ > off_t d_off; /* offset of disk directory entry */ > unsigned short d_reclen; /* length of this record */ > char d_name[1]; /* name of file */ >}; > >-=-=-=-=-=- AFTER -=-=-=-=-=- > >#ifdef mac >#define NFORKS 2 >#else >#error Hey you need to define how many forks to a file! >#endif > >typedef struct { > ino_t d_ino; /* "inode number" of this fork of the entry */ > ForkType type; > ForkCreator creator; >} fileFork; > >struct dirent { > fileFork d_forks[NFORKS]; > off_t d_off; /* offset of disk directory entry */ > unsigned short d_reclen; /* length of this record */ > char d_name[1]; /* name of file */ >}; > >-=-=-=-=-=- MORE COMMENTS :-) -=-=-=-=-=- As I mentioned above, a set of calls will be needed to manipulate the directory entry since it can't be modified from user space. There are few calls existing now for such manipulation. Additionally, each of these additional inodes could contain the extra information directly- as in the file type and creator information. Additionally, we need to provide an "open" for a fork so we can perform read/write on the information. Right now an open() call navigates the directory tree and attaches the file to a process, opening up access to it's contents. With the enhanced directory structure scheme, how do you select a fork? While this is incredibly clever, we need a new API (some of which can't be a simple layer but must drill down to the OS itself) to support this type of a file system. The number of programs and libraries that need to be modified is awesome. Another downside is that the information isn't automatically linked when multiple names have been given to a file; Each name for the same file will often have the fork information left behind. It'd also help if the number of forks available is variable, by the way... >I thought it would be more flexible if you put the type/creator >information in the fileFork struct, than have only one type/creator >for the "file". At the cost of more complexity, the d_forks could >be a pointer to an area after the name, and add a d_forkoffset >(to create the pointer), and a d_numforks, so you could have >any (reasonable) number of forks. A reasonable approach; The ability to have multiple resource forks opens up a new paradigm of file access. In an object oriented system w/ inheritance, each fork would work it's way *up* the chain of inheritance until a function that can manipulate this file can be found. >The current calls to manipulate files would use the 'DATA' >fork. Additional calls could be added to access alternate >forks: > >int forkopen(char *name, int oflag, int forkNum); or fkopen() >int forkTypeToID(char *name, ForkType type); >// returns the fork number of file name that has ForkType type :-) Why? This' be more logical as: fkstat() and what would be the return of the normal "stat" call. Additionally, this information must be replicated when a link() call is performed, unless we do it via fklink(). >If we allowed arbitrary numbers of forks per file: >int forkCreate(char *name, ForkType type,ForkCreator creator); no, fkcreat() or fkappend() Now is the information within a fork an actual file, with it's own name? If it has an inode, it will probably need to have it's own top-level file name... >For forks that have formatted data (resource for example) >you would pass the refNum returned by forkopen to appropriate >calls... Once you have an fd it's associated to an open i-node; there's no need to be concerned with the name once this has been completed. The name space exists to make the open() phase easier... >Network exporting of this file system would involve some >translation for folks not using this type of file system, >but then, don't most machines' file systems require some >translation to get them into NFS? (I'm pretty sure that >BSD, SYSV4, SYSV<4, Linux and other unix variants all >use incompatible dirent structures, haven't seen them >in a long time, however.) Well, you can export a mounted MS-DOS filesystem from Linux but Linux (and FreeBSD, I am certain) will handle the translation to/from this structure for NFS (though you're not likely to like the limitations). >Anyway, did someone already talk about this and I missed it, >or, what do you think? While at first blush this is a hot idea, there are problems I'm having with it; I've focussed on enhancing the i-node since it's the ultimate single point of maintenance for a file system; Additions made at that level can be pretty well hidden from all but a few existing Unix utilities (though the criticism that we shouldn't have to open the file to see which icon needs to be displayed is a good one). Some have suggested adding type/creator codes and new timestamps (like a *real* creation time) directly to the inode would balloon the structure but would not require opening it (so you can suck in the information w/ a stat() call); The cost would be a reduction in capacity for a file system and imposes limits on what can be expressed. Hmmmm... Maybe we can insert inode indices within an inode so it can be treated as a cross reference. This moves the fork information down to the inode again, placing a single point of maintenance back at the actual file object and not within the namespace. While that's clunky, it certainly reduces overhead and drops the number of changes needed to the Unix system; Extra ioctl() and fcntl() calls could handle the file out-of-band information. Heck, creators/etc can have inodes and some information in the /proc filesystem while the system is running... Hmmmm... We'd still have a limit to the number of forks a file could have, but it's a compromise that allows Apple-like files to coexist with the existing Unix utility suite- Which is the primary thrust of this exercise... -- John R. Campbell, Speaker to Machines, Resident Heckler soup@jtan.com "As a SysAdmin, yes, I CAN read your e-mail, but I DON'T get that bored!"-me Disclaimer: I'm just a consultant at the bottom of the food chain, so, if you're thinking I speak for anyone but myself, you must have more lawyers than sense.
From: don@globalobjects.com (Don Yacktman) Newsgroups: comp.sys.next.programmer Subject: Re: MiscTableMatrix Palette !! Date: 28 Feb 1997 16:15:47 GMT Organization: Global Objects Inc. Message-ID: <5f70bj$6b6$1@news.xmission.com> References: <5f6rl6$nb4@hpuniv.univ-lr.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit yannick buisson (université de La Rochelle) wrote: > I have the MiscKit 2.0.2 version. > > I try to compile the few available palettes .... > But i just manage to compile the MiscSwitchView palette ! > > Does someone manage to compile the MiscTabMatrix palette > under OpenStep 4.1 ?? > When i try to compile MiscTabMatrix, i have an error like > NEXT_ROOT = variable undefined !!! > > If yes, i am interessting to get a good version So am I! :-) Seriously, I'm working on getting things working more smoothly, but there is still a lot of work to do. Help is certainly wanted and welcome... I do hope to be making some new releases soon, but please remember that the OPENSTEP stuff is, right now, pretty gamey and needs a lot of work before it has the maturity of the NEXTSTEP kit. -- 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.mac.system,comp.sys.next.programmer,comp.sys.mac.programmer.codewarrior,comp.sys.mac.oop.powerplant,comp.sys.mac.programmer Subject: Re: Mac/NeXT & Unix: You're all NUTS! Date: 28 Feb 1997 05:34:56 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5f5qq0$14s@usenet.rpi.edu> References: <5d8qta$6np@news.bu.edu> <5dbfr3$g10@dismay.ucs.indiana.edu> <connelly-ya023680000602970146410001@news.ziplink.net> <Pine.SGI.3.95.970207004811.10697B-100000@wong> <An362Z_00iWm02vQI0@andrew.cmu.edu> <330CEC81.5A34@acm.org> <Un3Q9l_00iVC022esD@andrew.cmu.edu> <33138B25.B5F@acm.org> <Mn4w7wm00iVCIHHMVm@andrew.cmu.edu> <3314AD68.5B51@acm.org> Ian Joyner <i.joyner@acm.org> wrote: > Charles William Swiger wrote: > > I don't see any point to discussing this further. > > The first sensible thing you have said in a long time. It's interesting that you start out this way, and then go on with another 27 lines of self-serving rubbish. If there isn't any point in discussing it further, then shut up. > This has not been a pleasant internet exchange. But for all of > it, you have failed to show that my original insight was wrong. My guess is that you have failed to convince anyone other than yourself that you have any insight, or that your comments were right. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA ng. I do think the defaults-database (in NeXTSTEP) works better than having *every* application have it's own preference file. However, that does not mean that I think all applications should have their "preferences" (loosely speaking) in the defaults database. Loosely speaking, one could consider the list of usenet newsgroups you are in as a preference setting on your newsreader. However, I would not want a single application dumping that much information into the defaults database. If a single application has a lot of information to keep around, then it's perfectly reasonable to create a separate file for that info. But for those applications which only have a few settings, it's better (in my opinion) to have those few settings in the default database than to have a preference file created to hold 100 bytes of info. --- 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 Subject: Re: OpenStep: what does the term mean? Date: 28 Feb 1997 06:00:01 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5f5s91$14s@usenet.rpi.edu> References: <msg37701.thr-34dc7b90.54c5638@flannet.middlebury.edu> <5evgk9$7m4@news.next.com> <qdiv3f2b7i.fsf@blues.cygnus.com> Stephen Peters <speters@cygnus.com> wrote: > Once upon a time, NeXT had a problem with capitalization. They > had one product, which was spelled, at various times from various > sources, NeXTSTEP, NextStep, NeXTstep, Nextstep, NEXTSTEP, and > I'm sure others that I've missed. This generated a small amount > of confusion, but luckily you always knew what people were talking > about, since it was all the same thing. Actually, that's not true either. Originally (meaning release 1.0), "NeXTstep" was the name given to the code which was sold to IBM as a user-interface (etc) to add on top of AIX. Thus, NeXTstep was *originally* the set of API's & stuff that we would now call OpenStep. It explicitly did not include the Mach OS, or the BSD layer & utilities that came with NeXT hardware, because it was going to be put on top of AIX. That IBM/AIX project fizzled out at the release of NeXTstep 2.0. From that point until release 3.1 of NeXTSTEP, no one focused too much on what the term meant, because whatever it was it was still tied to NeXT hardware. With release 3.1, NeXT had a product for hardware that NeXT did not build. That was called NeXTSTEP, but now that explicitly *included* the MachOS and BSD-layer. Then came the deal with Sun, which swirled around OpenStep (the generic specification). This defined an explicit set of API's, and was explicitly divorced from a connection to any particular operating system. As I understand it, this isn't exactly the same distinction made with the early NeXTstep product (for IBM), because (I *think*) the earlier product was supposed to look & feel the same at the user interface layer. OpenStep does not define what the user sees, just the API's a programmer would use to create a program. And indeed, NeXT itself came out with OPENSTEP for WindowsNT, which caused something of a fuss in the NeXTSTEP community as applications written with this looked more like Windows applications (to the user), compared to NeXTSTEP applications. Now with release 4.0 (or was it 4.1?), NeXT decided it didn't want the name NEXTSTEP around at all, no matter what the capitalization, so they called that product "OPENSTEP for MachOS". Now, if you compare that to the name "OPENSTEP for WindowsNT", you would think this was a product for someone else's operating system. However, "OPENSTEP for MachOS" explicitly includes the MachOS from NeXT, while "OPENSTEP for WindowsNT" explicitly excludes it (and excludes WindowsNT, for that matter -- you buy WindowsNT from Microsoft and get "OPENSTEP for WindowsNT" from NeXT as something to run on top of a copy of WindowsNT that you already own). People who are just joining this adventure now might think that I'm making all of the above up just to be funny, but I'm reasonably sure that I have all the facts straight there. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
From: Charles William Swiger <cs4w+@andrew.cmu.edu> Newsgroups: comp.sys.next.programmer Subject: Re: DEBUGGER INFO NEEDED Date: Fri, 28 Feb 1997 12:19:21 -0500 Organization: Fifth yr. senior, Computer Science, Carnegie Mellon, Pittsburgh, PA Message-ID: <Yn5lCNS00iWZI536lR@andrew.cmu.edu> References: <3316E60E.5BCC@gcomm.com> In-Reply-To: <3316E60E.5BCC@gcomm.com> Excerpts from netnews.comp.sys.next.programmer: 28-Feb-97 DEBUGGER INFO NEEDED by amando@gcomm.com > I am a newbie in the nextstep programming enviroment and I need to learn > a bit more about Next's GDB. The info offered by Next is very > complicated for me, since I am just beginning. Could anybody please tell > me where can I find more info or a book that explains with more detail > GDB and the art of debugging programs? I will thank you very much all > the info... Well, there are two paths you can take towards learning how to use GDB, depending on your needs and what you want to do. If you want to do things the NeXT way, and are dealing with NeXT-specific or OPENSTEP-specific applications, you'll we working in a project managed by ProjectBuilder.app. This provides a nice GUI display of the project and any errors encountered while compiling, and lets you easly run a debuggable version. This'll start up your project under GDB, and you can type 'view' to bring up project source files in Edit.app. There's a GUI control panel which is available which will let you browse the data structures and procedure call stack, let you single-step, set breakpoints, etc. This is pretty easy to understand and learn, but it hides some of what's going on and doesn't really teach you how to use GDB by itself. But it might qualify as a good introduction to using GDB at a simpler level. Alternatively, you can view the GDB Info documentation, which should be available within the Emacs editor via 'M-x info m GDB'. This will provide a very different viewpoint on GDB, but it will also teach you how to use it better. It's also much easier to work with just GDB for non-NEXTSTEP specific code since you don't have to convert a generic Unix source code tree into a ProjectBuilder.app project before debugging whatever it is. (By the way, some of the above is a matter of opinion; add "IMHO's" when needed. :-) -Chuck Charles Swiger | cs4w@andrew.cmu.edu | standard disclaimer ----------------+---------------------+--------------------- I know you're an optimist if you think I'm a pessimist.
From: Garance A Drosehn <gad@eclipse.its.rpi.edu> Newsgroups: comp.sys.next.programmer Subject: Re: Return-key image in IB of OS4.1? Date: 28 Feb 1997 06:09:07 GMT Organization: Rensselaer Polytechnic Institute, Troy NY, USA Message-ID: <5f5sq3$14s@usenet.rpi.edu> References: <Pine.NXT.3.95.970224164748.1075A-100000@pollux.jura.uni-bonn.de> <E64pKz.4Dt@novice.uwaterloo.ca> <5etk58$cos@kaopala.mhpcc.edu> <E68KEu.z3@shinto.nbg.sub.org> tomi@shinto.nbg.sub.org (Thomas Engel) wrote: > altenber@acpub.duke.edu (Lee Altenberg) wrote: > > close button, JUST LIKE WINDOWS95. And NeXT had reportedly > > shifted internally to running NT. I hope that the Apple > > purchase has stanched this slide into perversity and depravity > > within the NeXT team. I'll go out on a limb and predict that they'll have a few PowerMacs running Rhapsody, instead of sliding further into WindowsNT. Just a wild guess, of course. > > Maybe the return of Jobs will presage the Return of the Return! > > -- > As far as the window goes the story is a little tricky. Moving > the closer and minimizer together is a bad thing since you can > accidently click the wrong one. But keeping them where they are > _and_ add the really great "drag-me-docu-icon" inside the titlebar > causes some esthetical conflicts. It really looks a lot better > if the doc icon is on the one side...and the buttons are on the > other side. > > Apple has the icon and text centered...but this does not work > once your try to put in the whole text of the docuemnts path...which > basically will left-align your document icon again. > > Hmm.can't have it all. I'll agree with Tomi on this. On the one hand I don't like moving closer and minimizer to the same side, but I can see why it makes sense once the document icon is added. And I do think that the document icon was worth adding. My guess is that Rhapsody will look more like the MacOS than the GUI initially planned for NeXTSTEP 4.0, even though I liked the look of that new NeXTSTEP interface. I could go with either one myself, and I imagine it's to Apple's advantage to stick with the look they were trotting out for Copland. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA
Date: Fri, 28 Feb 1997 13:11:09 -0600 From: dashlangan@hotmail.com Subject: The Quickest, Dirtiest Y2K Solution Newsgroups: alt.comp.shareware.programmer,comp.os.os2.misc,comp.os.os2.programmer.misc,comp.programming,comp.sys.mac.misc,comp.sys.next.programmer,comp.unix.misc,comp.unix.programmer Message-ID: <857156472.16550@dejanews.com> Organization: Deja News Usenet Posting Service For the quickest, dirtiest Y2K solution check out the following web site: http://www.geocities.com/ResearchTriangle/3462/ Dash Langan -------------------==== Posted via Deja News ====----------------------- http://www.dejanews.com/ Search, Read, Post to Usenet
From: deniseh@nntp.best.com (Denise Howard) Newsgroups: comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.misc,comp.soft-sys.nextstep Subject: Re: Q:Reporting tool Followup-To: comp.sys.next.programmer,comp.sys.next.software,comp.sys.next.misc,comp.soft-sys.nextstep Date: 28 Feb 1997 19:11:42 GMT Message-ID: <5f7ale$7ra$1@nntp2.ba.best.com> References: <E6BKEz.165@oic.de> Juergen Moellenhoff (jurgen@oic.de) wrote: : Hi, : I'm looking for reporting tools, but I don't know which report writers are : available for OPENSTEP 4.x/Mach and EOF? Can someone give me an : advice which tools are available (and usable)? If you mean database reporting tools, check out CompleteAccess by Ocean Software (info@oceansoft.com) or DaTASMITH by BLaCKSMITH (info@blacksmith.com). They are both outstanding. I don't know what their availability is for OPENSTEP (as opposed to NEXTSTEP), though. 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: tkimpton@mail2.maned.com (Thomas R. Kimpton) Newsgroups: comp.sys.mac.programmer.codewarrior,comp.sys.mac.system,comp.sys.next.programmer Subject: Re: Mac/NeXT & Unix: File System Date: Fri, 28 Feb 1997 19:31:07 -0500 Organization: Managing Editor, Inc. Message-ID: <tkimpton-ya023180002802971931070001@newsserver.epix.net> References: <5ddp66$jpc@news.bu.edu> <5dtpb5$h4t@news.bu.edu> <Mn1TiBm00iVC81ZnAQ@andrew.cmu.edu> <AF2E42E196681EFC18@node50.tfs.net> <5eb9r5$iv2@csugrad.cs.vt.edu> <AF39A1D79668E697E@pm3-p20.tfs.net> <33145CC0.6C05@worldbank.org> <tkimpton-ya023180002702971745260001@newsserver.epix.net> <slrn45hdvdh.6p.campbejr@phu989.um.us.sbphrd.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In article <slrn45hdvdh.6p.campbejr@phu989.um.us.sbphrd.com>, soup@jtan.com wrote: [stuff deleted] > >int forkopen(char *name, int oflag, int forkNum); > > or fkopen() > > >int forkTypeToID(char *name, ForkType type); > >// returns the fork number of file name that has ForkType type :-) > > Why? I was thinking in terms of: int whichFork = forkTypeToIndex(name, 'RSRC'); if(whichFork != kNoSuchFork) fd = forkopen(name, O_RDWR,whichFork); > > This' be more logical as: > > fkstat() > > and what would be the return of the normal "stat" call. > > Additionally, this information must be replicated when > a link() call is performed, unless we do it via fklink(). > See below about links... > >If we allowed arbitrary numbers of forks per file: > >int forkCreate(char *name, ForkType type,ForkCreator creator); > > no, fkcreat() > or fkappend() > > Now is the information within a fork an actual file, > with it's own name? If it has an inode, it will > probably need to have it's own top-level file name... > In unix file systems 1 file == 1 fork (inode), in this file system 1 file == n forks (inodes). There would be no "unadorned" inodes. It has the same "name" as the 'DATA' fork, or the 'DBAS' fork, or the ... [stuff deleted] > > While at first blush this is a hot idea, there are > problems I'm having with it; I've focussed on enhancing > the i-node since it's the ultimate single point of maintenance > for a file system; Additions made at that level can be pretty > well hidden from all but a few existing Unix utilities (though > the criticism that we shouldn't have to open the file to see > which icon needs to be displayed is a good one). > One thing that I didn't mention was: with the addition of a define to dirent.h (direct.h or whatever): #define d_ino d_forks[0].d_ino you *should* be able to recompile the kernel, any utilities that depend on dirent.h (direct.h or whatever), use the newly compiled newfs to create new file systems, load the new kernel and utilities and run. Everything would ignore the superfluous fork information until new syscalls were added and utilities were modified to take advantage of multiple forks. (Additional work would probably be necessary to take advantage of arbitrary numbers of forks, however.) Any Linux gurus want to give this a try :-)? > Some have suggested adding type/creator codes and new > timestamps (like a *real* creation time) directly to the > inode would balloon the structure but would not require > opening it (so you can suck in the information w/ a stat() > call); The cost would be a reduction in capacity for a > file system and imposes limits on what can be expressed. > In unix, the inode contains (again, this is from Solaris 2.5) 3 timestamp fields ic_atime, ic_mtime, ic_ctime that are supposed to be last access time (should be anything that accesses the inode, whether for reading, writing, mode changing), modify time (anything that changes the inode: writing, mode changing) and creation date. Both mod and access times are settable, however, I don't believe the creation date is (except via resetting the clock, copying the file and removing the original :-). > Hmmmm... > > Maybe we can insert inode indices within an inode so it > can be treated as a cross reference. This moves the > fork information down to the inode again, placing a single > point of maintenance back at the actual file object and not > within the namespace. > Well with the inode refs coming from the directory structure, there's no intrusion in the name space: you have the original calls that access d_fork[0].d_ino in the open(name), and fkopen(name,forkIndex) accessing d_fork[forkIndex].d_ino still using the *same* name. A utility like cp (copies a file) wouldn't have to know anything about the contents of the file, just iterate over the number of forks to a file, and use ordinary read/write calls: numForks = GetNumForks(name); for(i=0,i < numForks, i++){ forkType = getForkType(name,i); forkCreator = getForkCreator(name,i); fkCreate(name2,forkType,forkCreator); fd = fkopen(name,0_RDONLY,i); fd2 = fkopen(name2,0_WRONLY,i); copy(fd,fd2); } copy(fd,fd2) { while(read(fd,buf,&bufSize)) write(fd2,buf,bufSize); } > While that's clunky, it certainly reduces overhead and drops > the number of changes needed to the Unix system; Extra ioctl() > and fcntl() calls could handle the file out-of-band information. > > Heck, creators/etc can have inodes and some information > in the /proc filesystem while the system is running... > > Hmmmm... > > We'd still have a limit to the number of forks a file could > have, but it's a compromise that allows Apple-like files to > coexist with the existing Unix utility suite- Which is the > primary thrust of this exercise... > [stuff deleted] Hard links would be a problem: they were created to allow a speed up of file access by duplicating directory entries (that contain the inode number, with only the name being changed)*, however, because the mac allows you to delete the forks of a file you could have inconsistent views of the file. With a file == inode system, when you remove a file you decrement the link count on the inode, remove the inode if link count == 0, then remove the directory entry. With file == n forks, you could remove a fork from file1 (actually you'd decrement the link count on the inode of that fork of the file) and remove it's inode reference from the directory entry, and file2 (that was a hard link to file1) would still contain that fork. This *may* not be a bad thing, but, I suspect this was a major reason why Apple only has Aliases (apple file structure analogous to soft links). * soft links are files that have the link bit set in the mode bits, they contain the name of the file, at the time the soft link was created. Thus accessing a soft linked file has an extra layer of lookup to get to the file, though it has the benefit that soft links can extend across file systems (volumes) while hard links cannot. I guess I just want to have the fork abstraction at a higher level than inside the inode :-). -- This address may *not* be used for unsolicited commercial mailings. Help stamp out SPAM in this thread's lifetime.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.