Yep. I remember when Be first announced Replicants. They were going to be the next ActiveX. I wonder what ever happened to them.
The sad truth is that absolutely nothing happened to Replicants. Almost no one ever used them. No great mountains of applications ever came out for them. I was chatting with some people the other day on IRC and we wondered about this. Needing to write an article and not sure what to write, that commiseration came back to mind.
Body: Let me start out by saying that I am not "against" directories. It is more like "rethinking" directories. We have been talking on the Glass Elevator list about queries and how to make them more useful for some time now. There is a pretty broad consensus that we should try to bring more use of queries into R2 and beyond, that we should help the end user to use them far more than R5 does.
BodyA printer driver in BeOS R5 is an add-on that exports a specific C interface. This add-on is used by the print_server to add a new printer, configure a page, configure the print job, and print the print job on the printer. This article describes how the print_server interfaces with the printer driver.
The print_server is responsible for maintaining common settings. BMessage objects are used to pass settings from the print_server to a printer driver and vice versa.
Body[Obnoxious, snotty narrator begins]
"....When last we left our heroes at Munstris Diveloperz Inc., they were left wondering how applications can be made truly simple. Some software just worked well and other software just seemed bad, but they couldn't figure out why. It seemed like finding a good software tool was no simpler a task than navigating a vast digital jungle with little more than a pocket knife while wishing for a razor-sharp machete.
This document describes the feature of the BeOS kernel to monitor nodes. First, there is an explanation of what kind of functionality we have to reproduce (along with the higher level API), then we will present the implementation in Haiku.
Requirements - Exported Functionality in BeOS From user-level, BeOS exports the following API as found in the storage/NodeMonitor.h header file:
status_t watch_node(const node_ref *node, uint32 flags, BMessenger target);
BodyI'm sorry, this is not about how to lock Haiku developers into basements to ensure they are most productive--it is a well known fact that this is BGA's speciality, anyway ;-) --no, I want to talk a bit about multiple threads and how to prevent them from mangling shared resources due to uncontrolled access.
Before you skip to the next article expecting to be bored to death by repetition of well-stressed basics, give me a chance to explain: Instead of wading through the fundamentals on BLocker or semaphores, I want to discuss a specific locking problem, for which I recently found, as I feel, quite an elegant solution.
BodyAlmost all of my recent coding efforts have gone into work on BMessage. Early on, I decided that wanted to try a more "modern" back-end to BMessage, something that would leverage the power of the STL. The end result is out there enough that I'm not sure I want to use it. At any rate, I'm not going to talk about that right now; maybe in another article, if you're all good.
BodyPart 1 Before the musicians in the audience get too excited, I'm not going to talk about getting together with buddies to crank out some tunes. Nor will the cooks in the audience find instructions on making the perfect fruit preserves. No, when I say Jamming, I refer to the act of using the Jam build tool.
In this first part of my series on the Jam build tool, I'm going to provide a high level overview as well as show the product of some of my recent labors with Jam: the Jamfile-engine.
BodyAll BeOS programs have "resources". Simply put, a resource is data that is bundled with your application's executable. Typical examples are the application's icons and its signature, but you can attach any data you want. Many applications store bitmaps, text, cursors, and even complete user interfaces (dialog boxes, menus, etc.) as resources.
This may sound a lot like attributes; after all, aren't attributes a way to store additional data alongside your files as well?
BodyThis second part of my introduction to MIDI programming on (Open)BeOS is about timing. If you read Part 1 and tried out the demo app, you may have noticed that playback of the notes really lagged behind if you quickly pressed several keys in a row. That is bad, because we want MIDI processing to be as real-time as possible. This article explains where the lag comes from, and shows you how to prevent it.
