Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!caesar.cs.montana.edu!ogicse!ucsd!hub!6600pete From: 6600pete@hub.UUCP Newsgroups: comp.sys.mac Subject: Re: What do I want to see in the Apple of the 90's? Message-ID: <3317@hub.UUCP> Date: 15 Dec 89 00:41:08 GMT References: <10077@zodiac.ADS.COM> Sender: news@hub.UUCP Lines: 168 Here we go again. I wonder how long this will last... If anyone doesn't wand to read a long message, bail now. From article <10077@zodiac.ADS.COM>, by jtn@zodiac.ADS.COM (John Nelson): > In article <3273@hub.UUCP> 6600pete@hub.UUCP writes: >>> o Rewrite in Pascal and make software calling sequence ANSII C >>> complient. CtoPstr and PtoCstr is a boatload of nonesense. >>> Of course this will break all kinds of code out there, but then >>> Apple plans to continue support of OS 6 right? >> >>How do you rewrite the OS in Pascal but make the calling sequence ANSI C >>compliant? I agree that CtoPstr() et. al. are hurtful wastes of resources, > My mistake. That should read: "Rewrite the system in C." So what if > we throw Pascal users out on the streets? ;-) ;-) ;-) Well, there's a lot of "what". Firstly, the OS isn't written in Pascal. It's written in 68000 assembler. It observes Pascal calling sequence. That is all. If you can make a persuasive case that somehow Pascal calling sequence is inferior to C calling sequence, I'm with you. As I understand it, C's calling sequence pushes arguments on the stack right-to-left and makes the called routine responsible for cleaning up the stack. Pascal pushes args left-to-right and the caller cleans up the stack. Doesn't strike me that either has a clear advantage, especially when you consider that OS calls are made via the "pascal" function modifier keyword, which forces them into Pascal calling sequence. And the extra typing of "pascal" is covered by the compiler vendor. >>This could be done with CDEF resources. People just haven't done it yet. And >>to look really NeXTy, people would have to adopt the convention of using a >>grey background pattern in their windows. None of this would be Apple's >>responsibility, because it is already possible. > > Why hasn't apple developed sets of resources WDEFS CDEFS and so on to > extend the Mac OS becuase it sounds like this is just what resources > are good for? At the very LEAST Apple could act as the distribution > center for such new extensions. Because, as I said below, destroying the unification of the interface would be suicide. The strength of the Mac interface is its homogeneity, its consistency. Apple probably has official policy high-up NOT to be a clearing house for interface deviations. This is a feature, not a bug. > It looks to me like Apple isn't doing > a whole lot to help the little guy or the public domain BBOARDS. > They just don't seem to participate (although individual employeess do). Agreed. The $600 fee for developer support will eventually kill shareware when the system becomes too hard to program without guru help. It's already having an effect. I wasn't on UseNet when the fee was announced; I imagine there was an uproar; maybe someone could fill me in on anything that didn't make it to CompuServe. > I've found APDA to be a pretty poor solution as well. I'm not a big-time > developer, just a hacker. APDA isn't a support group. It's a tool clearing-house and a publisher and a few other little services as well. > I also thinkApple is pretty poor concerning their > warrantys, service, Me too. > technical support, etc. If you can afford to be a Registered Developer, the tech support is pretty well wonderful, dammit. They've got people who'll crawl the ROMs to find out why your code doesn't work; they work with you; they're cheerful and friendly. (Maybe a tad bit slow, but they make up for it in comprehensivity.) There's NOBODY NOWHERE NOHOW who even comes close Apple's MacDTS. >>> All of these items should be sharable by users without clobbering >>> each other's applications too! >>This is also up to third parties. Apple has made it possible for applications >>to be launched more than once on a server. It's now up to developers to play >>by the rules that make it possible. > Apple could incoprporate more good ideas from outside sources. Diversity will kill the Mac interface. Apple is doing the right thing in not actively encouraging it. > They > might also pay more attention to fixing the work they've started, as > opposed to intensifying on their grand visionary strategies (like > MultiMedia, portable Macintoshes, etc). Actually system 7.0 is a step > in the right direction since it makes up for many things that the old > system is lacking (virtual memory, scalable font technology, etc). I > guess what I'm asking for is more support at the low level. I don't see how any of this relates to what I said. >>> o Stress a greater tie-in with colour. [ complaints about mono Finder ] >>That's what ColorFinder is for. You can get it via anonymous ftp to >>apple.com. I think it's in /pub/dts/mac/hacks. > all I know is what I pick up on the street. Me, too. I don't even have a color Mac. > Why can't Apple sponsor an organization like BMUG which would make these > things known? A newsletter would be nice for a start. Hmmm. Answer: because there are organizations like BMUG. >>Get THINK (Lightspeed) C. It handles all of that kind of stuff. MPW and Aztec >>probably do too, but I haven't looked at either of them in very much depth. > I shouldn't have to rely on a third party library to provide this > compatibility though. You don't. Apple makes MPW. I just haven't looked at it too closely. I've looked at code for it, though, and it looks pretty UN*Xy in most cases. >>As for the esoteric qualities of xDEF's, don't be fooled by Steve Jobs' >>rhetoric. The NeXT requires you to know how to develop for UNIX, Objective >>C, and the class library NeXT has constructed if you want to build new >>objects for the NeXT. This is as esoteric if not more esoteric than anything >>on the Mac. And it's the ENTIRE basis of the OS. > > Granted, both are obtuse. I don't have experience with the NeXT (wish I did) > to make comparisons. The only reason I'm going with a Mac now and not a NeXT > is because the software I need is available on the Mac NOW. You're kidding? The NeXT still hasn't gone anywhere to prove that it will go anywhere. I suppose when the third parties (Lotus? Ashton-Tate?) get their products out, we'll know something more. Now, though, your reasoning strikes me as pretty risky. >>Ever hear of MacApp? Or the THINK Class Library? > Again Apple is relying on a third party developr to provide products and then > the end user to integrate and develop the extensions. Nope, MacApp is from Apple. In C++, even. > I'm only expressing my desires, not a path to > attaining them. We can all dream and I dream of a Mac with more > capability, cleaner design, attention to standards... You can't escape flames with the "It's just my opinion" defense. Dreams are nice, but you haven't shown why the current Mac is inadequate. If you want to bitch about Apple support (I'll probably join you), go ahead. Otherwise, back up your arguments instead of labelling them "dreams" and expecting us to jump on the bandwagon. > ...hopefully fewer bugs Gads, here's this myth about the OS being buggy again... It's applications breaking the rules that crash, not the System. What do you think the whole System 6.0-6.0.1-6.0.2 upgrade path was about? Apple fixing bugs. They're fixed. 6.0.2 has been stable for a long time (God, it must be at least a year, which in the world of micro's means a lot); the upgrade path was a matter of months. > and better support from Apple Computer. User support, yes. Developer support, which seems to be your concern, no, as I outlined above. ------------------------------------------------------------------------------- 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