TweetFollow Us on Twitter

September 92 - Fun with Fred and Barney

Fun with Fred and Barney

Steve Mann and MACAPP3TECH$

Gee, with a name like Bedrock would we be talking about a TFred class, a TWilma class, etc.?
- Kirk Austin, ILM

Since the last FrameWorks went to press, there has been a lot of AppleLink traffic discussing Bedrock. The most heated discussion so far took place on the MACAPP2TECH$ and MACAPP3TECH$ AppleLink group addresses. In addition, there is an ongoing discussion in the AppleLink Developer Support bulletin board (Developer Support: Developer Talk: Macintosh Development Tool Discussion: MacApp Discussion Folder) about the viability of MacApp3.

We thought it might be appropriate to include some of this electronic activity for those MADA members that don't have access to AppleLink or don't belong to the MACAPP2TECH$ or MACAPP3TECH$ group addresses. These messages, presented in chronological order, are all culled from those two group addresses,

A few recurring themes stand out in this series of links:

  • Bedrock source code availability-Many MacApp developers think it's essential that the Bedrock class library source code be available.
  • MacApp 3.X support from Apple-There is concern that MacApp 3.X will not be upgraded to fix known bugs, that there will never be even a MacApp 3.1, and that current MacApp developers are essentially being stranded with an orphaned technology.
  • Porting MacApp applications to Bedrock-Developers want to know just how useful their MacApp knowledge will be for Bedrock, and what tools will be available if it is possible (unlikely) to port MacApp code to Bedrock.
  • The Yet-Another-OOF (Object-Oriented Framework) Syndrome - First it was MacApp 2.0, then 3.0, now Bedrock, all in relatively quick succession-when will it stop? How does Pink fit into this sequence?
  • How strong is Symantec and Apple's commitment to MacApp developers and the timely delivery of information to those developers?

On that last theme, Symantec has a telephone number (408/446-8931) you can call to apply to join the Bedrock early developer program. If you leave an appropriate message, they'll send you an application. Included with the application questionnaire is a copy of the Bedrock press release, a Bedrock white paper, and a overview of the development tools market. Symantec is collecting names and basic qualifications for those people they hope to anoint as early developers.

Gordon Apple at Advanced Communications Engineering (one of our FrameWorks authors this month) found the telephone number on Compuserve. As one of the links in this collection indicates, Symantec has an active forum on Compuserve, none on AppleLink. This focuses the last item in the list above a bit more-what is Symantec's commitment to MacApp developers?

Symantec clearly wants to penetrate the PC development tools market. They also have their own developer group for Think Class Library users. Sources at Symantec have essentially said that selling Bedrock to MacApp developers is like preaching to the already converted. All of this suggests that on the priority list, MacApp developers are perhaps third or fourth on Symantec's list of preferred partners, which is unfortunate. Perhaps they forgot that religious wars are bound to fail if the zealots lose their zeal.

So far we've seen a lot of advance marketing and hype, but very few specifics. Most of the MADA members I've talk to are skeptical about Bedrock. Until Symantec and Apple provide developers with answers to some of the questions posed in these links, that's not going to change. In the mean time, this collection of links, courtesy of MADA members, may give you some insights into some of the choices that you may be facing in the future.

From:D5858Industrial Light & Magic, Lenci,PRT

Sub: Re: Bedrock 'n stuff

    Gee, with a name like Bedrock would we be talking about a TFred class, a TWilma class, etc.?

Kirk Austin, ILM

From:D3943West Publishing, Dean Stambaugh,PRT

Sub: Bedrock Packaging

    It seems to me that the break from MacApp & TCL provides an opportunity to market the source separately from the libraries. There are surely many programmers, both professional and amateur, who never need to refer to MacApp's source. (Just as there are many of us who make a living from our ability to navigate the backwaters of MacApp.)

    I would like to see Apple/Symantec sell a basic package (no source) for something like the current price of Think C/TCL. This could get a lot more programmers on the O.P. bus (probably a "good thing") particularly on the Windows side.

    A separate source package on CD-ROM could sell for (say) $250. It would be available only to registered owners of the library version and only direct from Apple or Symantec.

    And of course there's the combo box with both parts at a small discount.

    I think the most important thing is to find ways to make this stuff available to the largest possible number of people. So, Apple Marketing Folks - let Symantec set the price.

Bill Colsher
SKAMP Computer Services

Item0852241 24-June-9209:33PDT
From:CAERE.WADECaere, Wade Eilrich,PRT

Sub: Bedrock source is necessary

    We would never have been able to ship our two products (OmniPage Professional and OmniPage Direct) if we had not had the source to MacApp. MacApp contained so many bugs, that without the ability to correct the problems in the source we would STILL not have those products on the market. When a program, like MacApp, becomes the basis for application generation it is imperative that the application developer be able modify/customize the source for their own needs. There still are bugs in 3.0 final that we reported in 3.0b2...

    Without source I cannot justify the use of a product like Bedrock as a foundation for our product family. It is much more important to me to be able to release bug-free applications on time than it is to have a common UI code base and be unable to get an application through our QA cycle.

Wade Eilrich
Manager of Macintosh Projects
Caere Corp.

