Developers—have you shown your application(s) to any user groups yet? User groups are one of the best ways to spread the word about your product.

Demonstrating your product to a user group accomplishes several desirable goals:

• You are informing users of your product's existence (and after the demo they inform others).

• You are showing them how it works and how they would use it.

• You are learning from your potential customers what they want to know. Often the question and answer period after your demonstration is the most important part of your visit.

When visiting a user group, bring you own computer with everything set up and ready to go. You probably won't need a monitor, but ask ahead of time just in case. Now I'll remind you of the obvious: once you set a date, make sure you arrive with your demo well-prepared, machine fully tricked out, goodies to give away, and so on. Bring one or more copies of your product for a raffle. If you only sell online let them know that you'll send the product to the winner(s). If you're demonstrating to a PC user group instead of a Be user group let us know and we'll try to provide some things, like T-shirts and copies of BeOS to raffle, to help you out.

There are now over 100 Be User Groups (BUGs) and they are eager to see your products. They would be more than happy to arrange a meeting to show a Be app. You can find them on the web at:

http://www.be.com/usergroups/usergroups.html.

Send them a note asking if you can be added to their schedule. If you want more specific information about specific groups, contact sylvie@be.com.

Don't limit yourself to Be user groups! PC user groups are not necessarily Windows user groups and the BeOS runs on PCs. Everyone with a Pentium is ultimately a potential customer for your BeOS application, so it's a GREAT idea to look PC user groups and arrange to show them your product. The BeOS runs on Intel architecture, which means that there are a huge number of potential customers out there right now—but they don't know about you yet! You can bring the news about the BeOS to these groups by showing your product.

Here are some links to lists of PC user groups to check out:

http://www.apcug.net/
http://www.user-groups.com/
http://www.yahoo.com/Computers_and_Internet/Organizations/User_Groups/

One more thing—remember my article on sending press releases? It's also a good idea to send them to Be and PC user groups.

It's helpful to become familiar with the various BeOS-related web sites. Check them out! Contact the people in charge and find out how to send them news, articles, review copies, etc. A relationship with a news site is a relationship with its readers.

Tip: Advertise! You get exposure and the web site gets support if you place a banner ad on the web site!

Check the BeOS-related web sites below:

Be Leading Edge:  http://subway.student.utwente.nl/edge.html
BeOS Central:  http://beos.newdream.net/
BeHive:  http://www.zdnet.com/mac/behive/
Believe:  http://www.napanet.net/~xredbear/
Be Happy:  http://www.qnx.com/~chrish/Be/
Let It...Be:  http://www.boomweb.com/LetItBe/index.html
Be Dope  http://www.bedope.com/
Be News Now:  http://beos.ethereal.net/
BeOS for Intel:  http://www.befunk.com/
BeForever:  http://www.beforever.com/
BeIntouch:  http://www.guerilla.com/beintouch/
BeGames:  http://free.prohosting.com/~dunham/
Plan Be:  http://www.planbe.com/
BeGeek.com:  http://www.begeek.com/
BeTrieve:  http://betrieve.zippysoft.com/
Time to Be:  http://www.imada.ou.dk/~moriarty/be/
Be Different (Spanish):  http://web.jet.es/pong/

Here's something I've been meaning to bring up for a while: Shareware authors—consider selling your product as a commercial application instead of shareware. Selling your product commercially through BeDepot offers all the advantages of shareware with fewer disadvantages. Make your product available at low cost, a "no-brainer" price, and you won't believe how many you'll sell! The revenue can finance the next version, maybe even enable you to quit your day job.

One of the main reasons for making a product available as shareware has been the difficulty of collecting payment, especially using credit cards. BeDepot <http://www.bedepot.com/> collects payments for you, and even accepts credit cards. You just sit back and get checks.

Another typical reason for selling as shareware has been the difficulty of delivering the product once it is ordered. You either have to print manuals and boxes and duplicate disks, or send a large file (or ship a package) when you get the order. BeDepot delivers the product electronically for you.

So once again, I urge you to use BeDepot instead of trying to make money through shareware. You'll make more, with less hassle.

Another place to gather and spread information is on newsgroups. Check the Be newsgroups located at comp.sys.be.*. It isn't good manners to just show up and advertise (except at comp.sys.be.announce, if you follow their rules), but there is a lot to gain from being active on these newsgroups. You can help people with their questions and also get information from a wide variety of sources. Newsgroups are read by a lot of people, even if they are not actively posting, so being active helps you and your products become known.

Take a look sometime inside of support/ClassInfo.h. You will see some useful macros there that probably do not see the light of day as much as they should, at least if outside engineers are anything like we are. The cast_as() macro is the most important of these functions (although the others can certainly be useful.)

There are some places in the BeOS where void *s are thrown about with great abandon. Those that leap readily to mind include dealing with items from BLists and arguments for thread entry functions. It is very tempting to simply use C-style casts to deal with these pointers, but this is not smart. (And before we go farther I will admit to being dumb in all of my sample code until now, look for updates in the near future to correct this.) Let me give you a concrete example of how this could be problematic.

