A lot of Be developers have expressed interest in writing drivers for all sorts of network media, such as ATM, 100VG, 100Base-T, alternative ISA and PCI Ethernet cards, PLIP, and SLIP. In fact, I've had more requests about doing network media drivers for the BeOS than doing anything else that's network-related, whether it be alternative protocol stacks, TCP enhancements, or application issues. It isn't what I expected, but then again, things never are.

In response to the great developer interest in doing network drivers, I'll do two things:

• First, I'll increase the priority of developing a netcard driver architecture for BeOS, aiming for release in DR9.

• Second, I'll start an "early adopter" program where you can get started with DR8. To enroll in the program, all you need to do is read this article and download some stuff from the Be FTP site. I won't ask you for money, date of birth, spending habits, or how often you pick your nose.

Now, for some caveats and limitations:

• The DR8 version of the driver architecture will only support Ethernet drivers or things that look like Ethernet. In other words, your driver had better be prepared to read and write 1514-byte packets, including the 14-byte Ethernet header. The header contains the 48-bit destination address, followed by the 48-bit source address, followed by the 16- bit protocol field.

• A lot of things will change when the API is officially released, so please don't start flaming me when your code doesn't recompile or your binary stops working.

• The interface presented here is somewhat messy. Its purpose is to get you started getting real work done, not to be framed, placed lovingly upon a wall, and admired for hours on end.

OK, now that we have that out of the way, let's get down to business.

The BeOS is full of lots of nifty things that make programming a breeze. We'd like you to think that the API presented by the system is much easier to use than a lot of legacy systems. Well, this is true to a point. And that point is what distinguishes Be, Inc. from everyone else. Even if the API isn't easier in some areas, we will make sure that it is at least well understood so that useful work can be done as painlessly as possible.

On BeDevTalk and comp.sys.be there has been much discussion about issues at as low a level as the effects of cache line contention on multithreaded applications, and as relevant as optimal graphics blits using the vertical blanking area of a graphics card.

Well, I've also received requests for some very basic information on how to get started using the BeOS. This week I'd like to address this very basic need.

"The Be Book" is very good at explaining the API of the system as it exists. There are now currently a number of sample programs that developers can look at to get started. But there doesn't necessarily exist a straightforward tutorial on how simple things should actually get done.

So... You will find such a tutorial in: ftp://ftp.be.com/pub/Samples/January.tgz

It's about time! Well, actually it's not, it's just a simple calendar program.

In this tutorial you will find things such as:

• How do I create a basic GUI based application?
• How do I draw to the screen?
• How can I display text quickly?
• How do I deal with messages?
• How do I close down the application cleanly?

The sample application is a simple calendar display of the month of January. The application itself isn't too fancy, as we don't want its functions to get in the way of a clear understanding of what's going on. But there's enough interesting stuff to make it less trivial than the HelloWorld application.

Most of the information in the tutorial can ultimately be found in "The Be Book," but this tutorial puts it together in a succinct way so that you don't have to go read the whole book to figure things out.

I have a particular agenda for what things will be introduced in tutorials in the near future, and in what order. If you have any requests, please feel free to e-mail me and tell me what you want (wadams@be.com).

I'm not a professional programmer. I'm a chemist working on organic and inorganic hybrid materials for a Japanese automobile company. Currently, I'm studying the reaction of silane compounds and the product consequent to such reactions.

In my laboratory I use a number of different scientific instruments, which output data in various formats: MS-DOS text from the X-ray diffract meter, CP-M unknown files from the Infrared spectrometer, USCD P-sytem(!) files from TG/DTA. Most modern instruments are computer-controlled, but some of the older instruments—the pH meter, thermometer, and so on -- give me only DC voltage, and I have to store the data on an analog chart recorder.

Old or new, almost all my instruments have either a serial port or an analog voltage output. To manage all my instruments in a uniform way, I need a PC that accepts both analog data and digital data. This PC is called the BeBox. It has a nice "GeekPort" and many serial ports (including the MIDI ports—it can convert physical properties to musical data!). I want the BeBox to be the interpreter between my instruments, and to control the machines that don't naturally understand digital signals.

I have just received DR8 and am studying the GeekPort. My plans are only just forming, but here's what I'm thinking: One of my ideas as a chemist is to make an easy-to-use, data-collection/analysis/synthesis-control program. As a geek who likes music, I'd also like to make a MIDI-to-CV converter application that can play the antique music synthesizers I have (the one that don't understand MIDI signals).

Of course, the BeOS isn't perfect; I wish it could handle the 2-byte character codes we use to represent the Japanese language. I've heard that the BeOS will support Unicode in the near future. This is a start -- but in Japan, we use JIS code on the internet, and S-JIS code on PCs and Macs. If the BeOS is going to compete with PCs and Macintosh in the Japanese market, I think it must at least support S-JIS Kanji code.

Last time I started to describe our channel strategy and promised future articles to elaborate on it. I haven't forgotten this promise, but, this time, I wanted to take a side trip into a topic that's always on our minds at Be: recruiting.

Startup companies tend to have two distinct recruiting modes: "Pain relief" and "go for it." You may not be familiar with these terms (I just made them up), so let me explain.

