Buried deep at the very heart of BeOS is a silent agent that rules the traffic inside the computer: the scheduler. The scheduler's job is basically to choose which thread will now run, and this happens whenever some special events trigger. The scheduler is one of the components that enable preemptive multitasking.

Warning

The technique described in this article is an unconventional way of programming (in other words, a hack). While it is believed to be reasonably safe, it has a number of side effects. Using it might make the system behave oddly, and/or exhibit problems in programs that otherwise seemed to work.

Warning

This article only deals with the case of a single CPU system. The behaviour of a multi-CPU system is somewhat more complex and is beyond the scope of this article

bare-bones                          35            3060
bare-bones, with annoying program  136            3219
bare-bones, with annoying
program and rescheduler            365             459
normal                             702            4776
normal, with annoying program     1139            6127
normal, with annoying program
and rescheduler                   2970             838

In my last article for the newsletter, I presented a simple network server program that would respond to connections by spewing back the entire contents of a file, with a very simple header.

Developers' Workshop: Serving It Up: Creating a Simple Server Application

I received a few emails thanking me for this example, but a couple of them suggested that I should also show the other side of the coin: how about a client designed to access this server?

So this week we'll have a look at Requester, the counterpart to the Responder program created in my last article.

Before we begin, I should point out a trio of matching silly bugs in Responder:

connect->Send(&buffer, count);

ssize_t size = file.Read(&buffer, 65536);
connect->Send(&buffer, size);

On these three lines in the send_file() function, the "&" is unnecessary (and is in fact a major bug). The code worked, but was stomping loudly through memory. Just take those "&" characters out and everything will be much better.

OK, on to the Requester program:

#include <NetAddress.h>
#include <NetEndpoint.h>
#include <File.h>
#include <stdio.h>
#include <socket.h>
#include <OS.h>
#include <stdlib.h>


static status_t request(char *host, char *filename);

int main(int argc, char *argv[]) {
    char *filename;
    char *host;
    status_t err;

    if (argc != 3) {
        printf("usage: requester <host> <filename>\n");
        return 1;
    }

    host = argv[1];
    filename = argv[2];

    err = request(host, filename);

    if (err == B_OK) {
        printf("File received.\n");
    } else {
        printf("An error occurred receiving the file.\n");
    }

    return 0;
}

The primary purpose to main(), as in Responder, is to parse the command line and dispatch control. As a client, we won't bother to spawn any additional threads. We just grab the first argument as the hostname to connect to and the second as the filename with which we'll save the retrieved file. We then call request() to actually handle the networking.

status_t request(char *host, char *filename) {
    BNetEndpoint server;
    status_t err;
    bool first_buffer = true;
    uint8 buffer[65536];
    uint8 *bufstart;
    int32 count;
    char header[32];
    off_t filesize;
    BFile file;

    if (server.InitCheck() < B_OK) {
        return B_ERROR;
    }

As in Responder, we start by instantiating a BNetEndpoint and then we check to ensure that it's valid by calling InitCheck(). If it's invalid, we return an error.

    err = server.Connect(host, 4242); // Connect to server
    if (err < B_OK) {
        goto bail;
    }

Then we connect to the host, whose name was specifed by the user on the command line. If this fails, we use the oft-debased but occasionally handy goto statement to bail out of the request() function.

After this, the loop to receive the file begins, since immediately after we connect to the server, we'll begin receiving data. We use a while loop to continue to receive until there's no more data. Since there's a header that needs to be parsed, we special-case the first buffer using the first buffer flag. Once we've received the first buffer, we clear the flag so we won't look for the buffer anymore.

    while ((count = server.Receive(buffer, 65536)) > 0) {
        if (first_buffer) {
            int i;

            first_buffer = false;    // Don't do this again
            for (i=0; i<32; i++) {
                if (buffer[i] != '\n') {
                    header[i] = buffer[i];
                }
                else {
                    header[i] = 0;
                    break;
                }
            }
            // Got the header.  Parse it.
            if (!strcmp(header, "ERROR")) {
                err = B_ERROR;
                goto bail;
            }
            filesize = atoll(header);
            if (!filesize) {
                err = B_ERROR;
                goto bail;
            }
            i++;
            bufstart = &(buffer[i]);
            count -= i;
            file.SetTo(filename,
            B_CREATE_FILE|B_WRITE_ONLY);
            if ((err = file.InitCheck()) < B_OK) {
                goto bail;
            }
        }
        else {
            bufstart = buffer;
        }

If the first_buffer flag is true, we begin by clearing it so we don't try to parse headers out of future blocks. Then we copy the header into the header string. Since the header is always a one-line string (either the file size in bytes or "ERROR" followed by a newline), this is easy to do.

Once the header has been grabbed, we check to see if it's "ERROR". If so, we return B_ERROR to the caller. Otherwise, we use atoll() to get the file's size from the header. Then we set bufstart, our buffer pointer, to point past the header, and subtract the appropriate number of bytes from the buffer size in count.

Then the file is opened; if this fails, we return the appropriate error.

If the buffer isn't the first, we simply set the bufstart pointer to the beginning of the buffer, since we want to process all of it.

        err = file.Write(bufstart, count);
        if (err < B_OK) {
            goto bail;
        }
    }

    err = B_OK;

bail:
    server.Close();
    return err;
}

