Issue 1-46, October 23, 1996

Be Engineering Insights: Writing Netcard Drivers for the BeOS

By Bradley Taylor

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:

Now, for some caveats and limitations:

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

The DR8 Version

For the DR8 version, an Ethernet driver consists of two binaries. The first is the low-level device driver for the card you're interested in. The second is a high-level add- on, which is used to configure the card. For example, let's say your card is the fictional "Ackme" card. Your device driver would be stored in "/system/drivers/ackme", and your add-on would be in "/system/add-ons/net_server/ackme".

The device driver needs the following standard device driver entry points: open(), control(), read(), write(), and close().

  • open(), in most cases, should always return B_NO_ERROR. The actual opening of the card is performed by...

  • ...the control() call. There are two messages for the control call: ETHER_INIT and ETHER_GETADDR. ETHER_INIT takes card-specific parameters —such as IRQ values or I/O port numbers—and attempts to open the card. ETHER_GETADDR returns the 48-bit Ethernet address associated with the card.

  • read() blocks until a packet is received, and then fills in the input buffer with the packet contents (including header) and returns the size.

  • write() does the opposite of read().

  • close() does pretty much what you would expect.

The add-on contains three entry points: configure(), driver_open(), and get_pretty_name().

  • configure() is the main guts of the add-on. It's called by the Network preferences application, and its job is to put up a window to ask users how they want the card configured.

  • driver_open() is called by the net server to open the driver. It returns a file descriptor that the net server will invoke ioctl(), read(), write(), and close() on.

  • get_pretty_name() is called by the Network preference application to print a more mnemonic name for the driver, such as "3Com Etherlink II" rather than "3c503".

There are a lot of details that I've left out here, but the source code from the FTP site should be pretty self- explanatory.

The Future

The API for the "real" architecture will be a lot cleaner than this. Most likely, it will be an object-oriented add-on that the net server and Network preferences application can both use. The add-on, in turn, may invoke its own device driver, but that's an implementation detail that only the add-on will need to know about. Therefore, some network drivers can be written completely as user programs. However, anything that wants to catch interrupts must have a device driver component.

Stay tuned for further details. In the meantime, check out ftp://ftp.be.com/pub/Samples/netcard_driver.tgz.


News From The Front

By William Adams

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:

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).

From Your Bench

Here are some recent ftp.be.com uploads that you might find interesting and want to employ.

Title: BeInfo
Location: ftp.be.com/pub/contrib/util/BeInfo.tgz
Author: Frederic Tessier (tessier@moebius.qc.ca)

This is a nice system info display that shows you things like memory used, pages, semaphores, ports, threads, teams. It also shows machine ID, type of CPU, clock rate, and PCI bus clock rate. The display of resource information is updated periodically.

Title: New games including BeTetris, XOIDS
Location: ftp://ftp.be.com/pub/contrib/games

Need I say more? Everybody needs a way to burn all those extra cycles on their machines. Here are a few games that will help you do this with ease.

Title: DataTypes
Location: ftp.be.com/pub/contrib/libraries/Datatypes13.tar.gz
Author: Jon Watte (hplus@ix.netcom.com)

This is one of the most powerful concepts that exists on the BeOS. The problem is simple: How can you translate between file types without having to write a whole bunch of code? This library provides a framework that should be used by all developers interested in integrating foreign data.

Jon Watte, who happens to work for Metrowerks, has developed and provided this library on his own time to make the BeOS incrementally better than what's available on other platforms. You can't go wrong using this free software, or at least learning from it and trying to implement your own framework (please don't do this).

Jon is very receptive to suggestions as to how this library can be improved and has been trying to get it adopted for the longest time. There is probably no better endorsement than from the horse's mouth, so I say, "Go use this thing." It will be used in future tutorials as a matter of course. Get used to it, feel comfortable with it, make suggestions as to how it can become better.

The Demo Scene

We are presently in the process of compiling a demo CD, which will be used by the Be demo team to show off the BeOS around the world. We have asked that developers wanting their software to show up on this CD make it available real soon. The first CD will be pressed within a week (by October 28). Don't panic if you can't make it for this one. There will be more in the future, because we always want to put our best foot forward.

If you have any ideas or votes for your favorite demos, please feel free to drop me e-mail and voice your opinion. You probably know as well, if not better than we, what really excites people about the BeOS.


Be Developer Talk: Masaaki Tani, Toyota Central Research & Developement Laboratories, Inc.

By Masaaki Tani

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.


Be Marketing Mutterings: Recruiting

By Alex Osadzinski

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.


Apple's Quick Rebound

By Jean-Louis Gassée

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.

Creative Commons License
Legal Notice
This work is licensed under a Creative Commons Attribution-Non commercial-No Derivative Works 3.0 License.