Hi Elan, Another very interesting, reasonable, and though-provoking reply. I think I see where you're going with your thinking, and it makes me smile :) I have no love of any specific O/S... or ANY O/S at all, in fact! Give me a rebol-syntax-capable embedded tool that serves as the only piece of software I need for an embedded networking (messaging) application, and I'd be VERY happy! Allow it to be compiled for possibly faster running (though not terribly important to me in many applications), or at least provide a way to protect the source code for proprietary purposes, and stand back and watch the app's flow! :) >From what I've gleaned (I could be wrong), it seems REBOL makes heavy use of O/S networking capabilities (even if they were tacked onto the O/S in the first place, as with Winsock). There's no reason (other than time, effort, money! :)) that these could not be included within the language's native capability. Many embedded devices need no graphics, windows, etc... but they do need the ability to communicate with raw hardware through (hopefully, simple user-supplied) drivers for specific devices. One can pass off that task to the O/S or support it directly. Again, it's a matter of working smart vs. hard for the apparent payoff received. I understand why it's more tempting to ride on top of a sophisticated O/S and pass off as much as possible to it. Ya get further with less effort that way. But you also take on the (often horrendous -- at least for embedded app's) overhead of that O/S! I'm all ears to any encouragement you can give others to see things from this perspective. But I also understand fully why no actions might be forthcoming. Russ ------------ At 01:22 PM 10/27/99 -0700, you wrote: >Hi Russ, >you wrote: >>I agree that a working TCP stack is not the problem. I see the "DOS user >>base" issue quite differently, though. >> >>I'm not talking about people who actually run their PC with DOS as its O/S, >>but embedded systems that can very nicely (and efficiently, >>cost-effectively, etc) run from a DOS-type environment (both software and >>hardware) in devices where the O/S is not even visible (or a concern) to the >>user.... read "Internet Appliance" (set-top-box, etc etc etc). >> >>This IS in our future (see www.aplio.com for just one example), and to >>simply equate it to ancient DOS machines is missing the implications of this >>picture. Not all interesting/useful "networking" or "messaging" apps >>require 32-bit machines (and Windows and graphics and O/S's and OVERHEAD) to >>work effectively. Heck, I've done TCP/IP in an 8-bit micro w/o ANY O/S! How >>I'd love to have REBOL (or a compiled version of a rebol application) in >>there too :) > >For the sake of this discussion, perhaps it would be helpful to >conceptually separate the REBOL/Core implementation of REBOL from the REBOL >language (syntax and semantics)? > >Wouldn't an embedded REBOL implementation that includes a minimal set of OS >functionility be a better route then porting a REBOL implementation that >may include some unnecessary features to an operating system that also >probably includes quite a few bytes of unnecessary code (overkill + overkill)? > >What could be safely left out of REBOL for an embedded solution and which >features would have to be added in order to replace an OS? > >Elan > > >
