You may remember that BeOS Release 3 wasn't up to handling removable media in a flexible way. The SCSI and IDE drivers would fail to open if there was no media in a drive. This caused applications like DriveSetup and Tracker to open and close devices to check whether the media in the drives had changed. There are several disadvantages to doing this:

• The driver may be reloaded each time you check for media

• You can't get information about drives with no media

• You can't operate devices with no media

• The driver decides if you should wait on a busy drive

Let's look more closely at these problems. First, since BeOS unloads drivers that are not in use, using open/close to detect media presence often causes the driver to be reloaded. If the driver doesn't publish other devices that are in use, keeping the driver loaded, the device can never be opened when there is no media. The result is that every time you check for media the driver has to be loaded and initialized, then open is called, open fails, and the driver is unloaded. Since the IDE and SCSI drivers are built into the kernel, this is only a problem in Release 3 if you use third party drivers.

The second problem is more serious. That is, you can't get any information about a device. This means that an application like CDPlayer in Release 3 uses special devices that store information about all IDE and SCSI devices. It then uses this information to tell which devices are CD-ROM drives. So, for example, if you want to add a driver for a sound card CD-ROM interface, CDPlayer would not find your device. A less serious problem is that you can't see the icon for a device unless there is media in the drive.

Third, you can't operate devices with no media. This means that you can only eject media, you can't open an empty tray or close the tray of a CD-ROM drive.

Finally, the driver decides if you should wait on a busy drive. This means that either the open fails or it blocks until the drive is ready. The application may want to make that decision, so it can inform the user that the drive is busy, instead of just blocking.

R4 solves these problems by adding an ioctl, B_GET_MEDIA_STATUS, to get the media status. Open will succeed even if there is no media in the drive, and the driver will accept commands that do not require the media to be present. The following code shows how this ioctl can be used.

status_t media_status;
if(ioctl(devfd, B_GET_MEDIA_STATUS,
     &media_status, sizeof(status_t)) < 0)
{
  // old driver, abort
}

switch(media_status) {
  case B_NO_ERROR:
    // drive ready with media
    // enable all controls
    break;
  case B_DEV_NO_MEDIA:
    // no media in drive
    // disable controls that need media
    // delete information about media
    // load eject still works
    break;
  case B_DEV_NOT_READY:
    // drive not ready.
    // disable controls, keep media information
    break;
  case B_DEV_MEDIA_CHANGED:
    // media in drive has changed
    // delete old and collect new information about media
    break;
  case B_DEV_MEDIA_CHANGE_REQUESTED:
    // user pressed eject button on drive
    break;
#if R5
  case B_DEV_DOOR_OPEN;
    // eject/load button loads
    // handle ad B_DEV_NO_MEDIA;
    break;
#endif
  default:
    // unknown state
    break;
}

R4 adds another ioctl, B_LOAD_MEDIA, that tries to load media into the drive. Most CD-ROM drives use a tray to load CDs; for these drives B_LOAD_MEDIA closes the tray if it is open. R4 does not define a separate status for a drive with the door/tray open. If you want a combined load/eject button, you need to know if the door is open or not. If you need to do this, you can contact me about how to use the raw SCSI/ATAPI command interface, or you can wait for R5.

An important result of open succeeding with no media in the drive is that you can now iterate through devices in /dev/disk to find drives of a specific type. This is very useful for CDPlayer-type applications that want to find all CD-ROM drives in the system. Note that CD-ROM changers normally publish a separate device for each slot. In other words, make sure you allow the user to easily switch between the devices you find.

The following code shows how to find CD-ROM devices:

void search_dir(const char *dirname)
{
  BDirectory dir;
  dir.SetTo(dirname);
  if(dir.InitCheck() != B_NO_ERROR) {
    return;
  }

  dir.Rewind();
  BEntry entry;

  while(dir.GetNextEntry(&entry) >= 0) {
    BPath path;
    const char *name;
    entry_ref e;

    if(entry.GetPath(&path) != B_NO_ERROR)
      continue;
    name = path.Path();

    if(entry.GetRef(&e) != B_NO_ERROR)
      continue;

    if(entry.IsDirectory()) {
      if(strcmp(e.name, "floppy") == 0)
        continue; // ignore floppy (it is not silent)
      search_dir(name);
    }
    else {
      int devfd;
      device_geometry g;

      if(strcmp(e.name, "raw") != 0)
        continue; // ignore partitions

      devfd = open(name, O_RDONLY);
      if(devfd < 0)
        continue;

      if(ioctl(devfd, B_GET_GEOMETRY, &g, sizeof(g)) < 0)
        continue;

      if(g.device_type == B_CD)
        printf("found CD-ROM drive, %s\n", name);
    }
  }
}

