594 lines
43 KiB
HTML
594 lines
43 KiB
HTML
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
|
||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Be Newsletters - Volume 2: 1997</title><link rel="stylesheet" href="be_newsletter.css" type="text/css" media="all" /><link rel="shortcut icon" type="image/vnd.microsoft.icon" href="./images/favicon.ico" /><!--[if IE]>
|
||
<link rel="stylesheet" type="text/css" href="be_newsletter_ie.css" />
|
||
<![endif]--><meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /><link rel="start" href="index.html" title="Be Newsletters" /><link rel="up" href="volume2.html" title="Volume 2: 1997" /><link rel="prev" href="Issue2-8.html" title="Issue 2-8, February 26, 1997" /><link rel="next" href="Issue2-10.html" title="Issue 2-10, March 12, 1997" /></head><body><div id="header"><div id="headerT"><div id="headerTL"><a accesskey="p" href="Issue2-8.html" title="Issue 2-8, February 26, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a accesskey="u" href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a accesskey="n" href="Issue2-10.html" title="Issue 2-10, March 12, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="headerTR"><div id="navigpeople"><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div><div class="navigboxed" id="naviglang" title="English">en</div></div><div id="headerTC">Be Newsletters - Volume 2: 1997</div></div><div id="headerB">Prev: <a href="Issue2-8.html">Issue 2-8, February 26, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-10.html">Issue 2-10, March 12, 1997</a></div><hr /></div><div class="article"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Issue2-9"></a>Issue 2-9, March 5, 1997</h2></div></div></div><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering2-9"></a>Be Engineering Insights: Will Your DATA Look Like ATAD?</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Bradley</span> <span class="surname">Taylor</span></span></div></div></div><p>
|
||
What the heck is this guy talking about? Well, if you've ever transported
|
||
data between little-endian (for example, x86) and big-endian (for
|
||
example, PPC) processors, then you know exactly what I'm talking about.
|
||
Processor designers make choices when deciding how data will be stored,
|
||
and compiler writers add some of their own twists. It's likely that data
|
||
written on one platform can't be read correctly on another. If you're
|
||
aware of this and take some precautionary steps, you'll be safe when it
|
||
comes time to read your data on some other platform besides a PowerPC
|
||
version of the BeOS.
|
||
</p><p>
|
||
If you're writing a network application, pay attention. Even if you're
|
||
merely saving data to a file, you're unwittingly writing a network
|
||
application. Files are easily transported across a network and often read
|
||
in the future by applications on other platforms.
|
||
</p><p>
|
||
First, some background. Most programmers are familiar with the byte-order
|
||
differences among processors. If you aren't, consider this code:
|
||
</p><pre class="programlisting c">
|
||
<span class="type">int</span> <code class="varname">i</code> = 0x01020304;
|
||
<span class="type">char *</span><code class="varname">c</code> = (<span class="type">char *</span>)&<code class="varname">i</code>;
|
||
<code class="function">printf</code>("%02x %02x %02x %02x—%02x %02x %02x %02x\n",
|
||
<code class="varname">c</code>[0], <code class="varname">c</code>[1], <code class="varname">c</code>[2], <code class="varname">c</code>[3],
|
||
<code class="varname">c</code>[3], <code class="varname">c</code>[2], <code class="varname">c</code>[1], <code class="varname">c</code>[0]);
|
||
</pre><p>
|
||
On a little-endian processor, such as the x86 (or Pentium), the output is:
|
||
</p><pre class="screen">
|
||
04 03 02 01—01 02 03 04
|
||
</pre><p>
|
||
On a big-endian processor, such as the PowerPC (in the mode that the BeOS
|
||
uses) you get:
|
||
</p><pre class="screen">
|
||
01 02 03 04—04 03 02 01
|
||
</pre><p>
|
||
Little-endian means that the first byte contains the least significant 8
|
||
bits. Big-endian means that the first byte contains the most significant
|
||
8 bits. If you've never seen little-endian machines in action, you might
|
||
think they're doing things backwards. But they're no more backwards than
|
||
driving in Britain is backwards or the flushing of toilets in the
|
||
southern hemisphere is backwards. It's just different, and takes a little
|
||
getting used to if you aren't already familiar with it. The PowerPC can
|
||
actually run either little-endian or big-endian. Be chose the big-endian
|
||
mode for the BeOS (Windows NT uses the little-endian mode).
|
||
</p><p>
|
||
16-bit integers (shorts) and 64-bit integers (long longs, available with
|
||
some compilers) are treated by processors in an analogous manner. In
|
||
other words, the big-endian and little-endian versions are simply
|
||
byte-for-byte mirror images of each other. Floats and doubles are treated
|
||
as if they were 32-bit or 64-bit integers, with respect to endian- ness
|
||
issues. Bitfields are generally not portable, and should be avoided when
|
||
writing data externally. Of course, ANSI C says nothing about what sizes
|
||
the various types are, and they can vary from platform to platform. The
|
||
sizes I've assumed here for the various C and C++ types are the ones that
|
||
are used on most modern platforms, including the PowerPC versions of the
|
||
BeOS. However, to be safe, it's better to use typedefs than the built-in
|
||
C++ data types to force data items to be a given size on all platforms.
|
||
In DR9, Be will provide typedefs like "int32" to make this job easier.
|
||
</p><p>
|
||
Now, some more background, this time having to do with alignment. Many
|
||
processors can't read a data item from just any location in memory, but
|
||
require it to be "aligned." For example, the following code WON'T work on
|
||
a PowerPC processor:
|
||
</p><pre class="programlisting c">
|
||
<span class="type">char *</span><code class="varname">c</code> = <code class="function">malloc</code>(9);
|
||
<span class="type">double *</span><code class="varname">d</code> = (<span class="type">double *</span>)&<code class="varname">c</code>[1];
|
||
|
||
*<code class="varname">d</code> = 0; <span class="comment">/* causes an exception on ppc */</span>
|
||
</pre><p>
|
||
That's because malloc will return a pointer that's "aligned" on an 8-byte
|
||
boundary (the pointer is a multiple of 8), and the code is attempting to
|
||
dereference a double on an odd boundary (not a multiple of 8). That same
|
||
code, however, WILL work on an x86 processor (though it will run faster
|
||
on the x86 if you align it).
|
||
</p><p>
|
||
Because of this, compiler writers usually lay out your data in a fashion
|
||
that will both work with the processor and perform well. Some compilers
|
||
have flags to "pack" data, so the data structures are smaller at the
|
||
expense of running slower. Hence the rules for alignment vary from
|
||
machine to machine, even on the same machine with the same compiler (but
|
||
different compiler flags).
|
||
</p><p>
|
||
OK, I hope now you understand the magnitude of the problem. What's the
|
||
solution, you ask? For alignment, the answer's quite simple. The concept
|
||
of "natural alignment" means you lay out data in a way that's "natural"
|
||
for the size of the type. Shorts should be aligned on 2-byte boundaries,
|
||
integers and floats on 4-byte boundaries, and long longs and doubles on
|
||
8-byte boundaries. This works for all processors and compilers. For
|
||
example, consider this very unportable structure:
|
||
</p><pre class="programlisting c">
|
||
struct {
|
||
<span class="type">char</span> <code class="varname">c0</code>;
|
||
<span class="type">double</span> <code class="varname">d</code>;
|
||
<span class="type">char</span> <code class="varname">c1</code>;
|
||
<span class="type">int</span> <code class="varname">i</code>;
|
||
<span class="type">char</span> <code class="varname">c3</code>;
|
||
<span class="type">short</span> <code class="varname">s</code>;
|
||
} <code class="varname">foo</code>;
|
||
</pre><p>
|
||
This structure and its elements will be aligned all kinds of different
|
||
ways with different processors and compilers. The compiler will insert
|
||
padding into the structure as necessary to cause it to be aligned on the
|
||
target processor.
|
||
</p><p>
|
||
Without reordering the data elements, you can force natural alignment by
|
||
inserting your own padding into the structure:
|
||
</p><pre class="programlisting c">
|
||
struct {
|
||
<span class="type">char</span> <code class="varname">c0</code>;
|
||
<span class="type">char</span> <code class="varname">_pad0</code>[7]; <span class="comment">// align to 8-byte boundary</span>
|
||
<span class="type">double</span> <code class="varname">d</code>;
|
||
<span class="type">char</span> <code class="varname">c1</code>;
|
||
<span class="type">char</span> <code class="varname">_pad1</code>[3]; <span class="comment">// align to 4-byte boundary</span>
|
||
<span class="type">int</span> <code class="varname">i</code>;
|
||
<span class="type">char</span> <code class="varname">c2</code>;
|
||
<span class="type">char</span> <code class="varname">_pad2</code>; <span class="comment">// align to 2-byte boundary</span>
|
||
<span class="type">short</span> <code class="varname">s</code>;
|
||
} <code class="varname">foo</code>;
|
||
</pre><p>
|
||
Of course, if you reorder things you can get a more efficient structure
|
||
without sacrificing natural alignment:
|
||
</p><pre class="programlisting c">
|
||
struct {
|
||
<span class="type">short</span> <code class="varname">s</code>;
|
||
<span class="type">char</span> <code class="varname">__pad</code>[2]; <span class="comment">// force to 4-byte boundary</span>
|
||
<span class="type">int</span> <code class="varname">i</code>;
|
||
<span class="type">double</span> <code class="varname">d</code>; <span class="comment">// already at 8-byte boundary</span>
|
||
} <code class="varname">foo</code>;
|
||
</pre><p>
|
||
With natural alignment the alignment of a structure, versus a scalar,
|
||
should be the same as the alignment of the most restrictive element it
|
||
contains. For example, consider this structure:
|
||
</p><pre class="programlisting c">
|
||
struct {
|
||
<span class="type">char</span> <code class="varname">c0</code>;
|
||
struct {
|
||
<span class="type">double</span> <code class="varname">d</code>;
|
||
} <code class="varname">s</code>;
|
||
<span class="type">char</span> <code class="varname">c1</code>;
|
||
} <code class="varname">foo</code>;
|
||
</pre><p>
|
||
The most restrictive element is the double, so both structures <code class="varname">foo</code>.<code class="varname">s</code> and
|
||
<code class="varname">foo</code> itself should be aligned on double boundaries. To make this data
|
||
portable, massage it as follows:
|
||
</p><pre class="programlisting c">
|
||
struct {
|
||
<span class="type">char</span> <code class="varname">c0</code>;
|
||
<span class="type">char</span> <code class="varname">_pad0</code>[7]; <span class="comment">// pad out to double boundary</span>
|
||
struct {
|
||
<span class="type">double</span> <code class="varname">d</code>;
|
||
} <code class="varname">s</code>;
|
||
<span class="type">char</span> <code class="varname">c</code>;
|
||
<span class="type">char</span> <code class="varname">_pad1</code>[7]; <span class="comment">// pad out to double boundary</span>
|
||
} <code class="varname">foo</code>;
|
||
</pre><p>
|
||
If the most restrictive element were an integer, rather than a double,
|
||
then you'd only need 3 padding bytes instead of 7. Notice the padding at
|
||
the end of the structure. Another rule of natural alignment is that
|
||
structures should be sized to by a multiple of their most restrictive
|
||
element.
|
||
</p><p>
|
||
The last thing I want to say about natural alignment is that there's no
|
||
"natural" alignment for pointers, since pointers can vary in size.
|
||
They're 32 bits on PowerPC and Intel processors, but on a DEC Alpha
|
||
they're 64 bits. It doesn't make any sense to transport a pointer to
|
||
another machine anyway, but you might think you can get away with it if
|
||
you only use the value internally to your application. You can't, so
|
||
leave the pointers out please. You'll be thankful when it comes time to
|
||
read the data back on a 64-bit machine.
|
||
</p><p>
|
||
OK, so that does it for alignment. The harder problem is dealing with
|
||
endian-ness. There are several techniques. The simplest way is to just
|
||
set a bit somewhere indicating what byte-order (little-endian or
|
||
big-endian) your data was written out in. Then when you read the data
|
||
back, you simply check the bit to see if it matches the endian-ness of
|
||
your current environment. If it matches, you do nothing. If it doesn't,
|
||
then you swap. However, if you haven't written your little-endian
|
||
application yet, then you can delay writing the swapping code. Just put a
|
||
panic statement in there as a placeholder to remind you when you finally
|
||
do port your application. If you want to write the swapping code now, you
|
||
can take advantage of some handy routines that Be provides:
|
||
<code class="function">read_16_swap()</code>, <code class="function">write_16_swap()</code>,
|
||
<code class="function">read_32_swap()</code>, <code class="function">write_32_swap()</code>. The
|
||
<code class="function">read_64_swap()</code> and <code class="function">write_64_swap()</code>
|
||
routines are left as an exercise for
|
||
the reader (hee, hee). Consult the on-line documentation for more
|
||
information about the swapping functions.
|
||
</p><p>
|
||
Another way to deal with endian-ness is to always encode things in some
|
||
canonical format (usually big-endian). This isn't an ideal way to do
|
||
things, because machines with the same byte-order communicating with each
|
||
other will swap things unnecessarily with some loss (usually very
|
||
minimal) in performance. If you want to use this technique, you can use
|
||
the Berkeley networking functions <code class="function">htons()</code>, <code class="function">htonl()</code>,
|
||
<code class="function">ntohs()</code>, and <code class="function">ntohl()</code>,
|
||
which convert shorts and longs back and forth between native order
|
||
("host" order) and big-endian order ("network" order). On big-endian
|
||
platforms, such as the BeOS, the functions do nothing; on little-endian
|
||
platforms, such as Windows NT, they swap the data. These functions are
|
||
available on any system with Berkeley sockets, and your code should be
|
||
portable to many platforms if you use them.
|
||
</p><p>
|
||
Along the same lines, Sun's XDR (External Data Representation) will
|
||
encode and decode your data to and from big-endian format, plus deal with
|
||
alignment issues. Using their stub compiler (rpcgen), it will even write
|
||
all of the XDR swapping code for you (really!). It isn't the most
|
||
efficient way to do things, but it does the job flawlessly and can keep
|
||
you from pulling your hair out if you're dealing with fairly complex
|
||
data. The package is free and widely available. For example, you can get
|
||
it in both source and binary form in many Linux distributions.
|
||
</p><p>
|
||
We here at Be feel your pain. We're working on some tools to make your
|
||
life easier with respect to machine differences. Look for them in the
|
||
coming months. Until then, you can use the information in this article.
|
||
!kcul dooG, er, I mean, good luck!
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Engineering2-9-2"></a>Be Engineering Insights: Paper Or Plastic?</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Doug</span> <span class="surname">Fulton</span></span></div></div></div><p>
|
||
A couple of days ago, I stepped up to bat at Safeway, assumed my part as
|
||
the novice in the call and response (C: "hello" R: "hello" C: "how are
|
||
you tonight" R: "oh, OK" C: "that's good" R: ""), and then, rather than
|
||
continue this sham of an acquaintanceship, I avoided eye contact with the
|
||
checkeress and pretended to compute differential equations in my head. As
|
||
she pronounced my total, I noticed that she was eating an apple. (No,
|
||
wait. Let's make it some grapes.) Not her grapes—MY grapes, which I
|
||
was about to pay for. I gave her a look that requested an explanation;
|
||
she stopped a grape halfway to her open maw and held it up to better
|
||
gander at this bit of fruit that had, by weight of her expression, stuck
|
||
itself to her hand when she wasn't looking. Then she threw it below her
|
||
out of sight with a pitch of disgust that I couldn't help but take
|
||
personally. Not an endearing opening parry, but it broke the ice. Words,
|
||
not unfriendly, were spoken.
|
||
</p><p>
|
||
(By the way, why are grocery stores so proud of having drug- free
|
||
employees? Really—how much intelligence or presence of mind does it
|
||
take run a bar code over a scanner? Grocery checking isn't exactly a
|
||
going-somewhere career, the pay is lousy, and I can't imagine that anyone
|
||
with an ounce of self- respect actually WANTS to be declared employee of
|
||
the month, plum parking spot aside. We might as well let the poor
|
||
grubbers relieve the tedium a bit. It's almost civic-minded: If you're
|
||
going to get looped, better to be at the console of an NEC than behind
|
||
the wheel of a stolen BMW. Some savvy supermarket could even take up a
|
||
slogan of cynical goodwill: "Pik'N'Pay—Keeping the Stoners Off the
|
||
Street." I don't care, I want my clerks happy—as long as they don't
|
||
get hungry while they're ringing me up.)
|
||
</p><p>
|
||
Courtesies and histories were exchanged, and, half a conversation later,
|
||
when I told her I worked at Be, she began to ask about the new File
|
||
System API. The POSIX calls she knew; but the C++ API... she'd heard it
|
||
was screwy. So I explained the class layout to her satisfaction:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
There are two fundamental classes: <code class="classname">BEntry</code> and <code class="classname">BNode</code>.
|
||
</p><ul class="itemizedlist"><li><p>
|
||
<code class="classname">BEntry</code> objects identify files, let you ask uber-questions about
|
||
them (what's your name, who's your parent), and let you manipulate
|
||
them within the file hierarchy (rename, move, remove). <code class="classname">BEntry</code> is
|
||
instantiable and has no subclasses.
|
||
</p></li><li><p>
|
||
The <code class="classname">BNode</code> class also represents files; its mission is to let you
|
||
read and write the data (and attributes) that the files contain.
|
||
<code class="classname">BNode</code> is abstract; descending from it are...
|
||
</p></li></ul></li><li><p>
|
||
<code class="classname">BFile</code> (and on to <code class="classname">BResourceFile</code>),
|
||
<code class="classname">BDirectory</code>, and <code class="classname">BSymLink</code> (yes,
|
||
symbolic links are supported in DR9). In each case, the represented
|
||
file is opened when the object is created; destroy the object and the
|
||
file is closed. In this way, <code class="classname">BNode</code>s correspond to POSIX file
|
||
descriptors.
|
||
</p></li><li><p>
|
||
<code class="classname">BEntry</code> and <code class="classname">BNode</code> both descend
|
||
from a class called <code class="classname">BStatable</code>, as in
|
||
"able to be <code class="function">stat()</code>'ed." <code class="classname">BStatable</code> is utterly abstract; it's simply a
|
||
cover for the POSIX stat structure and includes functions that get and
|
||
set the stat fields. Conceptually, it's cleaner to ignore <code class="classname">BStatable</code> as
|
||
a class and pretend that <code class="classname">BEntry</code> and <code class="classname">BNode</code>
|
||
have no ancestor. (<code class="classname">BStatable</code>
|
||
is actually a "mix-in": It defines a set of functions that each of the
|
||
"mixed in" classes—<code class="classname">BEntry</code> and <code class="classname">BNode</code>
|
||
in this case—is obliged to
|
||
implement. You never instantiate a <code class="classname">BStatable</code> object. Forget I mentioned
|
||
it.)
|
||
</p></li><li><p>
|
||
Over in the corner are <code class="classname">BVolume</code>, which should be obvious;
|
||
<code class="classname">BVolumeRoster</code>, a global list of currently mounted volumes;
|
||
and <code class="classname">BQuery</code>,
|
||
which you can use to search for files based on the values of their
|
||
attributes. Let's ignore these classes for now, as well.
|
||
</p></li></ul><p>
|
||
The screwiness that my grape girl complained of centered on the
|
||
<code class="classname">BEntry</code>/<code class="classname">BNode</code> duality—why have
|
||
two classes that "mean" the same thing
|
||
(that is, a file)? Because (I answered) in POSIX (from which all
|
||
blessings flow) a "file" can mean a "plain" file, a symbolic link, or a
|
||
directory.
|
||
</p><p>
|
||
Let's back up a little more: In DR9, a file (whether plain, link, or
|
||
directory) is uniquely and persistently identified by an "entry ref."
|
||
Entry refs are the common currency of file identification: If you want to
|
||
tell another app about a file, you pass it an entry ref. When the user
|
||
drops file icons on your app, the files show up in your app as a set of
|
||
entry refs.
|
||
</p><p>
|
||
Getting back to the duality business: Let's say someone has just dropped
|
||
an entry ref onto your app. You want to construct a <code class="classname">BFile</code>, or a <code class="classname">BSymLink</code>,
|
||
or a <code class="classname">BDirectory</code> object to represent the ref. But you can't tell, from the
|
||
ref itself, which class to instantiate. You have to create a <code class="classname">BEntry</code> and
|
||
ask the object (through <code class="classname">BStatable</code> functions, actually, but don't let's
|
||
start) what sort of file it is. You can then construct an object of the
|
||
appropriate <code class="classname">BNode</code> subclass.
|
||
</p><p>
|
||
Is this screwy? No screwier than <code class="function">stat()</code>'ing a pathname and then calling
|
||
one of <code class="function">open()</code>, <code class="function">readdir()</code>, or <code class="function">readlink()</code>.
|
||
</p><p>
|
||
Of course, this didn't tell the entire story, but my little checkerella
|
||
was starting to fog over, the folks behind me in line were starting to
|
||
smell, and, anyway, I had a wife waiting at home and two kids locked in
|
||
the trunk of my car (you can't be too careful). Having, in the meantime,
|
||
cantilevered my produce into a replica of the Brandenburg Gate, the bag
|
||
boy asked, "What'll it be, sir, POSIX or C++?"
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="News2-9"></a>News From The Front</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">William</span> <span class="surname">Adams</span></span></div></div></div><p>
|
||
As I sit here, late with my newsletter article, I have plenty of time to
|
||
contemplate the nature of the Universe, where Be is headed, and whether
|
||
or not Godzilla is real.
|
||
</p><p>
|
||
I want to make a couple of final offerings to appease the /boot/apps
|
||
gods. So this week we have the source for a couple of the final holdouts.
|
||
</p><p>
|
||
Font Demo: This one's been a staple of our demos for the past year. It
|
||
demonstrates our drawing speed and how to do a few UI type things. It's
|
||
not too exciting, but those who haven't delved very deeply into our font
|
||
code might find this useful.
|
||
</p><p>
|
||
ftp://ftp.be.com/pub/Samples/fontdemo.tgz
|
||
</p><p>
|
||
Font Chart: This one probably doesn't get much play, but it's equally
|
||
useful for those who are wanting to delve into the bowels of fontdom. You
|
||
can use Font Chart to select a font and display all its characters. It
|
||
also does some nice funky things with keyboard events.
|
||
</p><p>
|
||
ftp://ftp.be.com/pub/Samples/fontchart.tgz
|
||
</p><p>
|
||
With these two programs, this concludes our release of sample apps from
|
||
the /boot/apps directory. It's taken a few months and quite a few
|
||
newsletter articles, but everything that was fit for publishing has been
|
||
published.
|
||
</p><p>
|
||
These will also serve as the basis for conversion to DR9. That is, we'll
|
||
try to refer back to these source bases to give you a leg up on how to
|
||
get to DR9 when it's available.
|
||
</p><p>
|
||
Speaking of DR9, the offer of the porting lab is still open. So send in
|
||
your name to DevServices@be.com and express your interest in
|
||
participating in our porting lab. The date is still middle to late March,
|
||
which still isn't solid, but gives you an idea as to what our schedule is.
|
||
</p><p>
|
||
We should have a lot of fun during this porting process, and the end
|
||
result will be your products running on DR9 real soon. Again, you'll only
|
||
really want to participate if you're trying to ship an actual product
|
||
that's time critical with the release of DR9.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551145"></a>Communicating</h3></div></div></div><p>
|
||
When I first joined Be way back when, there was this BeDevTalk mailing
|
||
list, which the community used to communicate with each other and with
|
||
Be. The list at the time dumped 100 e-mail messages into my mailbox every
|
||
day. That's lot of mail to go through if you're on the receiving end.
|
||
Since that time I've had to take responsibility for mail coming to
|
||
DevSupport, DevServices, and CustSupport. Another 100 messages a day. Not
|
||
wanting to be a slave to my desk all day reading mail, we've hired
|
||
additional people to take care of some of this. Brian Mikol is a new hire
|
||
who's slowly learning the ropes and dealing with the DevServices and
|
||
CustSupport mail. Brian's a smart guy and will come up to speed rapidly
|
||
—then we'll dump more in his lap.
|
||
</p><p>
|
||
The BeDevTalk mailing list is still useful, and at times becomes quite
|
||
rancorous. There are now more avenues available to developers who want to
|
||
communicate with the Be community. The comp.sys.be news group has been
|
||
split into quite a few groups, including comp.sys.be.announce, advocacy,
|
||
programming, and the like. In order to lighten the load on BeDevTalk,
|
||
some people might find it convenient to direct their comments to one of
|
||
those public forums. It would be a tremendous boost to all developers if
|
||
the BeDevTalk list were limited to discussions that are technical in
|
||
nature, with a high signal to noise ratio. Advocacy, ranting, and other
|
||
list-bulging discussions can go elsewhere. This will help us remain
|
||
responsive to your true needs when they do arise from the list.
|
||
</p><p>
|
||
Also, there are a couple of efforts underway to index this mailing list
|
||
and provide searchable content through the Web. This should make this
|
||
list more approachable and useful to everyone.
|
||
</p><p>
|
||
DR9 is coming inevitably closer to completion and release. There's a lot
|
||
promised and hinted at in this release. Here at Be we try to underpromise
|
||
and overdeliver, but when there's a long time between releases, things
|
||
can get a bit hyped up. We hope that DR9 will live up to our publicly
|
||
stated promises, and maybe even offer some pleasant surprises. As it gets
|
||
closer, you might notice our engineers becoming more silent. When this
|
||
happens, don't fret, it's a sure sign that you're about to get a new
|
||
release.
|
||
</p></div></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="Gassee2-9"></a>The Heat on the Clones</h2></div><div xmlns:d="http://docbook.org/ns/docbook"><span xmlns="http://www.w3.org/1999/xhtml" class="author">By <span class="firstname">Jean-Louis</span> <span class="surname">Gassée</span></span></div></div></div><p>
|
||
It looks like Apple isn't so sure it likes the Mac clones anymore. This
|
||
is neither surprising nor innocuous. It could end up doing irreparable
|
||
harm to Apple and to the industry in general. Hopefully, Apple's recent
|
||
actions have been misunderstood, the concerns of Mac cloners are
|
||
overstated, and—to be positive and proactive—there's a profitable
|
||
and friendly way out of Apple's dilemma. We've heard about Apple
|
||
Australia's alleged saber-rattling at Apple dealers who also sell Mac
|
||
clones. The written document was promptly leaked to the media. We saw the
|
||
news of a seminar in Oregon touting the advantages of Apple's hardware
|
||
against the products of Power Computing, Motorola, UMAX, DayStar, and
|
||
others. The licensees paying money to Apple must find the idea
|
||
interesting. Perhaps they're planning a seminar across the street where
|
||
they'll extol their flexibility, price, marketing, or quality. Just
|
||
kidding, I think. We learned Apple doesn't intend to license PowerBook
|
||
designs, much to the chagrin of cloners and customers. We heard questions
|
||
regarding Apple's real commitment to deliver a CHRP version of the MacOS.
|
||
And there are rumors Apple will demand much higher license fees for the
|
||
new hardware designs, several hundred dollars we're told by several
|
||
sources. The alleged reason is the need to recoup hardware engineering
|
||
costs at Apple. Privately, Apple executives express irritation at the
|
||
clones' "cherrypicking" and claim Apple's making all the investment in
|
||
the platform and the cloners reap all the profit. Let's hope these are
|
||
false rumors or merely reflect a temporary loss of composure.
|
||
</p><p>
|
||
As for "cherrypicking," the cloners exhibit unpredictable behavior:
|
||
Looking for the highest profit. As for making all the effort and the
|
||
cloners making money out of Apple's investment, one thought that's what
|
||
licensing the platform was about. We sell you a license. We both expect
|
||
to make more money out of the deal than we put in. The cloner's margins
|
||
are supposed to more than pay for the fee. And Apple is supposed to make
|
||
real money out of the licensing business. Well, it seems that's where the
|
||
stated assumptions, or the implementation, went wrong.
|
||
</p><p>
|
||
Regarding the stated assumptions, Apple went into the licensing business
|
||
for reasons others than directly making money from it. At the time, a
|
||
little more than two years ago, Apple's management felt the Macintosh
|
||
platform needed more credibility. The Mac was labeled as proprietary, no
|
||
alternative source of supply, no competition. With Mac clones, the
|
||
reasoning went, software developers would invest more because the cloning
|
||
would grow the Mac ecological niche, and corporate purchasers would feel
|
||
better, safer, about Apple and the Macintosh. Then, as the cloners came
|
||
on line, Apple's business and credibility started suffering for reasons
|
||
unrelated to the presence of alternative sources of Power Mac hardware.
|
||
As a result, these successful players in the Mac niche only exacerbated
|
||
Apple's financial problems. Instead of a positive-sum game where everyone
|
||
benefited from a growing PowerPC industry segment, the sum of the game
|
||
now appears to be zero and the cloners' profits seem to be sucked from
|
||
Apple's income statement. "Seem" is the verb I just used because we don't
|
||
know. Where would the Power Mac segment be without the pioneering,
|
||
audacious marketing of Power Computing, without players like UMAX, MP
|
||
systems from DayStar, or the credibility of Motorola targeting business
|
||
users?
|
||
</p><p>
|
||
The temptation might be to return to the old days where Apple ruled
|
||
alone, or to increase licensing fees "as needed." The first would durably
|
||
damage Apple's credibility at a critical time. So would the latter, by
|
||
discouraging cloners.
|
||
</p><p>
|
||
Yet there's a way out of this situation, a way that would maintain a
|
||
healthy growing Mac-compatible segment and preserve Apple's freedom to
|
||
make both hardware and software for as long as their shareholders want
|
||
them to. Right now, a cloner must license both hardware and software.
|
||
That's the rub. Apple needs to let go of the hardware licensing business,
|
||
establish a basic hardware design, the equivalent of the PC/AT at the
|
||
core of all PC clones—let's call it the PPC/AT—and supply software
|
||
that runs on that platform—no ifs, no buts. I wrote supply, not give.
|
||
OEM licenses or shrink-wrap licenses are available at competitive rates.
|
||
Everyone's free to improve on that core. The cloners can add hardware
|
||
features and supply drivers. So can the mother ship. But each basic
|
||
release of the OS works on the standard PPC/AT implementation. No more
|
||
cherrypicking, no more trying to pass on the cost of hardware designs,
|
||
just software licensing fees and market forces.
|
||
</p><p>
|
||
Unfortunately, there are several holes in this scenario. One is that
|
||
Apple could fear its inability to provide competitive designs, picturing
|
||
itself as overwhelmed by the cumulated energy and creativity of many
|
||
third-party designers extending the platform. The corollary hole is that
|
||
Apple could be tempted to design "private" features into the system
|
||
software only accessible by its own hardware design, thus protecting a
|
||
competitive advantage. From time to time, Microsoft is accused of doing
|
||
this in Windows for its applications. In any event, Apple's current
|
||
licensing program suffers from several genetic or structural defects.
|
||
Apple licensing was not born out of the desire to make money in and of
|
||
itself, and structural problems arise from the entanglement of hardware
|
||
and software in licensing discussions.
|
||
</p><p>
|
||
Appointing CHRP (or any other design) as the PPC/AT, letting everyone
|
||
build around it, and delivering, at last, a Mac OS version for CHRP, is
|
||
Apple's way to free its software licensing from hardware complications.
|
||
It will rekindle confidence and stimulate growth in the PowerPC industry.
|
||
This might even free Apple, in turn, to copy the Microsoft model and
|
||
build an immensely profitable application business on a thriving PPC
|
||
niche and a NeXT-based Mac OS. Apple shareholders might like that kind of
|
||
Microsoft cloning.
|
||
</p></div><hr class="pagebreak" /><div class="sect1"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h2 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="BeDevTalk2-9"></a>BeDevTalk Summary</h2></div></div></div><p>
|
||
BeDevTalk is an unmonitored discussion group in which technical
|
||
information is shared by Be developers and interested parties. In this
|
||
column, we summarize some of the active threads, listed by their subject
|
||
lines as they appear, verbatim, in the mail.
|
||
</p><p>
|
||
To subscribe to BeDevTalk, visit the mailing list page on our web site:
|
||
http://www.be.com/aboutbe/mailinglists.html.
|
||
</p><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551258"></a>WEEK 2</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551265"></a>Subject: Fonts, fonts, fonts!</h4></div></div></div><p>
|
||
More requests:<br />
|
||
Open the system so new font engines can be added as add-ons. Implement
|
||
the alpha channel for alpha-defined anti-aliasing.
|
||
</p><p>
|
||
And discussion:<br />
|
||
How should font color be handled? Should color data be recognized, or
|
||
should fonts be defined as grayscale with alpha?
|
||
</p><p>
|
||
What about background color? A font engine that renders over a graphic
|
||
(or other nonuniform color) needs more info than simply a solid
|
||
background color.
|
||
</p><p>
|
||
Bitmap vs outline fonts:<br />
|
||
The demise of bitmap fonts (in DR9) was lamented by a few. How can
|
||
outline fonts look good in something like Terminal? Anti-aliasing and
|
||
outline->bitmap conversion were offered as possible solutions. The
|
||
pro-bitmap crowd felt that with all the good bitmaps that are currently
|
||
available, conversion is unnecessary and wasteful.
|
||
</p><p>
|
||
THE BE LINE: Sorry, but add-on font engines will not be supported in
|
||
DR9, nor will you be able to directly load bitmap fonts.
|
||
</p></div></div><div class="sect2"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h3 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551313"></a>NEW</h3></div></div></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551320"></a>Subject: resolutions</h4></div></div></div><p>
|
||
Currently, Be defines screen sizes through a set of constants. But the
|
||
world seems to be moving to more flexible resolutions. It was suggested
|
||
that the constant-definition method be dropped in favor of an
|
||
x/y/depth/refresh-rate encoding within a 64-bit value. Implementations
|
||
and refinements were offered.
|
||
</p><p>
|
||
Relatedly, Chris Blackbourn asked for "screen quality" control in the
|
||
Game Kit:
|
||
</p><p>
|
||
“<span class="quote">What I'd like is a Game Kit call that returns a screen of a certain
|
||
'speed.' Where speed=1.0 means 'gimme the fastest available screen
|
||
you've got,' and speed=0.0 means 'give me the highest resolution screen
|
||
you've got.'</span>”
|
||
</p><p>
|
||
THE BE LINE: An encoded resolution is a pretty good idea, and we're
|
||
looking at the implications. However, we can't promise anything for DR9.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551358"></a>Subject: High Bandwidth multimedia</h4></div><div xmlns:d="http://docbook.org/ns/docbook"><h5 xmlns="http://www.w3.org/1999/xhtml" class="subtitle">AKA: What is Be's role?</h5></div></div></div><p>
|
||
What's the ideal system for real-time processing of wide data? Is the
|
||
BeOS it? And, more generally, what should be made of Be's espoused
|
||
emphasis on multimedia content creation?
|
||
</p><p>
|
||
Technically, the argument centered on bandwidth vs. dedicated
|
||
processing: Certain flavors of UNIX are great for pumping huge amounts
|
||
of data, but with invisible daemons and uncertain scheduling, latency
|
||
is hard to guarantee. "Not exactly so," said many UNIX supporters. They
|
||
felt that UNIX doesn't deserve the unfriendly scheduling reputation:
|
||
Many new flavors have emerged recently that CAN do real-time signal
|
||
processing. Tangentially, the thread moved into a discussion of what
|
||
constitutes UNIX.
|
||
</p><p>
|
||
On the philosophical side, a few listeners offered their
|
||
interpretations of (and offered suggestions for) Be's direction.
|
||
Eventually this discussion led back to analyses of Be's real-time
|
||
abilities.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551387"></a>Subject: Time is running out!</h4></div></div></div><p>
|
||
Chris Herborth listed issues that need to be resolved before the BeOS
|
||
can be considered forward-compatible and encouraged others to
|
||
contribute. This turned into a general wish list as many of the
|
||
requests were not strictly needed for forward compatibility. Some
|
||
highlights:
|
||
</p><ul class="itemizedlist"><li><p>
|
||
More binary formats and an Application Binary Interface spec
|
||
</p></li><li><p>
|
||
Internationalization
|
||
</p></li><li><p>
|
||
Driver registry
|
||
</p></li><li><p>
|
||
Clear data format definitions and assumptions
|
||
</p></li><li><p>
|
||
Language independence
|
||
</p></li><li><p>
|
||
Multi-user support and security
|
||
</p></li><li><p>
|
||
More and better bitmap (as in <code class="classname">BBitmap</code>) support
|
||
</p></li></ul><p>
|
||
The thread lurched into the perennial discussion of "how backwardly
|
||
compatible should an app be?"
|
||
</p><div class="blockquote"><table border="0" cellspacing="0" cellpadding="0" class="blockquote" summary="Block quote"><tr><td width="90%" valign="top"><p>
|
||
“<span class="quote">...do you use or know of anyone who uses a piece of software that has
|
||
not been updated in 5 years? It's a very romantic thing to think that
|
||
someone could write the perfect piece of software that could benefit
|
||
from no updates... I'd say such a beast does not exist.</span>”
|
||
</p></td><td width="5%" valign="top"> </td></tr><tr><td width="100%" colspan="2" align="right" valign="top">—</td></tr></table></div><p>
|
||
A new, slightly cynical, twist was added to the argument: Software
|
||
companies LIKE incompatible OS updates because it means revenue.
|
||
</p></div><div class="sect3"><div xmlns="" xmlns:d="http://docbook.org/ns/docbook" class="titlepage"><div><div xmlns:d="http://docbook.org/ns/docbook"><h4 xmlns="http://www.w3.org/1999/xhtml" class="title"><a id="id551477"></a>Subject: addressing pixels</h4></div></div></div><p>
|
||
Center-based vs edge-based pixel coordinate systems. Which is better?
|
||
</p></div></div></div></div><div id="footer"><hr /><div id="footerT">Prev: <a href="Issue2-8.html">Issue 2-8, February 26, 1997</a> Up: <a href="volume2.html">Volume 2: 1997</a> Next: <a href="Issue2-10.html">Issue 2-10, March 12, 1997</a> </div><div id="footerB"><div id="footerBL"><a href="Issue2-8.html" title="Issue 2-8, February 26, 1997"><img src="./images/navigation/prev.png" alt="Prev" /></a> <a href="volume2.html" title="Volume 2: 1997"><img src="./images/navigation/up.png" alt="Up" /></a> <a href="Issue2-10.html" title="Issue 2-10, March 12, 1997"><img src="./images/navigation/next.png" alt="Next" /></a></div><div id="footerBR"><div><a href="http://www.haiku-os.org"><img src="./images/People_24.png" alt="haiku-os.org" title="Visit The Haiku Website" /></a></div><div class="navighome" title="Home"><a accesskey="h" href="index.html"><img src="./images/navigation/home.png" alt="Home" /></a></div></div><div id="footerBC"><a href="http://www.access-company.com/home.html" title="ACCESS Co."><img alt="Access Company" src="./images/access_logo.png" /></a></div></div></div><div id="licenseFooter"><div id="licenseFooterBL"><a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/" title="Creative Commons License"><img alt="Creative Commons License" style="border-width:0" src="https://licensebuttons.net/l/by-nc-nd/3.0/88x31.png" /></a></div><div id="licenseFooterBR"><a href="./LegalNotice.html">Legal Notice</a></div><div id="licenseFooterBC"><span id="licenseText">This work is licensed under a
|
||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/">Creative
|
||
Commons Attribution-Non commercial-No Derivative Works 3.0 License</a>.</span></div></div></body></html>
|