From:ALGERAlger, Jeff,VCA

Sub: Re: Bedrock source is necessary


    There is a curious paradox in the debate over source. Let's assume, for the sake of argument, that the product works flawlessly in all its versions, or that Symantec's support is sooooo great that it doesn't matter, since they'll fix it in a flash anyway. The whole area of QA for class libraries is a quagmire of conflicting strategies and utopian visions. And let's assume for the sake of argument that the documentation is picture-perfect and kept perfectly up to date. It won't happen - witness the forthcoming "quick reference" for MacApp, which documents a fraction of the whole in 600 pages - but let's just assume that it can and will happen. Now, do _we_ still need source? Is it still in the _vendor's_ best interest to release the source?

    Polymorphism is the cornerstone of code reuse in OOP, and to take advantage of it a well-factored object-oriented designed decomposes methods into, ideally, one to ten lines of source per method. So in one sense, it doesn't matter: if the documentation is really good, it doesn't take a rocket scientist to figure out what the source must look like. And if you can't guess at it, anyone who ever took a course in assembler language can drop into a debugger and know for sure.

    One then has to question the worth of the documentation in the first place to the extent that it reproduces the algorithms of the code. (At this level of granularity, let's not get caught in silly semantics: usage protocols imply algorithms at some point.) C++ is nice and succinct. Ever try translating simple for loop logic into equivalent English (or whatever)? Natural languages are anything but succinct. Why turn what to a programmer is a precise expression, code, into something imprecise written by a technical writer who doesn't code or, worse, a coder who doesn't write? It mushrooms and distortion is always introduced. And that's before you start making changes over the life of the product.

    Another observation: stolen OOP code doesn't go far. Classes, for all of our bellowing about reuse, tend to be pretty well tied to the class library they come from. Furthermore, the only people who can really take advantage of stolen source are other big companies whose lawyers will jump up and down and scream at the thievery. So it doesn't strike me as in a vendor's interest to tie up source, since the source is likely to be reused only within that vendor's product, anyway. There are exceptions, chiefly in low-level stuff like code generators and real-time kernels that represent heady investments in discarding other alternatives, but most OOP code is just straightforward implementation of stuff that is in the manual. In fact, one could argue that really great OOP documentation just makes it _easier_ for someone to pirate by reverse engineering to the same interface, rather than browsing copyrighted code.

    So, in summary: It doesn't strike me as in the programmer's interest to see documentation only, since that is always more verbose than the equivalent code and far less precise. It doesn't strike me as in the vendor's best interest to not release source, since it means a heavier burden of QA and support, a heavier - perhaps impossible - burden of documentation, discouraging innovation from the user community that can lead to better future versions, and frightening away people with mission-critical projects that have to be controllable, in the worst case, from within.

Jeff Alger

From:DIGIMATCH3M, Ran Bedekar,PRT

Sub: Frameworks and the Toolbox

    It seems like a good time to resurrect a topic from the WWDC, namely what priority is Apple placing on supporting new features in their object framework.

    For example, Quicktime, in its initial form, is not entirely compatible with MacApp. If, as Apple says, object frameworks (i.e., MacApp) are the recommended way to write Macintosh apps, the object oriented interface should be as important as the Pascal interface for Inside Macintosh. At the WWDC there was a lot of finger pointing. The MacApp team said the groups extending the toolbox should guarantee compatibility with MacApp. The other groups normally said the MacApp team should do it. I came away with the impression that there was no real corporate commitment to timely support new toolbox features in their object framework. To be fair, the MacApp team has done a good job with System 7, but when will MacApp fully support Quicktime, the new technologies discussed at the WWDC, and future enhancements?

    Now with Bedrock, framework development seems to be shifting from Apple to Symantec with help from Apple. This is not supposed to be a least common denominator solution, but what happens to features beyond those common to GUI's? I assume Bedrock will support technologies Apple decides to port to Windows (e.g., Quicktime), but what about the unique things on each platform? How much framework support can we expect for state of the art technologies, and how long will we have to wait to see it? A greatest common denominator solution is not a good choice either. The framework will have to be different, at some level, for each platform supported. Otherwise, we're all back to reinventing new wheels everytime Apple or Microsoft releases a new technology.

    If Apple is really serious about the greater development community moving to OOP, I think they should make a public commitment to support their chosen framework to the same degree they support their other development environments.

Looking for a soup spoon,
Nick Nallick


Sub: Re: RE: Bedrock source is nece

    One of the most compelling arguments in favor of distributing source code is the following situation: Sometimes I want to override a MacApp method, just making some subtle change in the code. It's much easier to copy and paste the whole method and then make my changes than to try to reconstruct the method from nothing.

    I can think of several instances where my job would have been next to impossible had I not had access to the MacApp source code.

- Mark


Sub: Re: Bedrock source is necessary

    Clearly, the line is drawn according to the quality, stability and complexity of the software.

    Can you write a MacApp application without source? At no point in my exposure to MacApp have I ever thought anything but 'no'. This is generally because of the quality/complexity of both the library itself and of its documentation (the line about the MacApp source being the documentation is true).

    To use an example from another world, although source for Motif is available from OSF, many platform vendors that supply Motif do not ship source, because you do not need source code to run/compile a Motif application, and presumably they don't want to publish their vendor-specific code.

    Howerver, the question is: can you write a Motif application without the source? The emphatic answer is: NO. Can you port a Motif application to a new platform without Motif source for that platform? The answer is: Probably.

    So far I have begged the question of whether I need the source to the toolbox to write an application. Let me answer the question by saying: no, I don't need the source, because I don't 'use' the toolbox. I use MacApp, whose job it is to isolate me from the details of the toolbox. Other reasons why I don't need the source: much stabler interfaces, much stabler implementation, much stabler documentation, etc.

    Have I ever wished I had the source to the toolbox? Have I ever crashed inside the ROM and wanted to be able to step in to see what was happening? Would I have been able to find some bugs in my code faster this way? Yes. Do I require the source to the Toolbox in order to write applications? No.

    I'm not against a pricing structure that charges extra to acquire the source code, but I think it would be ill-advised not to make the source available at all.



Sub: Don't show the source code

    Buggy code and confusing implementation) *have* been some hallmarks of MacApp (and every other development tool ever written.) Source code availability has helped all of us overcome some of these problems. If we weren't able to overcome these problems, MacApp would have either (1) died or (2) gotten some additional engineering resources.

    Not having source code available forces better encapsulation, a clearer object model, and encourages managers to invest engineering resources because those engineers are creating something proprietary.

    I think documentation is probably not as important as overall design and power. Understanding the MacApp command chain (forgive my 2.X ref's, I'm not 3.0 fluent) might require quite a lot of documentation and training without source, but isn't a possible solution to make posting and reading commands simpler (semantic object model everywhere?) instead of providing tools to understand something (unnecessarily?) complex.

    I'm not sure that Bedrock will be *it* and it may be cheaper to provide source than provide all the engineering support that might be needed to make it work without source, but the future must be sourceless if vendors are going to stake their companies on the development of these frameworks.