void find_cdroms()
{
  search_dir("/dev/disk");
}

A final note if you are writing a disk driver that supports removable media. To ensure that media changes aren't ignored, the change has to be reported to all open file descriptors. When the driver detects that the media has changed, it should set a flag for each file descriptor that the media has changed. This flag should only be cleared by a B_GET_MEDIA_STATUS ioctl on the corresponding file descriptor. This is important, as it forces the caller to deal with the change. If the driver doesn't behave this way it's possible for an application to read a buffer from one disk, modify it, and write it back to another disk by accident.

For R4 only the IDE drivers implement B_DEV_MEDIA_CHANGED, so be careful with other drives, just as you were in Release 3.

I've been preoccupied lately with the R4 Beta Test, so it came as a surprise that I had two articles due this week, one for the Newsletter and one for the Developer Letter. I tried to get one of my DTS minions to pinch hit, but nothing doing. Being a manager is not all it's cracked up to be.

So here's an article and sample code to introduce a couple of new features of R4. The code runs only under R4, but you'll be getting that soon enough.

The code can be found at:

ftp://ftp.be.com/pub/samples/application_kit/Watcher.zip

Watcher is a very simple application. It keeps a current display of two sets of items: the currently running applications (with the active application in red), and a list of mounted and previously mounted volumes, the latter in blue.

Both of these tasks could be performed in R3, but with difficulty. To keep track of the apps, you had to poll the be_roster to get the list of running applications, and then check to see which one was active. You had to poll fairly constantly to keep the list up to date. On the volume side, a simple call to BVolumeRoster::StartWatching() would inform you about mounting and unmounting volumes, but determining if a newly mounted volume and a previously mounted volume with the same name were identical was difficult at best.

New features in R4 make these trivial to implement, which is what I've done in Watcher.

Watching applications is straightforward. The BRoster class now has StartWatching() and StopWatching() functions, letting you specify a BMessenger to receive notifications about launching, quitting, and activating applications. The messages sent in response to these requests contain the application signature, the team_id, the main thread_id, the launch flags, and the entry_ref for the application's binary. This concise information allows Watcher to display the application names and teams, and keep the list applications launched, quit, and newly activated up to date.

Keeping track of unique volumes is also much easier in R4. A new "be:volume_id" attribute is tagged onto the root folder of volumes. This uint64 provides an identifier that persists between mountings of the volume and boots of the BeOS. Now applications that need to uniquely identify volumes (like back-up utilities or databases) have an easier time. Watcher keeps track of all the persistent volumes mounted on the machine, and displays the volume_id, device id, and name of each. When a volume is unmounted, Watcher marks it in blue. When it is mounted again, Watcher looks to see if it can find a match for the volume_id, updating the device number and name of each volume appropriately.

That's pretty much it for Watcher. If you want to take a bit more advantage of its capabilities, you could expand it to watch MIME type information as well through the new BMimeType StartWatching() and StopWatching() functions. These inform a BMessenger of changes made to existing MIME types, but don't inform it when MIME types are added or deleted. Also, Watcher makes limited use of the new BString class for (you guessed it) string manipulation.

Look for these and other interesting features when R4 is released.

And now back to beta testing...

This article is written for engineering-oriented software developers who have a product to sell but have minimal marketing experience to guide them in the business side of the venture. The article introduces the concepts behind basic marketing research and offers practical examples of methods for conducting and analyzing simple tests. References to some more extensive web-based marketing research information are included at the end.

Anyone with surplus "thrill genes" might want to avoid this article. I'm going to spoil the fun and show you how to reduce the element of surprise when making business decisions.

I know, I know—what fun is it without the risk? Do you really want to give up the rush you get from making a big bet and waiting to discover that a strategy works or doesn't? Do you need to experience the extreme lows of utter failure to fuel your creative spurts?

