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

HoudahSpot 4.3.5 - Advanced file-search...
HoudahSpot is a versatile desktop search tool. Use HoudahSpot to locate hard-to-find files and keep frequently used files within reach. HoudahSpot will immediately feel familiar. It works just the... Read more
EtreCheck 4.0.4 - For troubleshooting yo...
EtreCheck is an app that displays the important details of your system configuration and allow you to copy that information to the Clipboard. It is meant to be used with Apple Support Communities to... Read more
WhatsApp 0.2.8361 - Desktop client for W...
WhatsApp is the desktop client for WhatsApp Messenger, a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. WhatsApp Messenger is available for... Read more
iClock 4.2 - Customize your menubar cloc...
iClock is a menu-bar replacement for Apple's default clock but with 100x features. Have your Apple or Google calendar in the menubar. Have the day, date, and time in different fonts and colors in the... Read more
Dashlane 5.7.0 - Password manager and se...
Dashlane is an award-winning service that revolutionizes the online experience by replacing the drudgery of everyday transactional processes with convenient, automated simplicity - in other words,... Read more
Garmin Express - Manage your Gar...
Garmin Express is your essential tool for managing your Garmin devices. Update maps, golf courses and device software. You can even register your device. Update maps Update software Register your... Read more
Things 3.4 - Elegant personal task manag...
Things is a task management solution that helps to organize your tasks in an elegant and intuitive way. Things combines powerful features with simplicity through the use of tags and its intelligent... Read more
SoftRAID 5.6.5 - High-quality RAID manag...
SoftRAID allows you to create and manage disk arrays to increase performance and reliability. SoftRAID allows the user to create and manage RAID 4 and 5 volumes, RAID 1+0, and RAID 1 (Mirror) and... Read more
Airfoil 5.7.0 - Send audio from any app...
Airfoil allows you to send any audio to AirPort Express units, Apple TVs, and even other Macs and PCs, all in sync! It's your audio - everywhere. With Airfoil you can take audio from any... Read more
SoftRAID 5.6.5 - High-quality RAID manag...
SoftRAID allows you to create and manage disk arrays to increase performance and reliability. SoftRAID allows the user to create and manage RAID 4 and 5 volumes, RAID 1+0, and RAID 1 (Mirror) and... Read more

Latest Forum Discussions

See All

Here's everything you need to know...
Alto's Odyssey is a really, really good game. If you don't believe me, you should definitely check out our review by clicking this link right here. It takes the ideas from the original Alto's Adventure, then subtly builds on them, creating... | Read more »
Alto's Odyssey (Games)
Alto's Odyssey 1.0.1 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.1 (iTunes) Description: Just beyond the horizon sits a majestic desert, vast and unexplored. Join Alto and his friends and set off on an endless... | Read more »
Vainglory 5v5: Everything you need to kn...
Vainglory just got bigger. [Read more] | Read more »
Check out these 5 games that are a lot l...
So you're in love with Minecraft, but you're looking for something else to play as well? You've come to the right place then, because this list is all about games that are a bit like Minecraft. Some of them, more than others. [Read more] | Read more »
Our top 5 characters from casual RPG Cre...
Creature Quest definitely lives up to its name with a host of collectible creatures based on fantasy tales and world mythologies. To celebrate Creature Quest’s first birthday, we’re going to lay out what we think are the five best characters in the... | Read more »
Around the Empire: What have you missed...
Did you know that Steel Media has a whole swathe of other sites dedicated to all aspects of mobile gaming? Sure you'll get the very best iPhone news, reviews, and opinions right here at 148Apps, but we don't want you missing out on a single piece... | Read more »
All the best games on sale for iPhone an...
Oh hi there, and welcome to our round-up of the best games that are currently on sale for iPhone and iPad. You thought I didn't see you there, did you, skulking behind the bushes? Trust me though, the bushes aren't where the best deals are. The... | Read more »
The Battle of Polytopia Guide - How to H...
A new update just released for The Battle of Polytopia (formerly Super Tribes), which introduces online multiplayer. For all the fans of Midjiwan’s lite take on Civilization, this is certainly welcome news, but playing online isn’t as easy and... | Read more »
Here are the very best mobile games to p...
It's Valentine's Day! Did you get loads of cards and chocolates and other tacky, simple expressions of human affection? Did you send out tat because you find it almost impossible to express emotion unless there's a section dedicated to it at your... | Read more »
Florence (Games)
Florence 1.0 Device: iOS Universal Category: Games Price: $2.99, Version: 1.0 (iTunes) Description: Florence is an interactive storybook from the award-winning lead designer of Monument Valley about the heart-racing highs and... | Read more »

