RE: [ros-general] New to ReactOS

[Casper Hornstrup]

You can come by IRC for more or less private discussions.

http://www.reactos.org/en/community_irc.html

Casper

>   -----Original Message-----
>  From: jwalsh(a)bigpond.net.au [mailto:[e-mail]]
>  Sent: 18. oktober 2005 20:51
>  To: ReactOS General List
>  Cc: Casper Hornstrup
>  Subject: RE: [ros-general] New to ReactOS
>  
>  Thank you Casper.
>  In a nutshell ! !
>  I only wish I could have put it so succinctly.
>  The problem with ros at the moment (and it is not life threatening) is:
>  There is no space set aside for private discussion, but which, at the same times allows
> for
>  returning to the ros-general thread again.
>  Because of that (design failure not code failure), we all stay in the ros-general public
> space and
>  argue over the top of one another.
>  Sometimes it seems like the floor of the NYSE, where people must waive and shout to get
> attention
>  to their particular issue.
>  Good fun for some but agony for others.
>  Regards and rosuccess
>  Justin
>  
>  
>  ---- Casper Hornstrup <ch(a)csh-consult.dk> wrote:
> >   You have to know when to use it. I think we do
> > okay in that area.
> >  We have assembler optimized versions of string functions which are
> >  often executed during operation, but we also have C versions of
> >  these functions to make ReactOS easier to port to new architectures.
> >  We have assembler code for very low-level code which would be
> >  impossible to do in C. I believe there should be a minimum of
> >  assembly used to increase maintainability/portability and when used,
> >  it should be because there is a major speed difference during
> >  _normal operation_ of the OS. If a function which is called only
> >  once during startup of the OS could be made 1ns faster using
> >  assembly, then it doesn't really make ReactOS feel faster to the
> >  user even though running the function 10000 times in a loop might
> >  show a 1000% average speed increase. If the function was run 1000
> >  times a second during normal operation then the user might feel
> >  a difference. There are other ways to make ReactOS faster than
> >  resorting to assembly. You could use better algorithms for
> >  instance.
> >
> >  Casper
> >
> >  > -----Original Message-----
> >  > From: ros-general-bounces(a)reactos.org [mailto:[e-mail]] On
> > Behalf Of 
>  Kevin
>  > > Lawton
>  > > Sent: 18. oktober 2005 10:30
>  > > To: ReactOS General List
>  > > Subject: RE: [ros-general] New to ReactOS
>  > >
>  > > Yeah, okay, but . . .
>  > > With C being a 'higher level' language than assembler it will always
> be
>  > > easier for a group of humans to work on a project in. You could take this
>  > > further and use something like Java, though not for an op-system kernel as
>  > > Java programs need something below them to run the run-time virtual machine.
>  > > C is a good language for writing an op system in because that is why it was
>  > > designed (by Kerningham and Ritchie - their book on C is still the best work
>  > > of its kind). It was created to write the Unix op system in and the
>  > > combination of high and low-level features will always make it ideal for
>  > > such a task. In terms of generating nice tight machine code when compiled, C
>  > > is probably the best high-level language in this respect.
>  > > Modern computers are so enormously powerful that most projects feel that it
>  > > is unnecessary to use assembler for the extreme efficiency it offers - C is
>  > > more than 'good enough'. But, when projects ARE written for modern
> machines
>  > > using assembler we then start to see just how fast things can go. We might
>  > > feel that the 'average' PC is plenty fast enough performing day-to-day
> tasks
>  > > with an op system written in C and applications in Java or VB, and it
>  > > probably is, but give it a chance to run software written in good assembler
>  > > and you can get quite a surprise. Even if we think we can spare it, those
>  > > high-level language programs (incl op system) can perform nothing like the
>  > > blistering performance you can get from really good assembler code. You also
>  > > find that because assembler programming is so 'direct' then the
> resulting
>  > > machine code tends to be far more compact than that generated from other
>  > > languages. Smaller programs (op systems included) use less room on disk,
>  > > load faster into a smaller memory space and tend to have shorter execution
>  > > paths.
>  > > It is all fine and dandy that ReactOS will be a working 'clone' of
> Windows
>  > > but Windows is often criticised for being large and slow. What if ReactOS
>  > > could achieve full Windows compatibility while being much smaller and faster
>  > > ?
>  > > Kevin.
>  >
>  > _______________________________________________
>  > ros-general mailing list
>  > ros-general(a)reactos.org
>  > http://www.reactos.org/mailman/listinfo/ros-general