[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 at bigpond.net.au [mailto:jwalsh at bigpond.net.au]
> 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 at 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 at reactos.org [mailto:ros-general-bounces at reactos.org] 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 at reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-general