Aaron Rosenbaum

From:DIGIMATCH3M, Ran Bedekar,PRT

Sub: Source vs. Commitment

    Yet another opinion on the framework source issue...

    For me the question of whether or not source is required for a framework comes down to the level of commitment from the provider. Providing the source is the easy way out for a vendor. Compare the toolbox with MacApp:

    • Quality Assurance.
      There is no contest. MacApp final versions probably contain more known bugs than the unknown bugs that turn up during the life of a version of the MacOS (ignoring the 6.0 debacle). This is a result of the level of commitment to quality. Would you bet your product/company on MacApp without the source? Probably not. What about the toolbox? Most people do.
    • Documentation.
      Again, no contest. Nothing in MacApp comes close to Inside Macintosh and the tech notes.
    • Debugging/Tools
      Debugging is probably easier with MacApp because of the source availability and the debug mode. The toolbox could really use a debug mode like MacApp's (I hear that the next version of Discipline will be much better). If you don't have the source for a framework you'd better get a really good debug mode. Sourcebug is a good first version, but would benefit from the maturity of SADE. ViewEdit and the first few years of ResEdit are probably comparable. MacBrowse is nice.
    • Design.
      Everybody has probably copied a method in MacApp and changed a couple lines. I regard this to be a failure in the design of a framework. For example, I do it much less in MacApp 3 than I did in version 2. It's much more difficult to design a good framework API than one for a procedural interface like the toolbox. Therefore you would expect a much larger investment from the developer. (Of course, the API is the part of the design that will always be available as source.)

    This is in no way meant as a dig at MacApp. It has been steadily improving with each new revision. I'm sure that all of the people working on it are as committed to quality, etc. as anybody. The point is simply to illustrate the level of commitment from Apple. How much of the billions in R&D dollars in the last few years has gone into MacApp vs.. the toolbox? MacApp is supposed to be the recommended development environment for the Mac. Yet there seems to be no investment in documentation comparable to Inside Macintosh, and no investment in QA comparable to System 7. Apple seems to be willing to make a greater commitment to Pink than MacApp.

    The question I have about Bedrock is not whether there will be source or not, but rather, how much of a commitment are Apple and Symantec willing to make to it.

Nick Nallick

From:D0532Aidea Systems, Don Park,PAS

Sub: Bedrock as a standard

    Fellow Bedrock Thumpers,

    It sure is amazing to watch the MacApp discussion flare up and my phone bill go up at the same time. Let me return the favor by dishing out some of my own irrelevant opinions.

    We should not be discussing whether Bedrock should ship with or without source code. We need to focus on what Bedrock really is. Is Bedrock a product or a standard?

    Bedrock, as a product, is a gamble. A bad implementation, whether it ships with source code or not, will curse us all for the next five years. Despite all the efforts that went into MacApp, it is leaky, fat, and rigid - sort of like a stuffed elephant with stool problem.

    Bedrock, as a standard, is the way to go. Apple should take charge of creating the standard and providing OS supports like dynamic linking. Symantec and other application framework vendors should provide Bedrock components.

Don Park

From:V0645Tandem, Gary Campbell,AM

