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.

Item074776024-June-9209:02PDT
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

Item074776224-June-9209:04PDT
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.

Item750108024-June-9210:09PDT
From:ALGERAlger, Jeff,VCA

Sub: Re: Bedrock source is necessary

    Yabadabadoooooo!

    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.

Regards,
Jeff Alger

Item477734824-June-9213:20PDT
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

Item166619024-June-9218:22
From:MDTAYLOR@APPLE.COM@INTERNET#

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

Item405297524-June-9219:04
From:ANDERS@VERITY.COM@INTERNET#

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.

anders

Item663245224-June-9213:03
From:AARON@GAMMA.COM@INTERNET#

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
aaron@gamma.com

Item617782525-June-9215:01PDT
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.

Regards,
Nick Nallick

Item468478324-June-9219:26PDT
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

Item031846724-June-9221:30PDT
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?

cheers,
Gary Campbell

Item030469224-June-9221:32PDT
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.

cheers
Gary Campbell

Item829851124-June-9209:19PDT
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

Item141667224-June-9211:31PDT
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

Item010436624-June-9213:40
From:MAJOR@BBN.COM@INTERNET#

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

Item672950424-June-9220:54PDT
From:MAJOR@BBN.COM@INTERNET#

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

Item514592024-June-9200:11
From:JWBAXTER@ONLINE.COM@INTERNET#

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.

-John

Item132485524-June-9212:11PDT
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

Item596966427-July-9215:10PDT
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".

Sincerely,
Jack Boepple
Siemens Gammasonics

Item835617227-July-9218:02PDT
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?

Item263801028-July-9212:33PDT
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.

Item10085704-Aug-9201:03PDT
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

Item653739916-Aug-9219:22PDT
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

Item461378117-Aug-9207:03PDT
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

 
AAPL
$95.60
Apple Inc.
-2.55
MSFT
$43.16
Microsoft Corpora
-0.42
GOOG
$571.60
Google Inc.
-15.82

MacTech Search:
Community Search:

Software Updates via MacUpdate