Assume that you have a BList that is (supposedly) full of BRect pointers. You want to look at these pointers and find one that contains a given BPoint. You would have a loop whose inner core looked like this:

BRect *rect = (BRect *) list.ItemAt(index);
if (rect->Contains(point)) {
  /* do something cool */
}

This is all fine and dandy if the item at index is actually a BRect. The result if the item is not a BRect is undefined (and probably most undesirable).

But there is a way to make sure that this slice of evil never occurs. Change the inner loop to something like this:

void *item = NULL;
BRect rect = NULL;

item = list.ItemAt(index);
rect = cast_as(item, BRect);
if (!rect) {
  printf("we don't have a rect here!\n");
  return B_ERROR;
}
/* we are safe and know that rect is indeed a BRect*/
if (rect->Contains(point)) {
  /* do something cool */
}

Now, in an ideal world you wouldn't end up with a situation where you have chosen the wrong BList to look through, or where you haven't accidentally added the wrong pointer to the right BList. But these things have been known to happen!

Another, and perhaps more common, use for the cast_as() macro is found when playing in the Interface Kit. There are many functions that simply return a generic BView*. Whenever these need to be cast to a more specific class using the cast_as() macro will prove much safer than a blind C-style cast.

A new thread control function was added to the Kernel Kit in Release 3 that deserves mention. snooze_until() allows a thread to block until a certain time is reached. This is exciting, of course, but how does snooze_until() differ from it's older sibling snooze()?

The most obvious way is that snooze_until() supports defining a time to awaken based on a named time base. In Release 3 the only time base supported is the B_SYSTEM_TIMEBASE, which simply deals with the system time. In the future we will support other time bases so snooze_until() could be used to block until a given frame of video is ready or until the next MIDI event needs to be sent.

The other major difference (and the only one of real use now) is that snooze_until() has been designed to be more accurate than snooze(). This accuracy comes in large part from the possibilities of being rescheduled between calls. Take the following example where you want to snooze for 25 milliseconds in between some printf() calls.

printf("let's print!\n");
snooze(25000);
printf("let's print again!\n");

In the best of all worlds there would only be the 25 millisecond interval between the calls. But in the worst case your thread could be rescheduled right after the first printf(), and when next rescheduled would immediately block for the 25 milliseconds, and then would be rescheduled after the snooze(). With a thread rescheduling latency of 1 -2 milliseconds, this could mean that you could sleep for a handful of milliseconds extra.

You could rewrite this code using snooze_until() and your worst case scenario would look a little better.

bigtime_t now = system_time();
printf("let's print!\n");
snooze_until(now + 25000);
printf("let's print again!\n");

This will base the wake-up time on the original "now" time, rather than the time that the snooze() function was called, and should be better.

There are currently some caveats, however. The difference in performance between snooze_until() and snooze() is generally not noticeable unless running within a real-time thread or if the amount of time to snooze is very small. In general, it doesn't make any sense to try and snooze for less than 1 millisecond, because interrupts are only looked at every millisecond. However, when snooze_until() is called and the amount of time left until the wake-up time is very small, it will return rather than have the thread rescheduled. This makes tight timing loops more accurate (assuming you have a need for such a tight loop anyway).

And as mentioned, this really only makes a huge difference when dealing with a real-time thread. If you are not dealing with a real-time thread there is no guarantee that you will run when you are ready. If higher priority threads are ready to run, they will go first, regardless of which type of nap you took. Even when dealing with a real-time thread, you must still be aware that there are latencies involved, on the order of 2-3 milliseconds max, and 1 millisecond on average, so timing loops will never be precisely accurate.

One last forgotten item. In the mad rush to get Release 3 out the door, we forgot to also release the GNU Public License code that used in the BeOS. We are rectifying this lapse in memory now.

We use GPL code for malloc, termcap and crypt. This are directly linked into the kernel, libroot, telnet, telnetd, top, and zbeos (the BeOS Intel bootloader). We have a single downloadable archive called gnu_x86.tar.gz that contains makefiles, the GNU source code, and object files that allow you to rebuild these components.

ftp://ftp.be.com/pub/gnu/gnu_x86.tar.gz

We also use GPL code for our 3Com 3C905 Ethernet drivers. This code comes from Linux and the source is available in an archive called linux_ether.tar.gz.

ftp://ftp.be.com/pub/gnu/linux_ether.tar.gz

The other GNU tools used by the BeOS are included in the /optional directory of the Release 3 CD.

The packages are complete and allow you to rebuild the GNU code and relink to produce the final binaries. Unfortunately if you make modifications (or used modified versions) we can't offer support if you run into problems.

We thank you all for your patience and friendly reminders to make these packages available. Be is a strong supporter of "free" software, and we will continue to do our best to comply with the license requirements of the code included in the BeOS.