#1071 Re: Project Definition
Expand Messages
Daniel Lee Kruse
Jul 31, 2004
Hide message history
--- In
osFree@yahoogroups.com, "Lynn H. Maxson" <lmaxson@p...> wrote:
[snip]
>
> Well, Frank Griffin and I argued on opposite sides of this on
> the FreeOS mailing list. He favored the layered approach;I,
> the uK. He favored concurrent execution with OS/2 as layer
> over a LInux kernel. I favored their concurrent execution
> running side-by-side, i.e. multiple OS personalities on a uK
> base. In that manner you could include Windows, BeOS, and
> others.
From the little that I've read of uKs, I think I prefer them over the
layered approach. All I do know, as long as it matches/exceeds the
performance of the current OS/2 kernel, I'll be happy. I have heard
that OS/2's thread scheduler is better than Linux's, at least at the
2.4 level. I haven't heard anything on the 2.6 level.
>
[snip]
>
> Regardless of whether you prefer a layered approach of a
> guest OS/2 replacement on a host Linux or a layered approach
> of an OS/2 replacement personality on a uK, you still have to
> define it to the detail that allows layering it on either. The
> only difference lies in what you have to know intimately,
> Linux or uK, to complete the detailed picture.
True.
>
> Now I really don't care what specification language used here,
> whether or not it differs from mine. If you choose to leave
> them "as is" in C, it has no bearing on my translating them into
> PL/E. The only real difference is that you will have two
> source forms, code and text, while I will have one: code. Thus
> I will only have one form to maintain, while you will have two
> to keep in sync.
>
> Now I started my thread on "Programming" give
> non-programmers an insight into the common features of an
> OS/2 API. Among those common features with few exceptions
> the return and parameter variables are all full words. As such
> they either contain an address or a signed or unsigned integer.
> Three possible data types: pointer, fixed bin (31) signed, fixed
> bin (32) unsigned. IMHO these have a clarity that the
> multitude of "extended" data types, which in fact introduce
> no real "new" data types, do not have.
>
> Until recently you could not say "pointer" in C because it did
> not exist as a separate data type. You still cannot say 'fixed
> bin (31) signed or (32) unsigned'. Instead the C advocates
> created extended data types by giving different names to the
> same underlying data type, relying on a macro language to
> resolve the extended name to the basic type, and
> incorporating the actual data type as a lower-case prefix in a
> variable name. Personally that seems like a hell of a lot of
> unnecessary extra work to define a 32-bit word in a language
> which has no means to operate on bits: no native bit string
> data types. Of course, someone will still insist that C more
> closely represent machine architecture even if it can't
> represent the one data type, the bit, which composes all the
> others.
And as I'm learning C better, the above mentioned is driving me up the
wall. Did somebody get bored so they need to "extend" the data types?
I'm so glad Java doesn't have the macros or typedefs.
>
> So we already have the C form of the OS/2 APIs published in
> IBM (and others') manuals as well as source code libraries.
> Instead of all these manuals we need only one, an open
> source one free of copyright restrictions, to call our own.
> What does it hurt to support two forms, a C form and a PL/E
> form? If at the end of the detailed design, the detailed
> algorithmic descriptions, you don't have a PL/E tool, you still
> have the uptodate C tools to use.
I don't see a problem in supporting a C and a PL/E form of
documentation. Actually, the specification language tool you keep
referring to could handle this.
>
[snip]
Daniel Lee Kruse