The "pain relief" mode of recruiting involves hiring people into the organization when the workload on people already in the company has attained maximum tolerable pain level. For example, if you find yourself waking up in the morning with your face down on your keyboard, you've probably reached this level. I should hasten to add that this is a rare occurrence at Be and, when it does happen, has occasionally resulted in the production of useful code, C++ being a sufficiently flexible language that random nocturnal movements of one's face on the keyboard during REM sleep can generate compilable code. "Pain relief" recruiting is partly a way of conserving cash during a company's formative years, mostly a consequence of the fact that, when you're busy, it takes longer than it should to hire new people.

The "go for it" mode of recruiting involves eyeballing a one, two, or three-year business plan, deciding that the company is destined for continued, solid growth, and hiring ahead of the curve to ensure that the growth is actually supportable.

You're probably ahead of me at this point: Be is about to enter a phase of "go for it" recruiting in the sales, support, and marketing areas. Next month, we'll be shipping Developer Release 8 of the BeOS for PowerMac, and "MacTech" magazine will be bundling a free copy in its January issue (which will also ship next month, because magazine publishers have a different calendar from the rest of us). Early next year, we'll be shipping a release of the BeOS for PowerMac targeted at a wider audience, not just at developers. This translates into big volumes, which in turn translates into the need for excellent order fulfillment, customer support, and technical support organizations.

Our web site will carry detailed job descriptions of positions as they come open; check out http://www.be.com/aboutbe/jobs/index.html if you're interested. During the next two months, we'll be building the support organizations designed to carry us through what promises to be a very interesting 1997.

The one-two punch of good news from Apple deserves more than a perfunctory cheer, it signals a new competitive stance and raises interesting questions for the Mac clone makers, including Motorola (who makes the PowerPC chips and is to supply Mac motherboards to cloners). Apple's numbers surprised most analysts. They expected a loss in the $30-60 million range. Instead, Apple posted a $25 million net profit. Perhaps more important, Apple's cash flow from operations amounted to $410 million. The next day, the company made headlines again by announcing some of the models Apple's COO had energetically previewed the week before—with surprisingly low prices. The new Performa 6400 models are priced several hundred dollars lower than Wintel clones with comparable processor speeds. The announcement was so sudden it must have caught some resellers off guard. This Sunday's "New York Times" offers an IQ test in the same J&R ad: would you rather buy a 120MHz 7200 with 16 MB RAM, a 1.2 GB drive, and a 4X CD-ROM, or a new 200 MHz 6200 with 16 MB RAM, a 2.4 GB drive, 8X CD-ROM, and 28.8 Kbps modem, microphone, and speakers thrown in? We can expect a little scrambling here and there. The rumor is Marco Landi won the decision for these aggressive prices at the last minute. Planned or not, this is exquisite timing, right at the edge of the Christmas buying season. First, announce financial results showing Apple coming out of a tailspin. This tells potential buyers they can trust Apple to be around for a while. Second, blow away the old Wintel selling point—price. This should make for an interesting quarter. Writing Apple's obituary isn't new: When I first started at Apple, naysayers were already predicting Apple's impending demise by reason of lacking CP/M and 8-inch floppies—and the company's imminent destruction by Fortune Systems homing in on Apple with 68000-based Wang emulation. Not then, not now. And marketing being just as much about minds as things, there's reason to hope Apple is beginning to reverse its downward momentum.

A few interesting questions remain, though. FY 96 revenues fell about 11 percent below the FY 95 $11 billion level, and this past quarter sales fell 23 percent under last years comparable level, this at time when the PC industry continues to experience double-digit growth rates. This could explain the aggressive pricing for the new models. Notwithstanding the dangerously naive "Win 95 = Mac 89" bumper stickers, the Macintosh had lost its technical edge over the Wintel machines and it was more expensive. This is no longer the case. It will be interesting to watch if and how new entrants, such as Sony and Toshiba, react and reprice their new 200 MHz machines and how the established home Wintel machines get repositioned against an aggressive 160 Mhz Performa at $1,499.

This, in turn, raises another question: What about the PowerMac clone makers? A few days before the latest announcement, a new Mac compatible maker appeared on the scene, APS, well-known in the Mac market for their storage devices and accessories. ("Maker" is probably a misnomer, as Motorola will make the motherboard and chassis for APS's clone.) The prices posted on their web site are not materially different from comparable Apple machines. Apple even appears to enjoy an advantage in bundling a modem and an interesting collection of software. Apple execs have been heard grumbling that clone makers were "cherry picking," that is, going for the juiciest higher-end segments of the Mac market instead of obediently focusing on the low end, where Apple couldn't make money. Things will get interesting and will test Apple's genuine will to create a vibrant hardware market based on the Macintosh platform. The conversations among Apple, Motorola, and clone makers are likely to be animated. Who gets the best price for processors, and by how much? Apple, the Motorola division making Mac motherboards, or Power Computing if they buy CPU chips from IBM? Besides the cost of the microprocessor, who manufactures the lowest cost motherboard: Apple, Motorola, Power Computing? We'll be watching to see whether the Mac clone market becomes freer or if it becomes smothered by the kind of "managed competition" that brought other plans to a halt.