From cpr at stibo.dk Tue Apr 1 03:43:15 1997 From: cpr at stibo.dk (Claus Priisholm) Date: Thu Nov 3 14:40:19 2005 Subject: Obj-C GC? References: <9703318598.AA859848864@ccmail.kenan.com> Message-ID: <199704011143.NAA00288@supermule.aas.stibo.dk> Hi >Objective C looks very much like C with bits of smalltalk. I like >smalltalk. This is cool. But smalltalk is garbage collected. Is >Obj-C? What is the finalization technique? Is it like smalltalk >where I need to explicitly call release methods or more automatic >like C++ destructors? You'll have to release the stuff, or let the system autorelease it (which is NOT automatic garbage collection) , see http://www.next.com/Pubs/Documents/OPENSTEP/Foundation (Intro to Concepts) for a description of the concepts. --- Claus Priisholm (cpr@stibo.dk) From kjell at oops.se Tue Apr 1 00:29:55 1997 From: kjell at oops.se (Kjell Nilsson) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation In-Reply-To: <97Mar28.022221gmt-0100.28707-1@mimer.upnet.se> Message-ID: <97Apr1.155828gmt-0100.29729-1@mimer.upnet.se> What Is this really true? >Currently under OpenStep, there seems to be some sort of Mach-related >limitation when it comes to making an NSConnection; namely, the `host' >specification in the +rootProxyForConnectionWithRegisteredName:host: method >requires that the target host be on the local subnet! This shortcoming is >putting a huge crimp in our design, not to mention making Distributed Objects >far less versatile as a paradigm. We have been developing at large system under NS3.3 an NXConnexion and it works in several subnets. There is no limitation. We are supposed to port it to OpneStep in a month from now and this would be a drawback if it is true. -- Kjell Nilsson - Member of Swedish Object Guild OOPS art HB, Phone +46-31-499713, Fax +46-31-474594 URL http://www.oops.se kjell@oops.se - NeXTMail, Mime welcome From ernest at alumni.caltech.edu Tue Apr 1 08:43:13 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <199704011643.IAA18707@alumnae.caltech.edu> I though the rule was that -broadcast- only worked on a subnet. If you specify a hostname, it will work anywhere. Of course, I haven't used it recently. -- Ernie P. >Currently under OpenStep, there seems to be some sort of Mach-related >limitation when it comes to making an NSConnection; namely, the `host' >specification in the +rootProxyForConnectionWithRegisteredName:host: method >requires that the target host be on the local subnet! This shortcoming is >putting a huge crimp in our design, not to mention making Distributed Objects >far less versatile as a paradigm. From mtarbell at akina.jpl.nasa.gov Tue Apr 1 10:23:13 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation In-Reply-To: <9704011703.AA26368@oz.next.com> References: <9703272300.AA06568@akina.jpl.nasa.gov> <9704011703.AA26368@oz.next.com> Message-ID: <9704011823.AA09238@akina.jpl.nasa.gov> Chris Kane writes: > Perhaps there is a firewall between you and the other subnet, or > some other network configuration issue. Yes, that is what the problem is. We are connecting D.O.'s to/from JPL and a subhost in a foreign domain; JPL (local) is apparently trying to do a reverse resolve to get the foreign machine and domain name and only the main remote node is in the DNS server at that site's ISP. I have tried establishing D.O. connections from that foreign site to a vended object at a specially configured JPL site, and it works in that direction; only in the reverse direction, it hangs (as expected, I guess). Fortunately, my suspicion of a Mach nmserver limitation is proved wrong; this also verifies that D.O.'s handily traverse subnets, as is claimed. Many thanks to all who answered. Sorry to have caused any panic. Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From toon Tue Apr 1 10:41:22 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation In-Reply-To: <199704011643.IAA18707@alumnae.caltech.edu> References: <199704011643.IAA18707@alumnae.caltech.edu> Message-ID: <9704011841.AA22365@omnigroup.com> > Currently under OpenStep, there seems to be some sort of > Mach-related limitation when it comes to making an NSConnection; > namely, the `host' specification in the > +rootProxyForConnectionWithRegisteredName:host: method > requires that the target host be on the local subnet! This > shortcoming is putting a huge crimp in our design, not to mention > making Distributed Objects far less versatile as a paradigm. This is absolutely not true. I have a couple DO apps running that are talking to servers 14 network hops and 8 time zones away at this particular moment. The host parameter in making the connection can be one of three things: - The empty string: looks on the local machine only. - A "*": broadcasts to find a host on the current subnet. - Any other string: a machine name. (e.g. "www.omnigroup.com") It is only the broadcast method where you are unsure of the machine you want to connect to that is limited to local subnets. (You wouldn't want to broadcast to every host on the internet, after all...) If you need to do broadcasts between subnets to find a service it is pretty easy to write a set of DO servers with one sitting on each subnet and explicitly connected to each other to provide naming services between the subnets. It would be cool if NeXT provided this kind of "gateway between subnets" / higher level naming service with DO, but it is really pretty trivial to do it yourself as well. If this is what you need to do, feel free to e-mail and I can go into more detail. -Greg From Aris_Colp at next.com Tue Apr 1 13:39:58 1997 From: Aris_Colp at next.com (Aris Colp) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation References: <199704011643.IAA18707@alumnae.caltech.edu> Message-ID: <9704012139.AA28894@femail.next.com> Another method would to be use NetInfo as a location finder for DO servers - but I don't think NeXT has done this. A. >I though the rule was that -broadcast- only worked on a subnet. >If you specify a hostname, it will work anywhere. Of course, I haven't >used it recently. > >>Currently under OpenStep, there seems to be some sort of Mach-related >>limitation when it comes to making an NSConnection; namely, the `host' >>specification in the +rootProxyForConnectionWithRegisteredName:host: method >>requires that the target host be on the local subnet! This shortcoming is >>putting a huge crimp in our design, not to mention making Distributed >>Objects far less versatile as a paradigm. -- Aris Colp NeXT Technical Support, Apple Computer Inc. aris@next.com; +1-415-780-3712; http://www.next.com/~aris From dmoore at gage.com Tue Apr 1 14:02:38 1997 From: dmoore at gage.com (Doug Moore) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <199703272232.QAA01322@falstaff.cmg.FCNBD.COM> References: <199703272232.QAA01322@falstaff.cmg.FCNBD.COM> Message-ID: <9704012202.AA02455@leinie.gage.com> I for one think that NeXT has opened up a large opportunity for someone to step in and provide a workable Project Builder. Granted, there are some nice features in the new PB. I do find myself using the code browser, and there are some nice usability functions in gdb (adding an executable to launch for example, makes bundle debugging much nicer...) I have not used any bundles to extend PB, but will concede that as a powerful addition. But this all in one design makes it more painful than necessary. I can not understand why the pre-4.x PB, IMHO a very good example of how different apps could be made to work with one another(PB,Edit,Terminal), was made into this monolithic beast. This is a Word-like PB from the company that brought us WriteNow. It is cumbersome for those of us who have more than one project ongoing at any one time -- everything's an inspector! Project Builder should be a makefile manager that knows how to build things. (make depend anyone?) Just like the old days. Edit (or TextEdit with all of Edit's features) is a better text editor, add a code browser if you want. Better yet, tell us how we can add it if we want. A seperate, semi gui gdb app would be nice, or once again, give us the api's so that we can do that too. I'll admit that the old programs had their problems. The new PB addressed many of those, at the expense of the flexibility and elegance of a collection of single purpose, specialized tools. This all reeks of trying to make things work under NT. Hopefully Apple will put an end to that junk being our lowest common denominator, and let this OS shine the way it can. To Apple -- Do Rhapsody well, port it to everything (Intel,DEC,SGI,Sun,HPPA,etc), and give the world a better choice. Doug Moore Gage Marketing Group OpenStep/EOF2 Development NeXTMail forever From mark at oaai.com Tue Apr 1 17:39:32 1997 From: mark at oaai.com (Mark Onyschuk) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <19970402013933056.AAA621@sapphire> When you attempt to connect to a D.O. server by name, you can either attempt to connect to a server on a named host, on the local host, or on some host on the subnet. The last option (connecting to host "*") involves UDP broadcast and so is typically limited to your subnet. We've run a number of D.O. processes over wide area networks by being explicit about the destination host when we connect via NSConnection. 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 ---------- > From: Kjell Nilsson > To: Multiple recipients of list > Subject: Re: Mach & D.O. Limitation > Date: Tuesday, April 01, 1997 11:28 AM > > What > Is this really true? > > >Currently under OpenStep, there seems to be some sort of Mach-related > >limitation when it comes to making an NSConnection; namely, the `host' > >specification in the +rootProxyForConnectionWithRegisteredName:host: method > >requires that the target host be on the local subnet! This shortcoming is > >putting a huge crimp in our design, not to mention making Distributed Objects > >far less versatile as a paradigm. > > We have been developing at large system under NS3.3 an NXConnexion and it works > in several subnets. There is no limitation. We are supposed to port it to OpneStep > in a month from now and this would be a drawback if it is true. > > -- > Kjell Nilsson - Member of Swedish Object Guild > OOPS art HB, Phone +46-31-499713, Fax +46-31-474594 > URL http://www.oops.se > kjell@oops.se - NeXTMail, Mime welcome From andrew Tue Apr 1 17:48:53 1997 From: andrew (Andrew Abernathy) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <9704020148.AA28573@omnigroup.com> Doug Moore writes: > I for one think that NeXT has opened up a large opportunity for someone to > step in and provide a workable Project Builder. [...] > But this all in one design makes it more painful than necessary. I can not > understand why the pre-4.x PB, IMHO a very good example of how different apps > could be made to work with one another(PB,Edit,Terminal), was made into this > monolithic beast. This is a Word-like PB from the company that brought us > WriteNow. It is cumbersome for those of us who have more than one project > ongoing at any one time -- everything's an inspector! Personally, I find the new PB very nice - integrating all this has made my development much easier (currently I usually have three projects open at once). Going back to the 3.x environment has become excruciating. I'm not sure that this level of integration could really be achieved via communicating apps. However, I do appreciate that many people prefer using different editors, etc. Note that you can easily rid yourself of the code view simply by sizing it out of the window. Then you still need to be able to communicate with your Editor of Choice: some support for that is there now and more is coming, though I'm not sure exactly how much. -andrew From wjs Tue Apr 1 19:31:15 1997 From: wjs (William Shipley) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <9704020331.AA29327@omnigroup.com> Doug Moore writes: > Edit (or TextEdit with all of Edit's features) is a better text editor, add > a code browser if you want. Better yet, tell us how we can add it if we > want. Now, hold on just a minute there, cowboy. I agree PB should be split up into several apps, but Edit and TextEdit are pathetic next to the power that is ProjectBuilder. PB 4.0 has much richer support for emacs keys and functions (including incremental search, split windows, swap characters, kill rings, and the hidden but always necessary towers-of-hanoi) than Edit, and its ability to do context finds and quick project-wide search and replace is unparalleled. You can also open two windows on the same file and they automatically stay in sync. PB is a great editor. Sure, I'd like to see the debugger and build windows broken out into their own apps so I could, for example, use the Java debugger (if there were one that didn't crash) if I were working on a Java project. -Wil From j_frey at lvc.edu Wed Apr 2 10:30:25 1997 From: j_frey at lvc.edu (Jeffrey Frey) Date: Thu Nov 3 14:40:19 2005 Subject: A new NSEvent Message-ID: In the interest of making Rhapsody a more fluid environment to develop in, wouldn't it make sense to expand the NSEvent class to incorporate AppleEvents? Personally, I found the environment proposed in Copland to be really cool -- AppleEvents would have been used not only for specialized events, but also for mouse clicks, key presses, etc. Does anyone else have an opinion or maybe facts to the contrary to add? Also, I'm under the impression at this time that sub-classing the NSEvent class would be a possibility in implementing AppleEvents? -Jeff -------------------------------------------------------- Jeffrey T. Frey SimplisticSolutions(TM) Lebanon Valley College Software Design & Computer Services Dept. Macintosh Consulting (Head Lab Asst.) (Founder, Programmer) Specializing in software and hardware solutions for users of the Apple Macintosh. j_frey@lvc.edu Work:(717)867-6072 Home:(717)272-6597 http://indigo.lvc.edu/~jfrey -------------------------------------------------------- From lbrooks at apl.bbdo.com Wed Apr 2 11:41:09 1997 From: lbrooks at apl.bbdo.com (Leigh Brooks) Date: Thu Nov 3 14:40:19 2005 Subject: NeXT help Message-ID: <1352140795-284405950@apl.bbdo.com> I realize this might not be the best place to ask a few questions that I have, but... I recently got a pre-release of OpenStep 4.2 for Mach, which came with a boot floppy for black hardware. Of course, my machine being a circa '91 '040 cube, I have no floppy drive. Is there any way of creating a bootable disk image on the MO drive? Even if I can get that to work I supposed I'm still hosed as there doesn't seem to be a boot floppy image for 4.2 on the NeXT site. And neither PC or Mac seem to be able to read the floppy to be able to ftp to the cube. Any help you could provide would be greatly appreciated. Also is there an OpenStep beginners list? Thanks Leigh Brooks From robertm at next.com Thu Apr 3 11:05:37 1997 From: robertm at next.com (Robert MacKimmie) Date: Thu Nov 3 14:40:19 2005 Subject: Apple Announces Cross-Platform Strategy for "MacOS X" Next-Generation Operating System Message-ID: <9704031905.AA00993@oz.next.com> [Press Release] Apple Announces Cross-Platform Strategy for "MacOS X" Next-Generation Operating System New "OpenStep eXtended" Allows "Write Once, Run Anywhere" on Mac, Windows, and Solaris systems; OS X Native Licensed to PPCP and Intel Clone Makers, Windows runtimes to Developers; Sun and Apple to collaborate on "JavaStep" APIs. [Image] "MacOS X" for Mac Platforms; "OS X" for Other Platforms [Image] OS X Technology Allows "Write Once, Run Anywhere" [Image] OS X to be fully integrated with Java and Java APIs [Image] Cross-Platform Push Supported by Aggressive Licensing [Image] OS X Runtime for Windows to be Distributed With Applications [Image] Industry Reaction Overwhelmingly Positive CUPERTINO, Calif.--Apr. 1, 1997--Apple Computer, Inc. today announced its long-awaited cross-platform strategy for "MacOS X", the next-generation operating system chosen as the successor to MacOS. Originally code-named Rhapsody, MacOS X builds upon the cross-platform OpenStep technology acquired from NeXT Software, Inc., as part of the December 20 acquisition which also brought back co-founder Steve Jobs, now CEO of Pixar. The cross-platform components of MacOS X will be known simply as "OS X", which stands for "OpenStep eXtended". These include the "Yellow Box" APIs (OpenStep and QTML) as well as the associated runtimes, and will run natively on PPCP and Intel hardware, as well as on top of Sun's Solaris and Microsoft's Windows NT and 95. In addition, Sun and Apple have announced the "JavaStep" initiative which includes Java bindings for OpenStep and QTML, as well as a commitment to converge the server (JavaStep) and client (AWT) APIs by the end of 1998. [Image] "MacOS X" for Mac Platforms; "OS X" for Other Platforms Apple's new operating system for the Macintosh will be called "MacOS X," with subsequent releases using roman numerals, i.e. MacOS XI, MacOS XII, etc. The name was chosen to stress the continuity for existing Mac users. "You can run the same applications on the same industry-leading hardware with a familiar look and feel - except with more speed, power, and reliability" explains Rhapsody Product Manager Ernie Prabhakar. "For existing Mac users, that means this effectively is a MacOS, so for them we call it MacOS 10." This new operating system, however, will run on much more than Macintosh hardware. To emphasize this, Apple has named the cross-platform portion "OS X". "OS X covers a range of products and technologies [see box], but basically it just MacOS X without the "Blue Box" compatibility layer," explains Prabhakar. "We wanted to make 80% of the Macintosh experience available to non-Mac users, as well as create an expanded market for people who write to the "Yellow Box" APIs. [TABLE] Name CPU Kernel UI System 7/8 compatibility? MacOS X PowerPC Mach Mac/NeXT Yes OS X "native" Intel/SPARC Mach Mac/NeXT From third-parties Windows OS X Intel Windows Windows N/A Solaris OS X SPARC Solaris CDE/NeXT MAE MacOS X and OS X "native" use NeXT's Mach kernel with 4.4 BSD UNIX as the base operating system. They are essentially identical, except that the System 7/8 compatibility layer will only be available on the PPCP platform. "The [old] MacOS is very tied to hardware, both technically and culturally," explains Prabhakar. "We want to respect that, but allow OS X to break new ground on its own." The 'foreign OS' versions of OS X for Solaris(tm) and Windows(tm) consist of the Objective-C runtime (including Distribute Objects) and Display PostScript (tm). "Our vision of OS X for other operating systems is primarily a way to deploy our apps in their environment, so we wanted to respect their look and feel," he adds. He also notes that Sun is updating their user interface to be more Mac-like. [Image] OS X Technology Allows "Write Once, Run Anywhere" OS X can be thought of as "OpenStep eXtended", as it is based primarily on the public OpenStep specification published by NeXT and Sun in 1994. It incorporates the API used in OpenStep 4.2 as well as Apple's Quick Time Media Layer (QTML). "We've taken it [QTML] and integrated it with NeXT's object frameworks to create an environment that is as pleasant for the developer as it is thrilling to the end-user," explains Prabhakar. Applications written to the OS X API can be cross-compiled for MacOS X and OS X native, as well as recompiled for Windows and Solaris OS X. "NeXT's fat binary technology and the GNU cross-compiler make compiling for multiple CPUs as easy as clicking a button. It just works!" exclaims Prabhakar. Apple is working with Sun to extend fat binaries to the Solaris platform, but currently users must have access to a Solaris machine, as they need to for Windows OS X. [Development is not supported under Windows 95(tm), so apps must be compiled under Windows NT(tm)]. The comprehensive and machine independent nature of the OS X API allow recompilation to be a trivial task. "We expect there to be a strong market in service bureaus that will handle things like cross-platform recompilation and testing, as well as internationalization," he suggests. The end-result will be that code written for OS X developers can be deployed any major operating system. "Any developer who writes for OS X will be guaranteed the best possible development tools and the largest possible market," asserts Prabhakar. "Why develop anywhere else?" [Image] OS X to be fully integrated with Java and Java APIs Adding to the momentum, Sun and Apple announce a broad cross-licensing strategy aimed at converging the Java and OpenStep APIs. "I've always thought the market-leading UNIX vendor should work with the most popular platform for content development" jokes Sun CEO Scott McNealy, "but I never thought that Apple would be the former and that we would be the latter!" Under the terms of the agreement, Apple will acquire the rights to use the "JavaStep" name for the Java bindings for OpenStep, and the AWT will be implemented on top of JavaStep. "Everything but the AppKit was translated into Java as part of the WebObject's project," explains Apple's Prabhakar. "The rest should be available in Java by the June developer release. While Java lacks some nice features of Objective-C, we realize the importance of Java, and will make OpenStep as accessible to Java programmers as is humanly possible." He also adds that OpenStep will be programmable from other popular languages, include C++ and Object Pascal. Sun will upgrade their OpenStep implementation to "JavaStep X" by the end of the year, and ship it as the default development environment for Solaris machines. Sun and Apple have cross-licensed QTML and JavaMedia and are committed to developing a "JavaTime" media layer which blends the Java APIs with the QTML architecture. Long-term, Sun and Apple intend to migrate JavaStep and the Java AWT into a single API, using Adobe's Bravo as the core imaging technology. [Image] Cross-Platform Push Supported by Aggressive Licensing Though pricing has not yet been finalized, Apple has promised to make OS X available on terms comparable to Microsoft's market-leading server operating system Windows NT (tm), at prices slightly higher than current MacOS licenses. Pricing will be independent of the type of CPU (PPC, Intel, SPARC), but will be higher for multi-CPU boxes. There will also be a server edition which comes pre-installed with Apple's award-winning "WebObjects (tm)" dynamic web-page system. The PPC version will be available through normal MacOS channels, and the SPARC version through Sun and its distributors. The native Intel version, however, will initially only be available to manufacturers, value-added resellers, and corporate customers. "Installing a new operating system on an Intel PC is a maze of hardware conflicts," explains Prabhakar. "We want every user to have a positive experience with OS X, and that means ensuring they get it pre-installed or through someone who can work out the configuration issues." He added that campus resellers will receive special training to allow them to make OS X/Intel widely available to students. Academic and non-profit institutions can obtain site-licenses which allow them to install OS X and OS X developer on any PowerMac or Intel machines, with a special discount for universities which teach courses on OS X programming. Apple is committed to becoming an 'agnostic' supplier of software. "We charge Apple's hardware division the same price we charge clone manufacturers," claimed Prabhakar. "They can run anything they want, and we can run anywhere we want." Apple is also exploring SGI and Alpha ports, as well as Linux support (possibly through the GNUstep project). Prabhakar confirmed that Apple will continue to focus on selling PPC-based hardware to education, publishing, and mainstream consumer markets, leaving Intel and other markets to the clone manufacturers. Already, Dell computer has promised that it will ships Windows NT/OS X dual-boot systems in 1998, and UMAX has announced both MacOS X/PPC and OS X/Intel clones. Apple's corporate sales force (inherited from NeXT) will continue to sell OS X-based software solutions using a variety of hardware partners. [Image] OS X Runtime for Windows to be Distributed With Applications The most innovative part is Apple's intended pricing scheme for Windows runtimes. There are two tiers. The normal "OS X foreign client" is targeted primarily at large corporate and academic sites. It includes a fully-enabled runtime, as well as tools to emulate the MacOS X user interface and networking tools. Users can buy any OS X app that supports Windows and run it directly, just as if they were using MacOS X. The second tier uses Richard Crandall's patented FEE public-key encryption technology to create what it calls "dynamic installicensing." Every "OS X for Windows NT" developer package includes an exportable copy of the OS X foreign runtime (which can run on either NT or 95). The developer can create a "extrafat" application which includes the OS X runtime. After registering a unique public key, the developer can distribute the runtime along with the application at a cost of 5% of sales. During installation of the app, it will install the runtime if it is not already present. The app will then license itself with that runtime. The runtime will be network aware, and notify users of inappropriate usage or updates. Shareware developers can register for a "free rider" public key which will allow their applications to run using any runtime that is already licensed for a commercial application. This technology allows naive Windows users to purchase and run OS X applications as if they were normal Windows applications, without any visible cost or extra effort. The technology is also being adapted for network licensing and demo applications. [Image] Industry Reaction Overwhelmingly Positive "I am ecstatic to have the best operating system in the world widely available on the best chips in the world." -- Andy Grove, CEO, Intel Corp. "We are pleased to be the premier provider of both Intel and PPC solutions for OS X customers." -- Connie Geiger, Channel Marketing, UMAX Computer Corp. "We have been using OS X technology internally for months, and we are thrilled to be finally able to offer it to our customers." -- Michael Dell, CEO, Dell Computer, Inc.. "Microsoft congratulates Apple on finally articulating a strategy, and will provide the OS X runtime the same fine support Microsoft gives all its developers" -- Dara Smith, Microsoft Public Relations "At last! This is what Apple developers have been waiting for. There'll be no stopping us now." -- Greg Anderson, President, Anderson Financial Systems "With OS X cross-platform, Apple has the best development and deployment strategy imaginable. OS X developers will kick butt." -- Andrew Stone, Chairman and CEO, Stone Design "I want my OS X! Now!" -- Don Yacktman, Chief Architect, MiscKit ------------------------------------------------ [Press Information Contact:] Rohit Khare OpenStep Users International 1115 Cordova St. Suite 114 Pasadena, CA 91106 (818) 568-9168 email: khare@w3.org References: Message-ID: <199704040457.XAA18555@digifix.com> You wrote: > In the interest of making Rhapsody a more fluid environment to develop > in, wouldn't it make sense to expand the NSEvent class to incorporate > AppleEvents? Personally, I found the environment proposed in Copland to be > really cool -- AppleEvents would have been used not only for specialized > events, but also for mouse clicks, key presses, etc. Does anyone else have > an opinion or maybe facts to the contrary to add? Also, I'm under the > impression at this time that sub-classing the NSEvent class would be a > possibility in implementing AppleEvents? AppleEvents proper don't really fit into OpenStep frameworks, an while NSEvents are certainly important, you don't often act on them directly... usually a class gets the event (a responder), and you may or may not look at the actual event object to find out more details about the event (what additional keys are pressed, etc..). You don't have to assume the responsiblity for looking at an event and then figuring out which window its in etc... The 'event' notion of AppleEvents seems to me like a way to get it to work under the Toolbox environment with a minimum of impact on the existing programs. With the exception of the 'basic' AppleEvents (open, print, quit etc..) pretty much everything else falls into the category of 'support to allow scripting of an application'. Since AppKit handles the majority of the basic interaction like this, adding stuff like 'select third word of fourth paragraph' will be easy to add using the notion of a first responder.. Similarly 'send mousedown to first responder at x,y' will also be something that the developer will really never have to deal with directly... they'll just get a mousedown: in the first responder. More complex stuff like 'select third word of fourth paragaph' would be even easier since all you really are doing is specifying a selection to an NSText object. Extend NSText's NSSelection protocol to support more complex selection hueristics and every app gets that capability. Back to the regular AppleEvents (open, print, quit etc )... Since every application on OpenStep has an NSApplication (or a subclass of it) the basic events are covered off using an NSApplication delegate. Delegates are 'helper' objects that you create for some classes. If an NSApplication has had a delegate set using setDelegate:, certain messages will be sent by the NSApplication when it needs things to be done. for example, if you double click on a file in the Workspace, the application for that document type will start (if it isn't already) and the NSApplication object receives a message that a file needs to be opened. If you've done a setDelegate:, the object that you've set to be the delegate will receive an - (BOOL)application:(NSApplication *)theApplication openFile:(NSString *)filename And you should then have it do what is appropriate for your application (open a new document with the file is the usual thing). There are NSApplication delegate methods for the expected open, print, quit etc... Many classes have delegate capabilities. From zander at conextions.com Thu Apr 3 21:05:47 1997 From: zander at conextions.com (Aleksey Sudakov) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <9704020331.AA29327@omnigroup.com> References: <9704020331.AA29327@omnigroup.com> Message-ID: <9704040505.AA00185@conextions.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 774 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970404/62191fd0/attachment.bin From fischer at fokus.gmd.de Thu Apr 3 22:29:07 1997 From: fischer at fokus.gmd.de (Robert Fischer) Date: Thu Nov 3 14:40:19 2005 Subject: NeXT help Message-ID: <9704040629.AA03269@unkerich.fokus.gmd.de> To upgrade an installed NeXTStep or OPENSTEP system you don't need a floppy to start up. There is an 'Upgrader.app' on CD. To boot from MOD you may use 'BuildDisk' (in /NextAdmin) to create a bootable system on the MOD. I have never tried this but it should work even from a MOD. The flopy is needed for a complete install with formatting the disk. Regards, Robert -- ----- - .-. -- -- --- / \ ---- Robert Fischer .-. / \ --- .-. __o .-. @ / \ / \ / \ _\<,_ / \ GMD-Fokus / \ / \ / \ (*)/ (*) / -------------- / ---' -' -----------' BTW: Watch for your NDA! R. From lukeh at xedoc.com.au Fri Apr 4 00:01:55 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <199704040801.SAA04610@alpha.xedoc.com.au> At 13:39 1/04/97 -0800, you wrote: > >Another method would to be use NetInfo as a location finder for DO servers - >but I don't think NeXT has done this. Well, it's not hard to do, particularly with the NIAccess.framework provided with OPENSTEP for Mach (and, presumably, Rhapsody). NeXT don't provide any direct support for NetInfo in DO -- eg. there's no established schema for registering DO string binding handles in NetInfo, or any methods in NSConnection for locating a DO server using NetInfo. There is an obscure NeXTanswer (one of the old NXApp issues, I believe) that vaguely hints at this idea, and for organisations which have deployed it, NetInfo is suitable "location broker". Then again, so is LDAP -- so it's probably best left in the hands of the developer, or a higher level API (like ADSI or JNDI). -- Luke (By way of introduction, I'm responsible for maintaining the NetInfo ports at Xedoc. I'm also doing some work on deploying LDAP as a replacement for NIS.) From fischer at fokus.gmd.de Thu Apr 3 23:23:19 1997 From: fischer at fokus.gmd.de (Robert Fischer) Date: Thu Nov 3 14:40:19 2005 Subject: Apple Announces Cross-Platform Strategy for "MacOS X" Next-Generation Message-ID: <9704040723.AA03699@unkerich.fokus.gmd.de> > CUPERTINO, Calif.--Apr. 1, 1997 C'mon, it's 4th of April today! R. -- ----- - .-. -- -- --- / \ ---- Robert Fischer .-. / \ --- .-. __o .-. @ / \ / \ / \ _\<,_ / \ GMD-Fokus / \ / \ / \ (*)/ (*) / -------------- / ---' -' -----------' From Mark.Anenberg at Eng.Sun.COM Thu Apr 3 15:01:18 1997 From: Mark.Anenberg at Eng.Sun.COM (Mark Anenberg) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation References: <199704040801.SAA04610@alpha.xedoc.com.au> Message-ID: <199704041501.HAA13899@velodrome.eng.sun.com> Yes, but netinfo is not part of the OpenStep Specification; It exists on OPENSTEP for Mach, but not Solaris OpenStep(NIS or NISPLUS) or NT(?); You can't count on it being there. For that matter, the whole DO wire protocol is not part of the OpenStep spec. It should be , but it aint. -Mark Begin forwarded message: From: Luke Howard To: Multiple recipients of list Subject: Re: Mach & D.O. Limitation At 13:39 1/04/97 -0800, you wrote: > >Another method would to be use NetInfo as a location finder for DO servers - >but I don't think NeXT has done this. Well, it's not hard to do, particularly with the NIAccess.framework provided with OPENSTEP for Mach (and, presumably, Rhapsody). NeXT don't provide any direct support for NetInfo in DO -- eg. there's no established schema for registering DO string binding handles in NetInfo, or any methods in NSConnection for locating a DO server using NetInfo. There is an obscure NeXTanswer (one of the old NXApp issues, I believe) that vaguely hints at this idea, and for organisations which have deployed it, NetInfo is suitable "location broker". Then again, so is LDAP -- so it's probably best left in the hands of the developer, or a higher level API (like ADSI or JNDI). -- Luke (By way of introduction, I'm responsible for maintaining the NetInfo ports at Xedoc. I'm also doing some work on deploying LDAP as a replacement for NIS.) From Magotron at aol.com Fri Apr 4 08:15:41 1997 From: Magotron at aol.com (Magotron@aol.com) Date: Thu Nov 3 14:40:19 2005 Subject: IS THIS FOR REAL??????? Message-ID: <970404111540_1850017436@emout02.mail.aol.com> In a message dated 97-04-04 02:02:29 EST, robertm@next.com (Robert MacKimmie) writes: << rhapsody-dev@omnigroup.com >> --------------------- Forwarded message: From: robertm@next.com (Robert MacKimmie) Sender: rhapsody-dev@omnigroup.com Reply-to: robertm@next.com To: rhapsody-dev@omnigroup.com (Multiple recipients of list) Date: 97-04-04 02:02:29 EST [Press Release] Apple Announces Cross-Platform Strategy for "MacOS X" Next-Generation Operating System New "OpenStep eXtended" Allows "Write Once, Run Anywhere" on Mac, Windows, and Solaris systems; OS X Native Licensed to PPCP and Intel Clone Makers, Windows runtimes to Developers; Sun and Apple to collaborate on "JavaStep" APIs. [Image] "MacOS X" for Mac Platforms; "OS X" for Other Platforms [Image] OS X Technology Allows "Write Once, Run Anywhere" [Image] OS X to be fully integrated with Java and Java APIs [Image] Cross-Platform Push Supported by Aggressive Licensing [Image] OS X Runtime for Windows to be Distributed With Applications [Image] Industry Reaction Overwhelmingly Positive CUPERTINO, Calif.--Apr. 1, 1997--Apple Computer, Inc. today announced its long-awaited cross-platform strategy for "MacOS X", the next-generation operating system chosen as the successor to MacOS. Originally code-named Rhapsody, MacOS X builds upon the cross-platform OpenStep technology acquired from NeXT Software, Inc., as part of the December 20 acquisition which also brought back co-founder Steve Jobs, now CEO of Pixar. The cross-platform components of MacOS X will be known simply as "OS X", which stands for "OpenStep eXtended". These include the "Yellow Box" APIs (OpenStep and QTML) as well as the associated runtimes, and will run natively on PPCP and Intel hardware, as well as on top of Sun's Solaris and Microsoft's Windows NT and 95. In addition, Sun and Apple have announced the "JavaStep" initiative which includes Java bindings for OpenStep and QTML, as well as a commitment to converge the server (JavaStep) and client (AWT) APIs by the end of 1998. [Image] "MacOS X" for Mac Platforms; "OS X" for Other Platforms Apple's new operating system for the Macintosh will be called "MacOS X," with subsequent releases using roman numerals, i.e. MacOS XI, MacOS XII, etc. The name was chosen to stress the continuity for existing Mac users. "You can run the same applications on the same industry-leading hardware with a familiar look and feel - except with more speed, power, and reliability" explains Rhapsody Product Manager Ernie Prabhakar. "For existing Mac users, that means this effectively is a MacOS, so for them we call it MacOS 10." This new operating system, however, will run on much more than Macintosh hardware. To emphasize this, Apple has named the cross-platform portion "OS X". "OS X covers a range of products and technologies [see box], but basically it just MacOS X without the "Blue Box" compatibility layer," explains Prabhakar. "We wanted to make 80% of the Macintosh experience available to non-Mac users, as well as create an expanded market for people who write to the "Yellow Box" APIs. [TABLE] Name CPU Kernel UI System 7/8 compatibility? MacOS X PowerPC Mach Mac/NeXT Yes OS X "native" Intel/SPARC Mach Mac/NeXT From third-parties Windows OS X Intel Windows Windows N/A Solaris OS X SPARC Solaris CDE/NeXT MAE MacOS X and OS X "native" use NeXT's Mach kernel with 4.4 BSD UNIX as the base operating system. They are essentially identical, except that the System 7/8 compatibility layer will only be available on the PPCP platform. "The [old] MacOS is very tied to hardware, both technically and culturally," explains Prabhakar. "We want to respect that, but allow OS X to break new ground on its own." The 'foreign OS' versions of OS X for Solaris(tm) and Windows(tm) consist of the Objective-C runtime (including Distribute Objects) and Display PostScript (tm). "Our vision of OS X for other operating systems is primarily a way to deploy our apps in their environment, so we wanted to respect their look and feel," he adds. He also notes that Sun is updating their user interface to be more Mac-like. [Image] OS X Technology Allows "Write Once, Run Anywhere" OS X can be thought of as "OpenStep eXtended", as it is based primarily on the public OpenStep specification published by NeXT and Sun in 1994. It incorporates the API used in OpenStep 4.2 as well as Apple's Quick Time Media Layer (QTML). "We've taken it [QTML] and integrated it with NeXT's object frameworks to create an environment that is as pleasant for the developer as it is thrilling to the end-user," explains Prabhakar. Applications written to the OS X API can be cross-compiled for MacOS X and OS X native, as well as recompiled for Windows and Solaris OS X. "NeXT's fat binary technology and the GNU cross-compiler make compiling for multiple CPUs as easy as clicking a button. It just works!" exclaims Prabhakar. Apple is working with Sun to extend fat binaries to the Solaris platform, but currently users must have access to a Solaris machine, as they need to for Windows OS X. [Development is not supported under Windows 95(tm), so apps must be compiled under Windows NT(tm)]. The comprehensive and machine independent nature of the OS X API allow recompilation to be a trivial task. "We expect there to be a strong market in service bureaus that will handle things like cross-platform recompilation and testing, as well as internationalization," he suggests. The end-result will be that code written for OS X developers can be deployed any major operating system. "Any developer who writes for OS X will be guaranteed the best possible development tools and the largest possible market," asserts Prabhakar. "Why develop anywhere else?" [Image] OS X to be fully integrated with Java and Java APIs Adding to the momentum, Sun and Apple announce a broad cross-licensing strategy aimed at converging the Java and OpenStep APIs. "I've always thought the market-leading UNIX vendor should work with the most popular platform for content development" jokes Sun CEO Scott McNealy, "but I never thought that Apple would be the former and that we would be the latter!" Under the terms of the agreement, Apple will acquire the rights to use the "JavaStep" name for the Java bindings for OpenStep, and the AWT will be implemented on top of JavaStep. "Everything but the AppKit was translated into Java as part of the WebObject's project," explains Apple's Prabhakar. "The rest should be available in Java by the June developer release. While Java lacks some nice features of Objective-C, we realize the importance of Java, and will make OpenStep as accessible to Java programmers as is humanly possible." He also adds that OpenStep will be programmable from other popular languages, include C++ and Object Pascal. Sun will upgrade their OpenStep implementation to "JavaStep X" by the end of the year, and ship it as the default development environment for Solaris machines. Sun and Apple have cross-licensed QTML and JavaMedia and are committed to developing a "JavaTime" media layer which blends the Java APIs with the QTML architecture. Long-term, Sun and Apple intend to migrate JavaStep and the Java AWT into a single API, using Adobe's Bravo as the core imaging technology. [Image] Cross-Platform Push Supported by Aggressive Licensing Though pricing has not yet been finalized, Apple has promised to make OS X available on terms comparable to Microsoft's market-leading server operating system Windows NT (tm), at prices slightly higher than current MacOS licenses. Pricing will be independent of the type of CPU (PPC, Intel, SPARC), but will be higher for multi-CPU boxes. There will also be a server edition which comes pre-installed with Apple's award-winning "WebObjects (tm)" dynamic web-page system. The PPC version will be available through normal MacOS channels, and the SPARC version through Sun and its distributors. The native Intel version, however, will initially only be available to manufacturers, value-added resellers, and corporate customers. "Installing a new operating system on an Intel PC is a maze of hardware conflicts," explains Prabhakar. "We want every user to have a positive experience with OS X, and that means ensuring they get it pre-installed or through someone who can work out the configuration issues." He added that campus resellers will receive special training to allow them to make OS X/Intel widely available to students. Academic and non-profit institutions can obtain site-licenses which allow them to install OS X and OS X developer on any PowerMac or Intel machines, with a special discount for universities which teach courses on OS X programming. Apple is committed to becoming an 'agnostic' supplier of software. "We charge Apple's hardware division the same price we charge clone manufacturers," claimed Prabhakar. "They can run anything they want, and we can run anywhere we want." Apple is also exploring SGI and Alpha ports, as well as Linux support (possibly through the GNUstep project). Prabhakar confirmed that Apple will continue to focus on selling PPC-based hardware to education, publishing, and mainstream consumer markets, leaving Intel and other markets to the clone manufacturers. Already, Dell computer has promised that it will ships Windows NT/OS X dual-boot systems in 1998, and UMAX has announced both MacOS X/PPC and OS X/Intel clones. Apple's corporate sales force (inherited from NeXT) will continue to sell OS X-based software solutions using a variety of hardware partners. [Image] OS X Runtime for Windows to be Distributed With Applications The most innovative part is Apple's intended pricing scheme for Windows runtimes. There are two tiers. The normal "OS X foreign client" is targeted primarily at large corporate and academic sites. It includes a fully-enabled runtime, as well as tools to emulate the MacOS X user interface and networking tools. Users can buy any OS X app that supports Windows and run it directly, just as if they were using MacOS X. The second tier uses Richard Crandall's patented FEE public-key encryption technology to create what it calls "dynamic installicensing." Every "OS X for Windows NT" developer package includes an exportable copy of the OS X foreign runtime (which can run on either NT or 95). The developer can create a "extrafat" application which includes the OS X runtime. After registering a unique public key, the developer can distribute the runtime along with the application at a cost of 5% of sales. During installation of the app, it will install the runtime if it is not already present. The app will then license itself with that runtime. The runtime will be network aware, and notify users of inappropriate usage or updates. Shareware developers can register for a "free rider" public key which will allow their applications to run using any runtime that is already licensed for a commercial application. This technology allows naive Windows users to purchase and run OS X applications as if they were normal Windows applications, without any visible cost or extra effort. The technology is also being adapted for network licensing and demo applications. [Image] Industry Reaction Overwhelmingly Positive "I am ecstatic to have the best operating system in the world widely available on the best chips in the world." -- Andy Grove, CEO, Intel Corp. "We are pleased to be the premier provider of both Intel and PPC solutions for OS X customers." -- Connie Geiger, Channel Marketing, UMAX Computer Corp. "We have been using OS X technology internally for months, and we are thrilled to be finally able to offer it to our customers." -- Michael Dell, CEO, Dell Computer, Inc.. "Microsoft congratulates Apple on finally articulating a strategy, and will provide the OS X runtime the same fine support Microsoft gives all its developers" -- Dara Smith, Microsoft Public Relations "At last! This is what Apple developers have been waiting for. There'll be no stopping us now." -- Greg Anderson, President, Anderson Financial Systems "With OS X cross-platform, Apple has the best development and deployment strategy imaginable. OS X developers will kick butt." -- Andrew Stone, Chairman and CEO, Stone Design "I want my OS X! Now!" -- Don Yacktman, Chief Architect, MiscKit ------------------------------------------------ [Press Information Contact:] Rohit Khare OpenStep Users International 1115 Cordova St. Suite 114 Pasadena, CA 91106 (818) 568-9168 email: khare@w3.org References: <970404111540_1850017436@emout02.mail.aol.com> Message-ID: <9704041624.AA26400@tinman.next.com> Look at the release date. CUPERTINO, Calif.--Apr. 1, 1997--Apple Computer, Inc. today announced its From ricardo at ccsi.canon.com Fri Apr 4 08:24:23 1997 From: ricardo at ccsi.canon.com (Ricardo Parada) Date: Thu Nov 3 14:40:19 2005 Subject: IS THIS FOR REAL??????? References: <970404111540_1850017436@emout02.mail.aol.com> Message-ID: <9704041624.AA15103@ccsi.canon.com> > IS THIS FOR REAL??????? If you notice the last few lines say: -------------------------------------- Updated Tuesday, April 1, 1997 by eText This isn't true [yet], but it should be. -------------------------------------- I realized it was not true after I found a few grammatical and spelling errors. - ricardo From dmoore at gage.com Fri Apr 4 08:52:46 1997 From: dmoore at gage.com (Doug Moore) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <9704012202.AA02455@leinie.gage.com> References: <9704012202.AA02455@leinie.gage.com> Message-ID: <9704041652.AA03086@leinie.gage.com> Yes, PB's editor has more features. The feature set that you like != those that I favor. That we will just have to disagree about. The point is that these choices don't need to be imposed by PB. The features you mention could just as well have been added into TextEdit. As long as those API's were public I could write MyDevEdit.app and sell it to the 3 people out there that see things my way. Yes, to be meaningful those API's would be rather large and complex. It opens up an business opportunity, which is probably interesting to someone out there. Same concept obviously holds for GDB. - Doug I wrote: >> Edit (or TextEdit with all of Edit's features) is a better text editor, add >> a code browser if you want. Better yet, tell us how we can add it if we >> want. William Shipley replies: >Now, hold on just a minute there, cowboy. I agree PB should be split up >into several apps, but Edit and TextEdit are pathetic next to the power that >is ProjectBuilder. PB 4.0 has much richer support for emacs keys and >functions (including incremental search, split windows, swap characters, kill >rings, and the hidden but always necessary towers-of-hanoi) than Edit, and >its ability to do context finds and quick project-wide search and replace is >unparalleled. You can also open two windows on the same file and they >automatically stay in sync. From ernest at alumni.caltech.edu Fri Apr 4 08:57:50 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:19 2005 Subject: IS THIS FOR REAL??????? Message-ID: <199704041657.IAA27679@alumni.caltech.edu> Yeah, Robert (naughty boy :-) forwareded it from his NeXT email account without any of the disclaimers (except for the one at the bottom, for those of you who read that far). Alas, I am not [yet] Product Manager for Rhapsody, so this is all marketing fiction. HOwever, as far as I know, this is all technically and financially possible, so maybe it will juggle some ideas loose at Apple. The current product manager is on a six-week sabbatical, which could mean the position is becoming open (Apple seems to use that as a prelude/euphemism for firing). Anyway, that is advocacy stuff and should be taken to comp.sys.next.advocacy. The part that is relevant for this group is the one piece of science fiction, the "dynamic installicensing". I have only vague notions of how to use public key digitial signatures to authenticate apps to a runtime, anyone want to discuss how it may be possible? Can this be integrated into a general licensing scheme? Anybody know off good LicenseKits than can be extended in this way? I also assume the general consensus is that it would be A Good Thing if Apple did all this... [Sorry Wil, if this is off-topic too much]. -enp From stark at easynet.fr Fri Apr 4 03:09:22 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: <9704040505.AA00185@conextions.com> Message-ID: <9704041109.AA00258@easynet.fr> [Several peoples talking about the pro/cons of new PB] Well, the integrated PB would be a cool stuff, if: 1 - It crashes less often 2 - It could understand that I want 4 space tabs 3 - It indents the code at least as correctly than Edit did 4 - I could see two documentations at the same time 5 - The terminal emulation for gdb was at least correct (ie: arrows should work, and if I type the selection should jump to the end of the buffer, and, no, I don't want my source window become key window when I step using keyboard) This new gdb integration is simply unusable for me. 6 - He doesn't try to open a whole project when I want to see a single NS3.3 source file All of this worked with the previous 3 apps system It also have usability problem from its own, so I'll be happy if 7 - It stops updating the source browsers when I come from a teared-off window [very frustrating] 8 - He manages the main/key window in a more natural way 9 - gdb was less buggy And it'll be cool to have new stuff like: 10 - A shelf were we could put often used files/classes/methods (What about a system-wide tabbed-shelf located at the bottom of the screen ? Sorry, just kidding... :-) ) 11 - True integrated source code control (like VC4.2/SourceSafe. I guess we'll have this one soon) Anyway, I feel the new PB is definitely a good thing and I hope NeXT^H^H^H^H Apple will fix those obvious quirks (which is not certain, remember: Edit _never_ understood the pageup/pagedown or shift select, workspace had never implemented alt-drag from shelf and Librarian kept accumulating new bugs since 2.x release...) Cheers, -- fred PS: I know it would not help people port to OPENSTEP, but I would really like being able to compile 3.3 stuff on a 4.1 system... From mpinkert at cc.gatech.edu Fri Apr 4 10:33:36 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <199704041835.NAA20489@lennon.cc.gatech.edu> stark@easynet.fr wrote on 4/4/97 1:15 PM >[Several peoples talking about the pro/cons of new PB] > >Well, the integrated PB would be a cool stuff, if: Why are we talking about all this UNIX-style development stuff? I want CodeWarrior. I suffered through years of dbx and gdb to get to where we are now, and I am not going back without a fight. Am I incorrect in pointing out that this Rhapsody is a Mac? Why are we even bothering to discuss the use of unix tools on a Mac? -- 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 kpackard at wpine.com Fri Apr 4 11:37:18 1997 From: kpackard at wpine.com (Kevin Packard) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: YES. >>[Several peoples talking about the pro/cons of new PB] >> >>Well, the integrated PB would be a cool stuff, if: > >Why are we talking about all this UNIX-style development stuff? I want >CodeWarrior. I suffered through years of dbx and gdb to get to where we >are now, and I am not going back without a fight. > if i am not mistaken, Metroworks is currently working with Apple to move CodeWarrior onto Rhapsody. From waltrip at aurora.jhuapl.edu Fri Apr 4 12:07:58 1997 From: waltrip at aurora.jhuapl.edu (Charles F. Waltrip) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: Message-ID: <33455F9E.1186@aurora.jhuapl.edu> Kevin Packard wrote: > [...] > > if i am not mistaken, Metroworks is currently working with Apple to > move CodeWarrior onto Rhapsody. Maybe Apple should sell Metroworks the entire Rhapsody developer environment and get out of the business of competing with development tool vendors. Any opinions as developers? Chuck From timothym at ncmi.com Fri Apr 4 12:19:11 1997 From: timothym at ncmi.com (Timothy Mills) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <33455F9E.1186@aurora.jhuapl.edu> References: <33455F9E.1186@aurora.jhuapl.edu> Message-ID: <9704042019.AA07207@omnigroup.com> By the word of "Charles F. Waltrip" on Fri, 4 Apr 97 at 12:09:25: > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with > development tool vendors. Any opinions as developers? > > Chuck Apple/NeXT should keep their development tools and continue to advance them as they have throughout the history of NeXT in order to maintain their robustness, quality, and ease of use. NeXT's tools have always been recognized as top of the line. Thanks. Timothy --- Timothy R Mills NationsBanc Capital Markets, Inc voice: 704-388-7025 NC1-007-09-08 fax: 704-388-9564 100 North Tryon Street email: timothym@ncmi.com Charlotte NC 28255 From robert at visgen.com Fri Apr 4 12:25:40 1997 From: robert at visgen.com (Robert Osborne) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: <33455F9E.1186@aurora.jhuapl.edu> Message-ID: <199704042025.PAA18103@blender.visgen.com> "Charles F. Waltrip" wrote: > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with development > tool vendors. Any opinions as developers? There is nothing I like better than reporting a compiler bug to my compiler vendor and having them say it's an OS bug and then having my OS vendor respond that it's a compiler bug. You also run into major problems anytime you are doing anything low level - it's just too easy for the compiler and OS to clash. I prefer the basic development environment and OS to come from a single vendor. Of course if the OS developers are using the third party compiler in house .... Rob. From lukeh at xedoc.com.au Fri Apr 4 14:20:37 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <199704042220.IAA10234@alpha.xedoc.com.au> At 07:03 4/04/97 -0800, you wrote: >Yes, but netinfo is not part of the OpenStep Specification; It exists on OPENSTEP for Mach, >but not Solaris OpenStep(NIS or NISPLUS) or NT(?); You can't count on it being there. It may not be part of the OpenStep spec, but it is available for Solaris. :-) Anyway, IMHO a higher level OO directory service API -- like JNDI -- should be part of the spec, and suitable service providers provided on each platform. >For that matter, the whole DO wire protocol is not part of the OpenStep spec. It should >be , but it aint. Which has implications for GNUstep, sadly (ie. their DO isn't wire compatible). -- luke From scott at QuickBase.com Fri Apr 4 13:23:22 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation In-Reply-To: <199704042220.IAA10234@alpha.xedoc.com.au> References: <199704042220.IAA10234@alpha.xedoc.com.au> Message-ID: <9704042123.AA07680@QuickBase.com> Luke Howard wrote: > It may not be part of the OpenStep spec, but it is available for > Solaris. :-) --- Actually, I think we may be talking about two different things. The API is part of the OpenStep spec, but the protocol isn't. That is up to the vendor to choose (as I understand it). BTW, multi-threaded DO connections are not supported under Solaris (yet). Apparently that is the part of the NeXT specific API and not the OpenStep spec. - Scott ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From Mark.Anenberg at Eng.Sun.COM Thu Apr 3 21:50:42 1997 From: Mark.Anenberg at Eng.Sun.COM (Mark Anenberg) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation References: <9704042123.AA07680@QuickBase.com> Message-ID: <199704042150.NAA14352@velodrome.eng.sun.com> He was talking about netinfo and that there is an implementation of it that runs on Solaris, but it isn't part of Solaris proper; Anyhow, the Solaris OpenStep implementation mapped nearly everything that used to go to netinfo over to yp calls. On the DO apis, yes NeXT added a few methods that we don't have. -Mark From: Scott Keith To: Multiple recipients of list Subject: Re: Mach & D.O. Limitation Luke Howard wrote: > It may not be part of the OpenStep spec, but it is available for > Solaris. :-) --- Actually, I think we may be talking about two different things. The API is part of the OpenStep spec, but the protocol isn't. That is up to the vendor to choose (as I understand it). BTW, multi-threaded DO connections are not supported under Solaris (yet). Apparently that is the part of the NeXT specific API and not the OpenStep spec. - Scott ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. ?http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From lukeh at xedoc.com.au Fri Apr 4 15:00:00 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <199704042300.JAA10506@alpha.xedoc.com.au> >Actually, I think we may be talking about two different things. >The API is part of the OpenStep spec, but the protocol isn't. That >is up to the vendor to choose (as I understand it). I was talking about the NetInfo API, as was Mark, not the DO API. The problem with leaving the DO *protocol* to the vendor to choose is that it makes wire compatibility very difficult (if not impossible). >BTW, multi-threaded DO connections are not supported under Solaris >(yet). Apparently that is the part of the NeXT specific API and not >the OpenStep spec. Perhaps Rhapsody will prompt Solaris to bring their OpenStep into line with NeXT's OpenStep extensions. (Hmm, NeXT could always bring out an "OpenStep 97" spec.) -- Luke From ericsc at apple.com Fri Apr 4 14:12:06 1997 From: ericsc at apple.com (Eric Schlegel) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: On Fri, Apr 4, 1997 10:15 AM, stark@easynet.fr wrote: > [Several peoples talking about the pro/cons of new PB] > > Well, the integrated PB would be a cool stuff, if: > > ... > 2 - It could understand that I want 4 space tabs This one's easy, at least. From the ProjectBuilder 4.1 release notes: defaults write ProjectBuilder tabStopChars 4 will make PB use 4-space tabs. Hope this helps, -eric ---------------------------------------------------------------------- Eric Schlegel ** Rhapsody Graphics, Apple Computer ** ericsc@apple.com From sanguish at digifix.com Fri Apr 4 14:15:12 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <33455F9E.1186@aurora.jhuapl.edu> References: <33455F9E.1186@aurora.jhuapl.edu> Message-ID: <199704042215.RAA22916@digifix.com> You wrote: > Kevin Packard wrote: > > > > if i am not mistaken, Metroworks is currently working with Apple to > > move CodeWarrior onto Rhapsody. > > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with development > tool vendors. Any opinions as developers? > Yeah, no ****ing way. Apple/NeXT must keep control of things like IB, and should offer their own tools as well. Being reliant on a third party isn't something I'm interested in. From lukeh at xedoc.com.au Fri Apr 4 15:11:41 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:19 2005 Subject: Mach & D.O. Limitation Message-ID: <199704042311.JAA10601@alpha.xedoc.com.au> At 13:51 4/04/97 -0800, you wrote: >He was talking about netinfo and that there is an implementation of >it that runs on Solaris, but it isn't part of Solaris proper; Anyhow, the Solaris OpenStep >implementation mapped nearly everything that used to go to netinfo over to yp calls. I'm surprised there were any direct NetInfo calls (except in Mail.app, where I think there were). Most OPENSTEP apps use libc calls, which go through lookupd. I always thought NetInfo would be a better defaults database than text files, though. -- luke From sanguish at digifix.com Fri Apr 4 14:19:36 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <199704041835.NAA20489@lennon.cc.gatech.edu> References: <199704041835.NAA20489@lennon.cc.gatech.edu> Message-ID: <199704042219.RAA22945@digifix.com> You wrote: > stark@easynet.fr wrote on 4/4/97 1:15 PM > > >[Several peoples talking about the pro/cons of new PB] > > > >Well, the integrated PB would be a cool stuff, if: > > Why are we talking about all this UNIX-style development stuff? I want > CodeWarrior. I suffered through years of dbx and gdb to get to where we > are now, and I am not going back without a fight. > Calling PB, unix-like is wrong. PB is a very nicely integrated development environment that is lacking only one major thing... maturity. And at the rate it is maturing I'm sure it'll be just great by OS 4.3 or Rhapsody. The fact that gdb is used in PB doesn't make it very Unix like. Infact I LIKE the front end PB offers to it, and want to see it progress. Don't assume that because the word gdb, cc, gcc, gnumake or whatnot is used that it has a UNIX command line style interface. > Am I incorrect in pointing out that this Rhapsody is a Mac? Why are we > even bothering to discuss the use of unix tools on a Mac? > Oh great, not this again. From kpackard at wpine.com Fri Apr 4 14:56:01 1997 From: kpackard at wpine.com (Kevin Packard) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: Scott Anguish wrote: >You wrote: >> Kevin Packard wrote: >> > >> > if i am not mistaken, Metroworks is currently working with Apple to >> > move CodeWarrior onto Rhapsody. >> >> Maybe Apple should sell Metroworks the entire Rhapsody developer >> environment and get out of the business of competing with development >> tool vendors. Any opinions as developers? >> > > Yeah, no ****ing way. > > Apple/NeXT must keep control of things like IB, and should offer >their own tools as well. Being reliant on a third party isn't something I'm >interested in. well, when it comes to Apple and development environments, i am reminded of how Metroworks saved the day by releasing the first stable PPC compiler for the MacOS, CodeWarrior. this release was critical to Apple's success in developing the PPC MacOS, becase MPW (Apple's development environment) did not release a working PPC compiler until months after the PPC MacOS shipped. you see, most of the MacOS development was done with CodeWarrior. those third-party developers that stuck with MPW and didn't switch to CodeWarrior were burned due to lack of support by Apple. furthermore, CodeWarrior ***is*** a mature development environment, and has a modular design, so Rhapsody support should not be difficult. As a company, Metroworks is quick with releases, has supported new MacOS technologies as soon as they are available, and listens seriously to developers' suggestions and bug reports. so, i say, let the 3rd party compiler developers slug it out. my money is on Metroworks. From sanguish at digifix.com Fri Apr 4 14:56:29 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:19 2005 Subject: OpenStep MiniExamples Message-ID: <199704042256.RAA23496@digifix.com> I've started to make some applications that are great MiniExamples available on Stepwise at http://www.stepwise.com/Resources/OpenStep_Examples The idea of a MiniExamples is that it should demonstrate how to do something with a class or two. The first is ToolHandle which was donated by Steve Nygard It uses NSFileHandle to talk to various inet ports. It talks to date, echo and will even retrieve a file from a web site using http: I've got another MiniExample in the wings that demonstrates some very basic interaction with NSColorWells and NSTextFields. Still another shows a very simple example of using NSTableViews with an array of NSDictionaries as the datasource. I'll be happy to add more user contributed examples... stuff like Matrix's, TextEdit stuff, etc would be great! Thanks Scott From gad at eclipse.its.rpi.edu Fri Apr 4 15:21:50 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: <33455F9E.1186@aurora.jhuapl.edu> Message-ID: <9704042321.AA29161@eclipse.its.rpi.edu> Charles F. Waltrip wrote: > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with > development tool vendors. Any opinions as developers? (not that I'm a big-time developer, but...) I think this would be a bad idea. If they have to make some significant change to the system (such as adding frameworks), then they'll need to make changes to things like IB and PB. So, I don't think they should turn all of that over to someone else. However, I can see how they should make it easy for writers of other development tools to hook in their own pieces to the development environment. NeXT should not be dictating what editor to use, for instance (even though I think they should provide one, it should be possible for alternate editors to easily plug in). This flexibility takes a bit of work, but that's the direction I would encourage them to go. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From kurt at frsvnsvn.vip.best.com Fri Apr 4 15:52:28 1997 From: kurt at frsvnsvn.vip.best.com (Kurt Werle) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <199704041835.NAA20489@lennon.cc.gatech.edu> Message-ID: On Fri, 4 Apr 1997, Mike Pinkerton wrote: > stark@easynet.fr wrote on 4/4/97 1:15 PM > > >[Several peoples talking about the pro/cons of new PB] > > > >Well, the integrated PB would be a cool stuff, if: > > Why are we talking about all this UNIX-style development stuff? I want > CodeWarrior. I suffered through years of dbx and gdb to get to where we > are now, and I am not going back without a fight. That's funny. Every codewarrior person I've demo'd gdb (via PB) to has said "yeah, that's OK; Codewarrior is nicer" up to the poing I typed print [myObject myMethod] and got a value back, at which point they all decided that gdb was cool, though there'd be a little learning. Once PB/gdb solves the recording of breakpoints issue (Rhapsody, I hope!), just about everyone will be happy. > Am I incorrect in pointing out that this Rhapsody is a Mac? Why are we > even bothering to discuss the use of unix tools on a Mac? Yup, you're incorrect. Rhapsody will be a Mac interface on a Unix box. If you want to use CodeWarrior, though, MetroWerks will gladly supply it to you. Kurt From stark at easynet.fr Fri Apr 4 12:31:20 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: <9704042321.AA29161@eclipse.its.rpi.edu> Message-ID: <9704042031.AA06449@easynet.fr> Charles F. Waltrip wrote: > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with > development tool vendors. Any opinions as developers? Well I think it would be a bad idea. Did apple had to sell them MPW ? Anyway I don't think they'll drop CodeWarrior while they are finishing the Win32 version. Furthermore, CodeWarrior have a impressive number of enthusiams in the Mac developer community (My personal opinion is that PB is superior to CodeWarrior and gdb is light-years ahead their debbuger but it is just an opinion... maybe that's why I don't want them to get their hand on PB/IB...:-) ) Selling them PB/IB to them could probably kill the NeXT dev environment because I don't feel they could market two development products at once and they would never drop CodeWarrior. So Apple/NeXT could keep PB/IB but should sell/donate them the basic things they need (nib file format, dynld format and so on), enabling Metrowerks to create its own development environment (via CodeWarrior plug-ins). My 0.02$ Cheers, -- fred PS: Should Micro$oft sell VC++ to Borland or Sybase :-) ? From ricardo at ccsi.canon.com Fri Apr 4 16:58:02 1997 From: ricardo at ccsi.canon.com (Ricardo Parada) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? References: <9704042031.AA06449@easynet.fr> Message-ID: <9704050058.AA21571@ccsi.canon.com> > So Apple/NeXT could keep PB/IB but should sell/donate > them the basic things they need (nib file format, dynld > format and so on) What is dynld? Sounds like a directory of shared libraries for a framework. :-) - ricardo From sanguish at digifix.com Fri Apr 4 20:17:25 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: References: Message-ID: <199704050417.XAA24907@digifix.com> You wrote: > Scott Anguish wrote: > >You wrote: > >> Kevin Packard wrote: > >> > > >> > if i am not mistaken, Metroworks is currently working with Apple to > >> > move CodeWarrior onto Rhapsody. > >> > >> Maybe Apple should sell Metroworks the entire Rhapsody developer > >> environment and get out of the business of competing with development > >> tool vendors. Any opinions as developers? > >> > > > > Yeah, no ****ing way. > > > > Apple/NeXT must keep control of things like IB, and should offer > >their own tools as well. Being reliant on a third party isn't something > >I'm interested in. > > well, when it comes to Apple and development environments, i am reminded of > how Metroworks saved the day by releasing the first stable PPC compiler for > the MacOS, CodeWarrior. this release was critical to Apple's success in > developing the PPC MacOS, becase MPW (Apple's development environment) did > not release a working PPC compiler until months after the PPC MacOS > shipped. you see, most of the MacOS development was done with CodeWarrior. > those third-party developers that stuck with MPW and didn't switch to > CodeWarrior were burned due to lack of support by Apple. Yes, but if Apple hadn't gotten itself into the muddle it did by letting MPW slide it wouldn't have been a problem. I'm not saying that Metrowerks shouldn't make an environment for Rhapsody. I'm saying that Apple shouldn't discontinue its own tools when they are usually hailed as the best development platform around. From bsears at physix.com Fri Apr 4 21:59:58 1997 From: bsears at physix.com (Brant Sears) Date: Thu Nov 3 14:40:19 2005 Subject: Developers Tools Message-ID: > >> Maybe Apple should sell Metroworks the entire Rhapsody developer > >> environment and get out of the business of competing with development > >> tool vendors. Any opinions as developers? > >> I definately think that having more choices in development tools is better than having fewer choices. I think that any good development tools are welcome no matter what the source. Brant Sears bsears@physix.com Physix, Inc. From ngian at ath.forthnet.gr Sat Apr 5 02:04:35 1997 From: ngian at ath.forthnet.gr (N. G.) Date: Thu Nov 3 14:40:19 2005 Subject: Developers Tools Message-ID: <199704051011.NAA25134@info.forthnet.gr> For those who haven't realized it yet, Rhapsody Developer will be based on NeXT's Developer tools simply because Rhapsody itself will be based on NeXT technology, and because NeXT's developer tools are years ahead to anything Apple's MPW has to offer. So please don't judge Rhapsody Developer thinking that it will be (is) MPW. Thanks :-) N.G. From kai at khms.westfalen.de Sat Apr 5 01:22:00 1997 From: kai at khms.westfalen.de (Kai Henningsen) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <33455F9E.1186@aurora.jhuapl.edu> Message-ID: <6UHghBZUcsB@khms.westfalen.de> waltrip@aurora.jhuapl.edu (Charles F. Waltrip) wrote on 04.04.97 in <33455F9E.1186@aurora.jhuapl.edu>: > Kevin Packard wrote: > > > > [...] > > > > > if i am not mistaken, Metroworks is currently working with Apple to > > move CodeWarrior onto Rhapsody. > > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with development > tool vendors. Any opinions as developers? I disagree strongly. MPW was a great environment. Unix-type stuff could be even better, since Unixyness is what made MPW great. Go away with those too-integrated environments. MPW had all the integration I wanted. (Besides, how many times can I buy MPW - nay, ETO - for the price of one CodeWarrior?) MfG Kai From kjray at ix.netcom.com Sat Apr 5 08:45:07 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <199704051647.KAA08622@dfw-ix14.ix.netcom.com> >(Besides, how many times can I buy MPW - nay, ETO - for the price of one >CodeWarrior?) You probably won't be able to buy MPW in the future, at least via ETOs. Apple screwed itself by basically giving MPW Shell to Metrowerks to be distributed on CodeWarrior -- receiving $0 from Metrowerks! Sales of ETO dropped to very low levels, despite the price drop to $195. When the cost-cutting began, ETO and MPW were earning very little revenues, so **SNIP**, a 50-person department gets reduced to 5. I suppose MPW Shell will continue to shipped by Metrowerks, but MrC/MrCpp, one of the best optimizing compilers available for PowerPC will not longer have distribution medium. People have reported 20% speed improvements of compute-intensive applications, compared to Metrowerks' compilation of the same code. And gcc is probably worse than Metrowerks for lack of PowerPC optimization, but gcc is being used to build Rhapsody. A bright spot is that at least one MrC engineer is working on gcc now, and may eventually improve its optimization. Keith Ray. Former tech lead for ETO #23. // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From owolf at pdnt.com Sat Apr 5 09:05:18 1997 From: owolf at pdnt.com (owolf@pdnt.com) Date: Thu Nov 3 14:40:19 2005 Subject: IS THIS FOR REAL??????? Message-ID: <199704051702.LAA29368@tempest.pdnt.net> This was a VERY cruel joke. Scott Johnson From markm at mail.tyrell.com Sat Apr 5 08:23:22 1997 From: markm at mail.tyrell.com (Mark F. Murphy) Date: Thu Nov 3 14:40:19 2005 Subject: gcc In-Reply-To: <199704051647.KAA08622@dfw-ix14.ix.netcom.com> Message-ID: At 8:49 AM -0800 4/5/97, Ray wrote: >And gcc is probably worse than Metrowerks >for lack of PowerPC optimization, but gcc is being used to build >Rhapsody. A bright spot is that at least one MrC engineer is working on >gcc now, and may eventually improve its optimization. I have a question for those in the know about gcc.... How difficult would it be to port gcc (including the Objective-C... cc1obj?) as a CodeWarrior compiler plugin? What I'm looking for is a way to bring Objective-C to CodeWarrior right now with whatever Objective-C support lib is needed? Any ideas or suggestions? mark --------------------------------------------------------------------------- Mark F. Murphy, Director Software Development (markm@mail.tyrell.com) Tyrell Software Corp (http://www.tyrell.com) --------------------------------------------------------------------------- Member of Families Against Internet Censorship: rainbow.rmi.net/~fagin/faic From mpinkert at cc.gatech.edu Sat Apr 5 09:36:02 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <199704051738.MAA03930@lennon.cc.gatech.edu> Kurt Werle wrote on 4/4/97 6:52 PM >That's funny. Every codewarrior person I've demo'd gdb (via PB) to has said >"yeah, that's OK; Codewarrior is nicer" up to the poing I typed >print [myObject myMethod] >and got a value back, at which point they all decided that gdb was cool, >though there'd be a little learning. Once PB/gdb solves the recording of >breakpoints issue (Rhapsody, I hope!), just about everyone will be happy. Ok, so GDB has some nice features. However, it has that wonderful feature of being a command line interface, which I consider to be a bug (this is the 90s). Now I'm not trying to start any religious wars, but all you unix folks have to realize that most mac developers have done both mac and unix, and prefer to do things the Macintosh way. >> Am I incorrect in pointing out that this Rhapsody is a Mac? Why are we >> even bothering to discuss the use of unix tools on a Mac? > >Yup, you're incorrect. Rhapsody will be a Mac interface on a Unix box. If >you want to use CodeWarrior, though, MetroWerks will gladly supply it to you. I sure hope so. I'm not giving up my nice development environment because the unix people want to preserve their heritage. -- 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 bsears at physix.com Sat Apr 5 09:55:09 1997 From: bsears at physix.com (Brant Sears) Date: Thu Nov 3 14:40:19 2005 Subject: Contextual Menus Message-ID: How about a triple click OR a modifier key + single click to bring up context menus? Some users might have trouble with a triple click, but most I think would like it. My only concern would be that it could interfere with the definition of a double click, but we are really only talking about the Finder and new applications, not contextual menus for existing apps, so I think it would work. Any thoughts on this? Is the triple click used anywhere else in the finder? To my knowledge it is not. Brant Sears bsears@physix.com From adamb at chesco.com Sat Apr 5 10:13:49 1997 From: adamb at chesco.com (Adam Balkwill) Date: Thu Nov 3 14:40:19 2005 Subject: Contextual Menus Message-ID: <199704051813.NAA04450@carriage.chesco.com> >How about a triple click OR a modifier key + single click to bring up >context menus? Some users might have trouble with a triple click, but >most I think would like it. My only concern would be that it could >interfere with the definition of a double click, but we are really only >talking about the Finder and new applications, not contextual menus for >existing apps, so I think it would work. Any thoughts on this? Is the >triple click used anywhere else in the finder? To my knowledge it is >not. > >Brant Sears >bsears@physix.com > > Triple Clicks are only used for within applications as a selection modifier. The implementation that apple will go with will be one of a modifier key and a single click. Specifically the control key. This is the way it works in System 8.0. I doubt they would change the way it would work from one system to the next. I have heard though that they may increase the customization of this by adding a control panel type of model in rhapsody that would allow the user to select the method. This was specifically planned on because two button mice were in the future. ____________________ Adam Balkwill imagenation, inc. ____________________ http://www.imagenation.net adamb@imagenation.net adamb@chesco.com phone: 610 380 4564 Fax: 610 384 5247 imagenation, inc. 1001 Saint George Road Coatesville PA, 19320 From bsears at physix.com Sat Apr 5 10:28:29 1997 From: bsears at physix.com (Brant Sears) Date: Thu Nov 3 14:40:19 2005 Subject: No subject Message-ID: >That's funny. Every codewarrior person I've demo'd gdb (via PB) to has said >"yeah, that's OK; Codewarrior is nicer" up to the poing I typed >print [myObject myMethod] >and got a value back, at which point they all decided that gdb was cool, This sounds a lot like NTK (Newton ToolKit) and I _love_ NTK. I will be the first to admit that NTK has some problems, but perhaps if someone is working on a development tool for Rhapsody, they might want to look at NTK and borrow some of its better ideas. Just a thought ;-) Brant Sears bsears@physix.com From bayou at rouge.phys.lsu.edu Sat Apr 5 12:36:34 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:19 2005 Subject: The system folder's fate Message-ID: Has there been any mention about whether the System Folder paradigm will be continued in Rhapsody? If I have to edit a bunch unix text files to install or manage system extensions, I'll cry. I might as well use Windows if I have to do that. later, James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From Scott_Harrison at next.com Sat Apr 5 12:36:50 1997 From: Scott_Harrison at next.com (Scott Harrison) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <9704052037.AA17243@toto.NeXT.COM> Mike Pinkerton wrote: >Ok, so GDB has some nice features. However, it has that wonderful feature >of being a command line interface, which I consider to be a bug (this is >the 90s). Now I'm not trying to start any religious wars, but all you >unix folks have to realize that most mac developers have done both mac >and unix, and prefer to do things the Macintosh way. > >>> Am I incorrect in pointing out that this Rhapsody is a Mac? Why are we >>> even bothering to discuss the use of unix tools on a Mac? >> >>Yup, you're incorrect. Rhapsody will be a Mac interface on a Unix box. If >>you want to use CodeWarrior, though, MetroWerks will gladly supply it to you. > >I sure hope so. I'm not giving up my nice development environment because >the unix people want to preserve their heritage. I think you misunderstand. There are Mac developers, UNIX developers, AND NeXT developers. NeXT developers do not have to use command line tools. NEXT/OPENSTEP provides a GUI environment for development. However, NeXT developers are used to having the benefit of having options. Therefore, if a NeXT developer chooses to use the command line interface for whatever reason (like being more productive), a NeXT developer has that choice. Rhapsody will offer developers and users a choice. This is the key point. --Scott From mpinkert at cc.gatech.edu Sat Apr 5 12:43:23 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <199704052045.PAA09450@lennon.cc.gatech.edu> Scott Harrison wrote on 4/5/97 3:37 PM >Therefore, if a NeXT developer chooses >to use the command line interface for whatever reason (like being >more productive), a NeXT developer has that choice. Rhapsody will >offer developers and users a choice. This is the key point. That's fine by me. I'm don't want to give the impression that I'm telling people what they should be using. I just want to ensure that we won't be losing a lot of the great tools that currently exist for the Mac. BTW, does anyone know what Apple's official position on the development tools is? They say they're going the Java route so no one needs to write Obj-C code to do Rhapsody development. How does that mesh with PB? -- 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 Scott_Harrison at next.com Sat Apr 5 12:56:50 1997 From: Scott_Harrison at next.com (Scott Harrison) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: <9704052056.AA17349@toto.NeXT.COM> Mike Pinkerton wrote: >That's fine by me. I'm don't want to give the impression that I'm telling >people what they should be using. I just want to ensure that we won't be >losing a lot of the great tools that currently exist for the Mac. > >BTW, does anyone know what Apple's official position on the development >tools is? They say they're going the Java route so no one needs to write >Obj-C code to do Rhapsody development. How does that mesh with PB? Whether you will be losing tools depends on the vendor supplying the tools for the Rhapsody environment. I suggest that you indicate to the appropriate vendor that you would like your favorite tools ported to Rhapsody. ProjectBuilder is very flexible, and can be configured to use different build software. So, one can use javac to compile Java, gcc to compile C, C++ and Objective-C, etc. There is no limitation on the use of Java versus Objective-C built in to ProjectBuilder. Currently, the APIs that are used in the NeXT kits are Objective-C. However, I would assume that work is being done on making Java APIs for the various kits. With those APIs, one should be able to use Java only and create a Rhapsody application. I do not know Apple's official position even though I work for Apple. Scott From cerveau at club-internet.fr Sat Apr 5 15:23:50 1997 From: cerveau at club-internet.fr (Laurent Cerveau) Date: Thu Nov 3 14:40:19 2005 Subject: The system folder's fate Message-ID: I hope both ways will be possible. For a single user, having a sytem folder, and all the configurations panels is great, but to configure a network, if the system administrator could do the job once for every computer using some files and shell command, it would be nice too. By the way, I like the principle of a System Folder, where all the configuration of your machine is put (in fact for the first Mac, it was very easy to understand what was what in the System, but it has grown too much, too fast) Laurent ---------------------------------------------------------------------------- Laurent Cerveau cerveau@club-internet.fr Laurent.Cerveau@ircam.fr ---------------------------------------------------------------------------- From ernest at pundit Sat Apr 5 10:06:08 1997 From: ernest at pundit (Dr. Ernest N. Prabhakar) Date: Thu Nov 3 14:40:19 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <199704051738.MAA03930@lennon.cc.gatech.edu> References: <199704051738.MAA03930@lennon.cc.gatech.edu> Message-ID: <9704051806.AA15799@alumni.caltech.edu> You wrote: > Ok, so GDB has some nice features. However, it has that wonderful > feature of being a command line interface, which I consider to be a > bug (this is the 90s). Now I'm not trying to start any religious > wars, but all you unix folks have to realize that most mac developers > have done both mac and unix, and prefer to do things the Macintosh > way. Um, have you used GDB on a NeXTSTEP platform? There are several GUI front-ends to GDB (I just renewed my license for SuperDebugger from Impact Software). The NeXT community *has* made a religion out of combining the power of UNIX with the ease-of-use of the Mac. Building spiffy front-ends on hard-core UNIX tools often does give the best of both worlds. Of course, the integration isn't perfect. It certainly could be that there are some things that Metrowerks does really well that aren't possible in GDB. But, I hope your comment is not simply based on a prejudice that "command-line-debuggers can't be useful." Some Mac people are under this delusion is that UNIX "can't" be easy, just because of bad experiences in the past. Hey, we're all children of Jobs here: we -get it-. Yes, there is the Mac way, and the UNIX way. And then there is the NeXTSTEP way, which is fundamentally different than both, which in its better moments really does combine the better aspects of both. It doesn't always, so we really do need constructive feedback on how to improve the system. But please don't lump us in with all those crufty unix systems where a GUI means a xterm with scrollbars. We share the dream for easy-to-use intuitive software. Work with us. -- Ernie "OS X Marketing" Prabhakar --- Dr. Ernest N. Prabhakar NeXTmail:ernest@alumni.caltech.edu "And ourselves, your servants for Jesus' sake." -- II Cor 4:5b http://www.alumni.caltech.edu/~ernest/Home.htmld/index.html From tomi at shinto.nbg.sub.org Sat Apr 5 14:27:05 1997 From: tomi at shinto.nbg.sub.org (Thomas Engel) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <9704052037.AA17243@toto.NeXT.COM> References: <9704052037.AA17243@toto.NeXT.COM> Message-ID: <9704052227.AA01167@shinto.nbg.sub.org> Scott_Harrison@next.com wrote: > > I think you misunderstand. There are Mac developers, UNIX > developers, AND NeXT developers. NeXT developers do not have to use > command line tools. NEXT/OPENSTEP provides a GUI environment for > development. However, NeXT developers are used to having the > benefit of having options. Therefore, if a NeXT developer chooses > to use the command line interface for whatever reason (like being > more productive), a NeXT developer has that choice. Rhapsody will > offer developers and users a choice. This is the key point. > I can underline that it is possible to develop applicaitons under NeXTSTEP without knowing how to write or maintain a makefile, handle gdb or gcc etc. pp. I havn't touched that level within 3 years of NeXTSTEP development. It really is one of the main arguments for NeXTSTEP that can use the command line...but you don't have to. And in reality this really works for Users and Developers (ok...sysadmins might have a harder life...but some more apps should help). Mike, think of GDB as the interactive console of a LISP system. If you need it...its there. Usually you won't need it but there is a couple of nice things you can do...like activly issuing messages and watching what happens. With the "fix-and-go" technology and a slightly optimized GDB text input view you could almost get the Smalltalk/Lisp feeling. But I have to agree that NeXTs current GDB frontend still is lacking many features. The old Turbo C system on the Atari ST was a lot more comfortable about 10 years ago. PB 4.0 has no UI for a lot of useful features...or I have not been able to find them. - Animated...timed...automatic execution where the source code scrolls as the code procedes. - Data watching. You can keep an eye on a couple of objects or variables (stack and breakpoints are not enough). - Provide readable views of object ivars (what about an inspector like IB uses ?) - Data breakpoints...stop when this guy changes or this particular object receives this particular message. - Thread support. Watch the execution of threads...suspend a specific thread etc.pp. - GDB windows text input really has confusing behavior - ...(more if you care)... I bet that most of these things can be done with some advanced GDB commands so it could be implemented on top of GDB. While currently you can get access to the data you can't really see all the things as fast as with a good UI. Other shortcomings of PB: - Profiling ? Just having the shitch is a joke IMHO. No frontend and worse..no real docu. (man gprof won't tell you why your MyApp.profile does not generate the gprof.out file..or where it would end up etc) - Needs thight integration with ObjectAlloc (this is a really useful too...but should be naturally integrated with PB...having access to debugging features) - Does not sync class modifications with IB and vica versa - (IB related) no ASCII NIB format so you can't make bulk class name changes happen automatically. I could go one and one about the problems of PB/IB...but that doesn't change that they still are the most productive environment I have used so far. My personal hope is that Apple/NeXT can now pay more attention and donate more Resources to these apps. Aloha Tomi From tomi at shinto.nbg.sub.org Sat Apr 5 14:50:11 1997 From: tomi at shinto.nbg.sub.org (Thomas Engel) Date: Thu Nov 3 14:40:20 2005 Subject: Defaults database Was: Mach & D.O. Limitation In-Reply-To: <199704042311.JAA10601@alpha.xedoc.com.au> References: <199704042311.JAA10601@alpha.xedoc.com.au> Message-ID: <9704052250.AA01183@shinto.nbg.sub.org> > I'm surprised there were any direct NetInfo calls (except in Mail.app, > where I think there were). Most OPENSTEP apps use libc calls, which go > through lookupd. I always thought NetInfo would be a better defaults > database than text files, though. > > -- luke > While we at it. I really really hope that Apple will update the NSUserDefaults class to add another non volatil domain (NSNetworkDomain) which would take the defaults right into NetInfo. I know that I can write that on my own (and that OmniWeb already did that)...but IMHO it would be a very nice feature to have for every application. Installing software on a network and ensuring that users have the best default settings for the local installation can be a nightmare without this features. NeXT as the right default system and this extension would be a nice thing to have. If you are not on a NetInfo network Apple could provide an alternative mechanims which might use a simple DO server process which could hold the default dictionraries and would offer the few Rhapsody systems on the local NIS system a way to share that data (don't know if writing into a special NIS map is a good idea...) If an application cares about security it could either ignor that Network domain or a special startup argument (-NSIgnorNetworkDefaults YES) could be provided to ensure that not networks settings can cause any harm. IMHO regular users and netowrk installation could benefit from this (perhaps Omni could donate that code to save Apple some time ?) Aloha Tomi From stark at easynet.fr Sat Apr 5 14:00:08 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? References: <9704052227.AA01167@shinto.nbg.sub.org> Message-ID: <9704052200.AA00837@easynet.fr> Thomas Engel wrote [crunch] > Other shortcomings of PB: > [shortcoming list skipped] Definitely agreed that PB/IB could do better but: I worked one year with VC++ 4.1 [NT] and (much less) with CodeWarrior [Mac] and they are even worse (You have to _insert_ function calls in your code for profiling with CodeWarrior, if I remember well. VC++ is not better, for instance the code coverage function just dumps your _whole_ source files in the console with a little '*' in front of lines that have been executed) Those two tools a crippled with bugs (I prefer not to talk about Borland or Watcom [should I say Sybase?] compilers), maybe less obvious that the one PB/IB suffer from [and this is not even sure] but you don't have the compensation of having workarounds to obtain the full power of your environment. Given the respective resources (and installed base) used for those environments, NeXT obviously did a good job. Cheers, -- fred From sanguish at digifix.com Sat Apr 5 20:46:40 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate In-Reply-To: References: Message-ID: <199704060446.XAA27989@digifix.com> "James Gregurich" wrote: > Has there been any mention about whether the System Folder paradigm will be > continued in Rhapsody? > > If I have to edit a bunch unix text files to install or manage system > extensions, I'll cry. I might as well use Windows if I have to do that. > This has nothing to do with development issues. But since you don't do edit text files to accompish configuration on NEXTSTEP for the most part, don't expect it to be the case in Rhapsody. From bentley at crenelle.com Sat Apr 5 23:24:10 1997 From: bentley at crenelle.com (Michael Brian Bentley) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate In-Reply-To: <199704060446.XAA27989@digifix.com> Message-ID: >"James Gregurich" wrote: >> Has there been any mention about whether the System Folder paradigm will be >> continued in Rhapsody? >> >> If I have to edit a bunch unix text files to install or manage system >> extensions, I'll cry. I might as well use Windows if I have to do that. > Scott Anguish replies: > This has nothing to do with development issues. > > But since you don't do edit text files to accompish configuration on >NEXTSTEP for the most part, don't expect it to be the case in Rhapsody. Sez I: It certainly has nothing to do with development issues while lacking concrete information, but I guarantee that the eventual actual answer will at least affect _my_ development work. To speculate about a real answer, I expect some "minor" changes to the current arrangement of the directory hierarchy away from the way they do it on NextStep to conform a little more to where MacOS puts things by default so that files that normally are apparent and out in the open but don't have to be will find a new home in a directory some where. A System-Folder like thing could be done using whatever goes for aliases in Rhapsody. The problem with the system folder growing so big is actually a MacOS problem of not being able to display the contents of a folder that has more than four hundred or so files and folders in it. This shouldn't be a problem under Rhapsody. -m Michael Brian Bentley / bentley@crenelle.com / Crenelle Inc. 1935 West Pratt Blvd Suite 3, Chicago Illinois 60626-3133 Voice (773)-508-9009 Fax (773)-465-2399 Web www.crenelle.com Network Applications Development Specializing in Mac OS From sanguish at digifix.com Sun Apr 6 00:17:14 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate In-Reply-To: References: Message-ID: <199704060817.EAA28678@digifix.com> Michael Brian Bentley wrote: > >"James Gregurich" wrote: > >> Has there been any mention about whether the System Folder paradigm will > >> be continued in Rhapsody? > >> > >> If I have to edit a bunch unix text files to install or manage system > >> extensions, I'll cry. I might as well use Windows if I have to do that. > > > Scott Anguish replies: > >This has nothing to do with development issues. > > > >But since you don't do edit text files to accompish configuration on > >NEXTSTEP for the most part, don't expect it to be the case in Rhapsody. > > Sez I: > > It certainly has nothing to do with development issues while lacking > concrete information, but I guarantee that the eventual actual answer will > at least affect _my_ development work. > Knowing full well I'll get blasted about this... This list is supposed to be about development issues. This is a user issue. How you configure a machine isn't a development issue. Unfortunately too many people are hearing UNIX and don't realize that NEXTSTEP is alot closer to MacOS as far as a user experience goes than what you may think of unix. This is obviously carrying over to the development tools as well. Yes, the development is built on GNU tools. But the developer experience isn't UNIX-like unless you choose not to use NeXT's tools. You're seeing GDB and assuming this is the same old command line debugger. Its not. > To speculate about a real answer, I expect some "minor" changes to the > current arrangement of the directory hierarchy away from the way they do it > on NextStep to conform a little more to where MacOS puts things by default > so that files that normally are apparent and out in the open but don't have > to be will find a new home in a directory some where. A System-Folder like > thing could be done using whatever goes for aliases in Rhapsody. > Speculation like this is dangerous because you are thinking from the existing Mac OS perspective. The way many of these things are handled on NEXTSTEP is different, and usually much, much easier and error proof. Font management, INITS and Control Panels (if I buy a an Adaptec PowerDomain 2940UW, I'll be installing drivers for it just like the control panels for it on the Mac but once I do that I'll likely _never_ have to worry about the actual files again).. I trust the people who are working on Rhapsody to know where the weakspots are and that they'll be addressed. Its MUCH easier to keep running than my Win 95 box that I use for games. From wjs Sun Apr 6 01:25:14 1997 From: wjs (William Shipley) Date: Thu Nov 3 14:40:20 2005 Subject: System folders and visual debuggers. Message-ID: <9704060925.AA26616@omnigroup.com> I don't want this list to be overcome with the noise of people's wish-lists for environments they love. On the extreme other end of the spectrum, nor do I want it to become an OpenStep evangelism list. It's for discussing facts about development. Right now, since Rhapsody isn't totally defined, this means we'll pretty much be talking about OpenStep/Mach. Speculation should be kept in other lists or newsgroups. I'd like to keep this list lean and mean, so we can keep around the developers at Apple and elsewhere who really don't have time to read 20 messages a day. Thanks, -Wil From lukeh at xedoc.com.au Sun Apr 6 04:19:14 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:20 2005 Subject: Defaults database Was: Mach & D.O. Limitation Message-ID: <199704061119.VAA23747@alpha.xedoc.com.au> >I know that I can write that on my own (and that OmniWeb already did >that)...but IMHO it would be a very nice feature to have for every Yes, but AFAIK Omni's relies on encoding property lists as one property value in NetInfo, whereas supporting NetInfo's hierarchy (ie. directories map to dictionaries and arrays) would be nicer. >If you are not on a NetInfo network Apple could provide an alternative >mechanims which might use a simple DO server process which could hold the >default dictionraries and would offer the few Rhapsody systems on the >local NIS system a way to share that data (don't know if writing into a >special NIS map is a good idea...) A mapping between a NIS map (eg. NeXTdefaults.byname) and the defaults database is conceivable. The OSFM 4.x lookupd has a DO interface, and potentially this could be extended to do such defaults database tricks without the client needing to talk to NetInfo directly. >IMHO regular users and netowrk installation could benefit from this >(perhaps Omni could donate that code to save Apple some time ?) I don't think it would be saving Apple all that time, to be honest, particularly given the Foundation bindings to Objective-C in OSFM. -- Luke From lukeh at xedoc.com.au Sun Apr 6 04:33:04 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:20 2005 Subject: Defaults database Was: Mach & D.O. Limitation Message-ID: <199704061133.VAA23843@alpha.xedoc.com.au> >I don't think it would be saving Apple all that time, to be honest, >particularly given the Foundation bindings to Objective-C in OSFM. I meant to NetInfo. I'll keep quiet on sysadmin matters before I get told off, anyway :-) -- luke From tomi at shinto.nbg.sub.org Sun Apr 6 01:40:00 1997 From: tomi at shinto.nbg.sub.org (Thomas Engel) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <9704041109.AA00258@easynet.fr> References: <9704041109.AA00258@easynet.fr> Message-ID: <9704060940.AA00417@shinto.nbg.sub.org> >4 - I could see two documentations at the same time PBs support for documentation is still not perfect but its a good start. I would like to be able to read the docu for one single method so that I don't have to load the entire docu file into the textview and then scroll for it. I want to write documentation for my classes right inside PB and not have to go to Edit.app to insert those help markers etc. pp. There is a lot that could be done better on the documentation front. But Next already has done a good work compared to other dev systems. And additional nice (and very easy to implement) feature would be to offer tear-off windows from the find panel. While you can ALT-drag a document reference to get the tear of window this is not possible with the small red documentation icons which show up in the search results. Currently you must turn on "tear-off" windows which will generate a new window..even if you don't want them. Given PBs (hopefully) modular implemenation I wonder if it would be to hard to repackage the entire classes and offer something like a dynamic browsing environment ala Taligent and Apple Dylan. It might be a nice alternative way of browsing ones project and coule be offered side by side with the current (Smalltalk oriented) code browser. Aloha Tomi From jpmorice at club-internet.fr Sun Apr 6 10:21:04 1997 From: jpmorice at club-internet.fr (Jean-Pierre Morice) Date: Thu Nov 3 14:40:20 2005 Subject: [need info] HW requirements for OpenStep/Mach/Intel Message-ID: <199704061716.TAA27409@mailhost.grolier.fr> I am willing to put OpenStep/Mach and the dev environment to the test on an Intel box. As a Mac User, I have to secure the corresponding hardware. What are the prerequisites I have to take into consideration ? I have heard ugly stories about IDE vs SCSI, are they true ? Are all video cards supported ? How many megs of RAM ? an so on... thank you by advance... *** jpm *** From ngian at ath.forthnet.gr Sun Apr 6 10:32:35 1997 From: ngian at ath.forthnet.gr (N. G.) Date: Thu Nov 3 14:40:20 2005 Subject: [need info] HW requirements for OpenStep/Mach/Intel Message-ID: <199704061735.UAA12704@info.forthnet.gr> You should check out the NeXT Wed site at "http://www.next.com" and find the Hardware Compatibillity Guide. As far as I know SCSI support is great. Drivers have been added to OpenStep for Mach to support IDE drives although you might encounter some problems. A very big list of video cards are supported so you need not worry. Minimum RAM requirements are 8 MB ( which you should avoid ) but if you want to see OpenStep for Mach in its full glory you must have 32 MB. :-) ---------- > From: Jean-Pierre Morice > To: Multiple recipients of list > Subject: [need info] HW requirements for OpenStep/Mach/Intel > Date: Juqiaj^, Apq_kior 06, 1997 8:19 ll > > > I am willing to put OpenStep/Mach and the dev environment to the test on > an Intel box. > As a Mac User, I have to secure the corresponding hardware. > > What are the prerequisites I have to take into consideration ? > > I have heard ugly stories about IDE vs SCSI, are they true ? > Are all video cards supported ? > How many megs of RAM ? > > an so on... > > thank you by advance... > > *** jpm *** From owolf at pdnt.com Sun Apr 6 12:00:25 1997 From: owolf at pdnt.com (owolf@pdnt.com) Date: Thu Nov 3 14:40:20 2005 Subject: IS THIS FOR REAL??????? Message-ID: <199704061857.NAA13507@tempest.pdnt.net> Once I read that it was an April Fools spoof I realized why it was written. However I was literally jumping for joy before that, thinking that the management at Apple had suddenly been graced with *vision* instead of desparation. I REALLY hope that you can get the right people at Apple to take what was outlined in that post seriously and implement it. I think the ficticious reactions at the end of the "press release" would actually happen. and the dream was so nice while it lasted.... Scott Johnson From mpinkert at cc.gatech.edu Sun Apr 6 13:44:02 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:20 2005 Subject: gdb front end screenshot? Message-ID: <199704062045.QAA14193@lennon.cc.gatech.edu> To clear the water a little bit.... I am _very impressed_ from what I have seen and about PB/IB (the tutorials and documentation on the NeXT site). It looks like a really awesome environment, and if it is as open as people say it is, it should be easy to extend to Java, C++, or whatever else comes down the line. I have yet to see anything about the front end for gdb (which is prompted the swarm of email last week), and since every other attempt I had seen to graft a gui onto gdb or dbx was crap, I am skeptical. Can anyone please send me a screenshot or two (or a url where I can find some documentation) for the openStep front-end to the debugger? Gif, jpeg, ps, or tiff are acceptable. I really want to get a feeling for what it is like to use this debugging environment. Thanks! -- 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 welles at allele.com Sun Apr 6 16:51:46 1997 From: welles at allele.com (Robert Welles) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? References: Message-ID: <9704062351.AA02397@allele.com> you see, most of the MacOS development was done with CodeWarrior. those third-party developers that stuck with MPW and didn't switch to CodeWarrior were burned due to lack of support by Apple. MPW is a good test of whether Amelio knows what to do. If MPW remains funded it is clear that Amelio is not up to speed. so, i say, let the 3rd party compiler developers slug it out. my money is on Metroworks. PB, IB, EOModeler, and WebObjects Builder are required. Unless Apple throws out things like EOF and WebObjects, Apple dev tools will correctly continue to be developed. Bob --- Robert Y. Welles welles@allele.com MIME ok. From bayou at rouge.phys.lsu.edu Sun Apr 6 17:20:02 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:20 2005 Subject: file system Message-ID: How easy will it be to change the Openstep file system? While I'm sure the current unix one is quite fast and can handle large numbers of files, it lacks such niceties as Creator and type codes, resource forks, and the ability to automatically and transparently keep track of Application/document relationships (mac desktop database). How difficult will it be to add such features to the file system? BTW: Does the OS development system have a system for building relational databases or will I still be stuck with foxpro when I get Rhapsody? later, James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From bbum at precipice.com Sun Apr 6 18:01:47 1997 From: bbum at precipice.com (Bill Bumgarner) Date: Thu Nov 3 14:40:20 2005 Subject: file system In-Reply-To: References: Message-ID: <199704070101.VAA01736@lux.precipice.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3192 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970406/1261408e/attachment.bin From sentman at cci.continental.com Sun Apr 6 19:31:48 1997 From: sentman at cci.continental.com (James Sentman) Date: Thu Nov 3 14:40:20 2005 Subject: file system Message-ID: >How easy will it be to change the Openstep file system? > It should be very easy to duplicate the functionality of the mac filesystem without making any changes to Next at all. I'm running the Netatalk appletalk server on our solaris box here that stores all the extra mac info in an invisible folder within the actual folder. Something like that would allow the blue box to coexist with only some very straight forward changes to the filemanager libs on the mac side. This way you would get most of the benifits of a UNIX file system while still getting creators, and resource forks. Is this realistic? I do hope that for the 'yellow' box the file system will not be changed. -James Sentman __________________________________________________________________ James Sentman sentman@cci.continental.com Internet Systems Specialist Continental Cable http://www.continental.com/ http://shoga.wwa.com/~sentman/ __________________________________________________________________ From joel at yinu.co.jp Sun Apr 6 23:50:59 1997 From: joel at yinu.co.jp (Joel Floyd) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? Message-ID: Charles F. Waltrip wrote: >> Maybe Apple should sell Metroworks the entire Rhapsody developer >> environment and get out of the business of competing with >> development tool vendors. Any opinions as developers? Interesting, NeXT Mail people think this is a bad idea, while others think its a good idea. I think its a good idea; Joel From Aris_Colp at next.com Mon Apr 7 02:25:14 1997 From: Aris_Colp at next.com (Aris Colp) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate References: Message-ID: <9704070925.AA08603@femail.next.com> Apart from the basic startup scripts (/etc/rc*) which take care of bring the OS up, a great deal of what is usually in flat files on other variants of UNIX are in NetInfo which comes built into NeXTSTEP machines (although NetInfo is not part of the OPENSTEP spec). In some ways, one can view a NetInfo database as a system folder (don't get me wrong here, I know what both are). Furthermore, you can define network-wide configuration details in a parent NetInfo database (so that you don't have to go and change every machines configuration). Some application developers have chosen to use NetInfo as a basic hierarchical, distrubuted database available on all NeXT machines, to store configuration details... others use the defaults database. I see no reason not to move the defaults database into netinfo (for specific users you could put the details in either password directory in NetInfo, and if the user doesn't have any it could inherit them from some default user). One could also modify dread/dwrite to be Netinfo clients, rather than working on flat files. A. >I hope both ways will be possible. For a single user, having a sytem >folder, and all the configurations panels is great, but to configure a >network, if the system administrator could do the job once for >every computer using some files and shell command, it would >be nice too. -- Aris Colp NeXT Technical Support, Apple Computer Inc. aris@next.com; +1-415-780-3712; http://www.next.com/~aris From john at balconessoftware.com Mon Apr 7 02:52:03 1997 From: john at balconessoftware.com (John R. Miller) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: Message-ID: Joel Floyd wrote: >Charles F. Waltrip wrote: >>> Maybe Apple should sell Metroworks the entire Rhapsody developer >>> environment and get out of the business of competing with >>> development tool vendors. Any opinions as developers? > >Interesting, NeXT Mail people think this is a bad idea, while others think >its a good idea. > >I think its a good idea; Note: not NeXT Mail, not NeXT person/developer; I think it's a very bad idea. I also think it's off topic. --- John R. Miller Balcones Software 13102 Briar Hollow Dr. Austin, TX 78729 USA mailto:john@balconessoftware.com http://www.balconessoftware.com 512/258-3731 or 512/353-7289 fax: 512/331-0155 or 512/353-3008 From grio at 280.com Mon Apr 7 02:50:23 1997 From: grio at 280.com (Dan Grillo) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate References: <9704070925.AA08603@femail.next.com> Message-ID: <199704070950.CAA01919@280.com> Aris Colp writes: > I see no reason not to move the defaults database into netinfo Netinfo is a fast read/slow write system; when making a write you have to talk directly to the master of that database, not to a clone. If everyone in a company kept their defaults in .. or /, it would be really, really slow, esp. for default items like last window position, which get written out all the time. --Dan -- Dan Grillo dan_grillo@280.com 415 575-4020 fax 415 703-7220 From carter at tuj.ac.jp Mon Apr 7 03:07:05 1997 From: carter at tuj.ac.jp (Stephen N. Carter) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: Message-ID: >Joel Floyd wrote: >>Charles F. Waltrip wrote: >>>> Maybe Apple should sell Metroworks the entire Rhapsody developer >>>> environment and get out of the business of competing with >>>> development tool vendors. Any opinions as developers? >> >>Interesting, NeXT Mail people think this is a bad idea, while others think >>its a good idea. >> >>I think its a good idea; > >Note: not NeXT Mail, not NeXT person/developer; I think it's a very bad idea. > >I also think it's off topic Perhaps we need a review of what's on topic. This seemed on topic to me, so I must not understand the scope of the list. Steve Carter ********************** ******************************** Stephen N. Carter 2-8-19 Minami Azabu, Minato-ku Computer Systems Administration Tokyo, Japan 106 Temple University Japan Phone: +81 3 5441 9800 Ext 502 ************************ Fax: +81 3 5441 9822 ******************************** From malte at us.upnet.se Mon Apr 7 05:04:41 1997 From: malte at us.upnet.se (Malte Tancred) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: <97Apr7.130323gmt-0100.28701-1@mimer.upnet.se> References: <97Apr7.130323gmt-0100.28701-1@mimer.upnet.se> Message-ID: <97Apr7.131722gmt-0100.28724-1@mimer.upnet.se> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 488 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970407/6c9fbf56/attachment.bin From scott at QuickBase.com Mon Apr 7 06:36:11 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:20 2005 Subject: file system In-Reply-To: References: Message-ID: <9704071336.AA09741@QuickBase.com> You wrote: > While I'm sure the current unix one is quite fast and can handle > large numbers of files, it lacks such niceties as Creator and type > codes, resource forks, and the ability to automatically and > transparently keep track of Application/document relationships --- While this may be true with unix, we aren't talking about unix! We are talking about OpenStep/NeXTSTEP which provides functional equivalents to the things you say are missing. I have to admit though, the things that ARE MISSING FROM NeXTSTEP when compared to MacOS include: 1. Poor print spooling. 2. A slow and unreliable file system. 3. Frequent system crashes. 4. Blocking file transfers. 5. Slow networking. 6. Blocking file operations. Awe darn! I am especially going to miss the those system crashes with the little bomb. As you can see from the list, NeXTSTEP is pretty deficient in a number of areas. But I am sure we will all adjust. My recommendation is to take a close look at NeXTSTEP before criticizing it. I think you will find that it is slightly different from MacOS, but easier and more convenient to use. You don't know what your missing until you have tried it. BTW, Can we please stop referring to NeXTSTEP/OpenStep as functionally equivalent to Unix? Thanks. Best regards, Scott Keith ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From scott at QuickBase.com Mon Apr 7 06:46:06 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:20 2005 Subject: file system & database In-Reply-To: References: Message-ID: <9704071346.AA09764@QuickBase.com> You wrote: > BTW: Does the OS development system have a system for building > relational databases or will I still be stuck with foxpro when I > get Rhapsody? --- Rhapsody has EOF (Enterprise Objects Framework), an advanced database connection product allowing applications to be built with database and database structure independence. It is really a nice system and it works with our product OpenBase SQL Server (for Rhapsody). There is a third party database product that will be announced in the next couple of months (based on OpenBase SQL Server) which will provide 4thDimention like functionality with more power. Best regards, Scott Keith ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From ehrich at minn.net Mon Apr 7 08:41:39 1997 From: ehrich at minn.net (William Ehrich) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? In-Reply-To: Message-ID: > Maybe Apple should sell Metroworks the entire Rhapsody developer > environment and get out of the business of competing with > development tool vendors. Any opinions as developers? I write C programs built with MPW, simple makefiles, and Motorola's compiler. I hope to be able to continue doing something like this, so as to concentrate on what the programs do and continue to avoid Metroworks. - Bill Ehrich From cpr at stibo.dk Mon Apr 7 08:24:15 1997 From: cpr at stibo.dk (Claus Priisholm) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? References: Message-ID: <199704071524.RAA00298@supermule.aas.stibo.dk> >I write C programs built with MPW, simple makefiles, and Motorola's >compiler. I hope to be able to continue doing something like this, so as to >concentrate on what the programs do and continue to avoid Metroworks. > >- Bill Ehrich Admitted it is more than 10 years ago I used MPW, but as I understand from this list, it is still a kind of shell environment, and if there is an area where UNIX excel it is in shell's. There are countless shells and tools that works with them. And even though I normally develop using the NEXTSTEP dev.tools, I still enjoy being able to type: make hack.c when I just need to make some minor hack. To add my 0.02$ to the UNIX vs MacOS debate: I have worked with many different UNIX based windowing systems, and most of the time they merely gave me the opportunity to have multiple terminal windows running shells. NEXTSTEP is the first of them to provide a 'desktop system' feel, where the visit to a shell window is fairly seldom - a couple a times per day on average, but then again I am a programmer (and I would not want to be without the powerful UNIX utilities). The average user propably never end up in a shell unless told to do so by a sadistic supporter... NEXTSTEP/OPENSTEP/Rhapsody is a fully fledged desktop/windows system with UNIX under the hood, whereas most other UNIX's are UNIX with a windowing system in the trunc... So please don't say NEXTSTEP = UNIX, because then I might be just as unreasonable and claim that MacOS is a fully fledged desktop/windows system with nothing under the hood :-) Apple should consider very carefully before removing any of the shell capabilities from Rhapsody, although, considering the confusion it seems to cause, it may be well advised to downplay the role of UNIX. --- Claus Priisholm (cpr@stibo.dk) From rm at objectdata.com Mon Apr 7 08:09:37 1997 From: rm at objectdata.com (Robert MacKimmie) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's !!! References: Message-ID: <9704071509.AA00244@objectdata.com> >>> people think this is a bad idea, while others think its a good idea ... It defies logic to even speculate that Apple purchased NeXT for $400 million, only to have people suggest that the family jewels be given away. We might as well give away the Statue of Liberty, the Liberty Bell and the Declaration of Independence... From kjell at oops.se Mon Apr 7 08:49:12 1997 From: kjell at oops.se (Kjell Nilsson) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's !!! In-Reply-To: <97Apr7.165606gmt-0100.28718-1@mimer.upnet.se> Message-ID: <97Apr7.170142gmt-0100.28713-1@mimer.upnet.se> Enough ! Move to comp.sys.next.advocacy -- Kjell Nilsson - Member of Swedish Object Guild OOPS art HB, Phone +46-31-499713, Fax +46-31-474594 URL http://www.oops.se kjell@oops.se - NeXTMail, Mime welcome From Chris_Kane at next.com Mon Apr 7 08:58:52 1997 From: Chris_Kane at next.com (Chris Kane) Date: Thu Nov 3 14:40:20 2005 Subject: The system folder's fate References: <9704070925.AA08603@femail.next.com> Message-ID: <9704071558.AA07102@oz.next.com> Aris_Colp@next.com writes: > I see no reason not to move the defaults database into netinfo [...] NetInfo does not scale well to massive quantities of info. At 50K of defaults per user (a typical number for an OPENSTEP-ified system), a 200-user site needs 10MB of just defaults info in NetInfo, all of which needs to be sync'd across the network (usually not all in one batch, unless a clone server was down and missed an update, and then it gets the whole database). The current NetInfo implementation needs major work before storing user defaults in it becomes practical. Christopher Kane OpenStep Application Frameworks From waltrip at aurora.jhuapl.edu Mon Apr 7 09:13:24 1997 From: waltrip at aurora.jhuapl.edu (Charles F. Waltrip) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? References: Message-ID: <33491D24.68B4@aurora.jhuapl.edu> Joel Floyd wrote: > > Charles F. Waltrip wrote: > >> Maybe Apple should sell Metroworks the entire Rhapsody developer > >> environment and get out of the business of competing with > >> development tool vendors. Any opinions as developers? > > Interesting, NeXT Mail people think this is a bad idea, while others > think its a good idea. > This is the division of opinion I expected. As you probably noted also, some good points were made. I'd like to comment on a couple of them. kpackard@wpine.com (Kevin Packard) noted that Metroworks saved the day for Apple developers during the transition to Power PC. This was definately a case where it was invaluable not to be stuck with a single supplier. I am glad that Apple is supportive of Metroworks' efforts to port CodeWarrior but is that enough? It might be if Apple could be left alone for awhile. However, the recent track record is not encouraging in that respect. Management changes and downsizing have already led to major instability (instability was NeXT's problem as well). With Larry Ellison talking takeover and no reason to believe that Apple's turnaround point has been reached, instability seems likely to remain a feature of Apple's future for a good while. That point was illustrated anecdotally when Keith Ray (Ray ) wrote "When the cost-cutting began, ETO and MPW were earning very little revenues, so **SNIP**, a 50-person department gets reduced to 5." Do you believe it *couldn't* happen again? Or would you rather have an independent supplier whose *primary* business was to supply development tools? But there's more to be considered. Garance A Drosehn weighed in with some excellent points (as usual). He noted that it could be necessary for Apple to make some changes to the system that would require changes to IB and PB. He also noted that Apple should make it easy for writers of other development tools to hook in to the main development environment. This suggests that Apple should not sell their development tools, they should license them (with source) to other development environment vendors for a fee. Internally, they could concentrate on making the changes noted by Garance, improving the tools (the better they are, the better they sell and the more they make from license fees) and developing frameworks, etc. Apple could continue to sell the tools directly as well. It must be noted that the development environment competition is going to heat up by an order of magnitude because of Java. The Netscape/IBM/JavaSoft/Symantec alliance should result in some superb tools. It will be virtually impossible for one vendor to supply a complete set of tools. Apple could be a player if they fix their tools up so that they a. support Java; and b. have the hooks to play with the other tools (as Garance suggested. Perhaps best of all, Apple should not only license their tools, they should actively try to sell members of the Netscape/IBM/JavaSoft/Symantec alliance on licensing them from Apple. Again, what do *you* think? Chuck PS: I've left this under the original topic since, another way of saying part of what I've just said is: a Development Framework is one of what's missing from the Developer Tools/Frameworks. From j_frey at lvc.edu Mon Apr 7 09:32:34 1997 From: j_frey at lvc.edu (Jeffrey Frey) Date: Thu Nov 3 14:40:20 2005 Subject: file system In-Reply-To: <9704071336.AA09741@QuickBase.com> Message-ID: >> While I'm sure the current unix one is quite fast and can handle >> large numbers of files, it lacks such niceties as Creator and type >> codes, resource forks, and the ability to automatically and >> transparently keep track of Application/document relationships > >My recommendation is to take a close look at NeXTSTEP before >criticizing it. I think you will find that it is slightly different >from MacOS, but easier and more convenient to use. You don't know >what your missing until you have tried it. There is a definite problem implicit in your thinking here, namely the fact that if we are to make Rhapsody a lucrative environment for current and future MacOS users, it needs to look and feel (underneath any fancy new garnish) like the same old MacOS. The average Joe user has now learned what he needs to do to work with MacOS 7.x, and we're about to tell him that he can't do it that way anymore? It's not going to fly; in fact, this is the main problem with Win95 on my campus -- users who were moved from Win3.1 to Win95 must cope with the paradigm shift involved. We MacOS programmers have to make some sacrifices, but you OpenSTEP/NeXTSTEP developers must also yield to some of our wishes. Don't forget; we're here to create a NEW operating system, not port OpenSTEP to the Mac. -Jeff -------------------------------------------------------- Jeffrey T. Frey SimplisticSolutions(TM) Lebanon Valley College Software Design & Computer Services Dept. Macintosh Consulting (Head Lab Asst.) (Founder, Programmer) Specializing in software and hardware solutions for users of the Apple Macintosh. j_frey@lvc.edu Work:(717)867-6072 Home:(717)272-6597 http://indigo.lvc.edu/~jfrey -------------------------------------------------------- From ricardo at ccsi.canon.com Mon Apr 7 09:36:30 1997 From: ricardo at ccsi.canon.com (Ricardo Parada) Date: Thu Nov 3 14:40:20 2005 Subject: Developer Tools / Frameworks - what's missing? References: <33491D24.68B4@aurora.jhuapl.edu> Message-ID: <9704071636.AA05670@ccsi.canon.com> Pleeaase, move this discussion to comp.sys.next.advocacy where it belongs. Thanks, ricardo From bayou at rouge.phys.lsu.edu Mon Apr 7 09:45:11 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:20 2005 Subject: file system Message-ID: >While this may be true with unix, we aren't talking about unix! We are >talking about OpenStep/NeXTSTEP which provides functional equivalents to >the things you say are missing. That's good to hear, but it's still a unix files system is it not? The only difference is that the OS jury-rigs sub directories into appearing as applications. I don't consider that to be an elegant solution. However, since it has been said that it would be fairly easy to add traditional mac filesystem functionality, I'm satisfied that they will. The bottom line is that I, as a user, don't want to have to worry about pathnames of applications and documents. Documents should belong to certain applications and the owner app should be independant of file type. I also don't want to fiddle with filename extensions. I consider that archaic and inelegant. The filename should contain only information I consider relevant. I don't want to ever have to worry about a list of application path names and a list of what file types belong to what apps. Simply stated, I want Rhapsody to basically work like the mac finder works now. I double click an arbitrarily named document with potentially a unique-to-that-document icon, and the owner of the document opens. So, if Rhapsody meets these goals, then I don't really care about the unix file system and it's jury-rigged subdirectories underneath. BTW: Are these jury-rigged subdirectories, "bundles?", for applications only or can any arbitrary file have a bundle, just as any mac file can have a resource fork? >I have to admit though, the things that ARE MISSING FROM NeXTSTEP when >compared to MacOS include: Now...why get all emotional and sarcastic? I didn't say anything bad about your church. Aren't we adults here? >1. Poor print spooling. >2. A slow and unreliable file system. >3. Frequent system crashes. >4. Blocking file transfers. >5. Slow networking. >6. Blocking file operations. > >Awe darn! I am especially going to miss the those system crashes with the >little bomb. As you can see from the list, NeXTSTEP is pretty deficient in a >number of areas. But I am sure we will all adjust. Why do you think Apple bought Next? :) ...but just because I gain stability and performance is no reason why I should give up sophistication, elegance and ease of use. >My recommendation is to take a close look at NeXTSTEP before criticizing >it. I think you will find that it is slightly different from MacOS, but easier >and more convenient to use. You don't know what your missing until you >have tried it. I wasn't criticizing OpenStep. I was criticizing a Unix file system. Happily, I've been informed that OS is completely Independant of it's file system. > >BTW, Can we please stop referring to NeXTSTEP/OpenStep as functionally >equivalent to Unix? Thanks. I didn't. I refered to a unix file system which I hate....with a passion. James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From bayou at rouge.phys.lsu.edu Mon Apr 7 09:52:57 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:20 2005 Subject: multiple copies of messages Message-ID: I quite often, but not always, get 2 copies of messages from the list. Are others having this problem? James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From dbj at apple.com Mon Apr 7 02:54:27 1997 From: dbj at apple.com (Dirk Johnson) Date: Thu Nov 3 14:40:20 2005 Subject: [need info] HW requirements for OpenStep/Mach/Intel Message-ID: <199704071654.JAA31232@scv2.apple.com> >I am willing to put OpenStep/Mach and the dev environment to the test on >an Intel box. >As a Mac User, I have to secure the corresponding hardware. > >What are the prerequisites I have to take into consideration ? > >I have heard ugly stories about IDE vs SCSI, are they true ? >Are all video cards supported ? >How many megs of RAM ? > >an so on... > >thank you by advance... Check out www.next.com. There is a section devoted to Intel hardware. A few pointers: Make sure there are drivers for the video card and SCSI controller BEFORE you buy them. Basically, for development, I would suggest minimum 32MB RAM, but preferably 64MB. A full dev tools install takes about 700MB, so get a very large HD. I suggest ALL drives be SCSI (even though the docs say it can handle IDE drives.) Stay away from NEC CD-ROMs - there seems to be a compatibility issue there. I would suggest working with a company like Data Net that sells CPUs pre-installed with OpenStep for Mach - it will save you lots of pain... and they deliver. =) Data Net 1188 Tiko Dr. Sunnyvale, CA 94089 408/747-1100 Dirk Johnson Developer Apple Computer, Inc. From bayou at rouge.phys.lsu.edu Mon Apr 7 10:42:27 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:20 2005 Subject: Plug'n'? (was HW requirements) Message-ID: >I would suggest working with a company like Data Net that sells CPUs >pre-installed with OpenStep for Mach - it will save you lots of pain... >and they deliver. =) This raises an interesting question. Is Openstep "plug'n'play" or "plug'n'pray?" :) Are the difficulties Intel platform related or can we expect to have such problems on Apple/Mac Clone/CHRP hardware as well? James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From scott at QuickBase.com Mon Apr 7 10:15:24 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:20 2005 Subject: NeXTSTEP is not UNIX In-Reply-To: <199704071510.LAA28366@lennon.cc.gatech.edu> References: <199704071510.LAA28366@lennon.cc.gatech.edu> Message-ID: <9704071715.AA10154@QuickBase.com> Mike Pinkerton wrote: > I dunno about that one....I can drag and item from one printer's > spool... > I wasn't aware you could do that in unix (or nextstep). It is NeXTSTEP. You can choose a printer or fax-modem anywhere on the network (when you print). Fax modems and printers can be defined public and private using graphical tools. They are both treated the same, except that you can specify a fax cover sheet when faxing. NeXTSTEP provides some backward compatibility with Unix commands, but the interface and management tools are more like the MacOS than Unix. You never see the Unix. It is based on the same concept as MacOS. NeXTSTEP and the MacOS were designed by the same person, Steve Jobs. The differences between the two are not significant. It wouldn't bother me to see NeXTSTEP take on the Mac interface. However, we have to be careful not to throw out the innovations or label them names (such as UNIX -- giving the connotation that it is just a command line interface). Labeling NeXTSTEP "unix" is like saying the Macintosh is really an IBM PC running DOS. It simply isn't true. Best regards, Scott Keith You wrote: > Scott Keith wrote on 4/7/97 9:52 AM > > >1. Poor print spooling. > > I dunno about that one....I can drag and item from one printer's > spool (while it is printing) and drop it on another printer and it > will switch automatically (it will even ask where I want to start > printing on the new printer, at the start or where the first one > left off). I wasn't aware you could do that in unix (or nextstep). > > -- Mike Pinkerton mpinkert@cc.gatech.edu > > Cyberdog: On the Internet, no one knows you're an OpenDoc part > --- ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From kc Mon Apr 7 10:54:35 1997 From: kc (Ken Case) Date: Thu Nov 3 14:40:20 2005 Subject: rhapsody-dev charter revisited: what's on topic, what isn't Message-ID: <9704071754.AA11490@omnigroup.com> Apparently, it's once again time to review our charter... The goal of rhapsody-dev is to provide a forum for those interested in developing software for Rhapsody to make progress towards that goal. Anything that helps that goal is "signal," anything else is "noise." I want to maintain a high signal-to-noise ratio on this list. This list is not for discussing what should be, it is for discussing (to the best of our knowledge) what what will be. We're not trying to affect Apple's (or anyone else's) direction here (not that that's not a worthwhile endeavor, it just belongs in a different forum). On this list, we are simply trying to help each other develop software for Rhapsody. If there's interest in discussing other Rhapsody-related topics (such as whether Apple should sell their development environment to Metroworks), I'm perfectly willing to create another list ("rhapsody-talk," perhaps?) which has a broader charter than this one. (Nobody has requested this yet, so I'm currently working under the assumption that newsgroups such as comp.sys.next.advocacy already fill that need.) Perhaps it would also help if I give a concrete example of staying within the bounds of this list... Discussing how the filesystem should work is not appropriate for this list, because it doesn't help us develop software for Rhapsody. Discussing how the current NEXTSTEP or Macintosh filesystems work might be appropriate for this list, if it helps us have a better understanding of how Rhapsody's filesystem may work. Discussing OpenStep's filesystem-independent API for accessing files is completely appropriate, since we've been told that the OpenStep APIs will be part of Rhapsody. Thank you. Your host, Ken From scott at QuickBase.com Mon Apr 7 10:57:44 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:20 2005 Subject: Plug'n'? (was HW requirements) In-Reply-To: References: Message-ID: <9704071757.AA10235@QuickBase.com> On Intel it is sometimes plug 'n' pray. That is why it is a good idea that you have a configuration that works well together. I'm looking forward to an integrated PowerPC solution from Apple. :-) - Scott You wrote: > >I would suggest working with a company like Data Net that sells > >CPUs pre-installed with OpenStep for Mach - it will save you lots > >of pain... and they deliver. =) > > This raises an interesting question. > > Is Openstep "plug'n'play" or "plug'n'pray?" :) > > Are the difficulties Intel platform related or can we expect to > have such problems on Apple/Mac Clone/CHRP hardware as well? > ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From wongj at rpi.edu Mon Apr 7 11:28:24 1997 From: wongj at rpi.edu (Jasper Y. Wong) Date: Thu Nov 3 14:40:20 2005 Subject: NeXTSTEP is not UNIX In-Reply-To: <9704071715.AA10154@QuickBase.com> from "Scott Keith" at Apr 7, 97 10:49:42 am Message-ID: <199704071828.OAA40384@alumni.rpi.edu> > > Mike Pinkerton wrote: > > I dunno about that one....I can drag and item from one printer's > > spool... > > I wasn't aware you could do that in unix (or nextstep). > > It is NeXTSTEP. You can choose a printer or fax-modem anywhere on > the network (when you print). Fax modems and printers can be > defined public and private using graphical tools. They are both > treated the same, except that you can specify a fax cover sheet when > faxing. > > NeXTSTEP provides some backward compatibility with Unix commands, > but the interface and management tools are more like the MacOS than > Unix. You never see the Unix. It is based on the same concept as > MacOS. > > NeXTSTEP and the MacOS were designed by the same person, Steve > Jobs. The differences between the two are not significant. It > wouldn't bother me to see NeXTSTEP take on the Mac interface. > However, we have to be careful not to throw out the innovations or > label them names (such as UNIX -- giving the connotation that it is > just a command line interface). > > Labeling NeXTSTEP "unix" is like saying the Macintosh is really an > IBM PC running DOS. It simply isn't true. > > Best regards, > > Scott Keith > > Huh? I believe NeXTStep is the GUI environment on top of the Mach operating system (a variety of UNIX). MacOS is a completely different beast altogther. Jasper > > You wrote: > > Scott Keith wrote on 4/7/97 9:52 AM > > > > >1. Poor print spooling. > > > > I dunno about that one....I can drag and item from one printer's > > spool (while it is printing) and drop it on another printer and it > > will switch automatically (it will even ask where I want to start > > printing on the new printer, at the start or where the first one > > left off). I wasn't aware you could do that in unix (or nextstep). > > > > -- Mike Pinkerton mpinkert@cc.gatech.edu > > > > > Cyberdog: On the Internet, no one knows you're an OpenDoc part > > > --- > > ____________________________________________________________________ > > OPENBASE INTERNATIONAL LTD. http://www.openbase.com > 58 Greenfield Road e-mail: info@openbase.com > Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 > -- --< NeXT >--| Table Tennis | \ / | Volleyball |--< BeBox >-- | Gergely / TSP X / RITC 802 \ / Tachikara SC-5W / Mizuno | | wongj@rpi.edu, jwong@bccn.org \ / IRC: mizzle @ #unix, #next | --< Homepage forever under .... \/ .... construction >NeXTMail>-- From bayou at rouge.phys.lsu.edu Mon Apr 7 11:35:01 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:20 2005 Subject: rhapsody-dev charter revisited: what's on topic, what isn't Message-ID: >Apparently, it's once again time to review our charter... > >The goal of rhapsody-dev is to provide a forum for those interested in >developing software for Rhapsody to make progress towards that goal. >Anything that helps that goal is "signal," anything else is "noise." I >want to maintain a high signal-to-noise ratio on this list. Are questions concerning how Openstep works and how it can be integrated with MacOS lawful? I want to get an idea of what this new thing is going to be able to do and how my work, which includes custom software development, will be affected. James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From Robert.Kieffer at Eng.Sun.COM Mon Apr 7 11:43:01 1997 From: Robert.Kieffer at Eng.Sun.COM (Robert Kieffer) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <199704071828.OAA40384@alumni.rpi.edu> References: <199704071828.OAA40384@alumni.rpi.edu> Message-ID: <199704071843.LAA12700@litehouse.eng.sun.com> >From http://www.techweb.com/wire/news/mar/0404apple.html > Apple's Java Rhapsody > (04/04/97; 3:30 p.m. EST) > By Deborah Gage, _Computer Reseller News_ > > SAN FRANCISCO -- Apple Computer is advising Apple developers > to plan to write applications in Java. > > Apple officials said the company plans to "Javatize" all > OpenStep _APIs)_. Apple is aiming to have the Java APIs set > for the developer release of Rhapsody slated for this summer. > > "Rhapsody developers will never have to learn Objective C. > The only reason NeXT did it was because Java was not around, > but they didn't make that last jump. OpenStep will have a > giant collection of Java libraries, and if those don't meet > your needs you can call the extra OpenStep libraries," said > Apple Product Manager Will Iverson. Iverson said Java also > solves the security problems that plague Microsoft's ActiveX > and would have plagued OpenDoc had Apple kept it. Apple is > also ruminating on a cross-platform strategy once Rhapsody is > ported to the PowerPC. > > Iverson promised formal announcements of the Java Rhapsody > effort in the near future. ) From toon Mon Apr 7 12:15:56 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:20 2005 Subject: gdb front end screenshot? In-Reply-To: <199704062045.QAA14193@lennon.cc.gatech.edu> References: <199704062045.QAA14193@lennon.cc.gatech.edu> Message-ID: <9704071915.AA12965@omnigroup.com> Mike Pinkerton says: > I have yet to see anything about the front end for gdb (which is > prompted the swarm of email last week), and since every other > attempt I had seen to graft a gui onto gdb or dbx was crap, I am > skeptical. I made a couple screenshots and some explanations and put them at: http://www.omnigroup.com/People/toon/gdb_gui/ The page is kind of written for Mike in that it assumes you know the basics about ProjectBuilder and about the capabilities of Unix gdb so it doesn't go into detail about features of either one. It just talks about the visual front end for gdb and how it interfaces with PB. If you aren't familiar with PB or gdb it might seem as if the debugger doesn't do a whole lot... Gdb is actually a very capable debugger, just not terribly friendly. Many debugging features are in there that just aren't exposed by the GUI. In some sense it is graphical "sugar" on a basically command-line oriented way of debugging, but (a) it is very well done, very easy to use sugar and (b) for anything more complicated than breaking/stepping/showing values I prefer a command-line interface anyway. --Greg From gad at eclipse.its.rpi.edu Mon Apr 7 14:01:16 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:20 2005 Subject: file system / list-charter References: Message-ID: <9704072101.AA05867@eclipse.its.rpi.edu> I have no idea how to encourage people to stick to development topics without sounding like some kind of smart-ass jerk myself. And, to be honest, I'm probably as guilty as the next guy when it comes to jumping in with my opinions on issues that are just tangents to development. However, it would be nice if we could somehow figure out how to keep this mailing list from drifting too far a-field. I suggest the following measure of what constitutes a useful message for this mailing list: "Will my message, or the answer to my message, be something that some developer is going to archive away, because the message (or the answer to it) will help them write some code for Rhapsody?" Note that this does not include topics which "effect" developers, like the price of Rhapsody or the makeup of the file system. It is only supposed to cover "Writing Code". While the file system question might effect whether *you* (some specific person) decide to write any code at all, your decision is not something I'm going to use when I am in the process of writing code. At no time will I be in the middle of some programming assignment and say "Gee, I wonder what Jim thinks about NeXTSTEP file systems? Boy, I'll need to know his opinion to get this widget-window working!". Hopefully it will be easier to keep to programming questions once Rhapsody is in our hot little hands, and we'll be more involved with real projects instead of speculation about how Rhapsody may, could or should be designed. We'll be too busy with how it is in fact designed, and how to get what we want out of it. Well, at least I can hope that's how it will work out... --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA [I'm not a jerk, but I can play one on mailing lists] From kai at khms.westfalen.de Mon Apr 7 15:39:00 1997 From: kai at khms.westfalen.de (Kai Henningsen) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <199704071843.LAA12700@litehouse.eng.sun.com> Message-ID: <6UV84SFUcsB@khms.westfalen.de> Robert.Kieffer@Eng.Sun.COM (Robert Kieffer) wrote on 07.04.97 in <199704071843.LAA12700@litehouse.eng.sun.com>: > >From http://www.techweb.com/wire/news/mar/0404apple.html > > "Rhapsody developers will never have to learn Objective C. > > The only reason NeXT did it was because Java was not around, I'd much rather be told I don't need to learn Java to program for Rhapsody. MfG Kai From izumi at pinoko.berkeley.edu Mon Apr 7 19:27:23 1997 From: izumi at pinoko.berkeley.edu (Izumi Ohzawa) Date: Thu Nov 3 14:40:20 2005 Subject: Opener'able version of new Rhapsody OpenStep doc Message-ID: <199704080227.TAA03234@moica.berkeley.edu> According to http://www.macintouch.com/ new files (most dated Apr. 2) on AppKit/Foundation/DevTutorial are at: ftp://dev.apple.com/devworld/Technical_Documentation/Rhapsody_OpenStep_Documentation/ However, it drives me crazy to see all those *.sit.hqx files which Opener.app can't handle. Is there a non-Mac specific version of all this documentation somewhere? Most infuriating of all, they also sit-hqx'ify Acrobat (PDF) files which are already compressed and very platform-independent, presumably just to preserve resource forks. Is it just me who thinks that this is crazy and counter-productive? From welles at allele.com Mon Apr 7 19:36:13 1997 From: welles at allele.com (Robert Welles) Date: Thu Nov 3 14:40:20 2005 Subject: file system References: <9704071336.AA09741@QuickBase.com> Message-ID: <9704080236.AA10509@allele.com> Consistent with the rhapsody-dev charter it must be said that Mach supports multiple file systems and that OpenStep/NeXTSTEP exploit this feature to simultaneously provide Mac, MS, and Unix file systems. You can plug a hard drive from a Mac into the SCSI chain on a NeXT machine and the OS will recognize the drive as a Mac file system. When you format a floppy disk you can format it as MS, Mac, or Unix. Bob --- Robert Y. Welles, (408)867-9567 welles@allele.com MIME ok. From bbum at precipice.com Mon Apr 7 19:41:27 1997 From: bbum at precipice.com (Bill Bumgarner) Date: Thu Nov 3 14:40:20 2005 Subject: file system In-Reply-To: <9704080236.AA10509@allele.com> References: <9704080236.AA10509@allele.com> Message-ID: <199704080241.WAA03049@lux.precipice.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 841 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970407/cb6bf189/attachment.bin From sanguish at digifix.com Mon Apr 7 20:22:54 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:20 2005 Subject: Opener'able version of new Rhapsody OpenStep doc In-Reply-To: <199704080227.TAA03234@moica.berkeley.edu> References: <199704080227.TAA03234@moica.berkeley.edu> Message-ID: <199704080322.WAA05706@digifix.com> Izumi Ohzawa wrote: > Most infuriating of all, they also sit-hqx'ify Acrobat (PDF) files > which are already compressed and very platform-independent, presumably > just to preserve resource forks. Is it just me who thinks that this > is crazy and counter-productive? No. Prime arguement against multiple-fork file systems. Aladdin had said that they would release an OpenStep/NEXTSTEP tool quickly I thought.. I guess hoping that it would be sooner rather than later would be pushing it... Its _probably_ safe to assume that they are just binhex versions of the macbinary stuffit files that have been available on the NeXT site for a couple of months now. From gad at eclipse.its.rpi.edu Mon Apr 7 21:11:30 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:20 2005 Subject: Opener'able version of new Rhapsody OpenStep doc References: <199704080227.TAA03234@moica.berkeley.edu> Message-ID: <9704080411.AA06845@eclipse.its.rpi.edu> Izumi Ohzawa writes: > However, it drives me crazy to see all those *.sit.hqx files > which Opener.app can't handle. > > Is there a non-Mac specific version of all this documentation > somewhere? > > Most infuriating of all, they also sit-hqx'ify Acrobat (PDF) > files which are already compressed and very platform-independent, > presumably just to preserve resource forks. Is it just me who > thinks that this is crazy and counter-productive? The sit files are serving two purposes: 1) save the "info fork" (file type and creator) info, so the PDF files will open up in Adobe Acrobat and not something like Simpletext. 2) some of those sit files are actually holding a directory of many PDF files. Mac developers can download 18 stuffit files, instead of 210 individual PDF files. The stuffit files do get a bit more compression, too. It looks like it's about a 22% savings. This is quite reasonable for an audience of MacOS developers. Of course I agree that it's not convenient for NeXTSTEP developers, but one would guess that this is Apple's attempt to get the documentation out to MacOS developers. Note that all Ric Ford (macintouch) said was "apparently it is updated". He didn't say "Apple has announced that developer documentation as rewritten for Rhapsody is now available". >From what I can see by 10 minutes of looking at these PDF files, they seem mighty similar to the documentation that NeXTSTEP owners already have on their CD-ROM's (although my 4.1 system is not here at work, so I can't really say for sure). The main README, for instance, says that the developer tutorial "Introduces programmers to NeXT's OPENSTEP 4.0 Developer Product". That ain't Rhapsody. I could make these PDF files available on eclipse in a tar.gz archive, assuming I would not break any rules by doing that. My guess is that it's not worth the trouble. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From paulrs at lgs-systems.com Mon Apr 7 12:49:59 1997 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <199704071843.LAA12700@litehouse.eng.sun.com> References: <199704071843.LAA12700@litehouse.eng.sun.com> Message-ID: <9704071950.AA14180@cube> Hello all, I'm confused about one key aspect of the announcement below. As I understand it, Java currently supports extensibility only through sublassing. Extension of classes through categories, as we have them in Objective-C, is not available. Given the fact that a tremendous amount of the OpenStep APIs were written using categories, how is this not going to present a large problem? Let me say that I feel quite strongly that it will be wonderful if all of the OpenStep APIs are written in Java, but I'm still hung up on this fundamental problem of Java lacking extensibility through categories. How do you get around this? Regards, Paul You wrote: > >From http://www.techweb.com/wire/news/mar/0404apple.html > > > Apple's Java Rhapsody > > (04/04/97; 3:30 p.m. EST) > > By Deborah Gage, _Computer Reseller News_ > > > > SAN FRANCISCO -- Apple Computer is advising Apple developers > > to plan to write applications in Java. > > > > Apple officials said the company plans to "Javatize" all > > OpenStep _APIs)_. Apple is aiming to have the Java APIs set > > for the developer release of Rhapsody slated for this summer. > > > > "Rhapsody developers will never have to learn Objective C. > > The only reason NeXT did it was because Java was not around, > > but they didn't make that last jump. OpenStep will have a > > giant collection of Java libraries, and if those don't meet > > your needs you can call the extra OpenStep libraries," said > > Apple Product Manager Will Iverson. Iverson said Java also > > solves the security problems that plague Microsoft's ActiveX > > and would have plagued OpenDoc had Apple kept it. Apple is > > also ruminating on a cross-platform strategy once Rhapsody is > > ported to the PowerPC. > > > > Iverson promised formal announcements of the Java Rhapsody > > effort in the near future. ) --- Paul Summermatter LGS Systems, Inc. paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) From joel at yinu.co.jp Tue Apr 8 00:37:24 1997 From: joel at yinu.co.jp (Joel Floyd) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody OpenStep Documentation Message-ID: I found this through another web-site, new documentation on Rhapsody I do not know exactly what it contains because I am in the middle of downloading it now; but, it seems to contain the App.kit, Foundation classes, and various other documentation; It could be that it is just an extension of the NeXT web site, or it could be something new. Joel From stark at easynet.fr Mon Apr 7 12:41:00 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody will feature _Java_ APIs References: <9704071950.AA14180@cube> Message-ID: <9704071941.AA00419@easynet.fr> (Sorry if this is off-topic) Hi, I double checked the date and it was not 01 april 97, so this is probably marketing hype :-) Note that Netscape already did that kind of things (IFC: ) Cheers, -- fred You wrote: > >From < > > Apple's Java Rhapsody > > (04/04/97; 3:30 p.m. EST) > > By Deborah Gage, _Computer Reseller News_ > > > > SAN FRANCISCO -- Apple Computer is advising Apple developers > > to plan to write applications in Java. > > > > Apple officials said the company plans to "Javatize" all > > OpenStep _APIs)_. Apple is aiming to have the Java APIs set > > for the developer release of Rhapsody slated for this summer. > > > > "Rhapsody developers will never have to learn Objective C. > > The only reason NeXT did it was because Java was not around, > > but they didn't make that last jump. OpenStep will have a > > giant collection of Java libraries, and if those don't meet > > your needs you can call the extra OpenStep libraries," said > > Apple Product Manager Will Iverson. Iverson said Java also > > solves the security problems that plague Microsoft's ActiveX > > and would have plagued OpenDoc had Apple kept it. Apple is > > also ruminating on a cross-platform strategy once Rhapsody is > > ported to the PowerPC. > > > > Iverson promised formal announcements of the Java Rhapsody > > effort in the near future. ) From mpinkert at cc.gatech.edu Tue Apr 8 06:55:54 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:20 2005 Subject: file system / list-charter Message-ID: <199704081357.JAA05157@lennon.cc.gatech.edu> Garance A Drosehn wrote on 4/7/97 5:29 PM >Note that this does not include topics which "effect" developers, >like the price of Rhapsody or the makeup of the file system. It >is only supposed to cover "Writing Code". While the file system >question might effect whether *you* (some specific person) decide >to write any code at all, your decision is not something I'm going >to use when I am in the process of writing code. At no time will >I be in the middle of some programming assignment and say "Gee, I >wonder what Jim thinks about NeXTSTEP file systems? Boy, I'll >need to know his opinion to get this widget-window working!". A large percentage of us on this list have no access to NextStep/OpenStep in our daily lives so this list is perfect for asking questions to those who do about the current internals (such as the file system, PB/IB, or the database). How would you like it if you were told that your future would rest in writing for a platform to which you had no access, and would have no access for probably close to a year? You'd be seriously frustrated whenever you asked a question and someone replied, "I don't see how that helps _me_ write my code so I don't think its relevant to this list." Unless we ask the people who know, how else are we going to get a feel for what our future holds? -- 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 kazuo-t at zoom.or.jp Tue Apr 8 08:23:23 1997 From: kazuo-t at zoom.or.jp (Kazuo Tsubaki) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody will feature _Java_ APIs References: <9704071950.AA14180@cube> Message-ID: <9704081523.AA00316@venus.shonan.zoom.or.jp> Hi forks, > I'm confused about one key aspect of the announcement > below. As I understand it, Java currently supports extensibility > only through sublassing. Extension of classes through categories, > as we have them in Objective-C, is not available. Given the fact > that a tremendous amount of the OpenStep APIs were written using > categories, how is this not going to present a large problem? Let > me say that I feel quite strongly that it will be wonderful if all > of the OpenStep APIs are written in Java, but I'm still hung up on > this fundamental problem of Java lacking extensibility through > categories. How do you get around this? How about @selector and a behavior when sending message to nil object? --- Kazuo Tsubaki mailto:kazuo-t@st.rim.or.jp (MIME, NeXTMail acceptable) http://www.st.rim.or.jp/~kazuo-t 679 Kasamacho, Sakae-ku, Yokohama 247 Japan Tel:045-890-1890 Fax:045-890-1890 From bakke at ad.enet.dec.com Tue Apr 8 07:37:36 1997 From: bakke at ad.enet.dec.com (A billion here, a billion there... pretty soon you're talking about REAL money.) Date: Thu Nov 3 14:40:20 2005 Subject: file system Message-ID: <9704081437.AA06398@easynet.crl.dec.com> > Regardless, in the rest of the industry the Macintosh filesystem is > generally considered to be a complete and utter failure outside of the > user perspective... it is difficult to move things around, difficult to > back up, difficult to create archives, and generally difficult to > inter-operate with from other filesystems. There is no doubt that the current Mac file system needs an overhaul, but not for the reasons you mention, IMHO. It seems that the debate of file extensions will never end. Speed and efficiency are important for any file system. However, after that, usability becomes the most important. How is the Mac file system considered a complete and utter failure? (ignoring opinions of MacOS market share) The Mac *does* have the reputation of the most user-friendly computer. The file system is one of the reasons for that. A UNIX file system as it stands would not fit the bill without alterations. I totally welcome improvement over the current Mac system, but going with the current Next/UNIX file system is not an improvement in usability. It is better technically performance-wise, but it's still UNIX. -SB From SSetzer at novell.com Tue Apr 8 08:53:48 1997 From: SSetzer at novell.com (Stephen-c Setzer) Date: Thu Nov 3 14:40:20 2005 Subject: Request for new list Message-ID: If I'm the only one requesting, go ahead and ignore this, but I think it might be nice to have a broader topic mailing list for Rhapsody in addition to this one. We're in the midst of creating a new community here--not MacFolk, not NeXTFolk, but RhapsodyKindred. A broader-chartered list would give us a chance to interact on a friendly basis while keeping rhapsody-dev lean. One of the things I like about this list is that it's less like Usenet and more like BIX--filled with technically knowledgeable people who understand what they're talking about and respect each other as professionals. The comp.sys.* newsgroups, while theoretically moderated, in practice often generate more heat than light. Here, even the off-topic threads have been generally useful and informed--a bit warm at times, but I don't think anyone's been abused in the week or so I've been on the list. From SSetzer at novell.com Tue Apr 8 12:14:14 1997 From: SSetzer at novell.com (Stephen-c Setzer) Date: Thu Nov 3 14:40:20 2005 Subject: Pricing must change Message-ID: Okay, it's been said before elsewhere, but I really think Apple needs to completely destroy and redo NeXT's pricing structure or developers will not develop for Rhapsody because they won't be able to afford the tools. Compare: OPENSTEP Enterprise for WinNT $4999.00 lets me develop on one station and deploy on 3 others CodeWarrior Gold 11 357.92 lets me develop on one station; unlimited deployment I understand that there will always be a runtime cost for NeXT because of technology licensed from others. Fine. I also understand that the NeXT tools, Objective-C language, and so on are very good and will make programmers more productive. Fine. More than 10 times productive? You've gotta be kidding. Even if it's true, I don't think most development managers would buy off on it. They'll just say, "Buy CodeWarrior for every programmer and give one guy a copy of Latitude." Or even, "Buy CodeWarrior and deploy on Blue Box." Get the initial cost of the COMPLETE toolset under $800, and get the runtime under $75 (fixed fee, none of this screw-the-little-guy pricing), or Jobs' claims about garage programmers will go up in multi-colored smoke. From gad at eclipse.its.rpi.edu Tue Apr 8 12:42:59 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:20 2005 Subject: file system / list-charter References: <199704081357.JAA05157@lennon.cc.gatech.edu> Message-ID: <9704081943.AA09137@eclipse.its.rpi.edu> Mike Pinkerton writes: > A large percentage of us on this list have no access to > NextStep/OpenStep in our daily lives so this list is perfect for > asking questions to those who do about the current internals > (such as the file system, PB/IB, or the database). This list is *not* perfect for advocacy issues, such as "Apple had better write the Rhapsody file system exactly as I like it, or I'm going to go away in a huff!". That is not a question at all, it is a declaration, and one that does not really do anyone on this list any good. > How would you like it if you were told that your future would > rest in writing for a platform to which you had no access, and > would have no access for probably close to a year? You'd be > seriously frustrated whenever you asked a question and someone > replied, "I don't see how that helps _me_ write my code so I > don't think its relevant to this list." I don't understand why people have such trouble with the concept of a mailing list having a very specific purpose. Several times Omnigroup has offered to start a *second* mailing list, one which *would* be perfect for issues which make no sense for this *development* list. No one wants to pick up on that. Instead, people want to bitch and moan about how they have some "right" to discuss any old topic that comes to mind, even if those topics are directly and specifically *not* related to this mailing list. I hereby suggest that Omnigroup create the rhapsody-talk list, and subscribe us all to it. Then maybe we can have everyone talk about the tangents on the "talk" list, and leave the "development" list for questions on writing actual code. Then, people who don't have time for the "talk" list can unsubscribe, and everyone might just end up happy. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From steffi at DGS.dgsys.com Tue Apr 8 12:50:18 1997 From: steffi at DGS.dgsys.com (Robert Nicholson) Date: Thu Nov 3 14:40:20 2005 Subject: How ellison can help Apple Message-ID: Assuming that Apple wants a piece of the corporate desktop why don't they have Ellison port Oracle Workgroup Server to run on Rhapsody. Didn't the availability of Sybase limited Servers make development with DBKIT/EOF less costly for the average developer? From steffi2 at DGS.dgsys.com Tue Apr 8 16:56:50 1997 From: steffi2 at DGS.dgsys.com (Robert Nicholson) Date: Thu Nov 3 14:40:20 2005 Subject: How ellison can help Apple In-Reply-To: Message-ID: I should have added that they should ship it free with Rhapsody. On Tue, 8 Apr 1997, Robert Nicholson wrote: > Assuming that Apple wants a piece of the corporate desktop why don't they > have Ellison port Oracle Workgroup Server to run on Rhapsody. Didn't the > availability of Sybase limited Servers make development with DBKIT/EOF > less costly for the average developer? > > > From thompson at filoli.com Tue Apr 8 17:05:55 1997 From: thompson at filoli.com (Peter Thompson) Date: Thu Nov 3 14:40:20 2005 Subject: Request for new list In-Reply-To: References: Message-ID: <199704090005.RAA22354@sunspot.filoli.com> > If I'm the only one requesting, go ahead and ignore this, but I think > it might be nice to have a broader topic mailing list for Rhapsody in > addition to this one. We're in the midst of creating a new community > here--not MacFolk, not NeXTFolk, but RhapsodyKindred. A > broader-chartered list would give us a chance to interact on a > friendly basis while keeping rhapsody-dev lean. While the topics have been quite interesting, I agree that another list would be good for broader issues. ************************************************************************** Peter Thompson ---- thompson@filoli.com ---- Filoli Information Systems. ************************************************************************** From kjray at ix.netcom.com Tue Apr 8 17:02:43 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects Message-ID: <199704090006.TAA02379@dfw-ix12.ix.netcom.com> Has anyone on this list used Distributed Objects? Is it good for IPC over a local network (I would assume it's INTENDED for that.) Is it good for IPC on the same machine? Can D.O. be used to talk to "client" or "server" WinNT/Win95/MacOS apps that were not compiled with OpenStep APIs? // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From Scott_Harrison at next.com Tue Apr 8 17:17:41 1997 From: Scott_Harrison at next.com (Scott Harrison) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects References: <199704090006.TAA02379@dfw-ix12.ix.netcom.com> Message-ID: <9704090018.AA09599@toto.NeXT.COM> >Has anyone on this list used Distributed Objects? > Yes. >Is it good for IPC over a local network (I would assume it's INTENDED for >that.) > Yes. It is intended for communications between any processes. >Is it good for IPC on the same machine? > Yes. It does not matter whether the processes are on the same machine, the local subnet, or the Internet. >Can D.O. be used to talk to "client" or "server" WinNT/Win95/MacOS apps >that were not compiled with OpenStep APIs? No. Well, only if someone were to do a LOT of work. DO can really only be used by applications that are using the OPENSTEP Foundation. One is able to compile OPENSTEP applications for WinNT and Win95 though. --Scott From don at misckit.com Tue Apr 8 17:19:44 1997 From: don at misckit.com (Donald A. Yacktman) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <199704090006.TAA02379@dfw-ix12.ix.netcom.com> References: <199704090006.TAA02379@dfw-ix12.ix.netcom.com> Message-ID: <9704090019.AA29049@misckit.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1415 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970408/33d5daaf/attachment.bin From ernest at alumni.caltech.edu Tue Apr 8 17:23:50 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects Message-ID: <199704090023.RAA26285@alumnae.caltech.edu> At last, a technical question! Yes, DO is great for single machine, local net, and internet applications. Using PDO, it can run on most UNIX servers, as well as NT (not AIX, for some reason, last I heard). I believe DO completely replaces the older Speak/Listener interface which was used for things like services and Mail APIs, though I don't know how many apps were rewritten. For example, how does OmniWeb message Mail.app for "mailto:" URLs? NeXT had a product called D'OLE which gatewayed PDO and OLE calls. For aa while it was the only way you could get two standard DOLE apps to talk to each other over a network (is that still the case?). I wrote an artcile on it for DrDobbs which NeXT has on their website. the URL is on my Writings page (with some other cute NeXT stuff) http://www.alumni.caltech.edu/~ernest/Writings.htmld/index.html DO would probably form a basis for any new scripting system developed, I imagine. To do that properly you need something like the old NXJournaler which 'eavesdrops' on system events, and has no current Rhapsody equivalent. -- Ernie P. From toon Tue Apr 8 18:08:35 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects Message-ID: <9704090108.AA02754@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1687 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970408/07d9d4e2/attachment.bin From james at advancedsw.com Tue Apr 8 18:33:55 1997 From: james at advancedsw.com (James Powell) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <199704090023.RAA26285@alumnae.caltech.edu> (ernest@alumni.caltech.edu) Message-ID: <199704090133.TAA12698@advancedsw.com> ernest@alumni.caltech.edu writes: >I believe DO completely replaces the older Speak/Listener interface which >was used for things like services and Mail APIs, though I don't know how >many apps were rewritten. A few questions about the implementation of DO as IPC, from one with only a little knowledge of NeXT (and yes, it is a dangerous thing, so watch out :-). Does DO utilize Mach's DO abilities? If not, no biggie, though it would be neat. I always liked that about Mach. Rhapsody will retain Mach, yes? Ok, on to question number two... er, two point five, When DO is utilized for IPC, does it route messages above the network level, or do they travel through the network's loopback interface? I'd imagine it could work either way, but for IPC you'd (arguably?) want them routed without passing through the loopback. Which brings us by a commodius vicus of recirculation back to... The "NeXT is not Unix" posts aside, , NeXT does use what I think everyone would agree is a very BSD-flavored version of Unix. I, for one, celebrate that, as I'm nearly as fond of Unix as I am of the Macintosh. Primarily as a porting issue, though, I wonder where NeXT is at regarding the System V IPC utilities (messages, shared memory, and semaphores)? Thanks in advance, -James- ------------------------------------------------------------------------------ James Powell - Software Engineer/Reverse Engineering - james@advancedsw.com ------------------------------------------------------------------------------ From james at advancedsw.com Tue Apr 8 18:46:02 1997 From: james at advancedsw.com (James Powell) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <9704090108.AA02754@omnigroup.com> (message from Greg Titus on Tue, 8 Apr 97 18:10:45 -0700) Message-ID: <199704090146.TAA12704@advancedsw.com> Oops, Greg answered my first 2 IPC questions neatly, just as I was composing them. Thank you. All that remains, I think, is just the question about the availability of (or workaround for code using?) the Sys V IPC facilities. I do a lot of porting of Unix code, and this has been a sticking point in a couple of cases. Someone was developing a library which supported them (ingres folks? postgres?), but hadn't released at that point (about three years ago). I'll indubitably run into it again, and a ready answer would be great to have. Thanks again, -James- ------------------------------------------------------------------------------ James Powell - Software Engineer/Reverse Engineering - james@advancedsw.com ------------------------------------------------------------------------------ From sanguish at digifix.com Tue Apr 8 21:00:01 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:20 2005 Subject: Finding reliable OpenStep information - sources other than this mailing-list In-Reply-To: <199704081357.JAA05157@lennon.cc.gatech.edu> References: <199704081357.JAA05157@lennon.cc.gatech.edu> Message-ID: <199704090400.AAA11349@digifix.com> First let me say that I do sympathize with the developers who feel they are having things jerked out from under them. Garance and others have asked for a talk list, and thats one solution, although if there are already 350+ people on this list, its gonna be a devil on bandwidth, and will quickly degrade to what semper-fi was. The comp.sys.next.(programmer|misc) groups are not high-traffic groups, and provided you don't cross-post into the groups like (mac|next).advocacy you're likely to get the same knowledgeable people as here answering your questions. Having looked in on the comp.sys.mac.programmer groups recently, I understand just how bad things are in those newsgroups... comp.sys.next.* groups (outside advocacy) aren't like this. Keeping this list focused on true development issues, and not advocacy is a VERY good idea. Many of the NeXT developers fled semper.fi because of what it became. As you've seen, most of us are willing to help out by providing example code, answer questions, provide screen-shots etc. I've never found a group of people on the net that is as much a community as the good folks here. Scott From pmarc at cmg.fcnbd.com Tue Apr 8 21:10:34 1997 From: pmarc at cmg.fcnbd.com (Paul M. Cardon) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <199704090023.RAA26285@alumnae.caltech.edu> References: <199704090023.RAA26285@alumnae.caltech.edu> Message-ID: <199704090410.XAA00359@abernathy.cmg.fcnbd.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1716 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970408/e6b57b99/attachment.bin From lukeh at xedoc.com.au Wed Apr 9 13:12:39 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <199704090410.XAA00359@abernathy.cmg.fcnbd.com>; from "Paul M. Cardon" at Apr 8, 97 9:13 pm Message-ID: <199704090512.PAA20610@alpha.xedoc.com.au> > As Don mentioned, firewalls often become an issue. Why? I'm glad you > asked. Just like basic Sun RPC (and protocols like NFS that are built on > top of it), DO has virtually no security. It is almost trivial to spoof. > If you have firewall to firewall encryption over the Internet then you are > ok only if you can trust the other security domain that is accessing your As far as I was aware, PDO 4.0 has support for replacing the transport. I *think* there's the source for a sample TCP transport included, in which case it may not be that difficult to add support for SSL encryption or Kerberos authentication, to name but a few possibilities. -- luke From kc Wed Apr 9 00:11:23 1997 From: kc (Ken Case) Date: Thu Nov 3 14:40:20 2005 Subject: New Rhapsody mailing list: rhapsody-talk@omnigroup.com Message-ID: <9704090711.AA06025@omnigroup.com> I've created the rhapsody-talk@omnigroup.com mailing list, where general discussions of Apple's Rhapsody operating system are welcome. Those interested can find more information about the list at: http://www.omnigroup.com/MailArchive/rhapsody-talk/ Or you can just subscribe directly by sending email to listproc@omnigroup.com saying: subscribe rhapsody-talk Your Name I'm hoping that the signal to noise ratio on this list will remain high, but the definition of what is "signal" on this list is much more broad than it is on the rhapsody-dev mailing list. Enjoy! Ken From toon Wed Apr 9 00:59:04 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:20 2005 Subject: distributed objects In-Reply-To: <199704090410.XAA00359@abernathy.cmg.fcnbd.com> References: <199704090410.XAA00359@abernathy.cmg.fcnbd.com> Message-ID: <9704090758.AA06696@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 4122 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970409/7a6bac09/attachment.bin From tom at icgned.nl Wed Apr 9 02:00:52 1997 From: tom at icgned.nl (Tom Hageman) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody Developers Archive - Current: Re: distributed objects Message-ID: <9704090900.AA18662@ icgned.icgned.nl > On Tue, 8 Apr 1997 19:46:02 -0600 James Powell (james@advancedsw.com) wrote: > Oops, Greg answered my first 2 IPC questions neatly, just as I was > composing them. Thank you. All that remains, I think, is just the > question about the availability of (or workaround for code using?) the > Sys V IPC facilities. I do a lot of porting of Unix code, and this > has been a sticking point in a couple of cases. Someone was > developing a library which supported them (ingres folks? postgres?), > but hadn't released at that point (about three years ago). I'll > indubitably run into it again, and a ready answer would be great to > have. Thanks again, Check out ftp://ftp.nl.net/pub/comp/next/SysVIPC/ Currently this emulates shared memory and semaphores. No messages yet. --- __/__/__/__/ Tom Hageman [NeXTmail/Mime OK] __/ __/_/ IC Group (work) __/__/__/ "Any magic sufficiently advanced is indistinguishable __/ _/_/ from a perl script" -- Larry Wall, mangled From phip at nice.ch Wed Apr 9 03:50:48 1997 From: phip at nice.ch (Philippe C.D. Robert) Date: Thu Nov 3 14:40:20 2005 Subject: Rhapsody OpenStep Documentation In-Reply-To: References: Message-ID: <9704091050.AA00306@nice.ch> You wrote: > I found this through another web-site, new documentation on Rhapsody > > < mentation/> On the NiCE page (Swiss NeXT User Group) I published some links about NeXT/Rhapsody Development, mainly the original NeXT pages... but have a look! http://www.nice.ch sweet dreams Philippe --- Philippe C.D. Robert, CS-student @ Uni Bern/Switzerland Member of NiCE : Swiss NeXT User Group - NeXTmail & MIME are welcome Programmer @ STONE soft GmbH Bern/Switzerland http://www.stonesoft.ch/h_phil.html From jk at EXnExt.com Wed Apr 9 04:48:35 1997 From: jk at EXnExt.com (John S. Karabaic) Date: Thu Nov 3 14:40:20 2005 Subject: How ellison can help Apple References: Message-ID: <199704091148.HAA04633@exnext.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 519 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970409/6362b9b0/attachment.bin From indy at gryphon.com Wed Apr 9 04:48:50 1997 From: indy at gryphon.com (Steve Weintz) Date: Thu Nov 3 14:40:20 2005 Subject: Introduction - Steve Weintz Message-ID: <9704091148.AA00344@gryphon.is.com> Yo! I'm cross-posting this message once; I'll sort out further missives based on topic. Good to see so many familiar names! I've been a NeXT user since early 1993 (around Black Tuesday, in fact!) At the time I was in grad school at the University of Illinois, and the only UNIX machines the unwashed could get an account on were the black boxes. As happend, I became interested in 3D graphics at the time and was blown away by the magic of Workspace Manager and the 3DKit. I dropped out of grad school, bought a Turbo NeXTdimension and holed up in my apartment for several months of dire poverty learning RenderMan. Four years later, after stints as a freelance artist and an art director and webhead for one of the first Web magazines, I'm a successful graphic designer at a Minnesota NeXTSTEP/OpenStep software firm and regularly participate in graphics and RenderMan discussions. Because i was able to teach myself UNIX, RenderMan, and digital illustration within NEXTSTEP's friendly environment, I found myself able to work at the Beckman Institute Visualization Lab (one floor down from NCSA!) and get interviews at Disney, Warner Bros., and other studios. I've long claimed that NEXTSTEP is the superior content-creation platform, and if it had MacOS's depth of software it would be heaven. Lo, my prayers have been answered! I'm ablaze with ideas about what I could do with Photoshop if it had the power of TIFFany 2, a Premiere within a multitasking environment, a solidThinking with a market of millions. I'm hoping to expand my digital studio to produce short 3D animated films, and am eager to build a Rhapsody/NeXTSTEP production environment. Do these lists support MIME? --- Steve Weintz * indy@is.com * Graphic Designer, Integrity Solutions, Inc. ------------------------------------------------------------------------------ When confronted with vastly intelligent, aggressive politics, do something totally irrational and let the enemy think himself to death. -- P. Chanur From adul at cmg.FCNBD.COM Wed Apr 9 07:15:20 1997 From: adul at cmg.FCNBD.COM (Albert Dul) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704081646.AA26237@omnigroup.com> References: <9704081646.AA26237@omnigroup.com> Message-ID: <199704091415.JAA10546@falstaff.cmg.FCNBD.COM> > > >From > > > Apple Product Manager Will Iverson said: > > > "Rhapsody developers will never have to learn Objective C. > > > The only reason NeXT did it was because Java was not around, > > I'd much rather be told I don't need to learn Java to program for > Rhapsody. Well, here's a "me too". What's wrong with Obj-C? Please at least allow us to continue to use the existing stuff as well. I suspect this is the case, and something got lost in the translation, as is often the case. Also as in "Corporate customers will get really pissed." Please confirm? Thanks. Al Dul --- Wk: adul@cmg.fcnbd.com Hm: aldul@concentric.net "This might not look as obvious to the 40 or 50 people who've never seen it before." From filip at filtronix.eunet.be Wed Apr 9 08:39:58 1997 From: filip at filtronix.eunet.be (Filip Lingier) Date: Thu Nov 3 14:40:21 2005 Subject: frame-grabbing Message-ID: Hi, How will frame-grabbing be supported on Rhapsody and which are the boards that are worth using? Filip -- ---------------------------- FILTRONIX ----------------------------- |-- --- \ / Software Development - OpenStep|Windows-NT/95 |- | X Web Design & Development - HTML|CGI|JAVA|WebObjects | | / \ From mtarbell at akina.jpl.nasa.gov Wed Apr 9 09:56:37 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: <199704090512.PAA20610@alpha.xedoc.com.au> References: <199704090512.PAA20610@alpha.xedoc.com.au> Message-ID: <9704091656.AA01206@akina.jpl.nasa.gov> Distributed Objects are a wonderful thing. Or at least, they _will_ be, as soon as they become mature. Let me explain... Here at the Jet Propulsion Laboratory, we've come up with a new design for automating the network prediction operations for the array of large satellite dish antennas of the Deep Space Network. Distributed Objects play a key roll in this. Architecturally, DO's allow for a very nice design. And, it works well, for about 2 minutes. Then it all comes tumbling down. We had to scrap the design with DO's, and replace it with a more brute-force point-to-point tcp/ip implementation. Although I would have designed DO's a little differently (i.e., more object-oriented), the main problems with DO's in their current incarnation (OS4.1) are implementation bugs. Here are the current DO implementation flaws preventing us from using DO's: a. Signal and thread models don't interoperate Because NSTimer can't issue its timer signal to the main run loop from another thread, we resorted to using Unix timer signals to a sighandler. Works fine, but eventually, some thread's autorelease pool becomes corrupted on thread launch. Always. b. NSConnections (for DO's) are thread-specific Don't know why it should be implemented this way, but it is. We've been able to work around it, but it's ugly. I hope this restriction goes away with Rhapsody. c. NSThreads using DO's leak thread resources Every new thread that does DO's actually uses 2 threads. And, there is a pipe between them. That's okay, but what happens with the leak is that the secondary thread (which is created behind the scenes) never gets messaged to go away when the first thread exits. Resources gets used up _very_ quickly; we were only able to process about a dozen events before we ran into thread, pipe, and file resource limitations. If there are any known work-arounds for these, it's still not too late for us to switch back to the original design. Hopefully, someone in the know can lead me to the light... Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From cliff at pdh.com Wed Apr 9 10:37:36 1997 From: cliff at pdh.com (Cliff Tuel) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <3.0.1.32.19970409103736.0090c8d0@snowbird> NeXT is merely slapping Java front-ends onto a slew of methods. They're using the Objective-C/Java bridge that was written for WebObjects 3.x. My opinion is that the bridge is a major kludge -- you have to worry about "jobs" files (Steve must love those) which map selectors between the two languages. It also adds overhead, as the mapping is done using the Objective-C runtime system. (insert Dennis Miller Disclaimer here) -- Cliff Tuel -- NeXTSTEP/OPENSTEP Wrangler -- cliff@pdh.com -- cliff@ablecom.net PDH Inc / 2635 North First Street Suite 224 / San Jose California / 95134-2032 From rcfa at cubiculum.com Wed Apr 9 13:34:38 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: RenderMan petition Message-ID: <9704092034.AA03022@ kannix.cubiculum.com > I think the following is of interest to all here. Make your voices heard. If someone else posted this here already, I apologize for the waste of bandwidth. Ronald Begin forwarded message: From: Thomas Engel Date: Wed, 9 Apr 97 21:10:24 +0200 To: g3dkit@immd9.informatik.uni-erlangen.de Subject: RenderMan petition Hi. For those who would like to see RenderMan bundled with (or at least offered for) Apple's new Rhapsody OS please sign the official petition which has been set up at: http://www.webnation.com/petition/index.html Aloha Tomi From james at advancedsw.com Wed Apr 9 13:34:10 1997 From: james at advancedsw.com (James Powell) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody Developers Archive - Current: Re: distributed objects Message-ID: <199704092034.OAA16555@advancedsw.com> >> On Tue, 8 Apr 1997 19:46:02 -0600 James Powell (james@advancedsw.com) >> wrote: >> Someone was developing a library which supported [SysV IPC] (ingres >> folks? postgres?), but hadn't released at that point (about three >> years ago). In response to which, Tom Hageman writes: >Check out ftp://ftp.nl.net/pub/comp/next/SysVIPC/ > >Currently this emulates shared memory and semaphores. No messages yet. Right on :) This looks like a great package. Message queues, I can work around with alternate IPC mechanisms, and otherwise their compatibility level looks quite good, so this oughta fit the bill nicely. Thanks muchly, -James- ------------------------------------------------------------------------------ James Powell - Software Engineer/Reverse Engineering - james@advancedsw.com ------------------------------------------------------------------------------ From jocke at rat.se Wed Apr 9 13:38:08 1997 From: jocke at rat.se (Joakim Johansson) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects Message-ID: <9704092038.AA00335@isdn-jocke.rat.se> Greg Titus wrote: > This is one difficulty with DO. DO uses a single socket to > communicate with a mach name service process on each machine, so if > you open up your firewall to allow a DO connection, you are opening > it for _all_ possible connections to DO servers running on that > machine. This hasn't been a problem in any of the projects I've been > involved in so far (we've either been running all within a company > WAN, or put the DO server(s) involved outside the firewall). I > imagine one way to get around this would be to put a DO server on > your firewall machine that accepts incoming connection requests, > authenticates them, and passes them off to the real servers to > contact the client. We solved this in a little different manner (the end result is very similar though...) We just vend *one* object publically which maintains a list of available server resources - which is given to authenticated clients when they request it. The resource data the client receives includes things like a proxy to the server, server name, type, etc, etc. (The client may then connect to one of those other servers, using whatever protocol is suitable for a server of that type) The first thing our servers does when they have initialized themselves, is to register themselves to that book-keeping server object. (sort of an object broker...) Joakim -- Joakim Johansson Software Engineer, Research & Trade jocke@rat.se http://www.rat.se/ From ernest at alumni.caltech.edu Wed Apr 9 13:50:01 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <199704092050.NAA12499@alumnae.caltech.edu> Sorry, I don't have the original Web page references, but this is all out there. 1) OpenStep as in Objective-C will continue to exist as the base API 2) Java bindings via NeXT's bridge will allow people to access most of OpenStep from Java. Yes, you don't get fun things like categories, but for the hordes of programmers who love Java and fear learning new languages (e.g. the 1 hour it takes to learn ObjC :-), this is important. And hey, those of us who know ObjC have a competitive advantage. 3) Other languages can call ObjC classes Objective-C++ is really a hybrid, but for marketing purposes it means C++ programs and programmers can call ObjC from within C++. Object Pascal is suppose dto be supported. And, someone has mentioend Perl and TCL can call ObjC already. Are there any other important languages tos upport? The big question is why NeXT chose to use a bridge between Java and ObjC rather than direct calling (like you can between Fortran and C). I can think of several reasons: a) It allos substitution of the appropriate objects (java.string vs. NSstring) b) it allows renaming (to conform with Java APIs?) c) it allows subclassing of the proxy classes (in both directions) - would this be possible otherwise? I doubt it, but am not sure d) It looks better Can you imagine calling myJavaPoint.addX:Y:(foo,bar) Those ':' would make a C programmer - or a Java compiler - barf. e) it is more general One can do a full API translation, which may become necessary, or just make it easy to port the AWT. Note that you can add new methods to the class, as well as hide old one, when doing hte Java proxy. I don't think there are many functional disadvantages, as you can just use the 'naive' mapping where appropriate. The biggest question is performance, though I can't imagine it is much worse than calling interpreted Java methods directly. It may get you when you move to full compiled server- side code. My biggest concern is whether the "JavaStep" bindings for OpenStep will mesh well with the JFC initiative at Sun/Lighthouse. For end-users it would be a mess, but I'm not sure how the political/business issues look from Sun and Apple's perspective. Here's hoping they do the Right Thing and make JFC == JavaStep. -- Ernie P. From rcfa at cubiculum.com Wed Apr 9 13:54:48 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody Developers Archive - Current: Re: distributed objects In-Reply-To: <199704092034.OAA16555@advancedsw.com> References: <199704092034.OAA16555@advancedsw.com> Message-ID: <9704092054.AA03089@ kannix.cubiculum.com > >> On Tue, 8 Apr 1997 19:46:02 -0600 James Powell (james@advancedsw.com) >> wrote: >> Someone was developing a library which supported [SysV IPC] (ingres >> folks? postgres?), but hadn't released at that point (about three >> years ago). In response to which, Tom Hageman writes: >Check out ftp://ftp.nl.net/pub/comp/next/SysVIPC/ > >Currently this emulates shared memory and semaphores. No messages yet. Has anyone ported PostgreSQL 6.x to OpenStep? Earlier versions required SysV IPC support, and have been ported, probably with the package mentioned above. The latest breed of EOF adaptors for PostgreSQL work however only with version 6.x Any hints welcome... Ronald PS: is it me, or does there seem to be quite a bit of overlap between the next-prog, and rhapsody-dev mailing lists, in terms of the topics that are apropriate to post on each? Is there an offical "policy" as to what should go where? With OpenStep being mostly portable, there really does not seem to be much of a point to have these two, unless the next-prog group would be reserved for backward compatibility issues that deal with NS3.3 and earlier... Maybe eventually they should be merged into an OpenStep list, with special topics like EOF, 3D, WebObjects etc. having their own lists (two of which already exist) From kjray at ix.netcom.com Wed Apr 9 19:11:20 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <199704100218.VAA11597@dfw-ix5.ix.netcom.com> (1) I'm sure Objective C will not go away, but Apple is bowing to the wishes of thousands of developers who protest learning a "platform-specific" language that, in their opinion, will not look good on their resumes. The closest thing to a valid protest I've heard was from a Claris engineer who says that they've wrapped WinTel and MacOS APIs in C++ frameworks that present the same platform independant API to the rest of their code, but doesn't think they could successfully wrap the OpenStep APIs in a C++ framework to present the same API. (*I* think it could be done.) (2) Someone asked if this list supports MIME. My email package supports MIME only for enclosures, I can't view NextMail or NetscapeMail in a WYSIWYG manner. (3) My resume is available from my home page listed in my signature. If you know anyone in the Bay Area that's looking to hire ex-Appleites with some NextStep experience, please put them in contact with me, or vice versa. // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From kc Wed Apr 9 20:05:24 1997 From: kc (Ken Case) Date: Thu Nov 3 14:40:21 2005 Subject: Overlap between next-prog and rhapsody-dev Message-ID: <9704100305.AA21981@omnigroup.com> > PS: is it me, or does there seem to be quite a bit of overlap > between the next-prog, and rhapsody-dev mailing lists, in terms of > the topics that are apropriate to post on each? There is some overlap to be sure, since Rhapsody and NEXTSTEP have some common technologies. However, Rhapsody and NEXTSTEP are definitely distinct systems, and as a result some people will be interested in rhapsody-dev who aren't interested in next-prog. (And some people may be interested in next-prog who aren't interested in rhapsody-dev, because they don't have any plans to go forward to Rhapsody.) > Is there an offical "policy" as to what should go where? When a topic is appropriate for one and not the other, I think the policy is clear. For example, it wouldn't make sense to talk about Apple-specific technologies such as QuickTime on next-prog, since they're part of Rhapsody, not NEXTSTEP. Neither would it make sense to ask about how to get some Speaker/Listener code to work on rhapsody-dev, since we don't expect Speaker/Listener to be in Rhapsody. When a topic applies to both lists equally, I guess I'd try to consider the target audience. Most subscribers to next-prog are probably current NEXTSTEP programmers. On rhapsody-dev you'll find many current NEXTSTEP programmers, but you'll also find many Macintosh programmers who have never used a NeXT (and probably never will). > With OpenStep being mostly portable, there really does not seem to > be much of a point to have these two, unless the next-prog group > would be reserved for backward compatibility issues that deal with > NS3.3 and earlier... There is more to Rhapsody than OpenStep, but OpenStep is certainly common ground between the two lists. > Maybe eventually they should be merged into an OpenStep list, with > special topics like EOF, 3D, WebObjects etc. having their own lists > (two of which already exist) I expect that there will be less to distinguish next-prog from rhapsody-dev once Rhapsody is actually available, and at some point we'll want to reevaluate whether having two separate lists is still worthwhile. Ken From toon Wed Apr 9 20:29:03 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: <9704092038.AA00335@isdn-jocke.rat.se> References: <9704092038.AA00335@isdn-jocke.rat.se> Message-ID: <9704100328.AA23435@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2634 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970409/1b9df2e3/attachment.bin From pmarc at cmg.fcnbd.com Wed Apr 9 21:06:48 1997 From: pmarc at cmg.fcnbd.com (Paul M. Cardon) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: <9704100328.AA23435@omnigroup.com> References: <9704100328.AA23435@omnigroup.com> Message-ID: <199704100406.XAA00312@abernathy.cmg.fcnbd.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3140 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970409/9aadd93f/attachment.bin From kurt at frsvnsvn.vip.best.com Wed Apr 9 21:48:49 1997 From: kurt at frsvnsvn.vip.best.com (Kurt Werle) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects References: <9704090018.AA09599@toto.NeXT.COM> Message-ID: > ... > Yes. It is intended for communications between any processes. > > >Is it good for IPC on the same machine? > > Yes. It does not matter whether the processes are on the same > machine, the local subnet, or the Internet. As long as nothing goes wrong. DO is a great light-weight messager - best used on one machine. As soon as you go into serving multiple machines and/or use on busy network and/or with busy clients/server, DO is probably not a good idea. In theory, replacing the transport mechanism makes DO as robust as one is willing to put effort into it, but out of the box it can't be expected to be robust or secure. Kurt -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 671 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970409/89243132/attachment.bin From dneumann at next.com Wed Apr 9 21:54:45 1997 From: dneumann at next.com (David L. Neumann) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects References: Message-ID: <334C7295.5E5ED1E8@next.com> Kurt Werle wrote: > > > ... > > Yes. It is intended for communications between any processes. > > > > >Is it good for IPC on the same machine? > > > > Yes. It does not matter whether the processes are on the same > > machine, the local subnet, or the Internet. I think it's important to add that the paradigm used for DO between processes & machines is the exact same one used between threads WITHIN a process or between different threads in different processes. - dave From rcfa at cubiculum.com Wed Apr 9 23:39:16 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: References: Message-ID: <9704100639.AA04460@ kannix.cubiculum.com > >DO is a great light-weight messager - best used on one >machine. As soon as you go into serving multiple machines >and/or use on busy network and/or with busy clients/server, >DO is probably not a good idea. In theory, replacing the >transport mechanism makes DO as robust as one is willing to >put effort into it, but out of the box it can't be expected >to be robust or secure. What do you base this assesment upon? It seems that DO was designed for use on LANs where most client/server apps run. It also seems that a lot of people are using DO and PDO successfully, hence it would seem quite robust. (Of course it's a different issue if you talk about the demo that implements DO ontop of TCP rather than MACH messaging protocols...) Mach messaging itself has been in use for a long time, and works fine... Ronald From cerveau at club-internet.fr Thu Apr 10 02:50:02 1997 From: cerveau at club-internet.fr (Laurent Cerveau) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: >(1) I'm sure Objective C will not go away, but Apple is bowing to the >wishes of thousands of developers who protest learning a >"platform-specific" language that, in their opinion, will not look good >on their resumes. I've never done Java programming and find myself a little bit confused about these Java API's. For me Java is more than a language, because you can write cross-platform softwares with it, and this is associated with the virtual machine. What does it mean to have Java API's then? Does that mean that developping in Java, programmers will loose benefit of the operating system, or that they will be able to access system function via Java calls, and the cross-platform development will be lost then? Of course you will always benefit of the choice of a specific OS (or not benefit...), in the way the virtual machine calls the system. For me Java and C (Obj-C) don't have the same goals, and are both useful; so I will learn the two of them depending on what I want to do. So this API's story is more confusing than helpful for me. It is nice to have a standard for cross-platform and Web development, but I don't see the interest of having an OS only to run Java virtual machine, even if it is well implemented, or maybe having a complete JavaOS, which the virtual machine is not. If someone could help me about making these points more clear, it would be nice. By the way, Obj-C is very fun, and learning it helps a lot about what is really object programming. The book available on Apple and NeXT sites (Object Oriented Programming and the Objective-C language ) is really good.If I remember well, it was indicated as a reference in one of the Sun JDK text! Laurent ---------------------------------------------------------------------------- Laurent Cerveau cerveau@club-internet.fr Laurent.Cerveau@ircam.fr ---------------------------------------------------------------------------- From stevec at magna.com.au Thu Apr 10 06:26:17 1997 From: stevec at magna.com.au (Stephen Coy) Date: Thu Nov 3 14:40:21 2005 Subject: Determining what "features" the OS has? Message-ID: G'Day, The current MacOS supports an API call "Gestalt", which a programmer can use to determine all kinds of information about the current environment in which an application is running. This includes stuff like the OS version, the availability of particular system features (such as balloon help, or the alias manager), or perhaps the version of a particular component, such as the AppleTalk stack. Prior to System 7 (from memory), this stuff was made available in a system function "GetSysEnvirons", which probably better describes what I am on about. Does anyone know how similar functionality will appear in Rhapsody? Presumably NextStep does this somehow? Regards, Steve Coy Resolve Software Pty Ltd 4 Andove St Belrose NSW 2085 Australia ****** This message was sent by CyberDog 2.0 ******** From stevec at magna.com.au Thu Apr 10 06:39:50 1997 From: stevec at magna.com.au (Stephen Coy) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody Message-ID: G'Day, The MacOS has always had reasonably sophisticated support for allowing applications and the system itself to deal with the way that dates, numbers and measurement are seen by the user. This includes functions for converting strings to dates/times and vice versa, in the local format. A component of this is an API for parsing strings into tokens, which we have found useful for parsing in general. Additionally, a Mac knows whether or not measurement should employ metric or imperial units, and where it is located geographically. Do you think we can expect to see this kind of thing in Rhapsody? Are there similar API's in OpenStep? Thanks, Steve Coy Resolve Software Pty Ltd 4 Andove St Belrose NSW 2085 Australia ****** This message was sent by CyberDog 2.0 ******** From kurt at frsvnsvn.vip.best.com Thu Apr 10 09:17:57 1997 From: kurt at frsvnsvn.vip.best.com (Kurt Werle) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: <9704100639.AA04460@ kannix.cubiculum.com > Message-ID: On Thu, 10 Apr 1997, Ronald C.F. Antony wrote: > >DO is a great light-weight messager - best used on one > >machine. As soon as you go into serving multiple machines > >and/or use on busy network and/or with busy clients/server, > >DO is probably not a good idea. In theory, replacing the > >transport mechanism makes DO as robust as one is willing to > >put effort into it, but out of the box it can't be expected > >to be robust or secure. > > What do you base this assesment upon? Experience (both mine and others). > It seems that DO was designed for > use on LANs where most client/server apps run. Yup, I guess that was the idea :-) > It also seems that a lot > of people are using DO and PDO successfully, hence it would seem quite > robust. Funny, I don't know of anyone who uses it that is not also frustrated at it's lack of reliability. > (Of course it's a different issue if you talk about the demo > that implements DO ontop of TCP rather than MACH messaging protocols...) Which I would tend to trust more than DO out of the box. > Mach messaging itself has been in use for a long time, and works fine... Most of DO's reliability problems (in my opinion) stem from nmserver. Replace the transport mechanism, and nmserver drops (90%) out of the picture. Kurt From mtarbell at akina.jpl.nasa.gov Thu Apr 10 09:33:58 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody In-Reply-To: References: Message-ID: <9704101634.AA01658@akina.jpl.nasa.gov> > The MacOS has always had reasonably sophisticated support for allowing > applications and the system itself to deal with the way that dates, numbers > and measurement are seen by the user. I'm hoping also that Rhapsody includes, by default, something akin to OpenStep-J, extending multi-byte character support to all classes. The current situation (wherein one must purchase a different version of the operating system) is a poor solution, as I cannot make apps which require nonexistent libraries on host machines. A universally present input system should also be default. Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From ernest at pundit Thu Apr 10 06:56:15 1997 From: ernest at pundit (Dr. Ernest N. Prabhakar) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: References: Message-ID: <9704101356.AA25443@alumni.caltech.edu> Laurent wrote: > I've never done Java programming and find myself a little bit > confused about these Java API's. > For me Java is more than a language, because you can write > cross-platform softwares with it, and this is associated with the > virtual machine. What does it mean to have Java API's then? Currently, OpenStep applications are written to the "OpenStep API", which is in Objective-C and is cross-platform. All the various UNIX APIs (e.g. BSD 4.3) are also avaialable, but people rarely write to them except for creating/porting unix utilities. Java is a whole mess of things: - a language - a framework (AWT) - a virtual machine (JavaVM) - an OS which runs all the above (JavaOS) What Apple is talking about is putting Java -the language- into OpenStep. Technically speaking, they are defining Java "bindings" for the OpenStep API. This is the same way old math libraries and things like POSIX (UNIX) and CORBA would defined 'bindings' for C, Pascal, Fortran, etc. That way programs could call the routines in their own natural format. This Java binding to OpenStep is often called "JavaStep". This woud also involve integrating the Java runtime into the Objective-C runtime - INSTEAD of running it inside a virtual machine. Of course, Apple has also announced the JavaVM will be available, to securely run Applet code downloaded from web sites. But actual Java applications will be compiled and run natively just like Objective-C programs. Now, once the -language- Java is integrated into Rhapsody, it should be fairly trivial to build the AWT on top of OpenStep. What's more, they'll probably take advantage of the mapping mechanism to make JavaStep resemble the AWT, to make it more familiar to Java programmers. What is more interesting is that Sun (via Lighthouse Design, a former NeXT ISV) and Netscape are integrating Netscape's IFC (which was designed by ex-NeXTer Jayson Adams and resembles OpenStep) into the AWT. The result should be something very similar to JavaStep, i.e. the OpenStepping of Java vs. the Java-izing of OpenStep. Hopefully they'll make them match up rather than confuse us all with two similar but distinct frameworks. The early IFC was handicapped by a lack of reflection, so they couldn't really handle target-action and delegation. This should improve in the new version. The bottom line is that many people are afraid of learning Objective-C the language; they shouldn't be, but they are. Java makes it emotionally easier for people to program for Rhapsody, which is A Good Thing. Java does do a few things better than Objective-C, though there are some things it doesn't do at all. People can use what they want, Apple will support both, and everyone should live happily ever after. -- Ernie P. From mont at echidna.doverpacific.com Thu Apr 10 10:24:02 1997 From: mont at echidna.doverpacific.com (Mont Rothstein) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects Message-ID: <3.0.32.19970410102402.0092aa30@doverpacific.com> I passed your questions on to one of our developers who has been working with DO in a multi-threaded situation. I've included his response below. -Mont Begin forwarded message: >a. Signal and thread models don't interoperate > > Because NSTimer can't issue its timer signal to the main run > loop from another thread, we resorted to using Unix timer > signals to a sighandler. Works fine, but eventually, some > thread's autorelease pool becomes corrupted on thread launch. > Always. You have to fire the NSTimer into your own thread. Then, using DO, you can send the message to another thread. >b. NSConnections (for DO's) are thread-specific > > Don't know why it should be implemented this way, but it is. > We've been able to work around it, but it's ugly. I hope this > restriction goes away with Rhapsody. You have to send the message [myConnection enableMultipleThreads. If you don't, you raise exceptions like "Message from incorrect thread". >c. NSThreads using DO's leak thread resources > > Every new thread that does DO's actually uses 2 threads. And, > there is a pipe between them. That's okay, but what happens > with the leak is that the secondary thread (which is created > behind the scenes) never gets messaged to go away when the > first thread exits. Resources gets used up _very_ quickly; > we were only able to process about a dozen events before we > ran into thread, pipe, and file resource limitations. Personally, using the cthread_count function call, I only noticed that this happened on the very first thread. Ie, the first thread you spawn, causes you program to jump from one to three threads. Subsequent threads only create one additional. Once you've gone multi-threaded, you cannot return to a single thread, because you'll always have two threads running. >If there are any known work-arounds for these, it's still not too late for >us to switch back to the original design. Hopefully, someone in the know can >lead me to the light... You can forward these if you'd like. Alex From gad at eclipse.its.rpi.edu Thu Apr 10 12:18:32 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs References: <199704091415.JAA10546@falstaff.cmg.FCNBD.COM> Message-ID: <9704101918.AA15634@eclipse.its.rpi.edu> > > > >From > > > > > Apple Product Manager Will Iverson said: "Rhapsody developers > > > > will never have to learn Objective C. The only reason NeXT > > > > did it was because Java was not around, > > > > I'd much rather be told I don't need to learn Java to program > > for Rhapsody. > > Well, here's a "me too". What's wrong with Obj-C? Please at least > allow us to continue to use the existing stuff as well. I suspect > this is the case, and something got lost in the translation, as > is often the case. Also as in "Corporate customers will get really > pissed." Please confirm? Thanks. The press release just says that Rhapsody developers will never *have* to learn ObjectiveC. It does not say that people who know ObjectiveC will have to learn Java. This seems like a reasonable strategy to me. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From gad at eclipse.its.rpi.edu Thu Apr 10 12:21:39 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs References: <199704092050.NAA12499@alumnae.caltech.edu> Message-ID: <9704101921.AA15642@eclipse.its.rpi.edu> Ernest N. Prabhakar writes: > 3) Other languages can call ObjC classes > Objective-C++ is really a hybrid, but for marketing purposes it > means C++ programs and programmers can call ObjC from within C++. > Object Pascal is supposed to be supported. > > And, someone has mentioend Perl and TCL can call ObjC already. > > Are there any other important languages to support? For those that are interested, there is also Eiffel available for NeXTSTEP 3.x. I don't know if it's available for 4.x, but if not then I'd think that Rhaposody makes it more likely to happen. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From sanguish at digifix.com Thu Apr 10 13:39:46 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:21 2005 Subject: Determining what "features" the OS has? In-Reply-To: References: Message-ID: <199704102039.QAA05370@digifix.com> "Stephen Coy" wrote: > G'Day, > > The current MacOS supports an API call "Gestalt", which a programmer can > use to determine all kinds of information about the current environment in > which an application is running. This includes stuff like the OS version, > the availability of particular system features (such as balloon help, or > the alias manager), or perhaps the version of a particular component, such > as the AppleTalk stack. Prior to System 7 (from memory), this stuff was > made available in a system function "GetSysEnvirons", which probably better > describes what I am on about. > > Does anyone know how similar functionality will appear in Rhapsody? > Presumably NextStep does this somehow? > OpenStep isn't as piece-meal as System 7, so you've not got as many issues as far as that goes. Since its a totally new environment for Rhapsody users, they'll 'get it all at once'. Alot of this type of fiddling is isolated by the fact that you have frameworks that you use, not raw tool-box calls. If the underlying handling of things changes, then the Framework internals are adjusted, but the API isn't changed. I would think that if something like this was to become necessary (and I hope that it doesn't) the API would be something like this.. dict=[NSInstallEnvironment infoForResourceNamed:name]; where name would be some keyword i.e. NSSystemVersion NSHardwareInformation which would then spit out some dictionary with the information in it.. Version = "Version in some easily machine parsed visual format"; AvailableResources = "EOF2.0.framework,BlahBlah.framework,YackityShmackity.framework"; or something along those lines. From rcfa at cubiculum.com Thu Apr 10 15:01:46 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody, Determining what "features" the OS has? In-Reply-To: References: Message-ID: <9704102201.AA06591@ kannix.cubiculum.com > Hi, you can expect any and all of these in Rhapsody. You may want to check out the OpenStep spec as published on NeXT's web site. The NeXT software platform is in most things AHEAD of the Mac, which is why Apple bought it, why Jobs had created it after he left Apple, etc. NeXTSTEP/OPENSTEP => Rhapsody is for all intents a system made by Mac lovers and users who asked themselves: what can we do better? hence if offers more freedom for power users than the somewhat claustrophobic Mac environment, while still allowing ease of use for the novice, that's why it has a less convoluted OO API, etc. If I remember correctly, features like drag&drop were FIRST on the NeXT, etc. In other words: most fears that some important Mac feature will be missing are for nothing. It'll be ok :-) NeXT has actually very nice support for user preferences, and most apps ship in only one version that behaves correctly based upon the user preferences. (inch vs. cm, date formats, interface language, number formats, etc.) Greetings, Ronald From Mike_Ferris at next.com Thu Apr 10 16:20:23 1997 From: Mike_Ferris at next.com (Mike Ferris) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody Message-ID: <9704102320.AA07378@oz.next.com> OpenStep is completely Unicode based. What you describe as the "current situation" is not current. When you buy OpenStep today you get full unicode support and full support for converting NSStrings to any number of other character encodings including most of the popular Japanese encodings. You do still have to buy a separate CD for Japanese but really only to get the extra fonts and input managers (which are expensive) (and to get separate versions of old NextStep apps anbd some command line utils that still have to be done in the old separtist way...) Mike Ferris OpenStep Application Frameworks From mtarbell at akina.jpl.nasa.gov Thu Apr 10 16:45:20 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody In-Reply-To: <9704102320.AA07378@oz.next.com> References: <9704102320.AA07378@oz.next.com> Message-ID: <9704102345.AA01854@akina.jpl.nasa.gov> Mike Ferris (Mike_Ferris@next.com) wrote: > When you buy OpenStep today you get full unicode support and > full support for converting NSStrings to any number of other > character encodings including most of the popular Japanese > encodings. Yes, this is true, and I happily stand corrected (although support for ISO2022JP, i.e., New-JIS, isn't part of the standard OpenStep spec; it looks like a NeXT-specific extension?). > You do still have to buy a separate CD for Japanese but really only to get > the extra fonts and input managers (which are expensive) (and to get > separate versions of old NextStep apps anbd some command line utils that > still have to be done in the old separtist way...) So... Japanese OpenStep apps won't crash on English OpenStep systems (the requisite libraries are present)? That was the gotcha with NEXTSTEP-J apps: short of using macho to change the app's libraries, they would crash on NEXTSTEP systems (even when they had an English.lproj) for lack of libraries, most notably the Text library which had special multibyte methods. Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From izumi at pinoko.berkeley.edu Thu Apr 10 17:49:53 1997 From: izumi at pinoko.berkeley.edu (Izumi Ohzawa) Date: Thu Nov 3 14:40:21 2005 Subject: Opener'able version of new Rhapsody OpenStep doc Message-ID: <199704110049.RAA04923@moica.berkeley.edu> Garance A Drosehn writes: >From what I can see by 10 minutes of looking at these PDF files, >they seem mighty similar to the documentation that NeXTSTEP owners >already have on their CD-ROM's (although my 4.1 system is not here >at work, so I can't really say for sure). The main README, for >instance, says that the developer tutorial "Introduces programmers >to NeXT's OPENSTEP 4.0 Developer Product". That ain't Rhapsody. The problem is that we decided to stop at NS3.x for black and Intel, so no OS4.x CDROM here. Aren't there substantial # of small-time developers who are in this situation? What is a Windows-only developer to do? If I were one, and happen to visit the NeXT or Apple web site now just out of curiosity, I will leave in frustration, with the obvious conclusion that Apple does not care. Just click on that "Windows NT" icon and see what you get (and don't get). It is unfortunate that NeXT's downloadable documentation page http://www.next.com/Pubs/Documents/Download/ has a full collection of docs only for Macs. I mean, the docs should be available to anyone off the street, even to developers who swear by Windows. However, there's virtually nothing for other platforms with respect to docs for OpenStep proper. And you can't unpack Apple files unless you have a Mac handy. Particularly missed are the Developer Tutorial, and the excellent Obj-C docs in HTML files. Perhaps, NeXT's assumption was that NeXT Mach, NT, Solaris developers all are running OS 4.x by now. That's incorrect for some developers, I am sure. Many if you count people who have never tried. I have developed for NS from 1.0 through 3.2, but we stopped at 3.2, seeing how much work it is going to take to move apps to OS 4.x. It is only because of Rhapsody that we have renewed our interest in diving into OpenStep. But we are not going to do it on black or Intel HW. We will only do it for Rhapsody, but would like to read some docs meanwhile, alas we don't have those docs related to OS Appkit/Foundation/DevTutorial etc. [#### This is stuff that makes the post appropriate for this list. ####] So, I have bulk-downloaded and repackaged a collection of PDF and HTML files obtained from http://www.next.com/Pubs/Documents/Download/apple.html and View Online links therein. WebObjects files are not included, as they are not central to my interest in Rhapsody/OpenStep and are quite large. I have it at (8.1MB): ftp://pinoko.berkeley.edu/pub/next/docs/OPENSTEPdoc.tar.gz which contains: Discovering OPENSTEP: A Developer Tutorial (PDF) Appkit Reference (PDF) Foundation Reference (PDF) Topics in OPENSTEP Programming (PDF) Object-Oriented Programming and the Objective-C Language (HTML) Open OPENSTEP/index.html with your Web browser set up for PDF. PDF is somewhat yucky compared with RTFD but I am not complaining. I hope NeXT/Apple don't mind. I will delete it if there are legal problems, but they should make this available at their Web site in the first place. StepWise and Peak etc are welcome to take the file out of my hand. I am waiting for dev. release of Rhapsody with money in my hand, so to speak, to buy some Macs for the first time. No, I am not going to buy a Mac just to open stupid *.sit.hqx before beta-Rhapsody is out. Couldn't get excited about Macs before, but now hopefully it will be different. I. From bakke at ad.enet.dec.com Fri Apr 11 04:34:18 1997 From: bakke at ad.enet.dec.com (A billion here, a billion there... pretty soon you're talking about REAL money.) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <9704111134.AA08183@easynet.crl.dec.com> Ernie P. Wrote: >Laurent wrote: >> I've never done Java programming and find myself a little bit >> confused about these Java API's. >> For me Java is more than a language, because you can write >> cross-platform softwares with it, and this is associated with the >> virtual machine. What does it mean to have Java API's then?=20 > >Currently, OpenStep applications are written to the "OpenStep API", = >which is in Objective-C and is cross-platform. All the various = >The bottom line is that many people are afraid of learning = >Objective-C the language; they shouldn't be, but they are. Java = >makes it emotionally easier for people to program for Rhapsody, = >which is A Good Thing. Java does do a few things better than = >Objective-C, though there are some things it doesn't do at all. = >People can use what they want, Apple will support both, and everyone = >should live happily ever after. It seems to me that the problem isn't Objective-C itself, but the fact that there don't seem to be any programming environments for anything but OpenStep. If someone is looking to create a cross-platform, consumer-level product, why would they use OpenStep? It costs way too much for the run-time environment. That, in my opinion, is the reason more people don't use it. If people could actually write programs for different environments using Obj-C, maybe they would. It's looked at as being proprietary right now. Does anyone know any details about the Objective C support that Metrowerks will be including in CodeWarrior 12? Would you be able to write MacOS programs in Objective C? Apple really needs to lower the costs for the OpenStep run-time. -SB From scott at QuickBase.com Fri Apr 11 05:24:09 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody In-Reply-To: <9704101634.AA01658@akina.jpl.nasa.gov> References: <9704101634.AA01658@akina.jpl.nasa.gov> Message-ID: <9704111224.AA13527@QuickBase.com> You wrote: > I'm hoping also that Rhapsody includes, by default, something akin > to OpenStep-J, extending multi-byte character support to all > classes. The current situation (wherein one must purchase a > different version of the operating system) is a poor solution, as I > cannot make apps which require nonexistent libraries on host > machines. --- I think there is a misunderstanding here. The version of OpenStep for Japan (which includes the two-byte character set) simply has a different version of the shared libraries -- the API is the same. Therefore, your program can be written on "normal" OpenStep and run on OpenStep for Japan without any changes. Your program simply calls methods that work slightly differently for each version of OpenStep. I hope that helps. Best regards, Scott Keith ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From scott at QuickBase.com Fri Apr 11 05:45:58 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:21 2005 Subject: distributed objects In-Reply-To: References: Message-ID: <9704111246.AA13549@QuickBase.com> You wrote: > Funny, I don't know of anyone who uses it that is not also > frustrated at it's lack of reliability. --- I am aware of a number of projects that use DO extensively and have found that it is reliable. We use it also for our product. In Denmark we have 23 replicated OpenBase SQL servers (for the Royal Danish Police) which run 24 hours a day 365 days a year. We use DO for all communications. If you know how to setup DO correctly it will work perfectly. - Scott ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From kazuo-t at zoom.or.jp Fri Apr 11 07:26:05 1997 From: kazuo-t at zoom.or.jp (Kazuo Tsubaki) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody References: <9704111224.AA13527@QuickBase.com> Message-ID: <9704111426.AA00313@venus.shonan.zoom.or.jp> Hi, You wrote: > I'm hoping also that Rhapsody includes, by default, something akin > to OpenStep-J, extending multi-byte character support to all > classes. The current situation (wherein one must purchase a > different version of the operating system) is a poor solution, as I > cannot make apps which require nonexistent libraries on host > machines. In short, Japanese version of OPENSTEP is almost same as OPENSTEP sold your country except for Japanese Fonts, Input Manager (in Mac world, Input Method) and Japanese NIB files and localized string resources (text files). I have been a Mac developer for seven years. Now I think OPENSTE is better OS than Mac. You mentioned "poor solution" but this is not technical issue but marketing issue. Regards, --- Kazuo Tsubaki mailto:kazuo-t@st.rim.or.jp (MIME, NeXTMail acceptable) http://www.st.rim.or.jp/~kazuo-t 679 Kasamacho, Sakae-ku, Yokohama 247 Japan Tel:045-890-1890 Fax:045-890-1890 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 970 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970411/9b3e3e3f/attachment.bin From mpinkert at cc.gatech.edu Fri Apr 11 07:34:36 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <199704111436.KAA08915@lennon.cc.gatech.edu> "A billion here, a billion there... pretty soon you're talking wrote on 4/11/97 7:40 AM >It seems to me that the problem isn't Objective-C itself, but the fact >that there don't seem to be any programming environments for anything >but OpenStep. I think a huge part of it is not the lack of environments or that people are "scared" to learn a new language. The problem is that this language exists, for all practical purposes, only on ONE platform (nobody uses objC on other platforms, even though it is part of gcc). No software company is going to invest in a project using a language which cannot be leveraged to any other platform. In a world of cross-platform code bases and products, having to write in C++ for windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for windows). >From the people I talked to at a big internet software company (to remain nameless, I don't want to speak for them) but they won't even think about porting their key product to Rhapsody if they have to touch ObjC. I'm sure other major developers feel the same way. -- 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 dwy at ace.net Thu Apr 10 08:00:24 1997 From: dwy at ace.net (David Young) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <199704111436.KAA08915@lennon.cc.gatech.edu> Message-ID: > I think a huge part of it is not the lack of environments or that people > are "scared" to learn a new language. The problem is that this language > exists, for all practical purposes, only on ONE platform (nobody uses > objC on other platforms, even though it is part of gcc). Wrong. We do systems programming on Solaris, Digital UNIX, AIX, BSDI, and HP-UX using Objective-C. We don't use OpenStep, we have our own set of classes, but we definitely use ObjC. Other people do too. > No software company is going to invest in a project using a language > which cannot be leveraged to any other platform. In a world of > cross-platform code bases and products, having to write in C++ for > windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for > windows). Have you missed the point of OpenStep entirely? Develop on Mach, deploy on NT, Mach, Rhapsody. Either way, developers aren't going to tell an installed base of 20+ million users to get bent. There's too much money available. > From the people I talked to at a big internet software company (to > remain nameless, I don't want to speak for them) but they won't even > think about porting their key product to Rhapsody if they have to touch > ObjC. I'm sure other major developers feel the same way. >From the people I talked to at my internet software company (to remain named in my .signature, I want to speak for them), we won't even think about developing for Rhapsody if we can't use ObjC. I'm sure other major developers feel the same way. Dave .............david.young...senior.developer...think.new.ideas.inc... ....work:.http://www.thinkinc.com...net:.david_young@thinkinc.com... From jperry at wizvax.net Fri Apr 11 03:49:31 1997 From: jperry at wizvax.net (j perry) Date: Thu Nov 3 14:40:21 2005 Subject: Java Interfaces != categories (was "Rhapsody will feature _Java_ APIs") Message-ID: Paul R. Summermatter wrote: >...As I understand it, Java currently supports extensibility >only through sublassing. Extension of classes through categories, >as we have them in Objective-C, is not available. I've not used either Java or ObjC; however I took Java "Interfaces" to be a solution for the same type of problems as ObjC's "Categories". Is this not so? TIA, Jeff Perry !!!!!!!!!!!!!!!!!!! , , jperry@wizvax.net . =================== - From bakke at ad.enet.dec.com Fri Apr 11 08:45:46 1997 From: bakke at ad.enet.dec.com (A billion here, a billion there... pretty soon you're talking about REAL money.) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: <9704111545.AA18652@easynet.crl.dec.com> David Young wrote: >> No software company is going to invest in a project using a language >> which cannot be leveraged to any other platform. In a world of >> cross-platform code bases and products, having to write in C++ for >> windoze and ObjC for Rhapsody is a non-issue (everyone will write C++ for >> windows). > >Have you missed the point of OpenStep entirely? Develop on Mach, deploy on >NT, Mach, Rhapsody. Either way, developers aren't going to tell an >installed base of 20+ million users to get bent. There's too much money >available. > I don't believe he's missed the point. What about most software companies who don't want to have to re-write all of their C++ or other code in Obj-C. This is just fine for Enterprise products, but what about consumer type products? The OpenStep run-time costs way too much for that. The product will not be able to compete unless OpenStep libraries can be made available for cheap. -SB From dwy at ace.net Thu Apr 10 09:22:53 1997 From: dwy at ace.net (David Young) Date: Thu Nov 3 14:40:21 2005 Subject: Java Interfaces != categories (was "Rhapsody will feature _Java_ APIs") In-Reply-To: Message-ID: On Fri, 11 Apr 1997, j perry wrote: > Paul R. Summermatter wrote: > >...As I understand it, Java currently supports extensibility > >only through sublassing. Extension of classes through categories, > >as we have them in Objective-C, is not available. > > I've not used either Java or ObjC; however I took Java "Interfaces" to be a > solution for the same type of problems as ObjC's "Categories". Is this not > so? This is not so. Categories provide lateral expansion of a class; interfaces are closer to ObjC protocols. Java also lacks an informal protocol scheme, which makes delegation a real nightmare.. .............david.young...senior.developer...think.new.ideas.inc... ....work:.http://www.thinkinc.com...net:.david_young@thinkinc.com... From ernest at alumni.caltech.edu Fri Apr 11 09:19:27 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:21 2005 Subject: Java Interfaces != categories (was "Rhapsody will feature _Java_ APIs") Message-ID: <199704111619.JAA04894@alumni.caltech.edu> Let me try to summarize this, in case nobody else has yet: Interfaces in Java ( as I understand them) are equal to Protocols in Objective-C. THey are abstract definitions of the methods that can be called. These exist in a separate hierarchy than actual classes, but can inherit from each other, including multiple. ie., MyProtocol can inherit form YourProtocal AND HisProtocol at the same time. There is not actual code associated with a protocol (or interface), just type-checking (both compile -time and run-time). Categories are somtimes treated as "mixins". You associate a category with a specific -class-. You can extend existing classes for which you do not have the source code by using categories (including the AppKit, in cool ways). You can even override the behavior of existing methods (which is horribly unsafe, but very powerful, especially for bug fixes!). The main limitations are: - categories can not contain instance variables - the order of categories is random; if you load two which define the same method, it is not clear which one will get called. I do not believe Categories are even imaginable as an option to Java because of the runtime and security issues. Although, I suppose one could imagine extending Java - especially if it uses the ObjC runtime - to support it for server-side applications (vs. client-side applets). Does that help> - Ernie P. From dwy at ace.net Thu Apr 10 09:32:17 1997 From: dwy at ace.net (David Young) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704111545.AA18652@easynet.crl.dec.com> Message-ID: > I don't believe he's missed the point. What about most software companies > who don't want to have to re-write all of their C++ or other code in > Obj-C. No one said they had to. C++ interoperates just fine with ObjC, if you use NeXT's compiler. > This is just fine for Enterprise products, but what about consumer type > products? The OpenStep run-time costs way too much for that. The product > will not be able to compete unless OpenStep libraries can be made available > for cheap. Yeah, I think the runtime should be cheap too. I have a feeling it will be. From stark at easynet.fr Thu Apr 10 08:54:37 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody References: Message-ID: <9704101554.AA00347@easynet.fr> "Stephen Coy" wrote > G'Day, > [crunch] > > This includes functions for converting strings to > dates/times and vice versa, in the local format. Look for the file Locales.rtf in Foundation reference to learn more about the defined locale information for OPENSTEP > A component of this is an API for parsing strings into > tokens, which we have found useful for parsing in general. NSScanner, NSString > Additionally, a Mac knows whether or not measurement > should employ metric or imperial units It knows at least NSLanguages/NSMeasurementUnit/NSPaperType. This can be overriden on a per application basis > and where it is > located geographically. 'located geographically' ? Why for ? > Do you think we can expect to see this kind of thing in > Rhapsody? Are there similar API's in OpenStep? Sure. Cheers, -- fred From stark at easynet.fr Thu Apr 10 08:30:14 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:21 2005 Subject: Determining what "features" the OS has? References: Message-ID: <9704101530.AA00325@easynet.fr> stevec@magna.com.au wrote: > The current MacOS supports an API call "Gestalt", which > a programmer can use to determine all kinds of > information about the current environment in which an > application is running. You have much less needs to know things in OPENSTEP than you have in MacOS, as Frameworks hides you from many details. > This includes stuff like the OS version You should not rely on such things. The OS is composed of many parts (kernel and UNIX tools/frameworks/applications). The fact that the kernel is [NeXT Mach 4.2] does not tell me much about the execution environment. The user can have replaced applications by others. The shared libs that my app currently uses can come from another version. You have two very low level functions for checking versions: NSVersionOfRunTimeLibrary( const char *libraryName ) NSVersionOfLinkTimeLibrary( const char *libraryName ) Generally, we could say that: * It is NeXT business to ensure that your application will run on all similar system with higher versions than the one you compiled on. They do a pretty good job at that [at least in my opinion]. * It is your business to ensure your application can run on system with a minor version lower than the one you compiled with. For this you do not need version numbers. You explicitly ask the run-time for information, like: if ([NSFileHandle respondsToSelector:@selector(initWithNativeHandle:closeOnDealloc:)]) // We can use this 4.1 specific method else // We cannot [I am not sure if this was always the case. I mean 3.3 app on 3.0 system, did it worked ?] * You cannot run on previous major version > the availability of particular system features Well, you can ask the run-time whatever you want. > (such as balloon help, or the alias manager) Let's be more specific: If balloon help is implemented as an addition to, say, AppKit framework, which new classes created: This would be a public API addition, so the 'compatibility version' of AppKit would have changed. You app wouldn't even launch on a system with a 'current version' of AppKit lower than that. If you want being executable on a system with lower version, you should link against the older version, and use run-time function to instanciate your baloon help functions. This would be a real pain. If baloon help is implemented as an addition to, say, AppKit, without new classes created (This is in fact the case. ToolTips are added in 4.2) with two more methods to view: - (void)setToolTip:(NSString *)string; - (NSString *)toolTip; You can ask the runtime to know if the routines are present. > or perhaps the version of a particular component, such as the > AppleTalk stack If you meant the protocol version implemented by the stack, a function to get it should be included in the API. > Does anyone know how similar functionality will appear in Rhapsody? > Presumably NextStep does this somehow? Anyway I beleive version numbers are a bad idea, because people tend to use them :-) After a while, the system ends up lying, pretending being a lowered numbered version for specific programs, because they would otherwise refuse to run on newer systems. [I guess there are people that patch the Gestalt manager...] Cheers, -- fred From mtarbell at akina.jpl.nasa.gov Fri Apr 11 09:36:06 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody In-Reply-To: <9704111224.AA13527@QuickBase.com> References: <9704101634.AA01658@akina.jpl.nasa.gov> <9704111224.AA13527@QuickBase.com> Message-ID: <9704111636.AA00521@akina.jpl.nasa.gov> Scott Keith wrote: > The version of OpenStep for Japan (which includes the two-byte character > set) simply has a different version of the shared libraries -- the API is > the same. Therefore, your program can be written on "normal" OpenStep and > run on OpenStep for Japan without any changes. Your program simply calls > methods that work slightly differently for each version of OpenStep. This is what I had been hoping! Under NEXTSTEP 3.xJ, there were different compile options (LANGUAGE=Japanese, -DKANJI, etc), that affected a lot of #ifdef code in the system header files! New methods enabled, alternate version of methods, different definitions, etc. Not a good way to do things. If this has all been changed, as you state, then this is a GOOD THING. Also, having to manually parse Shift-JIS, New-JIS, Old-JIS, NEC-JIS, etc, into EUC and back again was a small nightmare. Having this done for me will be a very welcome change. The big problem with the Text object under 3.3 was that you had to manually count the number of 2-byte vs. 1-byte characters to get the true "character" count offset into the Text object (not the byte offset). Glad to see that's all gone! All of that should be well hidden, from even the developer! Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From ernest at alumni.caltech.edu Fri Apr 11 09:42:26 1997 From: ernest at alumni.caltech.edu (Ernest N. Prabhakar) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology Message-ID: <199704111642.JAA06521@alumni.caltech.edu> Someone brought up the issue of licensing for the OpenStep runtime on Windows NT/95. The cost is alsmot entirely a marketing issue (modulo a few license costs which aren't that significant), because of the relative profit- ability and market importance of the different OpenStep products. We'll just have to wait for whatever Apple decides, and this isn't really very appropriate for this group. HOWEVER, the technical aspects of licensing are important. I am curious what Apple developers are used to, and lokoing for. I am not even sure what the current state-of-the-art is on OpenStep. Under NeXTSTEP, there were several common schemes: - license to CPU, where the app was bound to the Ethernet address - license to network user, where the app was bound to a username - floating network license, wher so many apps could run on the local LAN at any one time Of course there were many other -policies-, but these were the ones that were enforced by code (not to mention the infamous timed expiration:) Are Mac developers even used to thinking in those terms? I believe there were one or two commercial LicenseKit type thigns which handled these schemes. It may have also included the "demo" mode, where an App would weither not save/cut/paste or expire after 15 minutes until you entered the registration key. What I'd like to see is even more solutions for electronic distribution of software. Given all the battles Mac users have in finding software in stores (e.g. hybrid Cds, hostile clerks), it seems like the Intenrnet will be critically important. I can think of several things that would be cool: - WebObjects commerce solutions making it trivial for anybody with a web site to take and fulfill orders electronically - perhaps integrated into Installer/Mail.app on the back-end. - PUblication specs so that anyone who posts an page describing a product in the appropriate XML format would automatically get indexed by the various search engines (or Appple-specific ones) to generate a dynamic online catalog. - Object licensing schemes (for either classes or instances) to empower fourth-party publishing [Do the OpenDoc people have anything useful for doing that?] Anyway, we can't control what Apple does, but we can start priming the business pump. There's a lot we can do by working together as developers, and there may be some great business opportunities for somebody here. I'd be willing to provide free management consulting to anybody who'd want to run with these (I'm too busy doing -paid- MC to do it myself :-(). -- Enrie P. From ricardo at ccsi.canon.com Fri Apr 11 09:56:25 1997 From: ricardo at ccsi.canon.com (Ricardo Parada) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs References: Message-ID: <9704111656.AA11071@ccsi.canon.com> > > I think a huge part of it is not the lack of environments > > or that people are "scared" to learn a new language. The > > problem is that this language exists, for all practical > > purposes, only on ONE platform (nobody uses > > objC on other platforms, even though it is part > > of gcc). > > Wrong. We do systems programming on Solaris, Digital > UNIX, AIX, BSDI, and HP-UX using Objective-C. We don't > use OpenStep, we have our own set of classes, but we > definitely use ObjC. Other people do too. Objective-C will also be available soon from Metrowerks for Rhapsody, Windows 95 and NT. It's also available from Sun. - ricardo From gad at eclipse.its.rpi.edu Fri Apr 11 10:30:03 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs References: <9704111545.AA18652@easynet.crl.dec.com> Message-ID: <9704111730.AA19175@eclipse.its.rpi.edu> > > Have you missed the point of OpenStep entirely? Develop on > > Mach, deploy on NT, Mach, Rhapsody. Either way, developers > > aren't going to tell an installed base of 20+ million users > > to get bent. There's too much money available. > > I don't believe he's missed the point. What about most software > companies who don't want to have to re-write all of their C++ or > other code in Obj-C. > > This is just fine for Enterprise products, but what about consumer > type products? The OpenStep run-time costs way too much for > that. The product will not be able to compete unless OpenStep > libraries can be made available for cheap. For one, I definitely agree that the success of Rhapsody will depend a lot on the price it's sold at. For two, Apple is talking about Rhapsody being "language agnostic". If people who want to program in ObjectiveC can, and people who want to program in C++ can, and people who want to program in Java can, then I see little point in any one of those groups trying to convince the other groups of the errors of their ways. Now, it will be interesting to see how close they come to being truly language-agnostic, but that's a question which will only be answered by the release of Rhapsody. We should have a much better idea of the answer to that topic by the WWDC, next month. Let's leave this discussion until after that happens (and maybe pick it up in rhapsody-talk, once we have something to talk about). --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From chanson at mcs.com Fri Apr 11 10:31:15 1997 From: chanson at mcs.com (Chris Hanson) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: Message-ID: At 11:22 AM -0500 4/11/97, David Young wrote: >No one said they had to. C++ interoperates just fine with ObjC, if you use >NeXT's compiler. The issue isn't interoperability, the issue is compatibility. Is it possible in OpenStep now to use C++ *syntax* to access Objective-C objects? In other words, do I *have* to use [someObject someMessage:anArg] to send a message to an Objective-C object, or can I accomplish the same thing with someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++? I don't have a problem with using or learning Objective-C to develop for Rhapsody, but many other people appear to want to actually use C++ to program Rhapsody, not just to program the non-interface portions of their apps. I can totally understand this; right now, I'm porting a product from one platform and C++ class library to another and basically I'm writing shim classes to sit on top of the second library and interface with the ported code. I'd like to be able to do this for Rhapsody as well, if the port is desired there, and being unable to reuse that top layer of code (both model and view code) would make it much more difficult. From waltrip at aurora.jhuapl.edu Fri Apr 11 10:39:39 1997 From: waltrip at aurora.jhuapl.edu (Charles F. Waltrip) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs References: <9704101356.AA25443@alumni.caltech.edu> Message-ID: <334E775B.357B5B0D@aurora.jhuapl.edu> Dr. Ernest N. Prabhakar wrote: [...material deleted including a description of NeXT's plans to integrate the Java VM into the ObjC runtime...] > The bottom line is that many people are afraid of learning Objective-C the language; they shouldn't be, but they are. Java makes it emotionally easier for people to program for Rhapsody, which is A Good Thing. Java does do a few things better than Objective-C, though there are some things it doesn't do at all. People can use what they want, Apple will support both, and everyone should live happily ever after. > > -- Ernie P. I believe Java is a wonderful language but feel that ObjC is an even more wonderful language. What would be fantastic, in my view, would be if NeXT's compiler for C/C++/ObjC would include Java and would compile any C/C++/ObjC/Java language (or mixture of languages) into Java bytecodes as an option rather than only into ObjC runtime. Chuck From gad at eclipse.its.rpi.edu Fri Apr 11 10:53:18 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:21 2005 Subject: Eiffel for NeXTSTEP References: <9704111222.AA15864@ibx.com> Message-ID: <9704111753.AA19246@eclipse.its.rpi.edu> Several people have asked me questions along the lines of: > Hi Garance, > Would I find Eiffel/NS3.3 at 'www.eiffel.com', or is > it a non-commercial implementation? The web site at www.eiffel.com is from ISE. It seems to me that at one time ISE did have a version of eiffel for NeXTSTEP, but I don't see it at their web site. It could be that they never did have one. However, the eiffel I've used (a little) is the one from Tower. Their web site is at www.twr.com (note: "twr" not "tower"). They also have some extensions for using eiffel with the NeXTSTEP Interface Builder. Now I haven't used those extensions (due to a screw-up on my part), but I have used their eiffel compilier on NS/Intel. They have a collection of "Booch components" for Eiffel too. Their Eiffel products are also commercial products. I must admit that I haven't used eiffel on any major projects, but from what little I've done it seems like a decent product, and the folks at tower have been pretty reasonable to me. I have not asked them what their plans are WRT Rhapsody. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From jperry at wizvax.net Fri Apr 11 06:20:28 1997 From: jperry at wizvax.net (j perry) Date: Thu Nov 3 14:40:21 2005 Subject: Java Interfaces != categories Message-ID: Sorry folks, I completely misunderstood the original statement. When the original poster said "Extension of classes through categories, as we have them in Objective-C, is not available.", I was in fact thinking of protocols. Then came confusion. Thank you for the explanations, Jeff Perry !!!!!!!!!!!!!!!!!!! , , jperry@wizvax.net . =================== - From bayou at rouge.phys.lsu.edu Fri Apr 11 12:04:18 1997 From: bayou at rouge.phys.lsu.edu (James Gregurich) Date: Thu Nov 3 14:40:21 2005 Subject: Runtime costs Message-ID: Can this "runtime" be installed once on a machine, say NT, for multiple OPenstep programs or must each program include the runtime? James Gregurich LSU physics --------------------------------------------------------- Cyberdog ---A Product of Apple Computer, Inc. --------------------------------------------------------- From paulrs at lgs-systems.com Fri Apr 11 12:13:54 1997 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:40:21 2005 Subject: Java Interfaces != categories (was "Rhapsody will feature _Java_ APIs") In-Reply-To: References: Message-ID: <9704111913.AA19046@cube> Jeff, No, this is not so. The java categories more closely resemble the concept of protocols in Objective-C. The idea is to provide some multiple-inheritance support without all of the attendant problems. You can establish a group of methods as a protocol and objects with completely different heirarchies can conform to them. Many of the NeXT developers subscribing to this group probably have developed their own protocols for their enterprise objects. There's one that we all use everyday called the EOKeyValueCodingProtocol. Categories provide even more power. They can allow you to add methods to existing classes, or override existing methods without having to create a subclass of that object. I can't emphasize enough how tremendously important this is. Now that I have this functionality, I cannot fathom ever being without it. Let me provide some examples. One method which I really like to have is an isNotEmptyString method. I define empty string being any string which is nil, has zero length, or has only whitespace (returns, tabs, spaces, etc). The foundation classes do not provide an isNotEmptyString method for the NSString class. To solve this, I simply create a category for NSString, like the following, and implement my isNotEmptyString method (I've ommitted the implementation): @inteface NSString (LGSStringExtensions) - (BOOL)isNotEmptyString; @end This procduces a couple of desirable effects. Firstly, if I want to ask an NSString if it is not empty, I do not have to instantiate some new object which is a subclass of NSString and responds to this message, wasting valuable time and resources (both the computer's and mine). Also, if the object is nil, the system handles this properly and returns no so I don't have to do the following if (string && [string isNotEmptyString]) That was an example of creating a method which doesn't exist. Let's take a look at overriding a method which does exist. This one is going to be a little more esoteric, but hopefully it will make sense. As part of the foundation classes for OpenStep we have an EONull object which, and I hope I'm explaining this properly, is essentially a nil object without actually being nil. Most objects implement a description method. EONull is no exception. However, the folks at NeXT decided that the description for the EONull class should be . With this, if a null value was fetched from the database, the user would see the '' in the UI. Many people, myself included, found this quite distasteful. To fix this, we simply created a category on EONull @interface EONull (BetterDescription) - (NSString *)description; @end @implementation EONull (BetterDescription) - (NSString *)description { // Return an blank string return @""; } @end You need to understand how monumentally important this is. NeXT implemented default behaviour which we didn't like, and it took only 10 lines or so of code to fix the problem. I couldn't fix this problem with subclassing because I don't have access to the code which NeXT has written. This may seem like a silly example, but there are far more important, but difficult examples which I could provide. The principle is what is important here. Regards, Paul You wrote: > Paul R. Summermatter wrote: > >...As I understand it, Java currently supports extensibility > >only through sublassing. Extension of classes through categories, > >as we have them in Objective-C, is not available. > > I've not used either Java or ObjC; however I took Java "Interfaces" > to be a solution for the same type of problems as ObjC's > "Categories". Is this not so? > TIA, > > Jeff Perry > > > !!!!!!!!!!!!!!!!!!! , , > jperry@wizvax.net . > =================== - > > --- Paul Summermatter LGS Systems, Inc. paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) From rcfa at cubiculum.com Fri Apr 11 11:45:20 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704111134.AA08183@easynet.crl.dec.com> References: <9704111134.AA08183@easynet.crl.dec.com> Message-ID: <9704111845.AA09573@ kannix.cubiculum.com > > Apple really needs to lower the costs for the OpenStep run-time. I think key component of the high cost of the run-time is the DPS license. If Apple could cut a deal with Adobe, whereby Apple grants Adobe free licenses to the OpenStep runtime, if in exchange all Adobe apps for Win95, WinNT, Rhapsody, and Solaris are built with it and ship with the OpenStep runtime, in such a way that other applications can use it as well, then we'd have a great deal. Adobe would benefit, since the would have to maintain only one code base for all platforms. Many people would be tempted to buy Adobe apps, anf if only to get at the OpenStep runtime for cheap. Apple would benefit, since everyone who owns even one Adobe app, has the OpenStep runtime, and can buy other OpenStep apps and run them. This would make OpenStep the most powerful corss platform development environment. (Spare me the Java crap here, it's not even in the same league. When was the last time you tried to write printing support in Java, or do real WYSIWYG...) 3rd party developers would benefit, since they could write powerful OO apps and deploy them on almost any platform. The only time the runtime expense would still be an issue, is if someone does not either own the OPENSTEP environment or Rhapsody, at which point they would have to buy the OpenStep runtime, which could be sold like the Win95 Plus! pack. Of course, Apple could also spend a little money and fund the GNUStep people with about $10-20k, and get GhostScript turned into a fullblown DisplayGhostScript. After that, they could offer the AdobeDPS OpenStep runtime for a lot of money, and the generic DGS OpenStep runtime for more or less free. In either case, OpenStep as a development and deployment platform, as well as Apple's viability as a computer company would skyrocket. Ronald From dwy at ace.net Thu Apr 10 12:59:56 1997 From: dwy at ace.net (David Young) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: Message-ID: On Fri, 11 Apr 1997, Chris Hanson wrote: > The issue isn't interoperability, the issue is compatibility. Is it > possible in OpenStep now to use C++ *syntax* to access Objective-C objects? > In other words, do I *have* to use [someObject someMessage:anArg] to send a > message to an Objective-C object, or can I accomplish the same thing with > someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++? Partially. You can do objc_sengMsg(object, selector, arg, arg), but you can't do someObject->someMessage(anArg). Now, I wouldn't stop NeXT from writing proxy classes in C++ which allowed you to do this by masking the actual message calls. You currently cannot subclass ObjC classes in C++. With enough hacking NeXT could probably make some of these things happen. The end result is likely to be uglier than just learning ObjC, but whatever. It seems weird to me to want to preserve the syntax of C++ in a View class which wouldn't interact with anything but OpenStep libraries anyway, but whatever. > I can totally understand this; right now, I'm porting a product from > one platform and C++ class library to another and basically I'm writing > shim classes to sit on top of the second library and interface with the > ported code. I'd like to be able to do this for Rhapsody as well, if the > port is desired there, and being unable to reuse that top layer of code > (both model and view code) would make it much more difficult. Eh? If you've already got a layer of abstraction between you and your View code, then writing an interface layer in ObjC++ would be okay... .............david.young...senior.developer...think.new.ideas.inc... ....work:.http://www.thinkinc.com...net:.david_young@thinkinc.com... From don at misckit.com Fri Apr 11 12:56:14 1997 From: don at misckit.com (Donald A. Yacktman) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704111845.AA09573@ kannix.cubiculum.com > References: <9704111845.AA09573@ kannix.cubiculum.com > Message-ID: <9704111956.AA05745@misckit.com> On Fri, 11 Apr 97, Ronald C.F. Antony wrote: > I think key component of the high cost of the run-time is the DPS license. How can a <= $20 license be the cause of the current exorbitant price for NeXT's runtime? I don't have the exact number, but I know that is it definitely << $50 per DPS license, in the $20 ballpark. A DPS license add-on to allow printing to a non-PS printer costs more (since it allows any machine with OPENSTEP to turn *any* printer into a Postscript printer) but that is why it is an add on. Personally, I think the reason for NeXT's pricing is, well, NeXT. --- Later, -Don Yacktman don@misckit.com My home page From scott at QuickBase.com Fri Apr 11 12:58:45 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:21 2005 Subject: Runtime costs In-Reply-To: References: Message-ID: <9704111958.AA14252@QuickBase.com> You wrote: > Can this "runtime" be installed once on a machine, say NT, for > multiple OPenstep programs or must each program include the > runtime? > In most cases, Yes. The runtime is really a user license. If you already have OpenStep User then there are no licensing fees. The only exception is that if you bundle the user-license and work out a special pricing arrangement with NeXT/Apple then the license only covers your program. - Scott Keith ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From rcfa at cubiculum.com Fri Apr 11 12:58:05 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704111730.AA19175@eclipse.its.rpi.edu> References: <9704111730.AA19175@eclipse.its.rpi.edu> Message-ID: <9704111958.AA09782@ kannix.cubiculum.com > >For two, Apple is talking about Rhapsody being "language agnostic". >If people who want to program in ObjectiveC can, and people who >want to program in C++ can, and people who want to program in Java >can, then I see little point in any one of those groups trying to >convince the other groups of the errors of their ways. Well, technically, that's just not possible. Java, SmallTalk, ObjC are all languages that use dynamic, run-time binding. You CAN make the OpenStep APIs language agnostic among these (more or less). C++ and most other so called "strongly typed" languages, use static binding. They just cannot use all the OpenStep functionality. While it is possible too create a C++ syntax compiler that produces dynamically bound code, that's not C++ anymore. It wouldn't be portable to other C++ implementations, since they don't support the feature. It would be mock C++, syntactic sugar (quite bitter one at that), but not C++ As a matter of fact, Java (the language) is nothing but an attempt to pack Smalltalk and ObjC like functionality into the sick C++ like syntax. Ronald From blenko-tom at CS.YALE.EDU Fri Apr 11 13:44:14 1997 From: blenko-tom at CS.YALE.EDU (Tom M. Blenko) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology In-Reply-To: <199704111642.JAA06521@alumni.caltech.edu> References: <199704111642.JAA06521@alumni.caltech.edu> Message-ID: <9704112044.AA08457@ruebezahl.cs.yale.edu> > Anyway, we can't control what Apple does, but we can start > priming the business pump. There's a lot we can do by working > together as developers, and there may be some great business > opportunities for somebody here. I'd be willing to provide > free management consulting to anybody who'd want to run with > these (I'm too busy doing -paid- MC to do it myself :-(). Pardon me, perhaps I'm fighting old battles, but... You are correct that Apple's decisions are a big factor in whatever follows -- which customers they want, which customers they don't, where they're going to draw the line between themselves and the third party developers, what technology they will support and what they won't. >From a business point of view, I think the status quo, in which these things are yet to be revealed, is a no-go, for small businesspeople anyway. We've all seen a lot of casualties from the NeXTstep era, if anything Apple needs to make an extra effort to put that behind them. And perhaps the message is out, we just aren't hearing it right yet -- because we've heard absolutely nothing. If we are to be part of Apple's future, doesn't that seem a bit strange, no, make that singularly peculiar? Hard to believe that they would think that simply dropping a developer release of an entirely new software product, for machines that the predecessor software has never run on before, to address a (largely) new market, is a sufficient strategy for bringing developers to the platform. So maybe the process is already well underway between the major players and we're just not being invited to the party. It's very easy to get carried away with the promise of the technology, which I presume we all take inspiration from, but that's entirely different from a sound business proposition. When and if Apple decides that people like us have a role to play in their future, I'm sure we'll hear from them about (business and technical) issues that concern us. Or it will become clear that the opportunies are so overwhelming that we should pursue them over and against Apple's interests. I don't see a case for the latter yet (though there certainly may be niches). In the meantime, I think the sensible conclusion is that we don't play much of a role in their picture. Tom From andrew Fri Apr 11 14:36:48 1997 From: andrew (Andrew Abernathy) Date: Thu Nov 3 14:40:21 2005 Subject: fwd: The state of Sprockets Message-ID: <9704112136.AA29864@omnigroup.com> I'm forwarding an article Chris De Salvo (Sprockets Tech Lead) posted to the Mac games dev mailining list as I think it is of appropriate interest to these lists and I've not seen anyone else send this on yet. Of specific interest to the Rhapsody-dev list is confirmation that all of the Game Sprockets functionality will be available for Rhapsody, albeit with an at least somewhat different API, presumably designed to fit well within OpenStep. This should be a relief to those who were wondering what functionality would be available; now the question is reduced to how will the functionality be presented. -andrew Date: Wed, 9 Apr 1997 17:13:21 -0700 >From: Chris De Salvo To: mac-games-dev@solutions.apple.com Subject: The state of Sprockets Message-ID: I don't know where the rumors start about the fate/state of Sprockets, but let me set the record straight... Nothing is dying, nothing is being cut, nothing is being omitted. Period. All of the Sprockets will continue to exist in the Mac OS world. Mac OS will continue to exist for at LEAST another two years, probably more. As far as Rhapsody goes, there is no guarantee that the Sprockets _API_ set will be present. However, ALL of the FUNCTIONALITY will be present, it just might be part of a different API. For instance, the new OpenStep NSDirectScreen class provides all of the context and CLUT operations that DrawSprocket provides. It will soon provide the double-buffering functionality we need as well. In about a week there will be a new release of InputSprocket and DrawSprocket. They both fix a lot of bugs. Input will provide a lot of new drives and some new functionality as well. There is a future update to NetSprocket planned as well, but it's not due until a month+ from now. Please don't believe rumors. I'm the new tech lead for the Sprockets and I'm very accessible -- both on this list and via direct email. Thanks, Chris De Salvo ----------------------------------------------- Chris De Salvo | DrawSprocket Apple Computer, Inc. | Changing the World - desalvo@apple.com | One Frame at a Time From mtarbell at akina.jpl.nasa.gov Fri Apr 11 15:44:45 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:21 2005 Subject: NSThread, NSTimer and NSRunLoop Message-ID: <9704112244.AA00783@akina.jpl.nasa.gov> I have a not-so-hypothetical OS4.1 situation: An "event" object is inserted into a queue by a thread. That thread sets a timer for the earliest launch date of all of the events in the queue (which may be weeks in the future), and exits. When the timer fires, it invokes the queue's -service method, which launches another thread to issue a -execute to the queue element whose time is up. That in turn updates the queue timer to the launch date of the next-in-line queue element, and the cycle repeats. The problem is, from within an NSThread, an NSTimer can apply itself only to that thread's NSRunLoop. The NSThread exits, so its NSRunLoop exits, so the NSTimer exits. Unless I want to have a bunch of zombie threads hanging around, it looks like I can't use an NSTimer. Using a Unix timer, however, works for a while, but ends up wreaking havoc with the FoundationKit. There seem to be some elements of the FoundationKit that aren't signal-safe. Odd things (e.g., internal FoundationKit data structures) end up becoming corrupted. Q: Are there any plans in OpenStep or Rhapsody to allow an NSTimer to be applied to the app's main run loop, or have an NSRunLoop's NSTimers be anti-inherited to its parent or to the main run loop when it exits? Or maybe there's another way to do this? Thanks for your help. Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From chanson at mcs.com Fri Apr 11 16:14:08 1997 From: chanson at mcs.com (Chris Hanson) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704111958.AA09782@ kannix.cubiculum.com > Message-ID: At 3:25 PM -0500 4/11/97, Ronald C.F. Antony wrote: >Well, technically, that's just not possible. Java, SmallTalk, ObjC are >all languages that use dynamic, run-time binding. You CAN make the >OpenStep APIs language agnostic among these (more or less). Doesn't SOM allow you to do stuff like this in C++ (and C)? From chanson at mcs.com Fri Apr 11 16:25:35 1997 From: chanson at mcs.com (Chris Hanson) Date: Thu Nov 3 14:40:21 2005 Subject: Defaults database Was: Mach & D.O. Limitation In-Reply-To: <9704052250.AA01183@shinto.nbg.sub.org> Message-ID: At 6:34 PM -0500 4/5/97, Thomas Engel wrote: >While we at it. I really really hope that Apple will update the >NSUserDefaults class to add another non volatil domain (NSNetworkDomain) >which would take the defaults right into NetInfo. There's an Internet protocol called Application Configuration Access Protocol (ACAP) currently being designed for doing just this thing in a heterogenous, interoperable manner. Check for details. (I think I've got the URL right...) Let me know if I'm right about this: A developer could use Objective-C's posing and delegation facilities to replace the default database methods with their own which talk to an ACAP server. Am I right, or does the ability to override the system classes in that way have to be built in from the beginning? From chanson at mcs.com Fri Apr 11 16:34:50 1997 From: chanson at mcs.com (Chris Hanson) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology In-Reply-To: <199704111642.JAA06521@alumni.caltech.edu> Message-ID: At 11:43 AM -0500 4/11/97, Ernest N. Prabhakar wrote: > - Object licensing schemes (for either classes or instances) to empower >fourth-party publishing > >[Do the OpenDoc people have anything useful for doing that?] I don't think that such a beast existed, but there was a part that noticed when you were trying to display content for which you didn't have a part and could connect to an online parts vendor to allow you to purchase & download that part (or get a viewer). At least that was the impression that I got of the Part Merchant stuff. Are there "hooks" in the Objective-C runtime that would allow for similar things with finer granularity? (Such as automatically querying a license server when you want to create an instance of a particular class.) From stevec at magna.com.au Fri Apr 11 17:57:01 1997 From: stevec at magna.com.au (Stephen Coy) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs Message-ID: On Sat, 12 Apr 1997 12:52 AM, David Young wrote: >Have you missed the point of OpenStep entirely? Develop on Mach, deploy on >NT, Mach, Rhapsody. Either way, developers aren't going to tell an >installed base of 20+ million users to get bent. There's too much money >available. > David, To many of us, the point is still distinctly fuzzy. If I develop an OpenStep application, what else will my customers need to run it under NT? A (set of) DLL(s)? Or a complete protected sub-system? The ability to build Windows/Macintosh solutions is important to many of us. It is not clear how OpenStep helps us do this, if at all. In fact, it would be great if someone could enlighten me (us). Regards, Steve Coy Resolve Software Pty Ltd 4 Andove St Belrose NSW 2085 Australia ****** This message was sent by CyberDog 2.0 ******** From stark at easynet.fr Thu Apr 10 18:33:32 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:21 2005 Subject: Defaults database Was: Mach & D.O. Limitation References: Message-ID: <9704110133.AA00370@easynet.fr> > > Let me know if I'm right about this: A developer could > use Objective-C's posing and delegation facilities to > replace the default database methods with their own which > talk to an ACAP server. Am I right, or does the ability > to override the system classes in that way have to be > built in from the beginning? > No, you're right, but beware that posing does not allow you to add instance variables. For the defaults case, it is even easier, you need to override: + (NSUserDefaults *)standardUserDefaults in a subclass that do a 'poseAsClass:' In the new implementation, you create a instance of another subclass (that did not 'poseAsClass:') in which you can have all the ivars you need. The only problem is that it won't work, because 'standardUserDefaults' is called from within [NSBundle initialize] & [NSApplication initialize], so you'll probably don't have the time to poseAsClass before the shared instance is created. This is not a problem if nobody cached it at this time but it is not really nice. You can do the nasty trick of defining a category on NSUserDefaults that implements +standardUserDefaults. This will even work... Cheers, --fred From rcfa at cubiculum.com Fri Apr 11 17:35:24 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology In-Reply-To: References: Message-ID: <9704120035.AA10476@ kannix.cubiculum.com > >At 11:43 AM -0500 4/11/97, Ernest N. Prabhakar wrote: >> - Object licensing schemes (for either classes or instances) to empower >>fourth-party publishing >> >>[Do the OpenDoc people have anything useful for doing that?] > >[...]Are there "hooks" in the Objective-C runtime that would allow for >similar things with finer granularity? (Such as automatically querying a >license server when you want to create an instance of a particular class.) Gee, all that licensing talk makes me sick, particularly the "fine grained" part. It's one thing to pay for software (that's ok), it's another to have the software check if has been paid for (depending on how it's done, that's ok, too; unless it's done the Wolfram way where you can't change anything about your system without the license breaking), but having a gazillion of little programs, objects, frameworks, each trying to authenticate the payment almost on a per message basis, maybe even by broadcasting messages on the LAN and sending out messages to the developer, is both way too wasteful with resources and bandwidth as well as too much like 1984... Licensing, the way we have it now, is just fine. Keep it that way, or there are just a lot of people tempted to create competing products under the GNU license... At least I would be. Ronald From rcfa at cubiculum.com Fri Apr 11 17:44:55 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: References: Message-ID: <9704120044.AA10502@ kannix.cubiculum.com > >At 3:25 PM -0500 4/11/97, Ronald C.F. Antony wrote: >>Well, technically, that's just not possible. Java, SmallTalk, ObjC are >>all languages that use dynamic, run-time binding. You CAN make the >>OpenStep APIs language agnostic among these (more or less). > >Doesn't SOM allow you to do stuff like this in C++ (and C)? I bet they solve it on the "interoperability" level, not on the "compatibility" level... Or maybe they can just do messaging, but not instantiation, subclassing, etc. Or else it's no longer C++ or the ever expanding C++ standard proposal just added support for dynamic binding, runtime message selection, etc. Ronald From rcfa at cubiculum.com Fri Apr 11 17:24:43 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Defaults database Was: Mach & D.O. Limitation In-Reply-To: References: Message-ID: <9704120024.AA10446@ kannix.cubiculum.com > >Let me know if I'm right about this: A developer could use Objective-C's >posing and delegation facilities to replace the default database methods >with their own which talk to an ACAP server. Am I right, or does the >ability to override the system classes in that way have to be built in from >the beginning? This works (in theory) on a per application basis, if the posing is done programmatically. There may be certain problems though, in practice, since certain defaults may be read before you even have a chance to do the poseAs calls, etc. Maybe, at some point in time, when NeXT/Apple have finished all the dynamic shared library tools, it will be possible to override the calls right at the source, at which point it would work for all programs on the machine. At that point I may just reitterate my question, in case someone figured out an answer in the mean time: How can one override on a system wide basis all the networking calls to make use of SOCKS? If we had the correct shared library tools, that would not be a problem. Is there a way to do it without? e.g. creating a pseudo System.framework with the correct SOCKS calls in it, that was linked against the original System.framework, that has been moved elsewere and has been renamed? Any ideas? Thanks, Ronald From rcfa at cubiculum.com Sat Apr 12 02:53:17 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: References: Message-ID: <9704120953.AA11818@ kannix.cubiculum.com > >To many of us, the point is still distinctly fuzzy. If I develop an >OpenStep application, what else will my customers need to run it under NT? >A (set of) DLL(s)? Or a complete protected sub-system? > >The ability to build Windows/Macintosh solutions is important to many of >us. It is not clear how OpenStep helps us do this, if at all. > >In fact, it would be great if someone could enlighten me (us). What is needed is the OpenStep User environment. That is however not really a user-environment (hence the confusion), but a system environment (DLLs, PS resources, encoding tables, etc.). It is just called OpenStep user environment to distinguish it from the Developer environment that contains that plus developer tools, etc. At this point, there is only two things that prevent any sane developer from doing only OpenStep development and deploying on all platform, and those are a) the licensing fees due (which Apple should lower in their own interest, if they want to become once more a leader, and the platform for which companies target their applications first) b) the somewhat higher resource requirements (RAM, HD space, etc.) Obviously, there is a price you pay for having DPS run under Windows, etc. and that is paid in higher resource consumption. So possibly the lowest end Windows platforms might not be able to handle it. But given that these days pretty much everyone is running a 486 or higher that is not really that much of an issue. The key thing is, if and when will Apple drastically drop the licensing fee for the user environment. Ronald From scott at QuickBase.com Sat Apr 12 03:11:31 1997 From: scott at QuickBase.com (Scott Keith) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: References: Message-ID: <9704121011.AA00633@QuickBase.com> > Steve Coy Writes: > To many of us, the point is still distinctly fuzzy. If I develop an > OpenStep application, what else will my customers need to run it > under NT? A (set of) DLL(s)? Or a complete protected sub-system? > Just a set of DLLs. > The ability to build Windows/Macintosh solutions is important to > many of us. It is not clear how OpenStep helps us do this, if at > all. > I suppose it is something you may need to see for yourself. I would say that OpenStep easily increases productivity by about 5 times. The reason is that the API is clean and provides high-level objects that are reusable and subclassible. When Word Perfect decided to port their word processor to NeXTSTEP a few years ago it only took them a month. The reason is that they didn't have to rewrite essential high-level objects--they just had to replace them with what was provided in NeXTSTEP/OpenStep. The idea behind OpenStep is that they give you much more to start with so you don't have to write your own color pickers, printer/fax panels, communications objects, etc. Everything you can imagine is already there. The advantage is really clear when the same code that works on your OpenStep/Mac compiles and works the same on Windows NT. Again, OpenStep takes care of all the objects for Windows NT and gives you a common interface. The advantage to OpenStep is all the code that you DON'T have to write. Imagine not changing a single line of code and yet being able to compile your programs on Multiple operating systems. That is how OpenStep can help. I hope this helps. Scott Keith ____________________________________________________________________ OPENBASE INTERNATIONAL LTD. http://www.openbase.com 58 Greenfield Road e-mail: info@openbase.com Francestown, NH 03043 USA TEL: 603.547.8404/FAX: 603.547.2423 From tomi at shinto.nbg.sub.org Sat Apr 12 07:10:27 1997 From: tomi at shinto.nbg.sub.org (Thomas Engel) Date: Thu Nov 3 14:40:21 2005 Subject: C++ ? ObjC ? Java ?.. you can program whatever you want ! In-Reply-To: References: Message-ID: <9704121410.AA01368@shinto.nbg.sub.org> > The issue isn't interoperability, the issue is compatibility. Is it > possible in OpenStep now to use C++ *syntax* to access Objective-C objects? > In other words, do I *have* to use [someObject someMessage:anArg] to send a > message to an Objective-C object, or can I accomplish the same thing with > someObject->someMessage(anArg)? Can I subclass an Objective-C class in C++? > Its a common problem with NextStep since people always miss a little detail that makes so much of a difference. OpenStep Frameworks really _are_ the operating system. (at least they are a core part of the systems functionality and the same objects come with every machine and therefor are core OS features) IMHO this is a very crucial point when we talk about Rhapsody. Its not the BSD C APIs or the Mach C function bindings or direct DPS context communication which we should consider as the OS API...its OO frameworks which are written in a specific language (here ObjC) and therefore can be accessed naturally using that language. Now nobody seems to have a problem that early systems used stack based trap style OS APIs to access OS functionitly. There it seems just natural to everybody that in order to use C++ you need C++ frameworks to shield you from low level communications with the OS. (since that MAc was Pascal in the early days...you still have to pass Pascal strings when doing C++... or you have some wrappers which take care of the conversion) Now think of the C++/ObjC interoperability as the low level communication but if you want to do C++ only you need a C++ framework that shields you from pure OO communication (wreaps those "ugly" ObjC messages) Using ObjC has the benefits that you can easily customize the operating system since you can replace or remap certain OS behavior jsut natureally. C++ lacks certain features that ObjC offers at the language level so you need some meta-programming to solve these issues and you need a "smart" C++ compiler which knows who to generate code blocks that can 2patch" your system (which would mean repackage in an operating system conform runtime fashion...which happens to be the ObjC runtime) > I don't have a problem with using or learning Objective-C to develop for > Rhapsody, but many other people appear to want to actually use C++ to > program Rhapsody, not just to program the non-interface portions of their > apps. The "none-interface" argument always comes from the fact that there are (yet) no C++ wrappers for the operating systems (OpenStep ObjC) frameworks. Since C++ and ObjC integrate quite nicely...and the ObjC tools enable rapid GUI development most people took the "interoparability" route. You are free to write a C++ wrapper to the AppKit...and MetroWorks will propably offer a C++ framework which sits on top of the ObjC classes and not the core C-function services of Rhapsody. Not sitting on top of the operating system objects (which happen to be ObjC) would require to dublicate multilanguage support, window handling, etc. pp. This programming language confusion seems to be really big. This is why Apple emphazized the "Java" mappings and "Java" programming. Even Java has to interface to the operating systems...but since there is a simple way to map ObjC to Java programming in Java is a very natural thing under Rhapsody. So Java gives you "Java-OS-wrappers" almost for free... ...while C++ does not. C++ just offers easy interoparability and it takes a good C++ framework to shield you from "low-level OS communication" (using ObjC code). So what if Apple called their OS. "The first PDO-based OO OS". (replace PDO with CORBA to get it sound "hype-right"...or call it ObjC-runtime to get it technically more corerct). Now lets say Apple currently only offers an ObjC binding to the PDO-language-neutral system object model (yet another SOM system). Interestingly ObjC interfaces very well with Rhaspodies object runtime since all frameworks happen to be in ObjC and the OS'es runtime uses the same features. Which means a 100% OS object model to programming language mapping (similar to Java-OS/VM + Java). Now if you have a "Direct-To-PDO" C++ compiler things would be just fine. Wouldn't they ? I personally don't understand the "language" confusion which seems to be worrying Mac developers that much. There was Lisp, Smalltalk, Eiffel, Oberon, Scheme, and many more.. available for NextStep and you could write applications. No matter which language (read "object model") Apple would have picked for its next OS...usually its "natural" OS language which is the most elegant for the system (like PAscal for the Mac) until the other language tools and frameworks managed to wrap all OS services. Rhapsody developers will be able to program in any language they want once the tools have been ported, but ObjC and Java (and other dynamic OO languages like Smalltalk) should be the most natural. To summerize it...take a look at Rhapsodies "assambly" language (ObjC)...if its doesn't meet your requirements...use a different language. Aloha Tomi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 5156 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970412/294c28ab/attachment.bin From zander at conextions.com Sat Apr 12 11:03:18 1997 From: zander at conextions.com (Aleksey Sudakov) Date: Thu Nov 3 14:40:21 2005 Subject: Rhapsody will feature _Java_ APIs In-Reply-To: <9704121011.AA00633@QuickBase.com> References: <9704121011.AA00633@QuickBase.com> Message-ID: <9704121803.AA01879@conextions.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 600 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970412/76fcadc0/attachment.bin From stark at easynet.fr Fri Apr 11 05:38:02 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology References: Message-ID: <9704111238.AA00287@easynet.fr> > At least that was the impression that I got of the Part > Merchant stuff. Are there "hooks" in the Objective-C > runtime that would allow for similar things with finer > granularity? (Such as automatically querying a license > server when you want to create an instance of a particular > class.) As trivial as in C++ or java: /* Naive implementation. Will loose one not fully inited instance per unsucessful license test */ @implementation MyClass + (void)checkLicense { static BOOL first = YES; if (first && !/* Do what is needed to check the license */) { [NSException raise:@"LicenseException" format:@"No license for class %@", [self class]]; } first = NO; } - init { [super init]; [[self class] checkLicence]; // Init the instance return self; } @end [It'll take a dozen of seconds with gdb to crack, but this is not the point] Cheers, --fred PS: Does the from address of my mails are wrong ? From Peter_Graffagnino at next.com Sat Apr 12 13:56:08 1997 From: Peter_Graffagnino at next.com (Peter Graffagnino) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology Message-ID: <9704122056.AA02856@oz.next.com> >From a business point of view, I think the status quo, in which these things are yet to be revealed, is a no-go, for small businesspeople anyway. Apple is totally committed to the cross platform story for the OPENSTEP APIs. We are continuing to invest in the Windows NT/95 implementation to make it a viable substrate for ISVs. Come to WWDC and hear the details (http://devworld.apple.com/mkt/WWDC/index.html)... Peter From dbulman at gte.net Sat Apr 12 14:59:19 1997 From: dbulman at gte.net (David Bulman) Date: Thu Nov 3 14:40:21 2005 Subject: Objective-C on Macintosh Message-ID: SB wrote >It seems to me that the problem isn't Objective-C itself, but the fact >that there don't seem to be any programming environments for anything >but OpenStep. At least one Objective-C compiler _is_ available for the Macintosh. For about $150, you can buy CodeBuilder from Tenon It is a very much simplified version of their MachTen Unix, with most of the networking, TCP, etc removed. Basically, it is enough of MachTen to compile programs written in Objective-C, C, C++, Ada, Fortran, and Java. I bought it for Ada and Objective-C. I have used it to compile double-clickable MacOS applications in Ada. So far, I have only compiled and run sample Objective-C code from the CD, but it only runs under the CodeBuilder version of Unix so far. There is a way to compile double-clickable MacOS applications in Objective-C, but due to my ignorance, I have not yet figured it out. For those few of you who might not know about MachTen, it is a Unix which runs alongside MacOS on Macs. CodeBuilder only runs on Power Mac, not 68K machines. Dave %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% David Bulman Hawaii house for sale From J_FREY at LVC.EDU Sat Apr 12 15:49:34 1997 From: J_FREY at LVC.EDU (JEFFREY T. FREY) Date: Thu Nov 3 14:40:21 2005 Subject: Metrowerks? Message-ID: <970412184934.ff157@LVC.EDU> Has anybody tried to check out the MetroWerks site lately? I keep getting DNS errors when trying to look it up? Are they out of business? -Jeff From abridge at wheel.dcn.davis.ca.us Sat Apr 12 17:13:07 1997 From: abridge at wheel.dcn.davis.ca.us (Adam Bridge) Date: Thu Nov 3 14:40:21 2005 Subject: Error handling and console services Message-ID: <199704130012.RAA27639@wheel.dcn.davis.ca.us> I spoke about what I WANTED over on Semper.Fi but I didn't bother to check out what NextStep/OpenStep currently offer with regard to having a system console where non-ephemeral messages are logged, and system-wide error logging tools. One of the the things I've always disliked about the Mac is the way errors are displayed only in windows and not actually recorded anywhere. Certainly a part of this is a lack of robustness in the OS but another part is a design philosophy. How does Next deal with these issues? Is there a place, a window with a memory, where I can write messages? Is there an error log? Is there a crash-dump file and tools to read it? Are these standard parts of the OS that users can have access to? Thanks! Adam Bridge From lukeh at xedoc.com.au Sat Apr 12 17:30:37 1997 From: lukeh at xedoc.com.au (Luke Howard) Date: Thu Nov 3 14:40:21 2005 Subject: Error handling and console services Message-ID: <199704130030.KAA26631@alpha.xedoc.com.au> >One of the the things I've always disliked about the Mac is the way >errors are displayed only in windows and not actually recorded anywhere. Messages are logged using syslog(3), a standard library call in the Unix operating system. The syslog daemon (syslogd) receives these messages (which are categorised into different facilities and log levels) and diverts them to the appropriate log file, console, etc. There's also a NSLog() utility function, which accepts an NSStrings as an argument; as far as I know, it only logs to the standard error. I'm sure there's an Objective-C wrapper around syslog(3) somewhere. >Certainly a part of this is a lack of robustness in the OS but another >part is a design philosophy. How does Next deal with these issues? Is >there a place, a window with a memory, where I can write messages? Is >there an error log? Is there a crash-dump file and tools to read it? Workspace can bring up a console window. You can use gdb to examine core dumps, and to attach to kernels running on remote machines. -- Luke From don at misckit.com Sat Apr 12 18:03:45 1997 From: don at misckit.com (Donald A. Yacktman) Date: Thu Nov 3 14:40:21 2005 Subject: Error handling and console services In-Reply-To: <199704130030.KAA26631@alpha.xedoc.com.au> References: <199704130030.KAA26631@alpha.xedoc.com.au> Message-ID: <9704130103.AA18144@misckit.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2309 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970412/09ae42fb/attachment.bin From sterling at rahul.net Sun Apr 13 12:12:23 1997 From: sterling at rahul.net (Brian Sterling) Date: Thu Nov 3 14:40:21 2005 Subject: Metrowerks? In-Reply-To: <970412184934.ff157@LVC.EDU> Message-ID: At 3:51 PM -0700 4/12/97, JEFFREY T. FREY wrote: >Has anybody tried to check out the MetroWerks site lately? I keep getting >DNS >errors when trying to look it up? Are they out of business? I haven't had any trouble lately. In fact, I just tried it and got right in. Maybe there's something wrong with you DNS setup? --- Brian Sterling sterling@rahul.net http://www.rahul.net/sterling/ From mont at echidna.doverpacific.com Sun Apr 13 14:59:53 1997 From: mont at echidna.doverpacific.com (Mont Rothstein) Date: Thu Nov 3 14:40:21 2005 Subject: OpenStep Runtime explained Message-ID: <3.0.32.19970413145953.009459c0@doverpacific.com> Since there seems to be alot of confusion regarding the OpenStep runtime, I thought I'd try explaining it so we can get on with discussing Rhapsody Development. The OpenStep runtime is a combination of the following things: 1) A set of libraries that implement the OpenStep specification (and in NeXT's case a little more 2) A run-time for binding objects, interprocess communication, paste board services (cut and paste support), etc. 4) Display PostScript (DPS) enviornment. Regardless of the platform or OS you need these pieces to run fully graphical OpenStep applications. If you wish to run non-graphical apps then you can leave off the DPS and some of the libraries. Now under Rhapsody these will all be included as part of the standard OS. Under Windows NT/95 they break down into the following: I) A collection of DLLs that reside under $(NEXT_ROOT). These same DLLs can and will be accessed by all OpenStep applications. (i.e. each OpenStep app does not need its own copy of the DLLs). II) Four processes the comprise the total run-time enviornment. Two of these processes are non-graphical and are started as services when the machine starts, and two are associated with the user interface and are usually started when the user logs in. In both cases these processes are used by all OpenStep applications. (i.e. there is only one instance of each process runing at a time on a given machine). These processes are: machd - Mach Deamon nmserver - Network Messaging Server pbs - Paster Board Service Window Server - Display Post Script OpenStep User Enviornment - This is a combination of the OpenStep runtime as outlined above along with a collection of applications that use this enviornment. These apps include an editor, drawing application, postscript and tiff file viewing application, and some other usefull apps. While many of us like to use these applications, they are not required to run OpenStep applications, and they are not part of the OpenStep specification. Now there are currently three ways that these pieces are being distributed. The first is by Apple(NeXT) as part of the OpenStep/Mach operating system. This is how they will be distributed for Rhapsody. The second is as the OpenStep User Enviornment, or "OpenStep Enterprise Deployment" as it is now being called. The third mechansim is as embeded technology along with 3rd party applications. In this case the 3rd party installation program could check to see if the necessary pieces are already installed (in the correct versions) and if they are then not install them. Currently there is a fee associated with the runtime. This fee is much higher than the licensing fees that NeXT pays to other companies (under NT I think that may be only Adobe and Intel, but I'm not certain). They (NeXT) have felt in the past that the run-time fee was valid given the productivity gains of the development enviornment. Remember they were not aiming at 3rd party apps as much as corporate custom applications. Apple may or may not change their postion on this, and thus their pricing. Finally some brief comments on cross-platform development. The OpenStep specification provides a wrapper around the majority of operating system dependint calls that would normally be made. It also includes what many of us believe is the best library going for application development. This means all most all the common things that most applications need are already provided for you. So, from an aspect of writing apps that will work under Rhapsody and NT/95 OpenStep will give you a major step in that direction. In some cases you won't have to change a single line of code or have a single #ifdef to run on both platforms, there are a few cases where OpenStep is lacking from a cross platform standpoint, and thus it is not always 100% compatible. I hope this was helpful, -Mont From stark at easynet.fr Fri Apr 11 18:43:08 1997 From: stark at easynet.fr (stark@easynet.fr) Date: Thu Nov 3 14:40:21 2005 Subject: Error handling and console services References: <199704130012.RAA27639@wheel.dcn.davis.ca.us> Message-ID: <9704120143.AA00744@easynet.fr> > One of the the things I've always disliked about the Mac > is the way errors are displayed only in windows and not > actually recorded anywhere. Certainly a part of this is > a lack of robustness in the OS but another part is a > design philosophy. How does Next deal with these issues? > Is there a place, a window with a memory, where I can > write messages? The NSLog() function logs a message in OPENSTEP. From 4.2 release notes: Where Do NSLog()'d Messages Go? NSLog() and NSLogv() do not log an error message to stderr, as stated in the documentation. On HP-UX, Solaris, and Mach, it writes the log to STDERR_FILENO if the file descriptor is open. If that fails, the message is sent to the syslog subsystem, if it exists on a platform, with the LOG_USER facility (or default facility if LOG_USER doesn't exist on a platform), with priority LOG_ERR (or similar, depending on what the platform supports). If both of these attempts to write the message fail, the message is discarded. On Windows platforms, the message is written to the STD_ERROR_HANDLE, if that handle is valid, on Windows platforms that support that standard handle. It is also written to the Windows Event Log on Windows platforms that support the Event Log, or to the file c:\fndation.log on Windows platforms that do not, if that file can be opened. If all of these attempts fail, the message is discarded. On some Windows platforms, the message to the Event Log may be truncated if there is a limit to the size of a message that the Event Log can accept. On Windows platforms that support an application discovering whether or not it is running under a debugger, NSLog() and NSLogv() may only send the message to the debugger for its handling, via standard WIN32 mechanisms, and not also write the message to STD_ERROR_HANDLE and the Event Log. Note that a debugger may choose to not display messages thus sent to it, or may choose not to display all of the message-NSLog() and NSLogv() have no control over that. Output from NSLog() and NSLogv() is serialized, in that only one thread in a process can be doing the writing/logging described above at a time. All attempts at writing/logging a message complete before the next thread can begin its attempts. The effects of NSLog() and NSLogv() are not serialized with other subsystems than those discussed above (such as the standard I/O package) and do not produce side effects on those subsystems (such as causing buffered output to be flushed, which may be undesirable). The format specification allowed by NSLog() and NSLogv() is that which is understood by NSString's formatting capabilities. That is not necessarily the set of format escapes and flags understood by printf(), as mentioned in the documentation. > Is there an error log? > Is there a crash-dump file and tools to read it? > Are these standard parts of the OS that users can have access to? Those are implementation details :-) (Actually YES, YES and YES under current OPENSTEP implementations. So we can guess the answers would be the same for Rhapsody) Cheers, -- fred From joel at yinu.co.jp Sun Apr 13 21:50:09 1997 From: joel at yinu.co.jp (Joel Floyd) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody Message-ID: At 5:40 AM 97.4.11, Scott Keith wrote: >The version of OpenStep for Japan (which includes the two-byte character >set) simply has a different > version of the shared libraries -- the API is the same. Therefore, your >program can be written on >"normal" OpenStep and run on OpenStep for Japan without any changes. >Your program simply calls > methods that work slightly differently for each version of OpenStep. Does anyone know how to create the Front End language Processor (FEP) in OpenStep for languages like Chinese and Japanese. That is what we create now; and in Japan its a fairly large market, with three or four different companies competing to provide language services on the Mac. Joel From joel at yinu.co.jp Sun Apr 13 22:36:15 1997 From: joel at yinu.co.jp (Joel Floyd) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology Message-ID: At 9:43 AM 97.4.11, Ernest N. Prabhakar wrote: >HOWEVER, the technical aspects of licensing are important. I am curious >what Apple developers are used to, and lokoing for. I am not even sure >what the current state-of-the-art is on OpenStep. Cost is nothing except for the tools like CodeWarrior, absolutle no run-time cost for the basic stuff. Quicktime, other system extensions do or can cost and depend on Apple and whether your a member of Apple's developer program or not. When your license something from Apple it usually goes out in bulk, like $500 per 1000 shipped. The license fees last a year. >Under NeXTSTEP, there were several common schemes: > - license to CPU, where the app was bound to the Ethernet address > - license to network user, where the app was bound to a username > - floating network license, wher so many apps could run on the local LAN > at any one time Sun also does this; and I hate it--> this make the machine extremely unmovable and static (IMHO). Bacially you have to rely on trust =:-0 Some software like Photoshop search the network looking for serialized copies; Others like Quark Express use dangals or harware attachments to protect their software. >Are Mac developers even used to thinking in those terms? I believe there were >one or two commercial LicenseKit type thigns which handled these schemes. >It may have also included the "demo" mode, where an App would weither not >save/cut/paste or expire after 15 minutes until you entered the registration >key. All developers are trying something, the problem lies in the fact that it is so easy to copy and can be so valuable. No one thinks of coping a book, maybe pieces; a movie, well maybe, but after you have seen it 10-times it kinda gets old; Software -- always usable and the easist to copy. Joel From Kazuo_Tsubaki at next.com Mon Apr 14 02:24:26 1997 From: Kazuo_Tsubaki at next.com (Kazuo Tsubaki) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody References: Message-ID: <9704140924.AA09581@toto.NeXT.COM> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 517 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970414/6781eca8/attachment.bin From kjray at ix.netcom.com Mon Apr 14 09:00:56 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:21 2005 Subject: Apple in SJ Merc, again. Message-ID: <199704141602.LAA01320@dfw-ix11.ix.netcom.com> If you are a MacOS developer who is optimistic about Rhapsody, feel free to write to SJ Mercury News in rebuttal to // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From waltrip at aurora.jhuapl.edu Mon Apr 14 10:24:59 1997 From: waltrip at aurora.jhuapl.edu (Charles F. Waltrip) Date: Thu Nov 3 14:40:21 2005 Subject: Apple in SJ Merc, again. References: <199704141602.LAA01320@dfw-ix11.ix.netcom.com> Message-ID: <3352686A.C20B77D9@aurora.jhuapl.edu> Ray wrote: > > If you are a MacOS developer who is optimistic about Rhapsody, feel > free to write to SJ Mercury News in rebuttal to > > Thanks for calling attention to this. I am optimistic about Rhapsody but am also concerned. I felt the article addressed my concerns and hope that it stimulates Apple to do so as well. The fact that they interviewed Andrew Stone impressed me that they got to at least one of the "good guys" and, if they got one right, maybe they got to a good cross-section. Rhapsody will BE great. OpenStep IS great. NEXTSTEP WAS great. But history tells us that ain't enough. The writer of this article knows a little history, I would guess. Thanks again. Chuck From Mike_Ferris at next.com Mon Apr 14 10:29:42 1997 From: Mike_Ferris at next.com (Mike Ferris) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody Message-ID: <9704141729.AA15841@oz.next.com> The doc is a little sparse for this currently, but what you're looking for is the NSTextInput protocol and the NSInputManager and NSInputServer classes. Header files may be the best you can hope to find about it for now, although I believe there may be some example code on the release as well for a simple input manager or two. Mike Ferris OpenStep Application Frameworks From blenko-tom at CS.YALE.EDU Mon Apr 14 10:35:21 1997 From: blenko-tom at CS.YALE.EDU (Tom M. Blenko) Date: Thu Nov 3 14:40:21 2005 Subject: Apple in SJ Merc, again. In-Reply-To: <199704141602.LAA01320@dfw-ix11.ix.netcom.com> References: <199704141602.LAA01320@dfw-ix11.ix.netcom.com> Message-ID: <9704141735.AA10489@ruebezahl.cs.yale.edu> > If you are a MacOS developer who is optimistic about Rhapsody, feel free > to write to SJ Mercury News in rebuttal to > < ...and if you agree 100%? I posted a message with the same thrust to this list just a few days ago. An Apple/NeXT employee replied: wait until next month (my paraphrase). How in God's name does one plan products when one doesn't know, for example, what the cost of the supporting run-time system will be? I repeat: Apple needs to get way out ahead of this one, all the more so because of the overhang of the experience developers had with NeXT. Their developers are very important customers. Tom From izumi at pinoko.berkeley.edu Mon Apr 14 11:06:40 1997 From: izumi at pinoko.berkeley.edu (Izumi Ohzawa) Date: Thu Nov 3 14:40:21 2005 Subject: International support in Rhapsody In-Reply-To: <9704141729.AA15841@oz.next.com> Message-ID: <199704141806.LAA06094@moica.berkeley.edu> On Mon, 14 Apr 97, Mike Ferris wrote: > The doc is a little sparse for this currently, but what you're looking > for is the NSTextInput protocol and the NSInputManager and NSInputServer > classes. Header files may be the best you can hope to find about it for > now, although I believe there may be some example code on the release as > well for a simple input manager or two. At one time (around 92/93), Hironobu Suzuki at SRA in Tokyo released an alternative input manager for NS3.x-J called YaCaN (his personal project not related to work at SRA), which provided a NEXTSTEP frontend to a popular kanji input system "canna". This was a binary-only release for black hardware, but I believe he indicated a possibility of releasing source upon request privately. I have no idea how similar the new OS ImputManager API is from that of NS3.X-J, but it might be worth a look if he is willing to release the source. I understand that he doesn't do NS or OS dev. any more. I. From gad at eclipse.its.rpi.edu Mon Apr 14 11:59:01 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:21 2005 Subject: Licensing technology References: Message-ID: <9704141859.AA26222@eclipse.its.rpi.edu> joel@yinu.co.jp (Joel Floyd) wrote: > At 9:43 AM 97.4.11, Ernest N. Prabhakar wrote: > > HOWEVER, the technical aspects of licensing are important. I > > am curious what Apple developers are used to, and looking for. > > I am not even sure what the current state-of-the-art is on > > OpenStep. > > > Under NeXTSTEP, there were several common schemes: > > - license to CPU, where the app was bound to the Ethernet address > > - license to network user, where the app was bound to a username > > - floating network license, wher so many apps could run on the > > local LAN at any one time > > Sun also does this; and I hate it--> this make the machine > extremely unmovable and static (IMHO). > > Bacially you have to rely on trust =:-0 Some software like > Photoshop search the network looking for serialized copies; Others > like Quark Express use dangals or hardware attachments to protect > their software. For the public MacLabs at RPI, we use something called KeyServer. It works fairly well. See: http://www.sassafras.com/ Note that this does imply that the software developer trusts (to some extent) the administrator of a group of Macs or PC's. Still, some companies do, and this allows us (RPI) to make sure we are staying within our licensing agreements, and yet it does not put too many onerous restrictions on how we use or deploy the various applications. A recent interesting development is that some companies (well, Adobe at least, maybe some others) trust this keyserver app. If you are using keyserver, the application does not do it's usual protection schemes. Sassafras (the company) has Keyserver clients for both Macs and Windows boxes. I have no idea how readily their technology could be adapted for use with OpenStep. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From owolf at pdnt.com Mon Apr 14 13:05:43 1997 From: owolf at pdnt.com (owolf@pdnt.com) Date: Thu Nov 3 14:40:21 2005 Subject: Fear and loathing in Appleland: was Apple in SJ Merc again Message-ID: <199704141902.OAA13320@tempest.pdnt.net> >If you are a MacOS developer who is optimistic about Rhapsody, feel free >to write to SJ Mercury News in rebuttal to > > > > > // Keith and Jane Or write them to congratulate them on an even-handed, well-written article on the current state of Apple-developer relationships. Sorry, but this article is NOT another ignorant diatribe against Apple. The developers quoted in the article, Peter Jensen, the author of Cocoa and Peter N. Lewis, the proliferic author of many Mac shareware programs are not no-names that the author dredged up from nowhere just because they had negative comments about Apple. I'm sorry, but when Peter N. Lewis complains about the lack of communication from Apple about their plans then APPLE BETTER WAKE UP AND DO SOMETHING! Sorry about the shouting but my patience is wearing thin with Apple. Scott Johnson From russ at scheria.odyssey.com Mon Apr 14 12:58:12 1997 From: russ at scheria.odyssey.com (Russell Schissler) Date: Thu Nov 3 14:40:21 2005 Subject: Fear and loathing in Appleland: was Apple in SJ Merc again References: <199704141902.OAA13320@tempest.pdnt.net> Message-ID: <9704141958.AA12845@scheria.odyssey.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 91 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970414/9d9917a7/attachment.bin From toon Mon Apr 14 17:09:14 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:22 2005 Subject: NSThread, NSTimer and NSRunLoop In-Reply-To: <9704112244.AA00783@akina.jpl.nasa.gov> References: <9704112244.AA00783@akina.jpl.nasa.gov> Message-ID: <9704150009.AA02252@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1657 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970414/fa6962d4/attachment.bin From owolf at pdnt.com Mon Apr 14 23:08:41 1997 From: owolf at pdnt.com (owolf@pdnt.com) Date: Thu Nov 3 14:40:22 2005 Subject: Fear and loathing in Appleland: was Apple in SJ Merc again Message-ID: <199704150505.AAA17094@tempest.pdnt.net> I sent my reply to both Rhapsody-dev and Semper-Fi because: 1. The original post appeared on Rhapsody-Dev and I wanted to reply to it, although I did know that it wasn't really apropo to the list charter I wanted my opinion to appear there.I planned to continue any further discussion on Semper.fi because I thought that was the place to discuss such an issue (sorry I didn't put my intention in the original post). 2. I sent it to the Semper-Fi mailing list because the SJ Merc article discussed Apple- developer relationships, which IS apropo to the list charter of Semper-Fi. At least as far as I understand Sorry if I caused any consernation. Now, list-mom, may I please post to Semper-Fi on this issue henceforth? Scott Johnson From mtarbell at akina.jpl.nasa.gov Tue Apr 15 10:19:36 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:22 2005 Subject: NSThread, NSTimer and NSRunLoop In-Reply-To: <9704150009.AA02252@omnigroup.com> References: <9704150009.AA02252@omnigroup.com> Message-ID: <9704151719.AA00638@akina.jpl.nasa.gov> Hi Greg, Thanks for your reply. > The solution is to modify your event queue only in a single > long-lived thread ... provide an -addEvent: method which > inserts the event into the queue and resets the timer ... ...all from the same thread? I don't see how my queue's -addEvent: method can always be executed in the same long-lived thread. How could -addEvent: ever be issued again to add more events? How do you call a method already running in a thread? Instead, all I can think of is to _not_ modify the queue in a single long-lived thread, but rather have an NSConditionLock which is set by other short-lived threads calling -addEvent:, and have the single long-lived thread simply wait on that. When the condition of the lock changes, the long-lived thread recalculates the timer (and potentially executes an event in its own thread). Did I miss what you were saying? Thanks Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From sebestyen_g at usa.net Tue Apr 15 11:29:47 1997 From: sebestyen_g at usa.net (Gabriel Sebestyen) Date: Thu Nov 3 14:40:22 2005 Subject: File types in Rhapsody Message-ID: <3353C91B.C1E72497@usa.net> Hi! What would be the right way of the identification of the file types ? a., general solution (UNIX/Win/etc.): by filename extension. b., Macintosh solution: by a four-letter app/subtype integrated into the file's data fork (Do I know well? :-] ) c., A third way is, for example, the MIME content types (Well, Microsoft knows the future when this one is the part of Win95/NT)? What's your oppinion? Gabriel From toon Tue Apr 15 13:46:36 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:22 2005 Subject: NSThread, NSTimer and NSRunLoop In-Reply-To: <9704151719.AA00638@akina.jpl.nasa.gov> References: <9704151719.AA00638@akina.jpl.nasa.gov> Message-ID: <9704152046.AA15080@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2576 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970415/a397ec9a/attachment.bin From gad at eclipse.its.rpi.edu Tue Apr 15 13:54:45 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:22 2005 Subject: File types in Rhapsody - discuss in rhapsody-talk References: <3353C91B.C1E72497@usa.net> Message-ID: <9704152054.AA03299@eclipse.its.rpi.edu> > Hi! > > What would be the right way of the identification of the file > types ? Given that this is mainly a question of personal opinion (as many people have different opinions on what is the "right" way...), and as anything we say now is pretty much just speculation based on NeXTSTEP or the MacOS, I'd think this topic should be discussed on the rhapsody-talk@omnigroup.com mailing list... > a., general solution (UNIX/Win/etc.): by filename extension. > b., Macintosh solution: by a four-letter app/subtype integrated > into the file's data fork (Do I know well? :-] ) > c., A third way is, for example, the MIME content types (Well, > Microsoft knows the future when this one is the part of > Win95/NT)? > What's your opinion? While I'm glad to ramble on about my opinions, our speculation is not going to help anyone write code. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From mtarbell at akina.jpl.nasa.gov Wed Apr 16 10:07:22 1997 From: mtarbell at akina.jpl.nasa.gov (Mark Tarbell) Date: Thu Nov 3 14:40:22 2005 Subject: NSThread, NSTimer and NSRunLoop Message-ID: <9704161707.AA00990@akina.jpl.nasa.gov> Greg, >> How do you call a method already running in a thread? > By using DO between the threads: Actually, this was quite similar to my original design. The problem is that here at JPL we've already committed to the Sun Solaris environment for many of the pieces of this Deep Space Network project, so what I design must be compatible with that, i.e., it has to work on OpenStep for Solaris, not just on OpenStep for Mach. So, I'm forced to design for the lowest common denominator, OpenStep for Solaris. There's a HUGE bug in OpenStep for Solaris which disallows heavy usage of DO's and NSThreads. Apparently, under the Solaris implementation, every new thread that does DO's actually uses 2 threads with a pipe between them. But the secondary thread never gets messaged to go away when the first thread exits. Resources get used up rapidly from all of the zombie threads; only about a dozen events go through before thread, pipe, and file resource limitations blow the process away. This same bug doesn't seem to exist on OpenStep for Mach. Thanks for your help, Greg. Mark -- Mark Tarbell (Mark.A.Tarbell@jpl.nasa.gov) NeXTmail/MIME accepted Applications Development Section Information Systems Development and Operations Division Engineering and Science Directorate Jet Propulsion Laboratory From kjray at ix.netcom.com Wed Apr 16 13:20:21 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:22 2005 Subject: java reflection/resources/etc. Message-ID: <199704162022.PAA12611@dfw-ix12.ix.netcom.com> The slides from the JavaOne session "JavaTM Advanced Programming Tutorial" (TT29) had some interesting info about reflection, nested (named/unnamed) classes, resources, and native-code interfaces (including the new standard way of invoking java code from native applications - note that Apple's MRJ provides this ability today in the blue box/system 7-8). Since it looks like Java 1.1 will be a big part of Rhapsody's yellow box, I though I'd provides some URLs that were mentioned in TT29 for those who are interested: For information on the Java language changes in 1.1: http://java.sun.com/products/jdk/1.1/docs/guide/innerclasses/ Core Reflection API: http://java.sun.com/products/jdk/1.1/docs/guide/reflection/ accessing resources: http://java.sun.com/products/jdk/1.1/docs/guide/misc/resources.html To download the coding examples from TT29, browse here: http://java.sun.com/javaone/source.code.html Keith Ray // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From toon Thu Apr 17 13:40:43 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:22 2005 Subject: NSThread, NSTimer and NSRunLoop In-Reply-To: <9704161707.AA00990@akina.jpl.nasa.gov> References: <9704161707.AA00990@akina.jpl.nasa.gov> Message-ID: <9704172040.AA22183@omnigroup.com> A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 3867 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970417/b350a1db/attachment.bin From chuq at apple.com Sat Apr 19 08:57:07 1997 From: chuq at apple.com (Chuq Von Rospach) Date: Thu Nov 3 14:40:22 2005 Subject: Fear and loathing in Appleland: was Apple in SJ Merc again In-Reply-To: <199704150505.AAA17094@tempest.pdnt.net> Message-ID: At 11:08 PM -0700 4/14/97, owolf@pdnt.com wrote: >I sent my reply to both Rhapsody-dev and Semper-Fi because: > > 1. The original post appeared on Rhapsody-Dev and I wanted to reply >to it, although I did >Sorry if I caused any consernation. Now, list-mom, may I please post to >Semper-Fi on this issue henceforth? Oops, sorry. This got stuck in my "reply to" folder by a bunch of real work.. Sorry I didn't get back sooner. I am basically opposed to the practice of "joining in" other lists (or newsgroups) in the middle of discussions. At best, the new lists simply lack context (and in many cases, ended up getting jumped on bu suddenly having a running feud crossposted to it out of the blue). It's a good way to get people yelling at ecah other about "get this out of my list!" and the like, not a good way to start discussion or conversation. And if youa void all of that, you still end up with the problem of multiple, parallel, disjoint discussions. Not good. Better to leave a discussion where it starts than try to spread it across multiple lists. If you really feel its' semper.fi fodder, then write up a piece about the topic and start a thread about it. Moving them just doesn't work well. chuq -- Chuq Von Rospach (chuq@apple.com) Apple IS&T Mail List Gnome Plaidworks Consulting (chuqui@plaidworks.com) ( +-+ The home for Hockey on the net) From wjs Sun Apr 20 04:23:43 1997 From: wjs (William Shipley) Date: Thu Nov 3 14:40:22 2005 Subject: NSTextView page breaks? Message-ID: <9704201123.AA24979@omnigroup.com> I'm extending the OpenStep NSText system to do all the things displaying HTML requires of it (like side-aligned images, which were surprisingly easy to do), but I've hit on a stumbling block: I can't figure out a clean way to do insert forced page breaks in the new NSText system. Has anyone done this, or thought about it, or heard of soemone who thought about it? Thanks, -Wil PS: In case you are wondering what forced page breaks has to do with HTML, I'm looking at using a single NSTextStorage with multiple containers to do tables. From robertm at next.com Tue Apr 22 00:49:50 1997 From: robertm at next.com (Robert MacKimmie) Date: Thu Nov 3 14:40:22 2005 Subject: Getting Ahead With Rhapsody Today... (Wednesday, 7pm, Townhall, Cupertino ) BaNG meeting on OPENSTEP Development tools: Message-ID: <9704220749.AA00681@cougar.apple.com> Please inform Rhapsody interested people who are not on these mailing lists. "http://www.bang.org" Bay Area NeXT Group Monthly Meeting: Wednesday, April 23, 1997, 7-9pm, Townhall, Apple Cupertino General public, developers, end-users and employees are invited to attend. OPENSTEP Development Tools: Getting Ahead With Rhapsody Today... The monthly meeting of the Bay Area NeXT Group will be held Wednesday, April 23, 1997, at 7:00 PM, at the Apple Headquarters, R&D Building 4 - Townhall, Infinity Loop, Cupertino, California. This month, two talented OPENSTEP developers share their years of insight into why the Development Tools for OPENSTEP/Rhaspody are amazingly useful; able to create powerful applications quickly and easily. Both developers are nearing completion in ports of their application to OPENSTEP/Rhaspody. Apple bought NeXT for a reason - hear why! Speakers: Stan Jirman, Co-Developer and author of TIFFany II and TIFFany III from Caffeine Software, and Robert Vasvari, creator of RBrowser. TIFFany II by Stan Jirman, is a professional image processing application which takes full advantage of NeXT's Object-Oriented design and multi-threading capability and rivals the capability of Adobe's PhotoShop. Stan will talk about development on OPENSTEP, his port of TIFFany II on NEXTSTEP to TIFFany III on OPENSTEP/Rhapsody and new features included in the forthcoming release. Robert Vasvari, the creator of RBrowser will present: Using Interface Builder to create and extend the Appkit classes. His application Remote Browser (RBrowser) provides access to files on remote UNIX systems with NEXTSTEP graphical interface. While matching the Workspace Manager's file viewer look and feel it provides a uniform interface to distributed file transfer and file related operations, greatly simplifying access and use of files on remote systems scattered across the Internet. After the meeting, join us at a nearby restaurant for dinner. Please visit this page again soon for added links and details on upcoming meetings - . Where to Get More Information * Information: info@bang.org * World Wide Web: "http://www.bang.org" * Telephone: 1.415.487.6237 * Snailmail: BANG, P.O. Box 1731, Palo Alto, CA 94302 How to Get to Apple Townhall, From Carl de Cordova, Internet and Rhapsody Evangelist at Apple Computer: Apple Computer Inc. R&D facility is located at the corner of De Anza and the 280 Freeway in Cupertino. It is a group of 6 large four-story buildings that are located on a road called Infinite loop. Coming North from San Jose on 280, take the Cupertino exit and turn left. If you are coming South on 280 from the upper penisula, you will take the De Anza exit and turn right. Drivers coming South on 101 can cross over to Cupertino on 85, head South on 280 and the first exit will be De Anza, turn right. Once on De Anza and West of the Freeway, you will turn left at the first street light. This is Mariani Blvd. If you keep left, Mariani becomes Infinite Loop. You are now in front of building 6. Keep going until you are in front of building 4 and park your car. If you miss it keep going until it comes back around... that's why we call it Infinite Loop. Town hall is a large auditorium with entrances in the lobby of the R&D 4 building. Come in, have a seat and learn about the NeXT great thing from Apple.... NOTE: Please check these pages for updates and announcements. The date and venue may be subject to change. Copyright 1997 Bay Area NeXT Group Last updated: April 21, 1997. All rights reserved. From sanguish at digifix.com Tue Apr 22 12:55:48 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:22 2005 Subject: Getting Ahead With Rhapsody Today... (Wednesday, 7pm, Townhall, In-Reply-To: <9704220749.AA00681@cougar.apple.com> References: <9704220749.AA00681@cougar.apple.com> Message-ID: <199704221955.PAA02704@digifix.com> Robert MacKimmie wrote: > Robert Vasvari, the creator of RBrowser will present: > Using Interface Builder to create and extend the Appkit classes. > His application Remote Browser (RBrowser) provides access to files on > remote UNIX systems with NEXTSTEP graphical interface. While matching the > Workspace Manager's file viewer look and feel it provides a uniform > interface to distributed file transfer and file related operations, greatly > simplifying access and use of files on remote systems scattered across the > Internet. Does anyone know how to get in touch with Robert Vasvari? I'd love to be able to use RBrowser through a secure connection (like ssh).. From toon Thu Apr 24 11:24:30 1997 From: toon (Greg Titus) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC In-Reply-To: <199704241733.KAA19659@wheel.dcn.davis.ca.us> References: <199704241733.KAA19659@wheel.dcn.davis.ca.us> Message-ID: <9704241824.AA08275@omnigroup.com> Adam Bridge wrote: > It's only three weeks or so until the WWDC when many questions > regarding Apple's implimentation of Rhapsody will be unveiled. > Anyone on this list attending? I'd look forward to meeting NeXT > developers and discovering how to transport my Smalltalk knowledge > and applications over to this new environment. Four of us from Omni will be there. Hope to run into you... I'm curious how many people are planning to attend as well. There is also a NeXT Enterprise Alliance Partner's meeting the day before WWDC - any of the other NeXT people out there planning on going to this? We're trying to decide whether it is worth it to fly down a day early to go to a meeting that starts at 7:30 am (yeek!). I suspect it'll be one of those deals where they try to make you feel important by telling you the same information that is going to be public at the conference just one day later... Anyone have a feeling for what's going to happen there? -Greg From mpinkert at cc.gatech.edu Thu Apr 24 11:47:45 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC Message-ID: <199704241849.OAA07518@lennon.cc.gatech.edu> Greg Titus wrote on 4/24/97 2:26 PM >Anyone have a feeling >for what's going to happen there? I know this is sort of off the topic of the group, but will there be any closed-circuit simulcasts of any of the sessions/tracks like there was last year with the keynote/OpenDoc sessions? I really enjoyed going to my local apple HQ here in Atlanta and being able to see the sessions. -- 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 paulrs at lgs-systems.com Thu Apr 24 11:58:13 1997 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC In-Reply-To: <9704241824.AA08275@omnigroup.com> References: <9704241824.AA08275@omnigroup.com> Message-ID: <9704241858.AA06832@cube> You wrote: > Adam Bridge wrote: > > It's only three weeks or so until the WWDC when many questions > > regarding Apple's implimentation of Rhapsody will be unveiled. > > Anyone on this list attending? I'd look forward to meeting NeXT > > developers and discovering how to transport my Smalltalk > > knowledge and applications over to this new environment. > > Four of us from Omni will be there. Hope to run into you... I'm > curious how many people are planning to attend as well. > > There is also a NeXT Enterprise Alliance Partner's meeting the day > before WWDC - any of the other NeXT people out there planning on > going to this? We're trying to decide whether it is worth it to fly > down a day early to go to a meeting that starts at 7:30 am (yeek!). > I suspect it'll be one of those deals where they try to make you > feel important by telling you the same information that is going to > be public at the conference just one day later... Anyone have a > feeling for what's going to happen there? > > -Greg Greg, We're also considering coming in a day early for the EAP meeting. Actually, we're hoping they will cover everything that will be covered at the WWDC, as it's free. On that note, how does Apple expect to promote development for its platform when the fee for attending this conference, which is really a big networking and rah rah apple meeting, is a thousand dollars. Guy Kawasaki is always going on about how the next great software is coming from some guy in a garage. How many guys in a garage have the grand to blow on this meeting? Regards, Paul --- Paul Summermatter LGS Systems, Inc. paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) From robnewberry at grouplogic.com Thu Apr 24 12:19:54 1997 From: robnewberry at grouplogic.com (Rob Newberry) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC In-Reply-To: <9704241858.AA06832@cube> Message-ID: > On that note, how does Apple expect to promote development > for its platform when the fee for attending this conference, which > is really a big networking and rah rah apple meeting, is a thousand > dollars. Guy Kawasaki is always going on about how the next great > software is coming from some guy in a garage. How many guys in a > garage have the grand to blow on this meeting? Actually, for many of us, it's much more than that. First off, there's a week's worth of hotel rooms. Airfare is expensive, too -- especially if you don't stay through Saturday night, which means an extra two nights of hotel fare. It would cost me at least $2000 to make it, and given the fact that what we learned last year about Copland ended up being worth a big fat zero, I don't think there's any way I can convince my boss (and to some extent myself) that anyone here should go. I'll miss everyone from years past, and I'd sure like to see all the stuff on Rhapsody, but Apple's got to do better about making it cost effective. I don't see how it cost them a $1000 for each individual (since around 4000 are there, the cost per person should go down quite a bit), so the bottom line is Apple is making money on WWDC. Making money is for hardware and software sales. WWDC should be a place where Apple breaks even, and each WWDC attendee should feel like they got their money's worth in education. See above for the net worth of my notes from last year. Rob Rob Newberry Director of Fajita Technology Group Logic, Inc. From sanguish at digifix.com Thu Apr 24 12:30:44 1997 From: sanguish at digifix.com (Scott Anguish) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC In-Reply-To: <9704241824.AA08275@omnigroup.com> References: <9704241824.AA08275@omnigroup.com> Message-ID: <199704241930.PAA14456@digifix.com> Greg Titus wrote: > Adam Bridge wrote: > > It's only three weeks or so until the WWDC when many questions > > regarding Apple's implimentation of Rhapsody will be unveiled. > > Anyone on this list attending? I'd look forward to meeting NeXT > > developers and discovering how to transport my Smalltalk knowledge > > and applications over to this new environment. > > Four of us from Omni will be there. Hope to run into you... I'm > curious how many people are planning to attend as well. > > There is also a NeXT Enterprise Alliance Partner's meeting the day > before WWDC - any of the other NeXT people out there planning on > going to this? I'll definately be there, and at the WWDC as a whole.. > We're trying to decide whether it is worth it to fly > down a day early to go to a meeting that starts at 7:30 am (yeek!). I > suspect it'll be one of those deals where they try to make you feel > important by telling you the same information that is going to be > public at the conference just one day later... Anyone have a feeling > for what's going to happen there? > > -Greg From jordan at apple.com Thu Apr 24 12:54:41 1997 From: jordan at apple.com (Jordan Dea-Mattson) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC Message-ID: <199704241955.MAA08634@scv4.apple.com> Dear Ron - As someone who is in the middle of ADR (Apple Developer Relations) and very involved in working on WWDC, I can assure you that Apple is not making a dime on WWDC. Actually, we are losing money. If you have never been involved in a big event (and I was not until I worked in ADR), you would be suprised at all the various costs that are involved. First, there is the venue. AV equipment rental. Bringing in network connections. Then AV crews. Then food. Then power (yes, they actualy charge you for the electricity - with a big mark up - that you use). Then the goody bag. Then this and that. It is pretty amazing. You pay to have stuff taken off your trucks and to be taken to your booth and then for the trash that is taken out (at an hourly rate that probably rivals what the best of us make), with each and everyone being a separate bill. It is truly amazing, but it is also why people like to have convention centers. They generate a LOT of business. By way of compairson, last year I went to Java One and for three days paid $1,000.00. I am sure that Sun was not making money off of me. That is what it costs to put on an event like this one.... Yours, Jordan ==== PS. If you can make it to WWDC, then please do check out the Web Casts that we will be putting on. Jordan J. Dea-Mattson Senior Evangelist Tools & Utilities Apple Computer, Inc. 1 Infinite Loop, MS: 303-2EV Cupertino, CA 95014 408-974-4601 (Phone) jordan@apple.com From jocke at rat.se Thu Apr 24 15:39:58 1997 From: jocke at rat.se (Joakim Johansson) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC Message-ID: <9704242240.AA00241@isdn-jocke.rat.se> Greg Titus wrote: > I'm curious how many people are planning to attend as well. We'll send four people there - it's so cold here in Sweden right now so we need to thaw up our development team a bit to get things going... ;-) > There is also a NeXT Enterprise Alliance Partner's meeting the day > before WWDC - any of the other NeXT people out there planning on > going to this? Probably, if it's open to all EAP members... ;-) Is there any public information available, or is it just that we're not located in north America that makes us miss out information about this? (anyone out there with positive experiences dealing with any software vendors European offices, or have we just had bad luck?) Oh well, nothing new under the sun.. Joakim -- Joakim Johansson Software Engineer, Research & Trade jocke@rat.se http://www.rat.se/ From chuston at ibm.net Fri Apr 25 02:29:19 1997 From: chuston at ibm.net (Chris Huston) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC (from Denver) Message-ID: <3360796F.7B78@ibm.net> Greg Titus wrote: > > Adam Bridge wrote: > > It's only three weeks or so until the WWDC when many questions > > regarding Apple's implimentation of Rhapsody will be unveiled. > > Anyone on this list attending? I'd look forward to meeting NeXT > > developers and discovering how to transport my Smalltalk knowledge > > and applications over to this new environment. > > Four of us from Omni will be there. Hope to run into you... I'm > curious how many people are planning to attend as well. > I will be attending. (Been lurking all this time, so here's a little intro... I've been doing NEXTSTEP programming since 1991, weened on DBKit, I'm an independent consultant in Denver where 60% of my income comes from NeXT related work.) I believe many of you know Russ Schissler, he's planning on attending also. - Chris Huston From lbotez at cs.wisc.edu Fri Apr 25 08:46:28 1997 From: lbotez at cs.wisc.edu (Lynda Botez) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC Message-ID: If you can't afford WWDC, look into going to MacHack, scheduled for June 26-28th, in Dearborn, Michigan. This is the 11th Annual conference. It's only $425 (if you register before May 1st), and includes some meals and an unbelievable amount of geek entertainment.... A lot of the same information from WWDC is presented at MacHack; plus it's a lot more fun. No marketing types, no power lunches, no suits, etc. It's more of a "hands-on" type conference. Lots of computers... you'll probably get a wardrobe of t-shirts by the time you leave... Check out http://www.machack.com for more information. BTW, anyone know who's doing the keynote this year? From russ at scheria.odyssey.com Fri Apr 25 10:08:54 1997 From: russ at scheria.odyssey.com (Russell Schissler) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC (from Denver) References: <3360796F.7B78@ibm.net> Message-ID: <9704251709.AA07706@scheria.odyssey.com> > [snip] > I believe many of you know Russ Schissler, he's planning on attending > also. > > - Chris Huston > As Chris pointed out, I am going to WWDC and I most definitely will be attending the Marketing Forum. I rather doubt however, if many of you recognize the From: line; so I'm going to break one of my #1 rules and reduce the signal-to-noise ratio a bit. My Intro: I have been exclusively developing for NEXTSTEP (choose your favorite mixed-case) for 7 years and I'm excited about the potential of Apple/NeXT and Rhapsody. My thoughts on WWDC: For a couple days after the merger, I was brooding. Refocusing on how much potential this deal has if it is executed well (no small task) got me jazzed and I remain optimistic. My guess is, results from Bldg2 will support this optimism and knock peoples socks off. Marketing Forum Monday - Rhapsodic OpenStep will be excellent, the new hardware sounds excellent; but without an equally good plan on how to get these products accepted, we simply rewind the NeXT calendar to NeXTWorld #1 and its business as usual (ho hum). IMO, there must be a fresh and aggressive marketing strategy to overcome the hurdles Rhapsody has in its path, but the current Marketing Team has earned our respect; and I for one, want to hear the details of the insurrection! We now rejoin the regularly scheduled rhapsody-dev charter ... Thanks for your indulgence, Russ --- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Russell Schissler russ@odyssey.com Odyssey Technologies Inc. http://www.odyssey.com 1550 Larimer St #254 303.861.4270 Denver, CO 80202 NeXTMail / MIME preferred! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 1873 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970425/475e8bfb/attachment.bin From blenko-tom at CS.YALE.EDU Fri Apr 25 11:24:20 1997 From: blenko-tom at CS.YALE.EDU (Tom M. Blenko) Date: Thu Nov 3 14:40:22 2005 Subject: WWDC (from Denver) In-Reply-To: <9704251709.AA07706@scheria.odyssey.com> References: <9704251709.AA07706@scheria.odyssey.com> Message-ID: <9704251824.AA01896@ruebezahl.cs.yale.edu> > Marketing Forum Monday - Rhapsodic OpenStep will be > excellent, the new hardware sounds excellent; but without an > equally good plan on how to get these products accepted, we > simply rewind the NeXT calendar to NeXTWorld #1 and its > business as usual (ho hum). IMO, there must be a fresh and > aggressive marketing strategy to overcome the hurdles > Rhapsody has in its path, but the current Marketing Team has > earned our respect; and I for one, want to hear the details > of the insurrection! ...or, stated another way, if they don't have a comprehensive. ambitious, and credible marketing plan they should cancel the technical parts of the conference and save everyone the trouble. (Each of these, I think, is difficult). I have yet to see why new developers or customers from new categories should come to Rhapsody (and I am a friend to the technology, former developer, and NeXT owner). Until next month... Tom From SSETZER at novell.com Fri Apr 25 13:03:10 1997 From: SSETZER at novell.com (Stephen-c Setzer) Date: Thu Nov 3 14:40:22 2005 Subject: Market share Message-ID: is nearly meaningless next to profitability. Toyota, Honda, and many other companies do exceedingly well owning less than 10% of their core markets. Two facts: 1) Gil Amelio returned National Semiconductor to profitability. 2) NeXT was a profitable operation (I think) last year. Therefore, the team now running Apple knows how to create a profitable company. Given that Apple has incredibly loyal customers, $1.8 gigabucks in the bank, and owns a lot of serious, influential technology, I think it's a good bet Apple will be profitable in 1998, and will continue making computers we can all use and enjoy (i.e. not running Windows). In fact, I put my money where my mouth is--bought 15 shares of Apple last Monday (hey, 300 bucks is a lot to me!) As long as Apple makes a profit, I am assured of ever-cooler machines with ever-cooler technology. And, in the area of market share, MacOS systems from all vendors accounted for 11% of computer sales last year, versus less than 9% the year before. Most of last year's systems will be able to run Rhapsody when it ships. From SSETZER at novell.com Fri Apr 25 13:38:54 1997 From: SSETZER at novell.com (Stephen-c Setzer) Date: Thu Nov 3 14:40:22 2005 Subject: Market share -Reply Message-ID: In response to a post I made, >>> Cliff Tuel - 4/25/97 2:35 PM >>> wrote >Maybe this would be more appropriate for rhapsody-talk? and he was right. Sorry--I goofed. From kjray at ix.netcom.com Sat Apr 26 15:39:50 1997 From: kjray at ix.netcom.com (Ray) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface Message-ID: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> MacOS rumors web site has a screen shot of something that MAY look like Rhapsody's user-interface. http://www.netexpress.net/~rumors/next4.html // Keith and Jane ---- // --- ---------- Check out: --------- ---------- ----------- --- --- From mericksen at ccsi.canon.com Sat Apr 26 16:23:30 1997 From: mericksen at ccsi.canon.com (Mark Ericksen) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> References: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> Message-ID: <9704262323.AA14382@ccsi.canon.com> A non-text attachment was scrubbed... Name: not available Type: application/x-nextmail Size: 2291 bytes Desc: not available Url : /mailman/archive/macosx-dev/attachments/19970426/007b8e09/attachment.bin From mericksen at ccsi.canon.com Sat Apr 26 16:37:41 1997 From: mericksen at ccsi.canon.com (Mark Ericksen) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <9704262323.AA14382@ccsi.canon.com> References: <9704262323.AA14382@ccsi.canon.com> Message-ID: <9704262337.AA14414@ccsi.canon.com> Oops, here is the same mail in non-NeXTMail format.. This screen shot is the same interface NeXT WAS going to use for NEXTSTEP4.0 / OPENSTEP. The first beta's for OPENSTEP used this interface, but was reverted back to the current interface for reasons I don't know. I have a sneeky suspicion that we'll see a little of this in Rhapsody with more Macisms added. But we'll all find out more during the Mac developers conference... I liked the new OPENSTEP interface that this screenshot shows. I loved the blue graduated title bars and table view column headers. I liked the shelf at the botton. And I will like it if they moved the menu to the top of the screen like the Mac. The NeXT interface is the most elegent I've seen. I hope they don't sacrifice the "good looks" in their transition. -Mark You wrote: >MacOS rumors web site has a screen shot of something that MAY look >like Rhapsody's user-interface. > >< > > >// Keith and Jane >---- // --- >---------- Check out: << >--------- >---------- << >----------- >--- --- << > > From gad at eclipse.its.rpi.edu Sat Apr 26 17:00:24 1997 From: gad at eclipse.its.rpi.edu (Garance A Drosehn) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface References: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> Message-ID: <9704270000.AA05044@eclipse.its.rpi.edu> > MacOS rumors web site has a screen shot of something that MAY > look like Rhapsody's user-interface. > > http://www.netexpress.net/~rumors/next4.html This is nothing more than the new look that NeXT was working on for NeXTSTEP 4.0. I personally think it is better than the NS-3.3 look, but many NeXTSTEP aficionados reacted with close-minded horror at the time, and NeXT wanted to spend more time on OPENSTEP for WindowsNT anyway (to get OS/WinNT ready for it's first release), and therefore these changes were sidelined. Note what I'm saying is that this image is *exactly* the screen shot that was taken from some demos of NeXTSTEP 4.0. Based on that fact, and on the text which is on this rumours page, I wouldn't put too much credibility in the rumour that this will be the look for Rhapsody. I like it, I think it works better than NeXTSTEP 3.x, but my guess is that Rhapsody will be a cross between this and the standard MacOS look. I do think this is closer to the MacOS look, and thus it's more likely to be the basis for Rhapsody than the NeXTSTEP 3.x look. --- Garance Alistair Drosehn = gad@eclipse.its.rpi.edu Senior Systems Programmer (MIME & NeXTmail capable) Rensselaer Polytechnic Institute; Troy NY USA From rcfa at cubiculum.com Sat Apr 26 16:55:48 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <9704262323.AA14382@ccsi.canon.com> References: <9704262323.AA14382@ccsi.canon.com> Message-ID: <9704262355.AA22188@ kannix.cubiculum.com > >The first beta's for OPENSTEP used this interface, but was reverted back to the >current interface for reasons I don't know. The reasons are simple. NeXT made a 43mm software/consulting deal with Merrill Lynch. They wanted OpenStep-developer/WinNT and OpenStep-User/Win95. NeXT has/had strict deadlines to meet. At the same time the web and WebObjects became a big focus and stream of income to NeXT. Resources however were limited. The new GUI still had some bugs, and the OPENSTEP as an OS to compete with Win* was ever lower on their priority and they could strech the resources only that far. That's why we got stuck with Mach 2.5 and BSD 4.3, although Mach 3.0 and BSD 4.4 were planned. Chances are very high that we will see Mach 3.0 in the initial release of Rhapsody, and BSD 4.4 probably one or two releases later. (These are my guesses, no privileged information here.) Now, with Apple's cash in the back, and a viable outlet to compete in the OS market, all these things can come back out of the closet... Ronald From rcfa at cubiculum.com Sat Apr 26 16:47:55 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> References: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> Message-ID: <9704262347.AA22166@ kannix.cubiculum.com > >MacOS rumors web site has a screen shot of something that MAY look >like Rhapsody's user-interface. > >http://www.netexpress.net/~rumors/next4.html That's exactly the interface NeXT had desgined for OpenStep 4.0, and then dropped it, as they moved away from the OS business, and towards WebObjects and OpenStep/NT. There are a few mistakes though on what the web page tells in general: a) the current dock can hold an arbitrary number of items, but not next to each other. In practical terms that means that the number of items in the dock depend on the height of the screen (vertical resolution). In most cases that's 13 items, but on smaller screens less, on bigger ones, more. b) the square, tiled window that pops up if the mouse is held over the Applications folder shows the RUNNING applications, and not the contents of a folder in the file system. The tabbed-shelf dock/file viewer shelf replacement combo could auto-hide, such that only the tabs would be visible. It would pop up as soon as the mouse was over any of the tabs, or it was clicked. The running applications would pop up if you moved the mouse all the way to the lower left corner, this would allow bringing applications to the foreground that don't have any opened documents or that were hidden. It was an awsome interface, with the following exceptions: a) it needed an equivalent to the lower lefthand corner, to quickly pop-up the miniaturized windows. It was suggested that the lower right-hand corner serve that purpose. (The mini windows are otherwise accessible by means of the Documents icon, that is mostly hidden by the square tiled window showing active applications that was popped-up for this screen shot; you can still see part of the writing on the screen shot...) b) the miniaturize and close buttons on the window bars don't have an inactive border, since they are sized at the full width of the title bar. This makes it difficult to grab a window by the tip of a corner, when windows overlap. The current OPENSTEP and Mac version works better, where the button does not take up the full height of the window. c) the Dock is gone. While the shelf provided more than adequate replacement for it (it was awsome to use, I still miss it) in terms of starting applications, accessing frequently used files, etc. there is one thing the dock is way superior, particularly if you had the shelf configured to auto hide to minimize screen clutter and real estate: a status bar. There needs to be a place where one can check for new e-mail, the time, system load, new faxes, pending terminal output, compilation progress, etc. It was hence proposed to revive the Dock, but solely as a status bar, from which applications could request an area to display status information. This could even be dynamic. e.g. ProjectBuilder could display a progress pie chart when it's compiling in the background, but remove it, as soon as the application is un-hidden. This way, the chance that an application wants status area, but doesn't get it, is maximized. Of course, things like Mail or a clock, may want to have a permanent spot. d) The toolbars (little icon bars) should be on a split view, such they can be moved out of sight, at the user's convenience. (This is a very trivial change. It could be done in five minutes in IB... All this is however not new information. It has been posted all over the net, when OS4.0 was a project in progress. With the four minor exceptions noted above, this was the best GUI I ever used. The shelf was great, since you could group files and applications by projects. I was never so organized as during that time, and it came naturally, witout effor. It was a clear pain in the ass to go back to the old way of working. How do I know? I beta tested the beast. While I signed an NDA, I didn't post here anything that wasn't made public before. So if you ask me questions about this, I may or may not answer, depending on if we are talking about public information or not. Greetings, Ronald From bentley at crenelle.com Sat Apr 26 20:17:12 1997 From: bentley at crenelle.com (Michael Brian Bentley) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <9704262347.AA22166@ kannix.cubiculum.com > Message-ID: I believe that this is a relevant rumor, don't blame people for discussing it here.. I will be _really_ surprised if std Rhap uses much of this. I expect Apple to minimize the apparent differences between MacOS and Rhap to the relatively untrained eye (ala NT 4 adopting the face of Win31 and then Win95). MacOS 8's appearance is well along... However, knowing NeXTfolk, if they want some or all of this stuff, it's all a dedicated weekend away... -m Michael Brian Bentley / bentley@crenelle.com / Crenelle Inc. 1935 West Pratt Blvd Suite 3, Chicago Illinois 60626-3133 Voice (773)-508-9009 Fax (773)-465-2399 Web www.crenelle.com Network Applications Development Specializing in Mac OS From rcfa at cubiculum.com Sat Apr 26 23:18:04 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: References: Message-ID: <9704270618.AA23023@ kannix.cubiculum.com > >I believe that this is a relevant rumor, don't blame people for discussing >it here.. > >I will be _really_ surprised if std Rhap uses much of this. I expect Apple >to minimize the apparent differences between MacOS and Rhap to the >relatively untrained eye (ala NT 4 adopting the face of Win31 and then >Win95). MacOS 8's appearance is well along... > >However, knowing NeXTfolk, if they want some or all of this stuff, it's all >a dedicated weekend away... I hope that if Apple adopts the MacOS 8 look, that they create an alternate NeXT-look, that's user selectable as a preference. In theory that should be simple: a different set of system bitmaps, and using conditionals instead of removing the old stuff and replacing it with the Apple version. Given that all this should be in shared libraries, the look and feel could even be changed by installing a different shared library. Apple could even use a bundle approach, like for language localization, and load a different set of code and resources, depending on the GUI the user chose in his preferences... Ronald From rm at objectdata.com Sat Apr 26 20:49:28 1997 From: rm at objectdata.com (Robert MacKimmie) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody uzer interface Message-ID: <9704270349.AA00271@objectdata.com> This is a cheap shot to make all the MAC-O-philes wet their pants in horror! Maybe some of OPENSTEP 4.0 will come back in the future, but it is a sad thing to bait the *tender* audience with a year or two old interface that got mothballed. This isn't Rhapsody. Rhapsody is looking fab, but looks different. No more misinformation, please. I guess it will get a rise out of the crowd, though. From rcfa at cubiculum.com Sun Apr 27 00:38:34 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody uzer interface In-Reply-To: <9704270349.AA00271@objectdata.com> References: <9704270349.AA00271@objectdata.com> Message-ID: <9704270738.AA23208@ kannix.cubiculum.com > >This is a cheap shot to make all the MAC-O-philes wet their pants in horror! > >Maybe some of OPENSTEP 4.0 will come back in the future, but it is a sad >thing to bait the *tender* audience with a year or two old interface that got >mothballed. > >This isn't Rhapsody. Rhapsody is looking fab, but looks different. > >No more misinformation, please. >I guess it will get a rise out of the crowd, though. Don't complain here. No one here put up the picture, we just discussed it. However HORROR is a bit exaggerated. I can tell you from first hand experience with Win*, MacOS, NeXTSTEP 3.x, OPENSTEP 4.x, OpenLook, Motif, etc. that that particular interface was conceptually THE BEST I have ever worked on. It was way up there with things that are usually only done in research labs and take 10 years or so to trickle down to the masses. Whatever Rhapsody will look like, we will have to see. However to complain here about information put up on some Mac oriented web site is totally useless, since none of us is responsible for what's on that web site. It is however much more likely that some Mac user experienced that interface back when, and is now hoping it's going to become the new Rhapsody interface and put it up with exactly the opposite intention than to create horror. Ronald From owolf at pdnt.com Sun Apr 27 12:02:27 1997 From: owolf at pdnt.com (owolf) Date: Thu Nov 3 14:40:22 2005 Subject: Rhapsody User Interface Message-ID: <199704271759.MAA18474@tempest.pdnt.net> All I have to say is: File Manager!!!????!!! Scott Johnson From rcfa at cubiculum.com Sun Apr 27 11:09:58 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: Rhapsody User Interface In-Reply-To: <199704271759.MAA18474@tempest.pdnt.net> References: <199704271759.MAA18474@tempest.pdnt.net> Message-ID: <9704271810.AA24545@ kannix.cubiculum.com > >All I have to say is: File Manager!!!????!!! retching> What an unqualified comment. They might as well have called it Finder, if that name hadn't already been taken. What do you think the Finder is other than a file manager? It is quite ridiculous to make statements like yours based on a name. Ronald From patrick at ratbert.sos.uh.edu Sun Apr 27 17:06:27 1997 From: patrick at ratbert.sos.uh.edu (Patrick Gallagher) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> References: <199704262241.RAA17021@dfw-ix4.ix.netcom.com> Message-ID: <9704280006.AA11748@ratbert.sos.uh.edu> You wrote: > MacOS rumors web site has a screen shot of something that MAY look like > Rhapsody's user-interface. > > (NeXTmail and MIME welcome) --------------------------------------------------------------------------- "There is more to life than increasing its speed." -Mohandas Karamchand Gandhi (1869-1948) --------------------------------------------------------------------------- From rcfa at cubiculum.com Sun Apr 27 17:38:05 1997 From: rcfa at cubiculum.com (Ronald C.F. Antony) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface In-Reply-To: <9704280006.AA11748@ratbert.sos.uh.edu> References: <9704280006.AA11748@ratbert.sos.uh.edu> Message-ID: <9704280038.AA25409@ kannix.cubiculum.com > >The Rhapsody snapshots (http://www.netexpress.net/~rumors/rhapshot.html) are >somewhat less informative. What you see there is the OpenStep/Rhapsody/Mach monitor/kernel-console/boot-screen. Now before I have a bunch of MacAddicts saying stuff like: "Uhh, a text based boot screen/kernel-interface how horrible..." let me add that a) you can either boot the system in graphical or text mode. The text mode is very useful to track down problems if for some reason the system doesn't boot correctly. You have to specifically enable the mode of booting b) the kernel console has nothing to do with the rest of the user interface. It is used for kernel debugging, etc. You'll also see it in the rare cases when the kernel crashes (can't remember when that happened the last time to me. Must have been years, and my computers run 7*24) You can also break into that mode with a special key sequence for an emergency shutdown of the system. Also don't think that's needed ever by a normal user... In short, these sceen shots are completely useless. They show stuff that a normal user never would see. It only shows, that SOMETHING is running on what seems to be a Mac. No big surprise. For one NeXT had a PPC port of NeXTSTEP in the closet for a while, after all, before they went out of the hardware biz, they were about to release a PPC based machine. And also, if they had not something running by now, they would be in trouble with the deadlines... So everyone can relax now, there is no conversation topic in these pictures... Ronald From jhendry at cts.com Sun Apr 27 20:03:51 1997 From: jhendry at cts.com (Jonathan Hendry) Date: Thu Nov 3 14:40:22 2005 Subject: rhapsody user interface References: <9704280038.AA25409@ kannix.cubiculum.com > Message-ID: <33641397.2737@cts.com> Ronald C.F. Antony wrote: > > >The Rhapsody snapshots (http://www.netexpress.net/~rumors/rhapshot.html) are > >somewhat less informative. > > What you see there is the OpenStep/Rhapsody/Mach > monitor/kernel-console/boot-screen. > Now before I have a bunch of MacAddicts saying stuff like: > "Uhh, a text based boot screen/kernel-interface how horrible..." > let me add that More specifically, it appears to be a Rhapsody machine, running with the kernel attached to a remote debugger. This is not a typical arrangement, but just the sort of thing you'd expect to see when people are working on the kernel or device drivers. For Mac users, think of it as a sophisticated version of Macsbug. (Assuming Macsbug didn't advance considerably since I last saw it.) - Jon From andrew Tue Apr 29 08:57:22 1997 From: andrew (Andrew Abernathy) Date: Thu Nov 3 14:40:22 2005 Subject: Official: WWDC attendees to get OpenStep 4.2 PR2 Message-ID: <9704291557.AA15828@omnigroup.com> I'm sending this to both rhapsody-dev and rhapsody-talk as I think it's pertinent to both groups. Replies may or may not be. from : > Each WWDC attendee will receive a free "Prelude to Rhapsody" > shrink-wrap package which includes: > > * OPENSTEP User 4.2 for Mach Prerelease 2 > * OPENSTEP Developer 4.2 for Mach Prerelease 2 > * OPENSTEP Enterprise 4.2 for Windows NT and Windows 95 Prerelease > * WebObjects Developer 3.1 Associated on-line documentation > * Printed copy of 'Discovering OPENSTEP: A Developer Tutorial' > > The software bundle includes a development only, single-user license > for OPENSTEP and WebObjects, not valid for software application > deployment. Details on deployment licensing for products developed with > these tools will be disclosed at the WWDC. Although software in the > "Prelude to Rhapsody" bundle will be Intel-based, the tools and > programming environment will evolve to form the basis of the Rhapsody > platform on Power Macintosh and PowerPC Platform machines. From mjohnson at apple.com Tue Apr 29 10:42:03 1997 From: mjohnson at apple.com (Mark B. Johnson) Date: Thu Nov 3 14:40:22 2005 Subject: Prelude to Rhapsody Starts at WWDC Message-ID: Prelude to Rhapsody Starts at WWDC Attendees at Apple's Upcoming Developers Conference to Get Free OPENSTEP and WebObjects Development Tools CUPERTINO, Calif. - April 29, 1997 - Continuing to build momentum for its next-generation operating system, code-named Rhapsody, Apple Computer,Inc. today announced that it will provide all Worldwide Developers Conference (WWDC) attendees, free of charge, a "Prelude to Rhapsody" software bundle, which includes the latest versions of OPENSTEP and WebObjects development tools. These tools will allow developers to begin learning the OPENSTEP programming environment which is the basis for Rhapsody. They also include WebObjects, which is Apple's industry-leading tool for easily creating powerful and full-featured dynamic web sites. Apple remains on schedule to deliver a Rhapsody Developer Release later this year, in preparation for the introduction of customer releases in 1998. Apple's WWDC is May 13 - 16 at the San Jose Convention Center, San Jose, California. Details on the conference and registration procedures can be found at Apple's Developer World website at: http://devworld.apple.com/ David Krathwohl, vice president of developer relations at Apple Computer said, "We felt that the best way to prepare the developer community for Rhapsody was to provide the current OPENSTEP and WebObjects tools to WWDC attendees at no additional cost. This special offer will allow developers to learn about the technologies at the conference, then immediately apply what they've learned by starting to work with the programming environments. This special WWDC offer helps ensure that when we deliver the Rhapsody Developer Release later this year, these developers will already have significant hands-on experience with the tools and APIs." Each WWDC attendee will receive a free "Prelude to Rhapsody" shrink-wrap package which includes: - OPENSTEP User 4.2 for Mach Prerelease 2 - OPENSTEP Developer 4.2 for Mach Prerelease 2 - OPENSTEP Enterprise 4.2 for Windows NT and Windows 95 Prerelease - WebObjects Developer 3.1 - Associated on-line documentation - Printed copy of 'Discovering OpenStep: A Developer Tutorial' The software bundle includes a development only, single-user license for OPENSTEP and WebObjects, not valid for software application deployment. Details on deployment licensing for products developed with these tools will be disclosed at the WWDC. Although software in the "Prelude to Rhapsody" bundle will be Intel-based, the tools and programming environment will evolve to form the basis of the Rhapsody platform on Power Macintosh and PowerPC Platform machines. WWDC This year's Worldwide Developers Conference (WWDC) will showcase a wide range of Apple technologies for software and hardware developers - from an overview of Apple's upcoming hardware to in-depth sessions on operating system and multimedia technologies. At WWDC, Apple also plans to demonstrate an early version of Apple's next-generation operating system, code-named Rhapsody, as well as to preview Mac OS 8, a major upgrade to Mac OS planned for release in July 1997. The opening keynote on May 13 will be given by Apple Chairman and CEO, Dr. Gilbert F. Amelio and include contributions from senior Apple executives, including Avie Tevanian, senior vice president, Software Engineering, and Jon Rubinstein, senior vice president, Hardware Engineering. Further keynotes will be given by Apple Fellow Guy Kawasaki; Guerrino De Luca, executive vice president of Marketing; and Ellen Hancock, executive vice president, Advanced Technology, Apple Computer Inc. Apple co-founder Steve Jobs will also be hosting a special "fireside chat" at the conference. Media wishing to attend WWDC can contact: Doug van Aman, Burson-Marsteller for Apple Computer, Inc. Telephone (415) 463-4000 or email: douglas_van_aman@bm.com. Apple Computer, Inc., a recognized innovator in the information industry and leader in multimedia technologies, creates powerful solutions based on easy-to-use personal computers, servers, peripherals, software, personal digital assistants and Internet content. Headquartered in Cupertino, California, Apple develops, manufactures, licenses and markets solutions, products, technologies and services for business, education, consumer, entertainment, scientific and engineering and government customers in more than 140 countries. Press Contact: Russell Brady Apple Computer, Inc. (408) 974-6877 email: brady2@apple.com NOTE TO EDITORS: To access Apple press releases, background material, and contact information on the web, visit The Source at: http://www.apple.com/source/. If you are interested in receiving Apple press releases by fax, call 1-800-AAPL-FAX (1-800-227-5329) and enter your PIN number. If you do not have a PIN number, contact Apple's Media Helpline at (408) 974-2042 to request one. If you would like to receive Apple press releases by email, please send an email message to pressrel@thing2.info.apple.com. In the subject field, type the text "subscribe [your full name]." To remove your address from the mailing list, send an email message to pressrel@thing2.info.apple.com. In the subject field, type the text "unsubscribe [your full name]." Apple's home page on the World Wide Web: http://www.apple.com/ -30- Apple, the Apple logo, Macintosh, Mac OS are registered trademarks of Apple Computer, Inc. All other brand names mentioned are trademarks or registered trademarks of their respective holders, and are hereby acknowledged. Mark B. Johnson mjohnson@apple.com Director, Rhapsody Developer Team 1 Infinite Loop, MS 75-4RE Apple Computer, Inc. Cupertino, CA 95014 USA http://www.devworld.apple.com http://www.euro.devworld.apple.com "It is only with the heart that one can see rightly; what is essential is invisible to the eye." - Antoine de Saint-Exupery Le Petit Prince From paulrs at lgs-systems.com Wed Apr 30 13:26:20 1997 From: paulrs at lgs-systems.com (Paul R. Summermatter) Date: Thu Nov 3 14:40:22 2005 Subject: Newton Message-ID: <9704302026.AA15454@cube> Hello all, I just got a Newton 2000, and I must say that my geek meter just shot off the chart! This is now, in my opinion, a real tool for solving problems. Does anyone know if the newton os and/or newton/rhapsody integration is going to be discussed at the WWDC? Also, does anyone know what the current development environments are for the newton, and whether or not any of the OpenStep API's are going to be ported over to the newton? If the EOF guys are listening, I would kill to have a NEOF (newton enterprise objects framework), which would allow us to provide our clients with newtons for use as a data gathering tool. Regards, Paul --- Paul Summermatter LGS Systems, Inc. paulrs@lgs-systems.com (NeXT or MIME Mail Welcome) From mpinkert at cc.gatech.edu Wed Apr 30 13:44:24 1997 From: mpinkert at cc.gatech.edu (Mike Pinkerton) Date: Thu Nov 3 14:40:22 2005 Subject: Newton Message-ID: <199704302046.QAA18461@lennon.cc.gatech.edu> Paul R. Summermatter wrote on 4/30/97 4:35 PM > I just got a Newton 2000, and I must say that my geek meter >just shot off the chart! This is now, in my opinion, a real tool >for solving problems. Does anyone know if the newton os and/or >newton/rhapsody integration is going to be discussed at the WWDC? >Also, does anyone know what the current development environments are >for the newton, and whether or not any of the OpenStep API's are >going to be ported over to the newton? This isn't totally on topic but.... My thesis work allows appliations to be written in any language (java, c++, etc) running on any platform (mac, win, unix, be, next) to access information off of Newtons. http://www.cc.gatech.edu/fce/llamashare/index.html It might be possible to extend the distributed object idea into the Newton through my infrastructure. That's an interesting idea.... BTW, I _love_ my 2000. Apple's got a big Newton following here at Georgia Tech. ;) -- 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 steffi at dgs.dgsys.com Wed Apr 30 13:54:14 1997 From: steffi at dgs.dgsys.com (Robert Nicholson) Date: Thu Nov 3 14:40:22 2005 Subject: Newton In-Reply-To: <9704302026.AA15454@cube> Message-ID: As a recent Newton 20k owner I can tell you that that there's a couple of of development API's. Apple make NTK for Windows and Mac. It's currently $150 . Apple are keeping a low profile re: Newton's future at the moment so don't expect to see anything at the Developers conference. If anybody knows better please let me know as I might decide to attend. Check out comp.sys.newton.misc for more. I would much prefer Sun to buy Newton from Apple and make the 2K the reference platform for Java hand held computing. On Wed, 30 Apr 1997, Paul R. Summermatter wrote: > Hello all, > > I just got a Newton 2000, and I must say that my geek meter > just shot off the chart! This is now, in my opinion, a real tool > for solving problems. Does anyone know if the newton os and/or > newton/rhapsody integration is going to be discussed at the WWDC? > Also, does anyone know what the current development environments are > for the newton, and whether or not any of the OpenStep API's are > going to be ported over to the newton? If the EOF guys are > listening, I would kill to have a NEOF (newton enterprise objects > framework), which would allow us to provide our clients with newtons > for use as a data gathering tool. > > Regards, > Paul > > --- > > Paul Summermatter > LGS Systems, Inc. > paulrs@lgs-systems.com > (NeXT or MIME Mail Welcome) >