[ Be Logo ] [ Home ][ Site Map ][ Search ][ Contact ][ Be Europe ][ Developers Banner ]
About Be, Inc.Be ProductsThe World of BeDeveloper ServicesJobs @ Be[Bottom]

Be Developer Services

Free Resources

BeIA FAQ

BeIA Evaluation

Partner Program

Join

Partner Area

|

  The BMessage
Issue 19    February 21, 2001

News

Upcoming Events

Be regularly participates in computer industry events such as these:

Intel Developer Forum
February 26 - March 1, 2001
San Jose, CA
http://www.intel94.com/idf/index2.asp

CeBIT
Deutsche Messe
Hannover Germany
March 22-28, 2001
Be's location: Hall 9 Booth A42
http://www.cebit.de/

The Wired World of Be

Check out Be related web sites on the The Wired World of Be web page.

return to top

JLG

Jean-Louis Gassée Column
by Jean-Louis Gassée, CEO and Chairman

There is no JLG column this week. Please look for an article in the next issue.

return to top

The Be Line

Method and Madness
By Lee M. Williams, Director, Product Development and Delivery

Not long ago I was having lunch with a couple of associates from other companies also involved in the emerging Internet appliance arena, when the topic of markets came up. We were discussing the recent downturn of the once highflying NASDAQ Composite Index and Dow Jones Industrial Average. The financial pains caused by such downturn, cast in the shadow of the successes of last year, were hot topics for several minutes. Of course we also speculated about how long this downturn might last, and the reasons for the changes that have hit the markets over the last 6 months. By the time our food arrived, two interesting changes had occurred.

As in any conversation, we drifted on to related topics. At some point one associate asked my opinion of the IA market's progress. This person clearly felt that the market had run into trouble recently. Questions arose inside my head: Which market? Does he mean "financial" trouble? Does he know something I don't know? Then those thoughts gave way to a different, decisive viewpoint that I want to share with you.

A market is a forum or vehicle for exchange. I quoted Adam Smith in my last piece, so I won't repeat myself this time around. The NASDAQ Index and the market for IAs -- or any consumer or business product -- do have similarities at a macro level, in that they all have similar phases. In fact, there are five basic phases that you can observe and study. Without going into lengthy descriptions, these are:

  • Definition
  • Acceptance
  • Development
  • Growth or Scale
  • Sustain
The idea that markets go through these phases is as sound as the late Carl Sagan's conclusion that the world is built upon five basic solids. The NASDAQ market went through these phases as a forum for investment and the technology, communications, and entertainment sectors have all passed through them as their symbiotic markets have evolved. Technology development is more closely related to and dependent on the birth of the IA market, so I'll use that as an example.

At one time a market for PCs didn't exist. The concept of computing was there, thanks to World War II, but the idea of a personal computer was an absurdity. Someone, however, took the bold step of "defining" or speculating that there was a demand and started talking to colleagues and investors about supporting the development of such a concept. I won't go into who originated the PC concept -- that's for technologists who enjoy debating the dogmas of the computing religion more than they do observing its existence. There was a small development phase here, largely unseen by the public, which I consider an adjunct to the "Definition" phase more than a part of the other phases I named above. This is experimentation and exploration with loose and varied understandings of what the product definition even is.

Eventually you reach an "Acceptance" phase, usually tailored by industry announcements, investments, and signified by the "coming out" of the product concept. One key milestone of the PC revolution was the introduction of a portable market, signified by the first Compaq "suitcase" computer hitting the cover of a few mass circulation magazines. If an idea gains acceptance, it may lead to the formation of companies, with investment dollars and sales and marketing machines backing the market by taking notice of the concept's widespread acceptance. This lemming-like activity is a great sign for the viability of the market that is the financial canvas for the product. This is what I define as the "Development" phase; it begins once acceptance is in place.

Development, especially with technology sector products, has two aspects: internal and external. Many concepts will remain in widespread development and insiders see only the exposure or progress of those efforts. The external view is often modulated by first-to-market companies' product introductions, and what are often flawed or half-baked visions of the concept. The market staggers collectively at this point, and it's common for the press to declare a false start or flawed reasoning behind the acceptance of the product. However, this doesn't mean the Development phase isn't in full swing or that the market for the product is in doubt.