Sub: Re: Bedrock as a standard

    I agree, Its weird I have been gone for a week, came back to MacApp3Tech and expected to find some real meat discussing the pros, cons, the problems with a cross platform tool and all there is a source code debate.

    What features of my MA 3.0 app will not port to Bedrock?

    • Cohandlers?
    • Cool popups?
    • View files?
    • What classes are history?

    What features my be separately maintained?

    • View.rsrc files?
    • others?

Gary Campbell

From:V0645Tandem, Gary Campbell,AM

Sub: Re: Sources or no Sources...

    I could not have shipped a MacApp product WITHOUT the source CODE.

    Why not,

    1. Documentation

      Documentation for MA 2 was bad, you and everyone else are aware of why, split development/manual development.

    2. Bugs

      Basically I ship MA apps with MY PATCHES to the MA SOURCE to make it reliable on my App to my customers.

    3. Development

      Many many times, the only was I could figure out why I was getting bombed was by debugging into the MA source.

      Silly things like mis-spelling the 'fIdentifier' of an field or a Class name result in terrible failures.

      Maybe MA should be very helpful in these situations even if you are compiling with '-debug'. I never do any more.

Gary Campbell

From:WICATWicat Systems, Michael Rossetti,PRT

Sub: Bedrock-Let's Get Real

    Yes, let's get real!

    Apple/Symantec's going to ship Bedrock in the first half of 1993 and we're not going to need source! Not!

    Let's ignore the source code issue for the rest of this discussion and just talk about the likelihood that ANY group could deliver what everyone thinks they're going to need in that time frame.

    Let's put on our project management hat for a moment and pretend we are the ones who are going to have to ship this product. We'll work backwards.

    Ship Date: June 31, 1993.
    April 1, 1993: Package Goes Golden Master

    The product is going to have to be ready to package three months before FCS (First Customer Ship). Because it takes three months to get advertising space in most major magazines, there's still going to be bugs to fix, the documentation has to be printed, example programs have to be written, CD's have to be cut, etc. That's reality, right?

    January 1, 1993: Product Goes Beta

    There's no substitute for putting a development product into the hands of real, live, interested developers. Even though a three month beta is not really realistic either, we'll give it a shot.

    Now let's go to the other end of the schedule: design and implementation.

    July 1, 1992: Product Design

    Is three months enough time to work out the design of Bedrock? Probably not (after all we did JUST barely close the deal with Symantec) but we'll tell management it is (because they might take the project out-of-house if we don't). We've got to take the existing frameworks (MacApp, and some other unspecified framework which none of us has ever heard of before and if it was soooo good wouldn't someone have hear about it?) and meld them into some reasonably designed, easy-to-implement, superior framework which solves all the problems inherent in the currently 'superior' frameworks.

    September 1, 1992: Implementation

    Though some implementation has already taken place and though we are building on existing frameworks there's still going to be a lot of coding to perform. Coding to correct some major flaws in the contributed framework MacApp (such as view's being grossly heavy weight-views being the major contribution to the effort) and coding to incorporate Macintosh/Windows concepts into a framework which I assume came out of the Unix world. Three months? Well it'll be too late for management to do anything about schedule slips.

    Plus we've got to do the absolute best job of documenting the product so that developers can learn and design and code, provide tools for debugging, view construction and prototyping, and incorporating Quicktime, Quickdraw GX, etc.

    Does anyone out there really think it will happen by June 31st, next year? I don't.

    But I'll take whatever they give me. Because it will still be lightyears beyond anything else out there. Personally, I'd really like to see the class structure right away. That would be pretty enlightening.

    Gotta go but please don't think I'm flaming, mad, or otherwise deranged. I just think we all need to be realistic about what can be done in a year.

Mike Rossetti

From:D3943West Publishing, Dean Stambaugh,PRT

Sub: Re: Bedrock-Let's Get Real

    Just got back from lunch where this very topic was discussed. The consensus was that Bedrock is either effectively complete NOW and all that remains is incorporating politically motivated "enhancements" (i.e. how much can we afford to alienate our MacApp developers, internal and external) *OR* the one year time frame is pure smoke. (We also discussed what might happen to the PC & Mac teams currently working on parallel projects. Unfortunately, we concluded that management will decide the Mac is a secondary machine, order development only on the PC, and then bring in a couple of contractors to build the Mac specific parts of the application after PC development is complete. Sorry, but that's the reality in a world that's 85% PC.)

    In defense of the 1 year time frame:

    There are some hints in the white paper and Q&A that Bedrock might really be almost done. It is described as being used internally at Symantec and that it is in the hands of some corporate developers and ISV's already. In addition the Q&A states that Symantec will be signing up "Early Developers" this fall.

    On the other hand:

    There's nothing I can add to your comments...

    Your dose of realism should be appreciated by all. Sometimes we get so wrapped up in our own reality that we forget about that other reality.

Bill Colsher
SKAMP Computer Services
A'Link: SKAMP or the company shown above


