|
Be Newsletter
Issue 88, August 27, 1997
Table of Contents
BE ENGINEERING INSIGHTS: NetPositive and URLs
By Ron Theis
So, being a Webmaster, I'm asked several questions all the
time about the web, Be, and NetPositive. I thought I'd
answer some of them here.
Q. I'd like to learn HTML, but there are so many books to
choose from. Can you recommend a book on HTML?
A. Frankly, I've found that anything by Laura Lemay is
excellent. She wrote one of the first really great HTML
books a long time ago, and she continues to update and
refine several different titles she has. I believe I've used
"Teach Yourself HTML in 14 Days" in various revisions over
the years, and it's one of the books which never stays on my
bookshelf at Be for long -- it's constantly being read by me
and borrowed by others.
Q. Where do I go to find information about X? What's your
favorite search engine?
A. My favorite search engine is Ask Jeeves, at
http://www.askjeeves.com/, hands down. Jeeves takes
natural language questions, like "What is the BeOS?", and
provides suggestions for other questions you might actually
be asking. It's extremely intelligent about figuring out
what you're looking for, and it provides results from
several other search engines (like Excite and Alta Vista).
If you're looking for something on the web, Jeeves can
usually find it for you.
NetPositive and URLs
Q. How can I send NetPositive a URL?
A. NetPositive can actually be run from the command line,
meaning it could be given a command in a shell script, like
$ NetPositive http://www.be.com
This line would cause NetPositive start up (or open a new
window) and take the user to the Be web site.
Q. But I want to send it a URL from within an application --
can I do that too?
A. Sure, just send a BMessage with some argument information
filled in. The following does exactly what the command line
instruction above does, for instance:
BMessage msg(B_ARGV_RECEIVED);
msg.AddString("argv", "NetPositive");
msg.AddString("argv", "http://www.be.com");
msg.AddInt32("argc", 2);
BMessenger messenger("application/x-vnd.Be-NPOS", -1, NULL);
if (messenger.IsValid()) {
messenger.SendMessage( &msg );
} else {
be_roster->Launch ("application/x-vnd.Be-NPOS", &msg );
}
Note that this is merely a stopgap until a more formal
NetPositive scripting architecture is defined. We're just
pretending to give NetPositive command line instructions
here.
Q. What if I want to do FTP transactions too?
A. NetPositive can also take FTP URLs. So the following
would retrieve the list of files recently added to the FTP
site:
$ NetPositive ftp://ftp.be.com/pub/contrib/whatsnew.txt
This could also, of course, be sent via a BMessage from
within an application. NetPositive reacts as though the user
had entered that URL, though, so a file dialog is presented
to the user to save the file. The application therefore
doesn't know (without searching) where the file was saved on
the user's hard drive. The user also needs to know what to
do with the file once it's been downloaded.
Intelligent URLs
There are some interesting things an application could do by
sending URLs to NetPositive. Many BeOS applications are
providing documentation via HTML these days, and access to
these documents from within an application could be easily
facilitated. Buttons inside an About box or inside a window
could jump right to the application's documentation.
Applications which have web sites could even provide "Read
Local Documentation" (sending the local URL, in
file://path/file.html format) and "Read Latest
Documentation" (sending the absolute URL, in http:// format)
choices, jumping the user to NetPositive and the
application's instructions. Or a "Register Now" button could
jump the user to NetPositive and a remote registration page.
This could be carried even further by creative applications
which take advantage of the fact that a URL can contain form
information. A "GET" form request is one sent inside of the
URL, providing variable and value information to the remote
script. This kind of URL looks like:
http://www.company.com/myscript.cgi?First=Ron&Last=Theis
Variable names are matched with values using equal signs and
ampersands. Special characters need to be encoded in hex,
too; you'll want to reference an HTML book for the grisly
details. I've found that testing each character to see if
it's alphanumeric, then sprintf-ing it into hexadecimal
works pretty well.
The example URL above would send my first and last name to a
remote cgi, which could intelligently process the
information. The CGI could fill out a form for me and return
a web page which prompts me to register or purchase the
product. Or maybe I insert my e-mail address into the
application's about box, click the "Sign Up for Product
Info" button, and the application sends my e-mail address to
a CGI through NetPositive. The results page is returned to
me in NetPositive, welcoming me to the mailing list.
Or a "Check Version Info" button could send my program
version information to a remote CGI that tells me whether my
application is up to date or not. The resulting HTML could
then link me to appropriate download areas, or provide
information on how to upgrade to or purchase the latest
version of the app.
Doing It Yourself
An application doesn't have to use NetPositive, though; it
could make the network connection itself. The details for
doing so can of course be found in the Network Kit chapter
of the Be Book. This can get intimidating for non-networking
programmers, throwing them into the middle of an
sin_addr/sockaddr festival. If you're looking for basic
open/read/write/close client functionality, though, it will
pay to make friends with a BTSSocket. Check out the Network
tutorial in the Developer section of the Be web site for
source code and more information on how this is done.
Some basic knowledge of the actual HTTP protocol would be
required to pull this off, but with some cleverness, a lot
of information could be returned to the application. Scripts
could be run remotely, returning information back to the
program itself -- NetPositive wouldn't need to display an
HTML page. A script wouldn't even need to return HTML if the
program on the receiving end knew how to deal with the
information correctly. It might not be as efficient as
creating your own client-server arrangement for handling
communications, but it would allow an application to connect
to a remote information source and provide a dynamic
response to the user.
In fact, one could envision an application which queried a
remote database for the latest versions of the applications
on the user's hard drive (a primitive version of some of
StarCode's Software Valet functionality). Or one which
checked every so often to see if there were any new
applications released in the user's preferred categories,
such as games, productivity, etc. But in order to do that,
we'd need a database of available BeOS applications...like
BeWare. I'll discuss these possibilities in my next
Newsletter article. In the meantime, check to make sure your
BeWare records are up to date...
News from the Front
By William Adams
One of the most fun things that you can do with a computer is
generate interesting sounds. That's why whenever we give a
demo we use big loud sound systems and a thumping beat. Of
course, the history of sound and computers has come a long
way from playing the star spangled banner on a Teletype, to
now doing CD quality digitized stereo. Sound handling really
is simple to do in the BeOS. If you are familiar with our
streaming architecture, you know you get buckets, you add to
the buckets, you pass them on. We get much simpler questions
though. How do you turn the volume up or down.
If all you're after is the meta information related to
sound, take a look in the AudioStream.h file and you'll see
some interesting things.
class BDACStream for instance. Let's say you want to set the
master volume of the system to be 50% of max.
BDACStream aStream;
aStream.SetVolume(B_MASTER_OUT, 0.5, 0.5);
It's that simple. It's really neat to do while you have the
Sound preferences application up because you will see the
sliders change accordingly. If you take a look into
MediaDefs.h, you'll find some other interesting things that
you can set volumes on.
You can also use the same stream thing to enable and disable
various devices.
// Turn the internal speaker on
aStream.EnableDevice(B_SPEAKER_OUT, true);
// Turn the internal speaker off
aStream.EnableDevice(B_SPEAKER_OUT, false);
Audio is one of those things that I've never made a point of
becoming any sort of expert at, but I love playing with
things. When I first started at Be, there was this wacky
thing called Audio Elements. Audio Elements allow you to
play with sound by giving your a nice graphical user
interface in which you can tie things together into networks
and just fiddle to your heart's content. If you really want
to play with sound, but you don't want to get down into the
nitty gritty, you might check it out at:
http://www.adamation.com/
I've also found that speech synthesis gives me a thrill, and
through my various net wanderings I found that one text to
speech synthesizer suits me fine:
ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/synthesis/rsynth
and another great source of speech stuff:
http://www.speech.cs.cmu.edu/comp.speech
It suits me because the price is right, free, and the
quality is good enough for simple things. It has a tuned
database so that you can actually get quite good on those
easily mispronounced words. If anyone wants text to speech,
I would highly recommend these sources.
Do vampires have brides?
Apparently so, because Scott Paterson was getting married
this past week, so I had the opportunity to go to Atlanta to
give a demo to the Macintosh User's Group there. If you've
never done demo tours, you'd be in for quite a treat. And if
you've read the "How to give a BeOS Demo" guidelines, you
should take all that it says to heart.
My trip was going to be a lightning strike, leaving San
Francisco at 8:20am on Wednesday, returning by 10:25am on
Thursday. So what can possibly drive a guy like me to go off
to some city far across on the other side of this country
for one night just to give a demo? One comment that one of
the attendees made was they were grateful Be sent someone
who was lively and interesting, not like some of the demos
they get. I live for this. Spreading the infectious
enthusiasm that I have for the BeOS.
One of the little video clips that we have in our QuickTime
movie arsenal is that old 1984 commercial that shows the
hordes of people watching big brother on the big screen, and
in runs the sledge hammer wielding woman with the fruit
company logo on her shirt. I remember at the time the
enthusiasm that was sparked by such IN YOUR FACE defiance
and thus spurred the creation of what are now fondly known
as the Mac Faithful.
The world of computing is not over and done with. That
commercial still rings true today, the logos just need to be
changed around a little bit. I'm so danged enthusiastic
because I see in the BeOS a challenge to established norms
of acceptable performance. At Be, we take seriously the
notion that today's machines are not being fully utilized by
today's operating systems. In everyone's attempt to build
bigger better faster, we've largely thrown away the notion
that small is beautiful and efficient.
That's why I can fly across the country for a one night
stand, and spew forth a smile and a grin as I launch the
fourth movie on a machine that is already maxed out, and
feel confident that I'll still be able to move the mouse and
read my email. And did I say this app is less than 200K?
Unbridled excitement about running multiple movies is one
thing, but running actual applications is another. The
questions always arise, when will you be able to run such
and such, or so and so? Often times I'll answer that by
showing BeatWare Writer, or Adamation's Audio Elements, or
another fine product by our third party developers. You
can't believe how exciting it is to be able to show real
commercial apps that focus our performance advantages like a
laser beam. And I can point to our BeWare web pages and say,
"See here, there are hundreds of apps that are free,
shareware, or commercially available." I'm sure the
downcasting, give it up crowd will always retort, Yes but
it's not ____, to which I will always answer, thank goodness
there is still room for improvement and plenty of users
intelligent enough to spot a superior product when they see
one.
What a rant. I can't help it though. I was in Atlanta for
only a day, but the roar of the crowd, the smell of the
grease paint, the glare of the lights, brought out the
enthusiasm in my heart for the BeOS. Being a part of
something as new and exciting has no parallel, other than
raising a human child perhaps. I'm glad we're at a phase in
our development that we'll soon be sharing this great OS
with a greater number of people, and giving a number of
third party developers a chance at becoming the next big
thing.
BE ENGINEERING INSIGHTS: Extensions Disabled
By Doug Fulton
I am, I happily, ecstatically admit, a Macintosh novice. I
cut my teeth on various forms of UNIX in the days when a
stable, reliable operating system was regarded as far too
sophisticated for mom, pop, and their drunken coed daughter
at Wellesley. Recently, unfortunately, the tech writing team
at Be moved their (our, my) production machinery from an
oxygen-deprived form of UNIX (SCO) to Mac system
seven-point-something. Do people actually use this thing?
But the OS isn't Apple's only, or even most important,
problem. That would be this: Steve Jobs has become boring.
Forget the implications of the $150M Microsoft deal --
pundittier wits than I have frazzled that one to the bone.
What does it mean? Who cares. The important thing isn't the
deal itself, it's SJ's sound bite, blazing purple across the
cover of Time magazine: "Thank you, Bill. The world's a
better place."
Huh? Steve is admitting there's a world? I liked him better
when he was archly solipsistic. I worked for him (at NeXT)
for seven years; I never really enjoyed the aftermath of
being up close in the same room with him -- he has a talent
for siphoning your soul out through your eyeballs -- but he
was fun at a distance. Not more than a year ago, I saw him
on a television show (not that I watch TV, of course) in
which he spake the Steve gospel on the iniquitors of Redmond
(and I paraphrase, but probably not much, it was a memorable
spaking): "The thing I don't like about MS is that they have
no taste...and I don't mean that in a small way." Perfect.
Perhaps the last few years spent peddling celluloid sugar
water has softened his rabbit punch. Granted, many of his
myth-making quotables were stolen ("The journey...") or
nonsensical ("A dent in the universe"), but they never let
flag the "SJ Longa, Vita Brevis" banner that was so
disarmingly charming. Even his recent admission that he did
indeed dump all his Apple stock was impressive in its
up-yours impudence. I wish, at times, that I had that sort
of gall (although, honestly, it may not be a fair test: What
would YOU do with 1.5 million shares of AAPL?).
So, please, Steve, say something crudely amusing. Make fun
of Bill's haircut, impugn his typing skills, insult the
intelligence of his Smart House -- anything -- the more
tasteless and irrational, the better. Let us know that
you're the only one that exists. The world? Hey -- it's just
an extension. And extensions are disabled.
...But that's not why I called you all together here
tonight.
During the Audio and Video presentation of the BeDC in
Boston on a Tuesday in a dark room, I showed a trivial but
amusing application called Whisper. Whisper takes voice
input and fiddles with the sound in real time -- most
notably, it lets you shift the pitch of your voice as you
speak. Certain employees at Be have already used Whisper to
make prank phone calls, including a message in a demonically
basso voice left on Jean-Louis' voice mail demanding that
the caller (referring to himself in the third person) be
given a raise. Whisper is, obviously, a productivity tool.
Since returning from Boston I've received more than one
(two!) request that Whisper be availablized. Anyway, if you
start at
http://www.be.com/developers/developer_library/index.html
and poke around a bit (look in the "Sound" section), you'll
find a Whisper executable and BeIDE project. The interface
is pretty stark, the icon is vanilla, and there's no on-line
help, but all of that icing would only obscure a perfectly
twisted little cake.
Here's what you do:
- Get a microphone and plug it into the back of your
computer. It's possible to run music (from a CD, for
example) through the program, but it's not very satisfying:
Whisper gains real-time by cheating at fidelity (we all know
people like that). Music tends to fall apart under these
conditions -- except for the works of Sting, which,
mysteriously, sound much better.
- Gets some headphones and plug them in, too. You don't
*have* to listen through headphones, but it helps.
- Start the app; If you're running on a 66MHz machine, you
should immediately switch to 22050 in the SRate window
(otherwise it makes an annoying buzz). Faster machines
should have no problem running at the default sampling rate
(44.1K).
The app presents five "Fiddle" settings: Shift, Flipper,
Whisper, Chirpy, and Splatter. These are self-descriptive
sound manipulating filters. And there's a slider in the main
window that does something, although the relationship
between the slider and the something that it's doing isn't
always clear.
The sampling rate settings (44.1, 22.05, 11.025K), in
addition to having an effect on the performance of the app,
also influence the character of the filters -- more isn't
necessarily better: Splatter, for example, is more fun at
11025 than at 44010. (But aren't we all?)
Fool your landlord tomorrow -- download Whisper today! I
only put about 15 copies on the Web Site, so when they're
all gone, that's it.
Complement, Supplement or Replace?
By Jean-Louis Gassée
We are often asked if we are crazy and we think this is a
good question. Not just because we are polite and humble,
but because we feel this is a legitimate question, one that
allows us to clarify our position on the central issue of
our "raison d'être" -- as we say in English.
So, yes, we're crazy, but not that crazy. It would be really
insane, stupid, and expensively suicidal to present
ourselves on our developers and customers doorsteps,
assuming they have been waiting for us since the beginning
of time, or Windows, and declare we're here to displace
Microsoft. The BeOS is better, younger, faster, smaller,
cheaper, easier to program, we're taking over. OS/2, with
many good qualities and IBM's name and money, couldn't
compete with Windows. How could we succeed where IBM failed?
Precisely, as we'll discuss in a moment, we have very
different goals. Contrary to what IBM attempted to do with
OS/2, we are not trying to displace Windows.
Still, doing something different, against the official
thinking of the moment, requires a certain lack of wisdom,
the conventional one. Needless to say, we aspire to the
latter kind of unbalance. Then, if we're not competing
head-on with Microsoft, what are we doing on the Intel
platform?
The respective positions are quite simple. Windows 95 and
Windows NT are both general-purpose OSes. Windows 95 is
hugely successful on the desktop and Windows NT has become a
holy terror in the enterprise market. The BeOS, on the other
hand, is a nascent OS specializing in digital media content
creation. The general-purpose OSes have their advantages:
breadth of applications, familiarity, the support of a great
company.
Conversely, as a result of their very general nature, they
are at a disadvantage in more specialized media
applications. In our case, we lack legacy applications but,
free from the baggage, we offer superior performance, ease
of programming and (almost) friction-free market access,
specializing in the emerging digital media applications
where our elders are legacy-bound.
We are a complement to, not a replacement for, existing
general-purpose OSes. Depending upon their needs and
inclinations, users will pick one or the other, or more
likely both. They're already doing it today on Intel
systems.
From the very beginning, many operating systems have
coexisted on Intel-based PCs: Versions of DOS (MS/DOS, IBM
PC/DOS, DR/DOS), Windows (3.1, 95, NT), Unix (BSD, SCO, GNU,
Solaris), OpenSTEP, various flavors of Linux. As a result, a
genre has emerged, the boot loader. Linux, OS/2 and Windows
NT all offer one and there are several independent ones, the
most popular probably being System Commander. Not for my
mother, obviously, I don't see her partitioning her hard
disk and installing Linux or even her son's BeOS, but
technically proficient users, our natural audience, have
been doing it for years.
I dwell on this for two reasons. One is our Mac heritage.
Many of us come from Apple; the BeOS is currently available
on Power Macs. Contrary to the Intel world, the boot manager
genre has no meaning in the Mac space, no need. Second, I
believe there is a stark contrast between the high cost of
establishing a new genre and the much lower investment
required to play into an existing one. Which gets us back to
the earlier question of the kind of craziness tormenting us,
the lethally expensive one or the merely high risk, high
reward one. On Intel systems, we play in the established
context of multiple OS on the same hard disk. In that space,
there is the general-purpose OS category and the
special-purpose space. We play in the latter, we complement
rather than replace.
Now, there is the delicate matter of execution. It will
decide what kind of craziness really afflicts us.
BeDevTalk Summary
BeDevTalk is an unmoderated discussion group that's a forum
for the exchange of technical information, suggestions,
questions, mythology, and suspicions. In this column, we
summarize some of the active threads, listed by their
subject lines as they appear, verbatim, in the group.
To subscribe to BeDevTalk, visit the mailing list page on
our Web site: http://www.be.com/aboutbe/mailinglists.html.
- ----NEW--------------------------
Subject: Need input!
Marco Nelissen's solicited comments on his GUI layout tool,
and posed some font-management questions (the understanding,
here, is that the tool-built app wants to be able to
dynamically update fonts when the user changes the
preferences):
Q: If the program can specify any font for a control, then
what am I supposed to do when the default font changes? That
button that is currently set to use "Geek symbol fontset
bold italic size 85", should I reset it to the plain font?"
Q: Should a programmer be allowed to make a mess of his GUI
by creating, for example, multiple buttons all with a
different fonts?
Mr. Nelissen then offered his own inclination...
A: I'm inclined to make all classes in the library use one
of the three default fonts, always, and making them react to
those font-changed messages without regard to their current
setting. After all, those three fonts are what the user
prefers, and the user knows best, right? The most obvious
consequence of this would be that it would be pointless to
call SetFont()...
Laz Marhenke suggested that the proper principle to follow
is...
"...the right answer is 'whatever the program would have
done if it had been started up with these choices of plain,
bold, and fixed fonts"
...and gave an example that rebutted Mr. Nelissen's
always-use-default-fonts opinion:
"...my app will have Greek letters sprinkled here and
there... I don't want Omega turning into a little box when
the user switches font preferences."
Osma Ahvenlampi suggested an extended fonts preferences
mechanism:
"Could you perhaps let a program provide a list of the fonts
it uses in a BMessage ("big title font" = Times/20, "main
text font" = Times/14, and so on) that a separate extended
font config panel could edit?"
Mr. Nelissen turned the idea around:
"I just had an evil idea: drag&drop of fonts. Instead of
(or in addition to) making the library react to changes in
default fonts, FontSelector could let you drag a font onto a
control to change its font."
The thread then frayed into a separate debate: Should a
developer ever use a library that doesn't include source?
Most developers accept code-less system libraries
(libbe.so), but prefer that 3rd party libraries include
code. Some folks are adamant: They will not use a
(non-system) library that doesn't include code. Along the
same ethical standards line, a few developers also stepped
forward to aver that they do all their GUI design by hand;
given the right hands, layout can be done just as quickly by
typing in code.
Some other matters (picking on the state of the OS): There
should be a B_FONT_TYPE message type; BFont should be
archivable; UTF-8 encoding should revert to a default font
(death to the little empty squares).
- ----NEW--------------------------
Subject: format old FS disks
Ed Musgrove called in with this question:
"I have ... a handful of HD floppies formatted in the old
file system. PR recognizes these [but] I cannot for the life
of me format the now unneeded DR8 disks."
As Brian Stern and others correctly pointed out... "Use
DriveSetup. Unmount the volumes first, then you can
format/initialize them."
- ----NEW--------------------------
Subject: How compatible is Sockets API & behaviour
Is Be's socket implementation close enough to the BSD
standard to fool a CS professor? A few listeners wrote in to
give general approval to Be sockets, but also pointed out
some of the short-coming (sockets aren't file descriptors,
they aren't inherited across a fork, etc.).
So what about select()? Can it pass for the real thing?
Theoretically, yes (say most); but the implementation (one
thread per socket in the mask) is inefficient (say some).
The select() question opened a wider debate over
socket/thread scaleability (we travelled down this road some
months back). Should select() be avoided altogether? Says
Jon Watte:
"Actually, if you want to write efficient BeOS code, not
just port a quick UNIX program, you should spawn a thread to
serve each socket you're keeping open."
Howard Berkey agrees, but with a caveat:
"1 thread per socket has many advantages if you aren't
planning on one server instance handling more than a few
hundred connections at a time; it's elegant, robust, easy to
code, and in general far simpler. It's only when you get to
a huge number of threads that it starts to be a
problem... This is less of an issue currently under BeOS
[where] system limitations in Power Mac hardware preclude
I/O at a level where such scaleability issues become troublesome."
- ----NEW--------------------------
Subject: crypt standard
Is a crypt()-encrypted file portable? Answering the question
with a question, some folks wondered "why use crypt() (when
there are better encryption schemes)?" Answering with an
answer, the consensus seems to be "No -- not all crypt()'s
are the same."
Unsurprisingly, the initial simple question launched
discussions of the legality of encryption, the practical
applications in which encryption is most needed, encryption
implementations, and cracking the code. Osma Ahvenlampi
added this amusing, and probably accurate, note:
"...the easiest method of cracking the password is to ask
the user (in a state in which (s)he would be most likely to
answer)..."
- ----NEW--------------------------
Subject: Disabling live resizing
A question from Ficus Kirkpatrick: How do you ignore all but
the last of a series of FrameResized() events?
"What I am doing is spinning on GetMouse() until the buttons
are released... Unfortunately, I get all [the resized events]
once the mouse is let up..."
Some solutions were offered, none of them perfect. The best,
wait for the mouse up and then ignore all but the last
resize in the queue, is close, but a few resizes may still
trickle in.
- ----NEW--------------------------
Subject: B_PASTE vs BClipboard
Is Be's drag-and-drop messaging less than perfectly clear?
Trey Boudreau (and others) think so:
"There are now *no fewer* than THREE Be sanctioned methods
for Drag'n'Drop of text between applications: B_SIMPLE_DATA,
B_MIME_TYPE, and B_PASTE. BMessages and the Drag'n'Drop API
combine to make the most flexible system I've seen in a
static language. And right now, Be itself is driving it into
complete chaos."
Jon Watte amended the complaint somewhat:
"B_PASTE is not a sanctioned container of data. B_MIME_DATA
and B_SIMPLE_DATA should be folded into one, I agree..."
Mr. Boudreau also suggested that there should be more "what"
constants so message parsing can be quicker. Mr. Watte
countered that B_SIMPLE_DATA includes multiple format
representation; forcing data into finer categories inhibits
flexibility. But, says, Mr. Boudreau, what if two separate
field of the message are important (the example of dragging
text and a color chip at the same time was mentioned)? Brian
Stern...
"I think there will be very few cases where a single drag
target will allow more than one action for a given type of
data. In most cases the recipient of the drag looks through
the message for data that it knows about, and chooses to
handle the data however it wants... I'm not against custom
drag messages but I still think it's up to the drag
recipient to decide what to do with the drag"
The solutions to the text/color drag that were offered
involved developer intervention: It was conceded that the OS
itself can't figure this one out for you.
- ----NEW--------------------------
Subject: BeOS memory protection
Earl Malmrose was wondering:
"Outside of the known bugs, how can an app crash BeOS or
other apps?"
An immediate reaction (independently from two separate
BeDevTalk mainstays):
"Why do you ask?"
This coincidence didn't go unnoticed, at least not by James
McCartney:
"At 3:52 PM -0700 8/18/97, Howard Berkey wrote:
>The unknown bugs? :-)
> [...]
>Why do you ask?
At 4:13 PM -0700 8/18/97, Brian Stern wrote:
>Unknown bugs?
> [...]
>Why do you ask?
Aaaahhh...! They've finally cloned humans! I knew it
wouldn't be long after the Dolly thing!"
In response to the suspicion, Mr. Malmrose expressed some
skepticism of Be's claim for bullet-proof memory protection
(he comes from the Mac, so is understandably wary), and,
further, says he simply wants to know what to avoid doing.
Dave Haynie gave a thoughtful reply, which started with...
"each process (team) has its own MMU context, which does two
things. First thing it does is make every program start at a
fixed location (usually 0), which makes it possible to
easily share code segments, for example. The second thing
this does is define, on a per-process/ team basis, the
memory that the process/team can and can't access. Since the
protection is provided by the MMU hardware, it's very
robust, if not absolute."
|