When the efforts that have followed a successful method and development process come to fruition, the nay sayers go away and the revenue starts to pour in. This is when, in the tech industry, new magazines appear. It's as if the original publications that ran the tidbit about the market potential of the concept cannot possibly contain or effectively realize its potential once it takes hold. The key challenge at this point for companies heavily vested in the market is to "grow or scale" their vision to fit the increased and widely accepted demand.

The "Grow and Scale" phase for a large market, whether it's PCs, portable computing, or Internet appliances, can last for years. This phase can easily dwarf the others in the sectors under discussion. Once the players are established and the battles for supremacy in this market are resolved, the march toward saturation begins. This often leads to the creation of other product concepts. Sometimes there is a convergence with other markets and the original marketplace enters a phase where the most important focus for the companies whose primary revenue streams are tied to the markets is to sustain that revenue.

The question my lunch partner asked me about the IA market, and his assumption of its downturn was actually based on public perception of the product concept's viability. He was referring to that stagger I mentioned, wherein the first-to-market concepts were being challenged. He may have been unaware or not taking into consideration the fact that large scale and widespread development is still taking place. The companies with a true vision for the emerging market are in the process of executing against their plans, and business goals. This was never more evident than in the second change that occurred in the conversation.

We spent most of our time at lunch that day discussing how we had each networked our homes. We talked at length about how our televisions and stereos were key components of this strategy. We also wished that there were simpler ways to connect, converge, and access our media, both video and audio, with our computers. In essence we spent the majority of our time talking about the demand for seamless, cross-platform appliances that were networked to each other in a distributed manner. We also touched on the desire to share this with friends and family. None of us realized at the time that we were validating the very markets that were in question.

In my opinion we were validating the IA market, speculating on the growth path of the technology, communications, and entertainment markets, and clarifying that the NASDAQ Index is a cyclical entity. One that is reeling from the hype, speculation, and foolishness that was generated around flawed product concepts. These ideas had no true market and they didn't evolve through the five phases of development. A dot com with a $5M/month burn rate for pharmaceuticals that reach a 15% margin on some store shelves is a flawed concept. You need to sell a lot of drugs to be profitable, and that assumes a demand for pharmaceuticals online.

There is a method to what many people see as madness in this recent market. The fact that the IA market seems to be progressing through the standard development phases should give one a degree of confidence as to its momentum and strength. It has the potential to be big and it seems clear to me that the keys to pervasive computing are on their way into your hands.

return to top

Engineering Insights

Using the Source Level Debugger
By Myron Walker, Developer Technical Support Engineer

The advantages of a source level debugger cannot be overstated. Just as it's advantageous to write code in high level languages like C, C++, Java, and others, it's also important to be able to evaluate the function and performance of code at a higher level. The Be Debugger -- 'bdb' for short -- is the source level debugger for BeOS that fulfills this need. Bdb provides programmers with the necessary tools for verifying program functionality.

The architecture of BeOS encourages multithreading. In simple terms, a thread is a series of instructions to execute. Multithreading allows for simultaneous execution of the instructions of more than one thread. Applications written in BeOS often have more than one thread. The most basic GUI (Graphical User Interface) programs have a minimum of two threads -- one used by the BApplication object and another by the BWindow object.

An application's threads are organized into a team, which is similar to a process on other operating systems. The existence of teams and multiple threads makes it necessary to have a debugger that can debug multithreaded applications. Bdb provides access to team and thread information, as well as control over the current teams and threads running on the system. Bdb can halt individual threads in a team, while other threads continue to execute independently or until they block because of the halted thread. Bdb makes it possible to debug code in a multithreaded environment.

In order for bdb to function, you must compile your code to include debugging information. If you're using BeIDE, you do this by clicking 'Edit->Project' Settings, then selecting 'Generate debugging information' under the 'Code Generation' options. You'll have to recompile your code after making this change in the BeIDE. If you're a command line programmer you can use the -g compiler option to have debugging information included in the compiled code. Remember that compiling with debugging information turned on causes a dramatic increase in the size of the output binaries.

Using bdb is easy once you learn your way around. There are three window types in bdb. First is the 'Running Teams' window, which shows all teams running on the system. Double-clicking on a listed team activates bdb and throws that team into the debugger. Be careful which teams you throw into the debugger, though, and what you do with them when you're done. The second window type is a Team window, which lists all threads that belong to the team, as well as all source code files used in the compilation process. The final window type is the Thread window, shown when a thread stops executing. The cause could be an error or insertion of a breakpoint that halts program execution. The Thread window shows the current state of the stack and allows you to check the values of variables at all levels of the stack.