Sub: Bedrock is in use already!

    It's important for folks to understand that, as far as I know, Bedrock has already been used as the basis for several cross-platform Symantec products. I am certain that Symantec was telling people that it was "shrink-wrapped" and was trying out opinions on source-code issues, etc. in the early part of this year. And after all, Bedrock took as a starting point the TCL class design, which I'm told is pretty good. That is certainly the first place to look for hints about the future shape of Bedrock.

    So Apple and Symantec are not starting from a stand-still, by any means. We may not see a "Think C++" right away, but the high standards of Symantec's tools (Think Browser, Documentation, support, etc.) will be there with Bedrock. I can see that Apple's contribution, beyond MacApp, is also the Unix-like MPW environment where Zortech's C++ actually does run. After all, MPW is much closer to DOS and UNIX than Think C is, right now.

    The big question in my mind, as others have stated, is how much of MacApp's architecture will be translatable, and what the underlying "X-platform Toolbox" looks like - that is where the work will be for existing MacApp apps, right? I'm just now moving an app from MA 2.0 to 3.0 - sigh...

John Major
BBN Software Products


Sub: Re: Bedrock is in use already!

    Indeed President of Symantec Gordon Eubanks said at the annoucement that Symantec has already used portions of Bedrock for both their TimeLine and Q & A Windows products. I believe Q & A is to be released soon for the Mac. Haven't heard anything in relation to TimeLine on the Mac.

-Ken Addison
FutureSoft System Designs


Sub: Bedrock Discussion

    Hmmm...a 35 message thread about Bedrock over in Symantec's forum on CompuServe, and not one mention of the words "source code". There's even a little substance. That's more like it.

    And...TCL users are just as used to source code as MacApp users are.


From:D4887Advanced Comm Eng, G G Apple,PRT