Then we write the buffer to the file, starting at offset bufcount, and writing count bytes. If an error occurs, we bail out. Otherwise we continue looping until Receive() returns 0, meaning the connection has closed. We then close the BNetEndpoint and return.

When you build this code, don't forget to link against libnetapi.so.

This working client shares limitations with the Responder server—it sets the filename of the retrieved file to the name the user specifies on the command line (the server doesn't tell the client what to call the file), and file attributes aren't maintained. Only the file's data is transmitted. If you transmit an application, you'll have to chmod +x the file before you can run it.

When an idea, a proposition, a cause is presented to me in terms that leave me no alternative but to be for it, because it's all pros and no cons, then I know I'm being conned. How can I be against freedom? How can I be against innovation? How can I be against freedom to innovate? So, when I hear Microsoft's carefully orchestrated refrain—all we ask is the freedom to innovate, we'll never renounce our freedom to innovate -- being sung by top executives and paid consultants, I wonder. Do they really believe this? Or is it a calculated bet on what our emotional response to an appeal to higher principles will be?

Last Friday, November 5th, Judge Jackson gave his decoding of Microsoft's refrain. His finding of facts concludes that Microsoft is a monopoly. To quote his concluding paragraph:

The entire document is at <http://usvms.gpo.gov/findfact.htm>. It's long (412 paragraphs), but worth reading. It's written in plain English and takes pains to establish definitions for products and markets in order to create a structure for the findings.

The net effect of the finding is troubling. Even for someone as ambivalent (as in having truly mixed feelings) as yours truly towards Microsoft, my emotions range from surprise to sadness, laced with the expected irritation. Surprise, because I didn't expect the breadth and depth of abuse of power discussed by Judge Jackson's. From large companies such as IBM or Intel, to ISVs, service providers, and tiny start-ups such as ours, no one seems to escape Microsoft's vigilance. "Most harmful of all is the message that Microsoft's actions have conveyed to every enterprise with the potential to innovate in the computer industry", concludes the Judge.

My sadness at the language and conclusions of the finding comes from looking at the impenetrable wall of paranoia and misunderstanding. I'm reminded of a six-hour conversation I had with Bill Gates at a PC Forum conference early in 1988. He complained repeatedly that Apple didn't trust him, and nothing I said could help him see why his actions and words created fear and distrust.

A decade later, I've personally seen grown men fear for their company and themselves at the thought of incurring Bill's wrath and Microsoft's retaliation if they didn't "behave." DOJ officials spoke bitterly about PC makers' unwillingness to come forward to testify about Microsoft's business practices. Perhaps, but they would have done so at great potential cost. I'm in no position to blame them; I declined to testify because it might have interfered with other projects that were then pending at our company and also because testifying would have cost us hundreds of thousand of dollars in legal fees. We couldn't take those risks.

Still on the topic of the wall of misunderstanding, there is Microsoft's "what's mine is mine, what's yours is negotiable" attitude. Bill Neukom, the company's chief legal eagle, takes the position that "It's our song" when asked about the restrictions placed on Windows licensees. It's our song and we're free to dictate the way it'll be played on PCs. This is a strange metaphor. If I pay the royalties, I'm free to sing "Let it Be" in any key I want, preceded and followed by whatever act I fancy.

Returning to Microsoft's licensing, they used it as a club to prevent potentially errant PC makers from making BeOS visible to their customers. It "works" like this: You can use Microsoft's boot manager to load any number of OSes, as long as they're made by Microsoft. If you (the PC OEM, Windows licensee) use a non-Microsoft boot loader, you cannot use it to load Windows. If you do, you're in violation of the license and you could lose it—and your business.

That's how Microsoft prevented Hitachi from visibly offering Windows and BeOS at boot time. BeOS was loaded on the hard disk, but the customer didn't see the choice at boot time. You'd have to read complicated instructions to set up a dual-boot situation yourself. A neat legal trick that effectively prevents PC OEMs from offering a genuine dual-boot situation featuring both Windows and BeOS.

In that context, when I'm asked what Judge Jackson's ruling changes for us, I have to say that in the short-term, materially, not much. Psychologically, however, it's different. The ruling could open minds and, perhaps, doors. By shedding light on Microsoft's practices, the finding of fact might limit the company's ability to leverage its dominance of the PC market into the emerging Web appliance sector. As for specific remedies, they constitute a complicated, controversial topic. Fortunately, I found one well-written survey of this issue in this week's Time magazine (dated November 15th), shorter than Judge Jackson's document but balanced and complete nonetheless.