Price Scanner via

Lowest price of the year: 15″ 2.8GHz Apple Ma...
Amazon has the 2017 Space Gray 15″ 2.8GHz MacBook Pro on sale today for $251 off MSRP. Shipping is free: – 15″ 2.8GHz Touch Bar MacBook Pro Space Gray (MPTR2LL/A): $2148, $251 off MSRP Their price is... Read more
Apple restocks full line of Certified Refurbi...
Apple has restocked a full line of Apple Certified Refurbished 2017 13″ MacBook Pros for $200-$300 off MSRP. A standard Apple one-year warranty is included with each MacBook, and shipping is free.... Read more
Lowest sale price available for 13″ 1.8GHz Ma...
Focus Camera has the 2017 13″ 1.8GHz/128GB Apple MacBook Air on sale today for $829 including free shipping. Their price is $170 off MSRP, and it’s the lowest price available for a current 13″... Read more
21-inch 2.3GHz iMac on sale for $999, $100 of...
B&H Photo has the 2017 21″ 2.3GHz iMac (MMQA2LL/A) in stock and on sale for $999 including free shipping plus NY & NJ tax only. Their price is $100 off MSRP. Read more
Apple refurbished Mac minis in stock again st...
Apple has restocked Certified Refurbished Mac minis starting at $419. Apple’s one-year warranty is included with each mini, and shipping is free: – 1.4GHz Mac mini: $419 $80 off MSRP – 2.6GHz Mac... Read more
Tuesday MacBook Deals: $250 off 15″ 2.9GHz Ma...
Adorama has the Silver 15″ 2.9GHz Apple MacBook Pro on sale today for $250 off MSRP. Shipping is free, and Adorama charges sales tax for residents in NY & NJ only: – 15″ 2.9GHz Silver MacBook Pro... Read more
Save up to $350 with these Apple Certified Re...
Apple has a full line of Certified Refurbished iMacs available for up to $350 off original MSRP. Apple’s one-year warranty is standard, and shipping is free. The following models are available: – 27... Read more
B&H offers $200 discount on Silver 15″ Ma...
B&H Photo has Silver 15″ Apple MacBook Pros on sale for $200 off MSRP. Shipping is free, and B&H charges sales tax for NY & NJ residents only: – 15″ 2.8GHz Touch Bar MacBook Pro Silver (... Read more
12″ Apple iPad Pro Sale of the Year! Models u...
B&H Photo has 12″ #iPad Pros on sale for up to $150 off MSRP. Shipping is free, and B&H charges sales tax in NY & NJ only: – 12″ 64GB WiFi iPad Pro: $719 $80 off MSRP – 12″ 256GB WiFi... Read more
Deals on 32GB 9″ iPads: Up to $50 off MSRP, s...
B&H Photo has 2017 9.7″ 32GB iPads on sale for $299 including free shipping plus NY & NJ sales tax only. Their price is $30 off MSRP, and it’s currently the lowest price available for these... Read more

Jobs Board

*Apple* Retail - Multiple Positions - Apple,...
Job Description:SalesSpecialist - Retail Customer Service and SalesTransform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Sr. Experience Designer, Today at *Apple* -...
# Sr. Experience Designer, Today at Apple Job Number: 56495251 Santa Clara Valley, California, United States Posted: 18-Jan-2018 Weekly Hours: 40.00 **Job Summary** Read more
*Apple* Technical Specialist - Apple, Inc. (...
…customers purchase our products, you're the one who helps them get more out of their new Apple technology. Your day in the Apple Store is filled with a range of Read more
*Apple* Retail - Multiple Positions - Apple,...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
Strategist, *Apple* Media Products, Content...
# Strategist, Apple Media Products, Content and Marketing Job Number: 113399632 Santa Clara Valley, California, United States Posted: 20-Feb-2018 Weekly Hours: 40.00 Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.