[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] WCOWORK vs WINDOM for components



on 7/24/2005 2:28 AM, evan@coolrunningconcepts.com wrote:

> Quoting Lonny Pursell <atari@bright.net>:
> 
>> I also have no interest in windom or any other lib for that matter.
>> If these libs have bugs, then you are importing other peoples bugs.
>> Agreed it might be fine for some, but definitely not for everyone.
> 
> And unlike writing it all yourself, open-source libs have their bugs by more
> than just you (usually years worth of development and debugging), and most of
> the work is done for you so you can concentrate on more important things.

Still I don't care.  I have my way of doing things, you have yours.
Not interested in someone else's GEM lib.  Period.
 
>> I also don't like the assumption that because a lib is already present that
>> OS dev needs to be stopped or changed to suit the lib.  That is just
>> backwards thinking.  It needs to go into the OS so we can keep the apps lean
>> and clean and not huge and bulky.   Also if it's in the OS, it makes it far
>> more easier for any language to access the features.
> 
> If a language can't call a C lib, then the language needs to be updated.

I didn't say what language.  Nor did I indicate such a short coming.
You are making assumptions.
 
> And .. put user libs in the OS?   Uhmm .. NO!   The OS is supposed to control
> the hardware and present an API to that harware for applications as well as
> present sharing of resources, and provide for IPC.   You start adding
> every lib
> available to C developers and your OS won't fit into RAM, even if you have 4GB
> of RAM.

I didn't refer to user libs or every lib.  Again assumptions.
 
>> An example might be the socket calls, now that they have been moved into the
>> kernel, they are no longer limited to gcc coders.  Prior to that it pretty
>> much required gcc.
> 
> socket calls fall into IPC and networking ... its supposed to be in the
> kernel.

True.  But they were not always in the kernel, and during that entire time
pretty much only usable from gcc.

-- 
Lonny Pursell    http://www.bright.net/~gfabasic/