Sub: Questions about Bedrock

    I going to ask some questions straight out that I think most of us would like to know the answers to:
    1. Other than a possible release of MacApp 3.0.1, is MacApp 3.0 now dead as far as further class enhancements (like QuickTime support, and some of the other requested features)?
    2. Will we have to wait for Bedrock to get these much needed features? Or will there still be a MacApp 3.1?
    3. Was this (Bedrock MacApp replacement) actually planned and well thought out? Or is it a knee-jerk reaction to developer's wish-lists here, at the MADA conference, and WWDC?
    4. Did we bring this on ourselves (as in "Be careful what you ask for. You might get it.")?
    5. No one has mentioned PowerPC. Is that to be transparently included?
    6. How mainstream is Bedrock going to be in the entire Macintosh scheme of things? (Like concurrent class releases to support new system extensions? Or class releases to support what are now becomming "old" system extensions?)
    7. How about DLLs (Dynamic Link Libraries)?
    8. In spite of an announced doubling of support for developer tools, are the resources of the MacApp (Bedrock?) team going to be adequate for this very ambitious project? (I have my doubts. The MacApp teams obviously has some very bright people, but they deserve to be let out of their cage occasionally. If Apple computer really wants to take on Microsoft in both arenas plus PowerPC, I suspect they're going to have to double it at least a couple of more times.)
    9. Whereas hardware development cycles are now getting compressed intomonths instead of years, the software development cycle and feature cycle are still very long. System Extensions -> Framework -> Program Code -> Product.Is there any chance of publishing at least projected schedules andclass/feature lists?
    10. Is there any point (for the present) in developers continuing toexpress wish lists and architectural/performance suggestions? The earlier wecan get a look at Bedrock (in whatever stage of completion), the moreconstructive feedback can be provided. (Sure beats after-the-factwhy-the-h-did-you-do-it-that-way type of feedback.)
    11. In general, I vote for published source code. However, I would notobject strenuously to (and might in fact welcome) compiled classes thatencapsulate and even bypass sets of toolbox calls for certain system extensionclasses, e.g., QuickTime, QuickDraw GX, CommToolBox. Any chance?
    I'm sure I'll have a lot more questions, as will others. But it's a start.

G. Gordon Apple D4887
Advanced Communications Engineering, Inc.
Redondo Beach, CA

From:V0896Siemens Gammasonics,J Boepple,VAR

Sub: Platform Path

    We were planning to start converting our application from Object Pascal to C++ and MacApp 2.0.1 to MacApp 3.0 this summer after the completion of our latest release cycle. This will not be a trivial task since, as far as we know, we are the largest Macintosh application in existence - more than 800,000 lines of code.

    Well, we are going to continue with our plans to convert to C++, since it appears to be the only (non-dynamic) language option available.

    However, the news of Bedrock and the "informal" announcement of the gutting of the MacApp team (reference Chris Knepper's note) has left us in a quandary (i.e., a polite way of saying confused and frustrated) over what platform path to follow.

    To help clarify these platform options for us, I would appreciate your answers, opinions, or comments to the following:

    • Why go to MacApp 3.0 when Bedrock is targeted to be out in less than one year?

      Yes, it has more features than MacApp 2.0.1, but, as a new release, it is still relatively immature. MacApp 2.0.1 is a known quantity (plus we have already incorporated the MABuild options -ModelFarCode, -ModelFarData, and -Proff). Also, the reviews about the MacApp 2 to MacApp 3 conversion process have been less than stellar.

    • What are the plans for the maintenance and/or enhancement of MacApp 3.0? I am particularly disappointed that Apple has not even attempted any type of damage control after the announcement about the movement MacApp resources. More disheartening was the lack of a response when a (German?) developer posted a message stating that he was considering developing on an alternative *system* because of his experiences in reporting MacApp 3.0 bugs and asking for their resolution.
    • If we decide to bypass MacApp 3.0 and wait for Bedrock, what is the incentive not to wait another several months for the subsequent release of Pink? I have heard much more favorable comments and projections for Pink than Bedrock.
    • Since MacApp, Bedrock, and Pink are all Apple products (in one mutated form or another), which would you target to enhance an application of our size? I made this an open letter because I am also interested in what other people (i.e., the peanut gallery) are thinking about this subject.
    I are looking forward to your reply and hope it *starts* to gives us a warm, fuzzy feeling that the "platform path" is not "the road to nowhere".

Jack Boepple
Siemens Gammasonics

From:LANGFORDParadigm Publishing, B Langford,PAS

Sub: Re: Platform Path

    To know if it's worth going to MacApp 3, an answer to this question would be helpful...

    From the Bedrock QA:

    One thing to remember about the transition is that although some code will not transfer, many programming skills developed for MacApp will apply to Bedrock. That would be true for any C++ class lib.

    If you are already using the MacApp framework, the learning curve to adopt Bedrock will be low.

    Well, that sounds better...I'd say part of a "low" learning curve was "Most classes and methods still work as before with the same arguments." Anyone from Apple want to agree with that, or compare the conversion effort to the MacApp 2->3 conversion?

    And one more question: will Bedrock have a 'native' API that is different from it's MacApp semi-compatible API?

From:SESISys Engineering Sltns, Flack,PRT

Sub: Bedrock -> MA3.0 Tools

    Apple keeps talking about tools that they will make available to port from MacApp to Bedrock. I think it is about time someone told us what these tools will do, and how much more work will remain, once we have used the tools. If the tools are as simple as NameSmythe (a conversion tool for MacApp3.0 betas to the next MacApp3.0), they will probably not be sufficient to do the conversion quickly. We need to know this in order to know what path to take with MacApp and Bedrock.

Paul C. Ossenbruggen
Systems Engineering Solutions, Inc.

From:RSDResearch SW Design, D Goldman,PRT

Sub: Re: Platform Path

    People have been asking variations of this question for a while now. I haven't seen an answer to the basic question (my apologies if I missed it):

    Is MacApp 3.0 an Apple-supported product?

    Most of us recall the MacApp 2.0.1 debacle. After a couple years of betas, out comes MA 2.0 Final. Quickly followed by an official list of known bugs. Then followed by 2.0.1, with fixes to a fraction of the bugs on the official list. Finally, an announcement that Apple will never fix the rest of the bugs, because all of the MacApp staff is now working on MacApp 3.0 (available in beta soon!).

    Now there are strong hints that MacApp 3.0.1 is the end of MacApp 3.0 repairs, as everyone is now working on Bedrock.

    People do keep reporting small (and not-so-small) bugs in MA 3.0. Will Apple release repaired versions of MA 3.0 to keep up with these bugs, or have you simply launched this class library into the public domain and washed your hands of it, or what?

    Some of us are commercial developers. Using a no-longer-supported library as the base of our commercial products is, to say the least, unnerving. My users don't care if the bug in my product is really Apple's fault, they just want my product to do what it claimed to be able to do.

    PLEASE assure us that a skeleton crew will remain to maintain MA 3.0 for at least another year! Better yet, for two or three more years, even after Bedrock ships, since our current products will still be out there, and will still be in MA 3.0.

    If Apple REPEATS its MA 2.0 mistake of abandoning those developers who followed instructions and went with Apple's object-oriented class library, then Apple's credibility re Bedrock and Pink are going to take a nosedive.

- Dave Goldman
Research Software Design

From:UIOWA.ISDGU Iowa, Steve Wessels,HEP

Sub: MacApp 3.02...?

    Hello all,

    I've just been looking through ETO #8, specifically the "known MacApp 3.01 bugs." Even though most of them are minor, it's still a little depressing to keep paging and paging through the DocViewer file! Add to that the links that keep coming in to this address, and...

    Here's what I'm getting at. When the Bedrock announcement was made, it became obvious that there wouldn't (and needn't) be a MacApp 4.0. Over the next couple of weeks, it also became clear (SEVEN ENGINEERS?!!) that there wouldn't be a MacApp 3.1. Lately, however, there have been strong hints (on ETO#8, for example) that there probably won't be a MacApp 3.02!

    Now, let's mull this over. (Mull mull mull). Bedrock is supposed to arrive some time in the first half of 1993. If the next three ETO's arrive in November '92, February '93 and May '93, that means at least one and probably two or three ETO's before Bedrock. So why not at least have someone (ONE ENGINEER?!) hack around with MacApp, cleaning up this, that and the other thing? I think at least one more bug fix version is required; if Apple surprises us and presents Bedrock at MADA '93, we could live with just one more bug fix. If not, I'm sure there will be more bugs to fix for a 3.03, or even a 3.04. These maintenance releases would get easier and easier to do, requiring less staffing (ONE-SEVENTH OF AN ENGINEER?).

    This way, we'll always be getting something. You gotta have something. Either we get Bedrock on time, or we get more of those nasty little bugs fixed. I think that calling 3.01 the last word for MacApp would be a mistake - the updates are the main reason that some of us are getting ETO!

    Also, I know that Symantec is going to continue to patch up the TCL without having any more major releases - the same simple, prudent strategy I'm advocating here.

    One more very important question I'm almost afraid to ask: Is Bedrock going to be on ETO?? Anyway, that's my 2 cents worth.

Derek Siebert, U. of Iowa

From:GILLAM.RRichard Gillam,GEIS

Sub: Re: MacApp 3.02...?

    I think that Apple actually has at least one person left on MacApp, but I could be mistaken.

    The point you raise is one thing I want to amplify: There are a lot of bugs in MacApp. Most of them are minor, but still, there are a lot of bugs in MacApp. One of the nice things about MacApp is that because we all have the source code, if there's a bug, someone can come up with a fix and report it on AppleLink and everyone can fix the bug right then (if they have to) without waiting for Apple to make a new release.

    My point is that if Bedrock is going to ship without source code, quality control is going to have to be VERY HIGH (certainly higher than MacApp's), and the development team's response to bug reports is going to have to be very fast; otherwise, we lose some flexibility and some stability over MacApp now.

    This might be a good argument for shipping Bedrock with source code (at least for the less proprietary parts of it), but if not, it's still something it's imperative to take into consideration.

Rich Gillam
(stating my own opinions, not those of) GE Information Services


Community Search:
MacTech Search:

Software Updates via MacUpdate

Adium - Popular instant messagi...
Adium is a fast and free instant messaging client which supports AIM, ICQ, Jabber, MSN, Yahoo!, Google Talk, Yahoo! Japan, Bonjour, Gadu-Gadu, Novell Groupwise, SIP/SIMPLE (Text), and Lotus Sametime... Read more
CleanMyMac 3.8.1 - $39.95
CleanMyMac makes space for the things you love. Sporting a range of ingenious new features, CleanMyMac lets you safely and intelligently scan and clean your entire system, delete large, unused files... Read more
BusyCal 3.1.7 - Powerful calendar app wi...
BusyCal is an award-winning desktop calendar that combines personal productivity features for individuals with powerful calendar sharing capabilities for families and workgroups. Its unique features... Read more
Lyn 1.8.9 - Lightweight image browser an...
Lyn is a fast, lightweight image browser and viewer designed for photographers, graphic artists, and Web designers. Featuring an extremely versatile and aesthetically pleasing interface, it delivers... Read more
Tweetbot 2.5 - Popular Twitter client.
Tweetbot is a full-featured OS X Twitter client with a lot of personality. Whether it's the meticulously-crafted interface, sounds and animation, or features like multiple timelines and column views... Read more
Monolingual 1.7.8 - Remove unwanted OS X...
Monolingual is a program for removing unnecesary language resources from OS X, in order to reclaim several hundred megabytes of disk space. If you use your computer in only one (human) language, you... Read more
Dash 4.0.3 - Instant search and offline...
Dash is an API documentation browser and code snippet manager. Dash helps you store snippets of code, as well as instantly search and browse documentation for almost any API you might use (for a full... Read more
Posterino 3.3.6 - Create posters, collag...
Posterino offers enhanced customization and flexibility including a variety of new, stylish templates featuring grids of identical or odd-sized image boxes. You can customize the size and shape of... Read more
Apple Numbers 4.1.1 - Apple's sprea...
With Apple Numbers, sophisticated spreadsheets are just the start. The whole sheet is your canvas. Just add dramatic interactive charts, tables, and images that paint a revealing picture of your data... Read more
Apple Pages 6.1.1 - Apple's word pr...
Apple Pages is a powerful word processor that gives you everything you need to create documents that look beautiful. And read beautifully. It lets you work seamlessly between Mac and iOS devices, and... Read more

Latest Forum Discussions

See All

Get Ike in the new Fire Emblem: Heroes u...
One of the most popular Fire Emblem characters is finally available in a new update to Nintendo'sFire Emblem: Heroes. [Read more] | Read more »
Die With Glory in a new viking adventure...
If you're a fan of classic adventure games you'll do well to pick upDie With Glory, the gorgeous new title from Cloud Castle inc. Die With Glory updatesthe gameplay of the same kind of adventure classics such asMonkey Island for modern, mobile... | Read more »
Get up to speed with everything you need...
In case you haven’t heard, MU Origin just got a colossal new update with new all-server events, battle modes, and systems making their way to the land of MU. Here’s a handy guide to everything you need to know about the latest content. [Read... | Read more »
Minimalist puzzle game, Cuts, free on iO...
If you're looking for a gorgeous puzzle experience on iOS devices, developer's aesthetically interesting puzzler, Cuts, is discounted to free on the iOS App Store right now. [Read more] | Read more »
Anime tactical RPG, War of Crown, comes...
If you're looking for another tactical RPG fix to go alongside your Fire Emblem Heroes campaigns check out Gamevil's newest, anime-inspired tactics RPG, War of Crown, which comes out tomorrow. [Read more] | Read more »
Fantasy MMORPG MU Origin adds new modes,...
MU Origin, Webzen’s highly popular fantasy MMORPG is getting ready to shake things up for the second time this year, as a new update makes its way to the Google Play and App Store from today. Introducing new systems, modes, and events, the land of... | Read more »
Blizzard is looking to hire a mobile dev...
A new thread on the popular video game rumor forum, NeoGAF, uncovered an interesting job listing over at Blizzard Entertainment. It appears the studio behindStarCraft, World of WarCraft, Hearthstone,andOverwatch is looking to bring on a new hire... | Read more »
Legend of Zelda meets Cooking Mama in ne...
Dungeon Chef is what happens when you mix the RPG elements (and style) of a Legend of Zelda game, with cooking elements. Although, now that The Legend of Zelda: Breath of the Wild also has cookingelements, so maybe the gameplay is not so novel.... | Read more »
ChordFlow (Music)
ChordFlow 1.0.0 Device: iOS Universal Category: Music Price: $6.99, Version: 1.0.0 (iTunes) Description: ChordFlow is a chord sequencer with a unique 4-track polyphonic arpeggiator, extensive chord library, MIDI out and Ableton Link... | Read more »
The Walking Dead: A New Frontier is out...
The newest season of Telltale Games'The Walking Dead is well underway. After the release of the third episode, "Above the Law" about a month ago, episode four, "Thicker Than Water" is hot and ready for more zombies and gut-wrenching emotional... | Read more »

Price Scanner via

Digital Paper Tablet Offers Distraction Free...
I typically spend 8-10 hours a day gazing at the screens in my laptops and iPad, as tools of my livelihood, I don’t as a rule use electronic devices for pleasure reading. I subscribe to a daily... Read more
“Today at Apple” Bringing New Educational Ses...
Apple has announced plans to launch dozens of new educational sessions next month in all 495 Apple Stores ranging in topics from photo and video to music, coding, art and design, and more. The hands-... Read more
Smart Finance Free Comprehensive Personal Fin...
Moscow-based indie developer, Alexander Survillo has announced the release and immediate availability of Smart Finance: Personal Finance, Budget & Money 1.1.4, an update to his comprehensive... Read more
12-inch 1.1GHz Retina MacBooks on sale for $1...
B&H has 12″ 1.1GHz Retina MacBooks on sale for $100 off MSRP. Shipping is free, and B&H charges NY & NJ sales tax only: - 12″ 1.1GHz Space Gray Retina MacBook: $1199.99 $100 off MSRP - 12... Read more
13-inch 2.7GHz Retina MacBook Pro on sale for...
B&H Photo has the 13″ 2.7GHz Retina MacBook Pro on sale for $130 off MSRP. Shipping is free, and B&H charges NY & NJ tax only: - 13″ 2.7GHz/128GB Retina MacBook Pro (MF839LL/A): $1169 $... Read more
15-inch 2.2GHz Retina MacBook Pros available...
B&H Photo has the 15″ 2.2GHz Retina MacBook Pro available for $200 off MSRP including free shipping plus NY & NJ sales tax only: - 15″ 2.2GHz Retina MacBook Pro (MJLQ2LL/A): $1799.99 $200 off... Read more
13-inch Touch Bar MacBook Pros on sale for up...
B&H Photo has the 2016 Apple 13″ Touch Bar MacBook Pros in stock today for up to $150 off MSRP. Shipping is free, and B&H charges NY & NJ sales tax only: - 13″ 2.9GHz/512GB Touch Bar... Read more
Apple refurbished Apple TVs available for up...
Apple has Certified Refurbished 32GB and 64GB Apple TVs available for up to $30 off the cost of new models. Apple’s standard one-year warranty is included with each model, and shipping is free: -... Read more
12-inch 1.2GHz Retina MacBooks on sale for up...
B&H has 12″ 1.2GHz Retina MacBooks on sale for up to $160 off MSRP. Shipping is free, and B&H charges NY sales tax only: - 12″ 1.2GHz Space Gray Retina MacBook: $1439.99 $160 off MSRP - 12″ 1... Read more
HyperX Ships Pulsefire FPS Gaming Mouse, Winn...
Your reporter is a longtime fan of gaming mice for general purpose coomnputing use, finding them typically superior in comfort and performance. HyperX, a division of Kingston Technology Company, Inc... Read more

Jobs Board

Product Manager, *Apple* Platforms - Viacom...
…Product Manager to drive the execution of its iOS and AppleTV experiences. The Apple Platform Product Manager will be a leader in our Agile/Scrum environment and Read more
Geek Squad *Apple* Master Consultation Agen...
**500662BR** **Job Title:** Geek Squad Apple Master Consultation Agent **Location Number:** 000286-Canton-Store **Job Description:** **What does a Geek Squad Read more
*Apple* Mobile Master - Best Buy (United Sta...
**500710BR** **Job Title:** Apple Mobile Master **Location Number:** 000279-North Olmsted-Store **Job Description:** **What does a Best Buy Apple Mobile Master Read more
*Apple* Engineering Specialist - CSRA (Unite...
Apple Engineering Specialist All times are in Eastern Daylight Time Requisition ID Job Locations US DC Washington DC Posted Date Category Engineering Sciences Read more
*Apple* Mac Computer Technician - GeekHampto...
…complex computer issues over the phone and in person? GeekHampton, Long Island's Apple Premium Service Provider, is looking for you! Come work with our crew Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.