From: "Lars Hansson" > > Using a background CLI app in BeOS, is not quite like forking. > What, exactly, do you mean by "Using a background CLI app"? Exactly what you understand. > I cant see how it's not forking. If you understand that creating a THREAD in BeOS is like forking then, I think you deserve a short explanation about forking and spawning. As I said, short: * forking involves creating an new context for a new app( new PROCESS, new userspace memory allocation(+mirroring original app space), new internal kernel data for that app(linked lists), etc.). processes created by fork don't finish execution when the main thread is done. If fact, I don't if there is a main thread OR, a team. * spawning only involves creating a new THREAD ( new, small, internal data; NO memory allocation and no copying). They, by default have one feature that I really like: shared memory! Linux doesn't have that, you must use pipes for simple communication purposes. > > BeOS used threads, Linux doesn't. > Linux has threads. Linux doesn't have threads! Yet! > > Anyway, why use additional system resources( the > > ones involving a new process ) when you can simply use a library in the same > > space as you app. Because only small programs( exception: compiler IDEs) use > > background CLI apps, why not use a small module with the same functionality? > > Because if there already is a standalone app that will get the job done > ,and your application isnt in need of the theoretical speed increase > that using an addon would give, the right thing to do is to use the > already existing CLI app. Now, I think you are narrow-minded! > > How many apps depend on CLI programs? > > How may apps use modules to achieve a goal? > > I'd say... the majority! See... people know what's better! > "The majority" is also using Windows, not Beos, so I guess Windows is > much better than BeOS... I don't care the OS name, a fact remains a fact! > Modules arent always the right choice. Maybe... Adi.