great project / suggestions

[Jan Tisje]

hi,

yesterday I read the first time about ReactOS. Probably it exactly is,
what I am dreaming about for years.

Small, stable, easy to use. and compatible to windows.... GREAT

I did not read the whole list archies yet, so please be patient, if my
ideas are old ones ;-)

Since I do not understand C (in fact I hate c/cpp) some very odd
suggestions are, to use very current technologies like
- XML
- a progamming language that is cool (probably no one exists yet)

so, for now it seems to be best to stay with c/cpp. :-(

that means to me it does not make sense to help in kernel development. 

A part that I could imagine is, finding software that is "cool" and
assigning "certificates" to this software. 

ok, it seems a little bit early compared to reactOS state... but, let us
think about it. 

A great problem on windows at the time is, 
there are millions of software projects, free or commercial, that one
can easily find to be very bad in software architecture and/or GUI
design.
Now if reactOS gets more mighty on the OS market, it could be an
instance that labels good software and thus forces software development
to raise in quality.

different labels to give: 
"reactOS compatible", "easy to use", "poweruser software",
"absolutly
stable"...

It took me years to find some great software and I think I can name some
applications that will fit, and some that will never. ;-)

later, reactOS could use these certificates to obtain money from
commercial software developers, as M$ does with its driver certificates.
"reactOS certified" ;-)

what do you think?

bye

Jan

[Nate DeSimone]

>  Since I do not understand C (in fact I hate c/cpp) some
> very odd
> suggestions are, to use very current technologies like
> - XML
> - a progamming language that is cool (probably no one exists yet)
>   
>  
So what do you suggest we program in other than C? XML?!  XML is used to 
transfer land store data, and its not compiled, its interpreted.  Its 
not something you would even write a small app using since its not for 
programming.  C and C++ may have a little more of a learning curve than 
Javascript, but if you have a strong command for the language and on how 
to write fast algorithms then it is definitely for best friend.  There 
really is no alternative than C when you are writing a new kernel 
(except perhaps assembly, but I couldn't imaging trying to write a whole 
modern kernel in ASM, it would be near impossible to write that code.)  
Moreover we work very heavily with the WINE project and all their code 
is C.  C++ and the Standard Library is a very current technology and 
while its not a buzz word right now, it will remain the language of 
choice for serious developers for a long time to come.  C, in its pure 
form is starting to get a bit dated, but it reduces overhead and runs 
faster than C++.

Nate DeSimone wrote:

>  
> >   Since I do not understand C (in fact I hate
> > c/cpp) some very odd
> >  suggestions are, to use very current technologies like
> >  - XML
> >  - a progamming language that is cool (probably no one exists yet)
> >   
> >  
>  So what do you suggest we program in other than C? XML?!  XML is used 
>  to transfer land store data, and its not compiled, its interpreted.  
>  Its not something you would even write a small app using since its not 
>  for programming.  C and C++ may have a little more of a learning curve 
>  than Javascript, but if you have a strong command for the language and 
>  on how to write fast algorithms then it is definitely for best 
>  friend.  There really is no alternative than C when you are writing a 
>  new kernel (except perhaps assembly, but I couldn't imaging trying to 
>  write a whole modern kernel in ASM, it would be near impossible to 
>  write that code.)  Moreover we work very heavily with the WINE project 
>  and all their code is C.  C++ and the Standard Library is a very 
>  current technology and while its not a buzz word right now, it will 
>  remain the language of choice for serious developers for a long time 
>  to come.  C, in its pure form is starting to get a bit dated, but it 
>  reduces overhead and runs faster than C++.
>  
It's not impossible to write a modern kernel in assembly, BeOS was a 
fine example of such a thing. It's a shame that Microsoft killed it...

[Robert Köpferl]

> >   
> It's not impossible to write a modern kernel in assembly, BeOS was a 
>  fine example of such a thing. It's a shame that Microsoft killed it... 
OK, and assembly is the reason for it's portability, isn't it?
>   
>  
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general

[Tobias Ussing]

no, not really, most assembly is platform specific.
for instance:
addi $1,1,$2
will set $1=1+$2 on x86
and set $2=1+$1 on alpha.

C is the reason for its portability. the C is compiled on a specific platform. 
the C compiler then converts the C into the platform assembly.
so in C:
firstvalue = 1+ secondvalue;
will compile for both alpha and x86, and will be
x86: addi $1,1,$2
alpha: addi $2,1,$1.

Thus, compatability is established.

Sincerly
Tobias Ussing