OneNote 15.2 - Free digital notebook fro...
OneNote is your very own digital notebook. With OneNote, you can capture that flash of genius, that moment of inspiration, or that list of errands that’s too important to forget. Whether you’re at... Read more
iStat Menus 4.22 - Monitor your system r...
iStat Menus lets you monitor your system right from the menubar. Included are 8 menu extras that let you monitor every aspect of your system. Some features: CPU -- Monitor cpu usage. 7 display... Read more
Ember 1.8 - Versatile digital scrapbook....
Ember (formerly LittleSnapper) is your digital scrapbook of things that inspire you: websites, photos, apps or other things. Just drag in images that you want to keep, organize them into relevant... Read more
OmniPlan 2.3.6 - Robust project manageme...
With OmniPlan, you can create logical, manageable project plans with Gantt charts, schedules, summaries, milestones, and critical paths. Break down the tasks needed to make your project a success,... Read more
Command-C 1.1.1 - Clipboard sharing tool...
Command-C is a revolutionary app which makes easy to share your clipboard between iOS and OS X using your local WiFi network, even if the app is not currently opened. Copy anything (text, pictures,... Read more
Knock 1.1.7 - Unlock your Mac by knockin...
Knock is a faster, safer way to sign in. You keep your iPhone with you all the time. Now you can use it as a password. You never have to open the app -- just knock on your phone twice, even when it's... Read more
Mellel 3.3.6 - Powerful word processor w...
Mellel is the leading word processor for OS X and has been widely considered the industry standard since its inception. Mellel focuses on writers and scholars for technical writing and multilingual... Read more
LibreOffice 4.3.0.4 - Free Open Source o...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
Freeway Pro 7.0 - Drag-and-drop Web desi...
Freeway Pro lets you build websites with speed and precision... without writing a line of code! With it's user-oriented drag-and-drop interface, Freeway Pro helps you piece together the website of... Read more
Drive Genius 3.2.4 - Powerful system uti...
Drive Genius is an OS X utility designed to provide unsurpassed storage management. Featuring an easy-to-use interface, Drive Genius is packed with powerful tools such as a drive optimizer, a... Read more

Latest Forum Discussions

See All

Dawn of the Immortals Review
Dawn of the Immortals Review By Jennifer Allen on July 31st, 2014 Our Rating: :: RESPECTABLE EXPLORATIONUniversal App - Designed for iPhone and iPad Dawn of the Immortals might not re-invent the wheel, but it does tweak it a little... | Read more »
80 Days Review
80 Days Review By Jennifer Allen on July 31st, 2014 Our Rating: :: EPIC ADVENTUREUniversal App - Designed for iPhone and iPad A fantastic and fascinating re-envisioning of the classic novel by Jules Verne, 80 Days is a delightful... | Read more »
Battleheart Legacy Guide
The world of Battleheart Legacy is fun and deep; full of wizards, warriors, and witches. Here are some tips and tactics to help you get the most enjoyment out of this great game. | Read more »
Puzzle Roo Review
Puzzle Roo Review By Jennifer Allen on July 31st, 2014 Our Rating: :: PUZZLE-BASED TWISTUniversal App - Designed for iPhone and iPad A different take on the usual block dropping puzzle game, Puzzle Roo is quite pleasant.   | Read more »
Super Crossfire Re-Release Super Crossfi...
Super Crossfire Re-Release Super Crossfighter Coming Soon, Other Radiangames Titles Go 50% Off Posted by Ellis Spice on July 31st, 2014 [ | Read more »
Hexiled Review
Hexiled Review By Rob Thomas on July 31st, 2014 Our Rating: :: HEX SELLSUniversal App - Designed for iPhone and iPad In space, no one can hear you… spell? Hexiled is a neat concept for a word scramble puzzle, but it doesn’t go too... | Read more »
Summoners War: Sky Arena Passes 10 Milli...
Summoners War: Sky Arena Passes 10 Million Installs! Posted by Jessica Fisher on July 31st, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Deep Loot Review
Deep Loot Review By Jennifer Allen on July 31st, 2014 Our Rating: :: DIVE DEEPUniversal App - Designed for iPhone and iPad Dive deep in this fun explore-em-up that’s a little grind heavy but ultimately quite entertaining.   | Read more »
Despicable Me: Minion Rush is One Year O...
Despicable Me: Minion Rush is One Year Old, Gets its Biggest Update Yet Posted by Jennifer Allen on July 31st, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Fish & Shark Review
Fish & Shark Review By Jordan Minor on July 31st, 2014 Our Rating: :: FLAPPY FISHUniversal App - Designed for iPhone and iPad Fish & Shark’s beauty is only scale deep.   | Read more »

Price Scanner via MacPrices.net

All Over For Tablets Or Just A Maturing, Evol...
CNN’s David Goldman weighs in on tablet sector doom and gloom, asking rhetorically: “Is this the beginning of the end for the tablet?” Answering that, he contends that hysteria and panic are... Read more
Letterspace 1.0.1 – New Free iOS Text Editor...
Bangkok, Thailand based independent developer Sittipon Simasanti has released Letterspace, a new text editor for iPhone, iPad, and iPod touch devices. Letterspace is a note taking app with an... Read more
Save up to $130 on an iPad mini with Apple re...
The Apple Store has Certified Refurbished 2nd generation iPad minis with Retina Displays available for up to $130 off the cost of new models, starting at $339. Apple’s one-year warranty is included... Read more
iPad Cannibalization Threat “Overblown”
Seeking Alpha’s Kevin Greenhalgh observes that while many commentators think Apple’s forthcoming 5.5-inch panel iPhone 6 will cannibalize iPad sales, in his estimation, these concerns are being... Read more
Primate Labs Releases July 2014 MacBook Pro P...
Primate Labs’ John Poole has posted Geekbench 3 results for most of the new MacBook Pro models that Apple released on Tuesday. Poole observes that overall performance improvements for the new MacBook... Read more
Apple Re-Releases Bugfixed MacBook Air EFI Fi...
Apple has posted a bugfixed version EFI Firmware Update 2.9 a for MacBook Air (Mid 2011) models. The update addresses an issue where systems may take longer to wake from sleep than expected, and... Read more
Save $50 on the 2.5GHz Mac mini, plus free sh...
B&H Photo has the 2.5GHz Mac mini on sale for $549.99 including free shipping. That’s $50 off MSRP, and B&H will also include a free copy of Parallels Desktop software. NY sales tax only. Read more
Save up to $140 on an iPad Air with Apple ref...
Apple is offering Certified Refurbished iPad Airs for up to $140 off MSRP. Apple’s one-year warranty is included with each model, and shipping is free. Stock tends to come and go with some of these... Read more
$250 price drop on leftover 15-inch Retina Ma...
B&H Photo has dropped prices on 2013 15″ Retina MacBook Pros by $250 off original MSRP. Shipping is free, and B&H charges NY sales tax only: - 15″ 2.3GHz Retina MacBook Pro: $2249, $250 off... Read more
More iPad Upgrade Musings – The ‘Book Mystiqu...
Much discussed recently, what with Apple reporting iPad sales shrinkage over two consecutive quarters, is that it had apparently been widely assumed that tablet users would follow a two-year hardware... Read more

Jobs Board

*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
Sr. Product Leader, *Apple* Store Apps - Ap...
**Job Summary** Imagine what you could do here. At Apple , great ideas have a way of becoming great products, services, and customer experiences very quickly. Bring Read more
Sr Software Lead Engineer, *Apple* Online S...
Sr Software Lead Engineer, Apple Online Store Publishing Systems Keywords: Company: Apple Job Code: E3PCAK8MgYYkw Location (City or ZIP): Santa Clara Status: Full Read more
Sr Software Lead Engineer, *Apple* Online S...
Sr Software Lead Engineer, Apple Online Store Publishing Systems Keywords: Company: Apple Job Code: E3PCAK8MgYYkw Location (City or ZIP): Santa Clara Status: Full Read more
*Apple* Solutions Consultant (ASC) - Apple (...
**Job Summary** The ASC is an Apple employee who serves as an Apple brand ambassador and influencer in a Reseller's store. The ASC's role is to grow Apple Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.