[ros-kernel] ros wine dlls

[Waldo Alvarez Cañizares - another buried alive]

On Fri, 17 Oct 2003, Vizzini wrote:

> On Fri, 2003-10-17 at 15:00, pirata wrote:
> > > We're currently trying to forumlate permanent strategy with respect to
> > > using Wine code.  
> > Not to be very polemic/pessimistic, but it must be taken in
> > consideration we're developing a whole OS, my (very personal) point of
> > view is that it should be 100% fresh & new code, it could be 'wine
> > based' I don't disagree with that, but sharing code is a very
> > difficult task (think in ReactOS <--> Wine cvs code sync) and more
> > difficult if we take in mind we're talking about 2 VERY BIG projects.
> > Using existing code has the benefit of a very fast developing time
> > curve, but it inherits a lot of bugs, inconsistencies & the like.
> > Wine is developed as an Emulation, so its goal is to run Win apps
> > under other OSes.
> 
> I'm sympathetic to this stance, and it was how I felt originally.  I
> think the wine crowd has done a ton of really good work, though, and so
> for now, I want to use as much of it as we can.  If we have time to go
> back and re-do our own some day, we can consider the pros and cons
> then.  Re-inventing the wheel doesn't buy you anything either.
> 
> WRT code sync, I think we can get away with using cvs's built-in vendor
> branch management system.  Does anybody see a problem with that?  I've
> used it before to track apache, freeradius, and ultravnc, with good
> results.  This way we can maintain locally-modified sources, submit
> patches back to wine as needed, and still not lose track of everything.

I don't know what is a brach management but if is not a fork I think is 
good. With a fork or rewriting it from scratch the problem could be  in 
the future. Imagine some day we 
have ROS 
running 
pretty well (that day will come for sure) of course programmers will be 
able to use one of those sets of headers. So there will be 2 bands of 
programmers. Those using ROS headers and those using mingw ones. Fine also 
there will be ppl wasting their time trying to learn how to use both 
properly. 
Also building something COULD BE problematic in a computer having both 
sets. On the other side there will 
be some ppl working for ROS headers and those working for mingw. I think 
double work is bad for you. But when it goes for other ppl then you are 
wasting their time in a multiplicative way. I think the open source side 
could have a lot more advance if all those forks wasn't done. 

 
> > ReactOS is a full OS, so its main goals shoud be Efficiency and...
> > SPEED (very important), the code should be written optimally taken
> > these directives, no matter if it only runs in ReactOS, as we can
> > 'learn' from Wine, if we develop a cool thing, Wine's people can
> > 'learn' from ReactOS too, and we still can share experiencie,
> > knowledge, docs, etc
> 
> I agree here 100%.  I'd like to hear any opinions on how the wine x11
> driver approach would affect speed and robustness.  I'm skeptical, I
> admit, but I don't know very much about wine so I'm certainly open to
> being educated and convinced otherwise.  Regardless, as I said above, I
> do think we should use whatever we can from wine - we certainly don't
> have the resources at the moment to re-do this work.

According to software engineers there are some priorities to make quality 
software

1- Software should be correct (do what it is intended to do)
2- Software should be robust (not crashing with weird things and prevent 
security issues)

Have you ever seen an 8 billion dollars fireworks? The rocket Ariane is 
one example. The fault was a data representation error. It exploded in the 
37th second of flight. It's payload of 4 satelites was uninsured. !!!!

Or... how many companys have been hacked and lost money, the list is long.

Is like having a Formula-1 with an engine that will blow in your face.. or 
actually in your back :). Or without brakes :D

3- Should be extensible (cause you always want to rework something or add 
some feature as easy as posible) Every time you see something rewriten 
from scratch is because it was not properly planned. => Work to the trash 
can.

4 - Should be easy to use (cause you want a lot of users to use it, from 
genius to fools) of course if it is too slow you won't be able to use it.

5 - should be efficient (fast and eat little memory, including low hard 
disk 
space, low network bandwith required, ....)

6- Portable (cause you want to let it run if things change or maybe you 
want to explore new markets)

7- It must be economic (require little man power, time to produce) This 
one has a lot more priority in commercial software but can help in open 
source ones too.

OK orders may vary according to opinions but 1 and 2 are always going to 
be 1 and 2

Best regards
Waldo

> 
>  -Vizzini
> 
> 
> _______________________________________________
> Ros-kernel mailing list
> Ros-kernel at reactos.com
> http://reactos.geldorp.nl:8080/mailman/listinfo/ros-kernel
>