On Sunday 22 February 2004 03:13, Robert Köpferl wrote:
> >   It's not
> > impossible to write a modern kernel in assembly, BeOS was a
> >  fine example of such a thing. It's a shame that Microsoft killed it... 
>  OK, and assembly is the reason for it's portability, isn't it?
>
> >   _______________________________________________
> >  ros-general mailing list
> >  ros-general(a)reactos.com
> >  http://reactos.com/mailman/listinfo/ros-general 
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general

>   Nate DeSimone wrote: 
>   It's not impossible to write a modern kernel in
> assembly, BeOS was a
>  fine example of such a thing. It's a shame that Microsoft killed it... 
have a look at www.menuetos.org for a truly impressive assembler written os.

[Tom Lee Mullins]

ros(a)xzite.fsnet.co.uk wrote:

> >  Nate DeSimone
> > wrote:
> >     
> >  
>   
>
> >  It's not impossible to write a modern kernel
> > in assembly, BeOS was a
> > fine example of such a thing. It's a shame that Microsoft killed it...
> >     
> >  
> have a look at www.menuetos.org for a truly impressive assembler written os.
>
>
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-general
>   
>  
There is also a download section.

IIRC - isn't there an 'open source' beos? (I have to look again to see 
where I saw it).

TomLeeM

-- 
* * * * *BigWarpGuy / TomLeeM* * * *
 * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * eComStation * * * * * * * *
 * * * * * * * * * * * * * * * * * * * * * * * *
*   the os for the internet generation *
* * * * * * * * * * * * * * * * * * * * * * * * *
* * http://www.ecomstation.com * * * *
 * * * * *  * * * * * * * * * * * * * * * * * * *

[James Marjie]

Tom Lee Mullins wrote:

>   ros(a)xzite.fsnet.co.uk wrote:
>
> > >   Nate
> > > DeSimone wrote:
> > >     
> >
> >   
> >
> > >   It's not impossible to write a modern kernel
> > > in assembly, BeOS was a
> > >  fine example of such a thing. It's a shame that Microsoft killed it...
> > >     
> >
> >  have a look at www.menuetos.org for a truly impressive assembler 
> >  written os.
> >
> >
> >  _______________________________________________
> >  ros-general mailing list
> >  ros-general(a)reactos.com
> >  http://reactos.com/mailman/listinfo/ros-general
> >   
> >  
>  There is also a download section.
>
>  IIRC - isn't there an 'open source' beos? (I have to look again to see 
>  where I saw it).
>
>  TomLeeM
>  
http://openbeos.org/

[Martin Fuchs]

>   It's not impossible to write a modern kernel in
> assembly, BeOS was a 
>  fine example of such a thing. It's a shame that Microsoft killed it... 
BeOS?! BeOS is written using C++ and a _very_ object oriented API.

[Tom Lee Mullins]

Martin Fuchs wrote:

> >  It's not
> > impossible to write a modern kernel in assembly, BeOS was a 
> > fine example of such a thing. It's a shame that Microsoft killed it...
> >     
> >  
> BeOS?! BeOS is written using C++ and a _very_ object oriented API.
> _______________________________________________
> ros-general mailing list
> ros-general(a)reactos.com
> http://reactos.com/mailman/listinfo/ros-general
>
>   
>  
Is there an open BeOs?

TomLeeM

-- 
* * * * *BigWarpGuy / TomLeeM* * * *
 * * * * * * * * * * * * * * * * * * * * * * * *
* * * * * * * * eComStation * * * * * * * *
 * * * * * * * * * * * * * * * * * * * * * * * *
*   the os for the internet generation *
* * * * * * * * * * * * * * * * * * * * * * * * *
* * http://www.ecomstation.com * * * *
 * * * * *  * * * * * * * * * * * * * * * * * * *

[Martin Fuchs]

>   Is there an open BeOs? 
Well, look at http://www.beunited.org/ or http://www.openbeos.org/ .
But the most recent release seems to be non-free from Yellowtab:
http://www.yellowtab.com/

[Jan Tisje]

Nate DeSimone <desimn(a)rpi.edu> schrieb am Sat, 21 Feb 2004 11:51:52 -0500

>   
>  >Since I do not understand C (in fact I hate c/cpp) some very 
>  > odd suggestions  
^^^^^^^^^^^^^^^^
> >   are, to use
> > very current technologies like
> > - XML
> > - a progamming language that is cool (probably no one exists yet)
> >   
> >  
>  So what do you suggest we program in other than C? XML?!   
I am very sorry. you completly misunderstood. (seems to be my fortune --
to be misunderstood ;-)