If you're trying to debug an application (i.e., something with a main function), you can launch it in debug mode from BeIDE by clicking the 'Project->Debug' menu Item. You can also launch an application in the debugger by passing it to bdb on the command line (i.e., bdb/boot/develop/tools/experimental /QuickRes/QuickRes ). Once you start your application in the debugger, you click the Continue button (it looks like a play button on a CD player) and your application runs in debug mode. If a line of code causes a segment violation or a breakpoint is reached, the debugger stops on that line of code.

There are times when you may need to debug an add-on. Add-ons are executable code libraries that follow a specific interface standard and are loaded into an applications address space. In order to debug an add-on you must also debug the application that uses it. To do this you can simply run the application that loads the add-on from the command line using the debugger. The debugger will start and the Team window will appear. Click on the 'Debug->Break after the load_add_on' menu item. Then start the program execution. Do whatever is necessary for the application to load the add-on and the debugger should stop. Unfortunately, this causes the program to halt at every add-on it loads.

Another option for debugging add-ons is to use a 'debugger(char *)' function call at the entry point to your add-on code. This causes an error dialog to appear when the add-on in question is loaded. Select 'details' and a Terminal debug window opens. In the debug window type 'bdb(enter)' and the debugger opens. When you use this method, the thread stops inside the assembly code for the 'debugger(char *)' function. Now you can insert breakpoints in your add-on code and continue execution up to the desired break point.

Note: 'debugger (char*)' is declared in OS.h.

There are more useful things that you can do in bdb than I can mention here. One of the handiest features of the debugger is its ability to present the status and value of variables at the point where thread execution has halted. Bdb can show you fixed variables such as integers, floats, and pointer addresses. It also goes a step further by giving you, through the use of add-ons, the ability to view other types of data in intelligible forms (i.e., you can view BBitmaps and Strings as pictures and text).

Debugging is an integral part of programming, and having the right tools is essential for programmers. Bdb is a very valuable debugging tool. Becoming familiar with its abilities can save you hours of debugging time.

Related Links:
Current Version of bdb: ftp://ftp.be.com/pub/experimental/tools/bdb.zip

References:
Debugger Release Notes in BeOS:
file:///boot/develop/tools/experimental/debugger/Read.Me.First

return to top


Statements contained in this Newsletter that are not historical facts are "forward-looking statements" including without limitation statements regarding the demand for, future market penetration and market acceptance of BeIA and BeOS, the shipment dates of Be's products, and the future operating results of Be Incorporated. Actual events or results may differ materially as a result of risks facing Be Incorporated or actual results differing from the assumptions underlying such statements. Such risks and assumptions include, but are not limited to, risks related to competition, market acceptance and market penetration of Be's products, ability to establish and maintain strategic relationships, the benefit of Be's products to OEM and Internet appliance manufacturers. the continued availability of third party BeOS applications and drivers, and the ability to establish and maintain strategic publishing relationships. All forward-looking statements are expressly qualified in their entirety by the "Risk Factors" and other cautionary statements included in Be Incorporated's Annual Report on Form 10-K for the year ended December 31, 1999, and other public filings with the Securities and Exchange Commission.

The BMessage
Copyright (c) 2001 by Be, Inc.
All rights reserved.

Be, Inc.
800 El Camino Real, Suite 400
Menlo Park, CA 94025
Tel: (650) 462-4100
Fax: (650) 462-4129
Web: http://www.be.com/

Be, BeOS and BeIA are trademarks or registered trademarks of Be Incorporated in the United States and other countries. Other brand product names are registered trademarks or trademarks of their respective holders. All rights reserved.

The BMessage is sent to subscribers of one or more of the Be mailing lists. For more information about subscribing/unsubscribing, see the Be web site: http://www.be.com/world/mailinglists.html. The Be web site also offers a complete set of current and back issues of Be Newsletters: If you have any comments about The BMessage, please e-mail them to:newsletter@be.com.



.
About Be, Inc. | Be Products | World of Be | BeOS Support | Jobs | Developers | Press | Partners | Investors
.
Copyright © 2001 by Be, Inc. All rights reserved. (Legal Info)
Comments, questions, or confessions about our site? Please write the Webmaster!