I'm going to write about testing, measuring, and analyzing the collected data (marketing research). In later articles I'll talk about incorporating this data into the process of planning, projecting, and budgeting. This will ultimately lead to talking about developing a comprehensive business plan (groan). If you're not careful I might even turn you into a dreaded bean counter.

As one Apple wag used to say, the good thing about standards is that there are so many to choose from. That was said about ten years ago by Larry Tesler, known for his dry wit and his early work on the Lisa. Ten years later, we have even more standards, more confusion and, as a result, more difficulty establishing new standards.

Take HDTV and Digital TV, for instance. Last weekend, the local and national press, namely The New York Times, The San Francisco Chronicle, and The San Jose Mercury News (http://www.nytimes.com/library/tech/98/10/biztech/articles/26hdtv.html, http://eXaminer.com/981101/1101goodman.shtml, and http://www.mercurycenter.com/premium/unmarked/wire/89273l.htm) all wrote skeptical articles about the beginning of HDTV broadcasting. The skepticism is largely warranted by a long list of obstacles that HDTV must overcome before it becomes a reality. The sets are too expensive, the broadcasts are too few, the new equipment to produce HDTV content is more expensive, and, in any event, consumers don't care and wouldn't know the difference.

In many respects, it's chicken and egg situation, a vicious circle: no viewers, no broadcasts. The situation is made worse by the carriers, cable and satellite systems. The federal government has some power to dictate the use of the ordinary broadcast spectrum—hence the few hours of HDTV broadcast in the major markets (see the map in the NYT story) -- but the cable industry feels no real pressure to make costly updates to infrastructure and cancel a few home shopping channels in order to free bandwidth for HDTV.

Furthermore, consumers don't know what HDTV is. They don't know the difference between HDTV and DTV and Digital Television. They don't realize that broadcasters and cable operators would rather have several digital channels than one HDTV program. And, speaking of digital channels, because of cable and satellite systems, more and more TV today is "digital," even if the viewer doesn't realize it. Yet this isn't what the industry means by digital TV, which, in turn is different from HDTV. This confusion does not make the consumer feel smarter and safer, the necessary preconditions to separating him or her from a sizeable sum of money.

In general at Be, we love to see a little transition confusion in the marketplace; it creates an easier situation for us to carve new terrain, if we move fast enough and place the right bets. On the other hand, confusion paralysis doesn't help us. A reasonably clear DTV/HDTV picture, if you pardon the expression, would help the industry invest in content creation tools, and we would love to be of service in this domain.

Closer to us, there is a more modest standard called FireWire, IEEE-1394, or i.LINK, as Sony calls it for their DV cameras. This one, after about ten years in development, now seems ready to take off. Compaq offers it on selected Presario models and Sony on the GX version of their sexy new 505 laptop. This is promising, and, as soon as DV cameras cost less than the PC in charge of editing the DV tapes, we'll finally reach desktop video heaven—a nice opportunity for us to please a large number of users.

DV cameras really create a new standard of quality and usability well within the financial reach of the consumer. Better pictures, smaller cameras, easier connection to a computer. That shouldn't confuse consumers too much and my friends the marketing haruspices assure me 1999 will be the year of DV and, as a result, the year of FireWire.

The Presario model I saw at Costco the other day bore witness to the advent of another nice standard: USB. This computer offers three connectors up front (NOT in the back), USB, USB, FireWire—or digital photo camera, scanner and DV camera—the perfect system for our customer and our product.

USB also took a long time to happen (though only half as long as FireWire) and finally delivers much nicer low- to medium-speed peripheral connectivity. No more fighting for serial ports or risking sanity by adding ports to your PC. To borrow language from corporate America, FireWire and USB lower the cost of owning a media manipulation system.

The only piece of bad news—temporary we hope—is the accumulation of all these standards in a PC. Serial and parallel connectors, as well as USB and FireWire, IDE and SCSI, must coexist on some motherboards, just as PCI and ISA do. This standard medley adds cost and complexity to today's PCs, but that's an infinitely better situation than the vicious circle that's likely to paralyze the progress of a new TV standard, a problem sadly without apparent solution.