This is the discussion i did not want to start :-(

first, additional to the goals of the RealOS, my personal dreams are
about a "perfect" programming environment. like your dream about a
perfect OS. 
C will always stay the language of choice for low level programming. 
But probably not for app development.

I said this, to make clear I would not be of much help in this area,
despite i do know some theory on OS programming. 

so, i found the second part of my mail to be a project , that could in
not so near future be associated to RealOS...

and  i want to hear your opinion....

>   Its 
>  not something you would even write a small app using since its not for 
>  programming.   
please have look at XUL (mozilla)
(it's for GUI only, but is used for something you probably could call
programming)

it may be good idea to use such modern tools instead of old ones...


Jan

[Mark IJbema]

On Sun, Feb 22, 2004 at 09:50:50AM +0100, Jan Tisje wrote:
>   
>  Nate DeSimone <desimn(a)rpi.edu> schrieb am Sat, 21 Feb 2004 11:51:52 -0500
[XML]
> >   Its 
> >  not something you would even write a small app using since its not for 
> >  programming.   
>  
>  please have look at XUL (mozilla)
>  (it's for GUI only, but is used for something you probably could call
>  programming) 
MS introduces such a thing in Longhorn as wel (XAML iirc) but afaik it's
far less powerful..

Mark

[robert K.]

>   C will always stay the language of choice for low
> level programming.
>  But probably not for app development. 
Thats also what I think. Despite that i like c++
We should think about allowing more/other languages for 
APP-developement. Of course core programming must be in C/C++
At least for protability and 'ease' of  build.

But some more less importand usermode apps or services may be programmed 
in other languages. They should however be maintained as binary by the 
maintainer, too.

>   
>  I said this, to make clear I would not be of much help in this area,
>  despite i do know some theory on OS programming. 
>  
>  so, i found the second part of my mail to be a project , that could in
>  not so near future be associated to RealOS...
>  
>  and  i want to hear your opinion....
>  
>  
> >  Its 
> > not something you would even write a small app using since its not for 
> > programming.   
>  
>  
>  please have look at XUL (mozilla)
>  (it's for GUI only, but is used for something you probably could call
>  programming)
>  
>  it may be good idea to use such modern tools instead of old ones...
>  
>  
>  Jan
>  _______________________________________________
>  ros-general mailing list
>  ros-general(a)reactos.com
>  http://reactos.com/mailman/listinfo/ros-general

[Semyon Novikov]

rK> Thats also what I think. Despite that i like c++
rK> We should think about allowing more/other languages for 
rK> APP-developement. Of course core programming must be in C/C++
rK> At least for protability and 'ease' of  build.

rK> But some more less importand usermode apps or services may be programmed
rK> in other languages. They should however be maintained as binary by the
rK> maintainer, too.

I think good languge for APP-development is Java. Object-orientied,
portable, not so fast but solid rock. Moreover ROS will have Windows
binary compatibility ;) And ALL (include M$) compilers will be aviable
on ROS.

-- 
Best regards,
 tappak

[Nate DeSimone]

>  please have look at XUL (mozilla)
> (it's for GUI only, but is used for something you probably could call
> programming)
>
> it may be good idea to use such modern tools instead of old ones...
>   
>  
Yes I am well aware that Mozilla uses XUL for its GUI (and anything else 
they can reasonably code in XUL) but XUL is an extension of XML, XML is 
not XUL, if you meant XUL then yeah I suppose, but XUL doesn't offer a 
whole lot of functionallity, and yes you could write a small app in XUL 
and does something trivial but Javascript (which is what XUL uses for a 
programming language) and interpreted languages in general are not 
scalable, so on any medium or large scale project XUL on its own would 
fail.  Though I'm sure it saves the Mozilla project bundles of time and 
effort by using XUL, it saves them from rewritting a lot of GUI code 
since thier browser is cross platform.

[KJK::Hyperion]

At 17.51 21/02/2004, you wrote:
>  [XML] its not compiled, its interpreted. 
don't say that! it may actually happen! :-)

>  There really is no alternative than C when you are
> writing a new kernel 
you can write one in almost 100% Java. See 
<http://jnode.sourceforge.net/portal/>. The worst problem is, as always, 
finding drivers for it. Don't ask me how do they implement the early 
bootstrap or resident routines or interrupt handling (for the latter I 
hypothize something like Windows ISRs + DPCs), but I think they're just 
technicalities at JIT or runtime library level

>  C, in its pure form is starting to get a bit dated, but
> it reduces 
> overhead and runs faster than C++. 
please don't make statements you can't possibly prove (essentially because 
they are false)