gilstrap@swbatl.sbc.com (3929) (03/10/90)
Okay, perhaps someone can answer me this question: why not use an
implementation of Mach as verrsion 8.0 of the MacOS? It would seem that you
could preserve the shared memory areas via Mach's shared virtual memory through
VM inheritance (e.g. don't copy-on-write but inherit a shared chunk of VM).
This would allow the large majority of Mac programs which do twiddly things
in the system heap and such to still run correctly.
I guess I'm interested in hearing what the problems are (I'm sure there are
at least a few).
Thanks,
Brian R. Gilstrap
uucibg@swbatl.uucp OR ...!{ texbell, uunet }!swbatl!uucibgchewy@apple.com (Paul Snively) (03/10/90)
In article <1236@swbatl.sbc.com> gilstrap@swbatl.sbc.com (3929) writes: > why not use an > implementation of Mach as verrsion 8.0 of the MacOS? It would seem that you > could preserve the shared memory areas via Mach's shared virtual memory through > VM inheritance (e.g. don't copy-on-write but inherit a shared chunk of VM). > This would allow the large majority of Mac programs which do twiddly things > in the system heap and such to still run correctly. > > I guess I'm interested in hearing what the problems are (I'm sure there are > at least a few). Mmmm, yeah. Emulating the Mac toolbox and OS would be one, although it's already been done for A/UX. I'm not exactly sure how architecturally-specific that would be. Another would be size and installation. What do you do about non-MMU (non '020/851 and '030) machines? What about responsiveness? We'd like to stay more responsive than either a NeXT or a Sun. ;-) There'd also be an identity problem: is it UNIX, or is it MacOS? At least with A/UX you know what you're getting yourself into. We'd also have to deal with the same compatibility headaches as we do with A/UX. As UNIX kernels go, I really like MACH, but I wouldn't try to foist it off as the Macintosh Operating System. __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. 1st Choice: Paul_Snively.DTS@qm.gateway.apple.com 2nd Choice: CHEWBACCA@applelink.apple.com Last Choice: chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
6600pete@ucsbuxa.ucsb.edu (GurgleKat [Pete Gontier]) (03/10/90)
From article <1236@swbatl.sbc.com>, by gilstrap@swbatl.sbc.com (3929): > Okay, perhaps someone can answer me this question: why not use an > implementation of Mach as verrsion 8.0 of the MacOS? Shhhhhh! You'll give it away! :-) -- Pete Gontier | InterNet: 6600pete@ucsbuxa.ucsb.edu, BitNet: 6600pete@ucsbuxa Editor, Macker | Online Macintosh Programming Journal; mail for subscription Hire this kid | Mac, DOS, C, Pascal, asm, excellent communication skills
stoms@castor.ncgia.ucsb.edu (David Stoms) (03/11/90)
In article <1236@swbatl.sbc.com> gilstrap@swbatl.UUCP (Brian Gilstrap - UCI - 5-3929) writes: >Okay, perhaps someone can answer me this question: why not use an >implementation of Mach as verrsion 8.0 of the MacOS? It would seem that you >could preserve the shared memory areas via Mach's shared virtual memory through >VM inheritance (e.g. don't copy-on-write but inherit a shared chunk of VM). >This would allow the large majority of Mac programs which do twiddly things >in the system heap and such to still run correctly. First of all, Apple is never going to use any implementation of Unix in their current Mac platform for a number of reasons. Natually, Apple wont license a Unix from anyone and they wont want to rewrite the File Mgr again without a _VERY_ good reason. If Apple did decide to convert the File Mgr to un*x, it would be almost impossible to keep all the current programs compatable. Just the '/' instead of ':' would screw a few programs up and what about file types?. BUT, I would like to hear more about "Mach's shared virtual memory" though. Sounds interesting.
murat@farcomp.UUCP (Murat Konar) (03/11/90)
In article <7100@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: [responding to suggestion that Apple use Mach as a future OS for the Mac] > >What about responsiveness? We'd like to stay more responsive than either >a NeXT or a Sun. ;-) Thank god somone at Apple considers response time as critical as I do. What I'd like to see ideally is GUI co-processor that would be responsible for all screen updating, mouse tracking, etc. That way no matter what was going on in the background, you'd still get a menu right away when you click, or your windows would update at full speed. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
murat@farcomp.UUCP (Murat Konar) (03/11/90)
In article <164@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >Thank god somone at Apple considers response time as critical as I do. What Before some religious zealot flames me for neglecting to capitalize 'God' let me apologize; it was a typo. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
eb1z+@andrew.cmu.edu (Edward Joseph Bennett) (03/11/90)
>Okay, perhaps someone can answer me this question: why not use an >implementation of Mach as verrsion 8.0 of the MacOS? It would seem that you >could preserve the shared memory areas via Mach's shared virtual memory through >VM inheritance (e.g. don't copy-on-write but inherit a shared chunk of VM). >This would allow the large majority of Mac programs which do twiddly things >in the system heap and such to still run correctly. I don't see why not? In the February issue of Cursor, CMU's acedemic computing magazine, there is an article on MacMach " We are currently developing software that will allow MacMach users to run Macintosh applications under Mach. This system will allow the Macintosh Operating Sysytem and Toolkit to startup in a single MacMach process, and run either the Finder or Multifinder. To the user, a Macintosh running MacMach will appear no different than a Macintosh running the Macintosh Operating System, except that the MacMach user will also have acess to UNIX and Andrew applications. This system is in the experimental stage, but may be available in a limited form some time this spring. " Now since Apple is funding this project..., well you can infer the rest. Such a system that could exploit the power of Mach and UNIX but still run all Mac applications with the Mac interface would make the high end Macs formidable contenders in the Workstation Market. Funny, As a CMU student I may be able to test such a system BEFORE I get my hands on system 7.0. Ed
billkatt@mondo.engin.umich.edu (billkatt) (03/12/90)
In article <4260@hub.UUCP> stoms@castor.ncgia.ucsb.edu (David Stoms) writes: >In article <1236@swbatl.sbc.com> gilstrap@swbatl.UUCP (Brian Gilstrap - UCI - 5-3929) writes: >First of all, Apple is never going to use any implementation of Unix in their >current Mac platform for a number of reasons. Natually, Apple wont license a >Unix from anyone and they wont want to rewrite the File Mgr again without a >_VERY_ good reason. If Apple did decide to convert the File Mgr to un*x, >it would be almost impossible to keep all the current programs compatable. Just >the '/' instead of ':' would screw a few programs up and what about file types?. Look before you leap. Haven't you heard of AU/X? Well, AU/X 2.0 is great, and it will be coming back with a vengeance. They licensed Unix from AT&T, NFS from SUN, and extensions from Berkeley. Files are kept in AppleSingle format (very similar to MacBinary) and AppleDouble (similar to AUFS). As for compatibility, I ran MS Word and Excel under AU/X, in 32-bit addressing mode. These program were able to fully access unix files. Neat Huh? I am not espousing Unix for everyone (not even for me), but for those who want a Mac and Unix, too, it is coming quickly. -Steve
bowman@reed.UUCP (Eric Bowman) (03/12/90)
In article <165@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >In article <164@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >>Thank god somone at Apple considers response time as critical as I do. What >Before some religious zealot flames me for neglecting to capitalize 'God' >let me apologize; it was a typo. Can I flame you for capitalizing god? ;-) ^^^ bObO bowman@reed.{bitnet,UUCP,edu} tektronix!ogccse!reed!bowman
peirce@claris.com (Michael Peirce) (03/14/90)
In article <164@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >In article <7100@goofy.Apple.COM> chewy@apple.com (Paul Snively) writes: >[responding to suggestion that Apple use Mach as a future OS for the Mac] >> >>What about responsiveness? We'd like to stay more responsive than either >>a NeXT or a Sun. ;-) > > >Thank god somone at Apple considers response time as critical as I do. What >I'd like to see ideally is GUI co-processor that would be responsible for >all screen updating, mouse tracking, etc. That way no matter what was >going on in the background, you'd still get a menu right away when you >click, or your windows would update at full speed. Hear hear! I'd love to see future Macs become Multiprocessor machines. I see the trend going in the right direction with the new IIfx (or whatver it'll be called). This machine reportedly has processors to handle various i/o jobs. I'd like to see this extended so that I could plug in extra 680X0 modules for running applications. That what I could have at least one main processor running the foreground application with full responsiveness and maybe another processor or two running some sort of agent checking my stock portfolio or checking the usenet :-) Basic mac users could by single or double processor machines and let MultiFinder take care of sharing the processors (if you had two processors dedicate one to the foreground and share the other for the background tasks). Power users could pile on the processors. Using this idea. Joe Power user could buy some useful agent software and a processor module to dedicate to it. If I want four agents running all the time I'd add four processor modules and dedicate them to the four programs. Anyways, you get the idea. Claris Corp. | Michael R. Peirce -------------+-------------------------------------- | 5201 Patrick Henry Drive MS-C4 | Box 58168 | Santa Clara, CA 95051-8168 | (408) 987-7319 | AppleLink: peirce1 | Internet: peirce@claris.com | uucp: {ames,decwrl,apple,sun}!claris!peirce
baumgart@esquire.dpw.com (Steve Baumgarten) (03/20/90)
In article <1990Mar11.174227.19404@caen.engin.umich.edu>, billkatt@mondo (billkatt) writes: >Look before you leap. Haven't you heard of AU/X? Well, AU/X 2.0 is >great, and it will be coming back with a vengeance. They licensed >Unix from AT&T, NFS from SUN, and extensions from Berkeley. Files >are kept in AppleSingle format (very similar to MacBinary) and >AppleDouble (similar to AUFS). As for compatibility, I ran MS Word >and Excel under AU/X, in 32-bit addressing mode. These program were >able to fully access unix files. Just a brief comment, a bit off the topic: Isn't it kind of sad that Mac users now use Microsoft applications like Word and Excel as a measure of the compatibility of new operating systems and hardware? So basically we all consider Word and Excel to play by the rules about as much as Flight Simulator on the PC does... P.S. It sounds like A/UX will finally be coming into its own with 2.0. I'm looking forward to it. -- Steve Baumgarten | "New York... when civilization falls apart, Davis Polk & Wardwell | remember, we were way ahead of you." baumgart@esquire.dpw.com | cmcl2!esquire!baumgart | - David Letterman