ASUS EEE

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

tomleem
Posts: 651
Joined: Mon Mar 28, 2005 6:59 pm
Location: New Hampshire of United States of America
Contact:

More appropiate than Windows

Post by tomleem »

linuxgx wrote:Like I said just add wine!

I like reactOS but i dont see it as being a liable OS for a subnote book in its current state. Wine is a much better choice at the moment.
I think it would be more appropriate than Windows and more compatible (progam wise) than Linux; IMO. 8) Since it is takes a fraction of space that Windows does, it is more likely to run better on this type of computer.
* * * * * * * * * * * * *
Tom Lee M / BigGoofyGuy
* * * * * * * * * * * * *
linuxgx
Posts: 170
Joined: Wed Mar 29, 2006 4:18 pm

Post by linuxgx »

:x What’s with you telling me that Ros is better than windows. Did I at any point suggest installing Windows. The AEEE comes with a very efficient version of Linux built just for the device. Its faster than any other OS you could install.

Also what’s the point of installing Ros on a pc which requires Wifi and USB in order to be of any use at all. If you want a note book to take notes in there are quite a few kids toys that can do the task.

WINE /= Windows. Wine = Emulation Layer.

That very same layer that Ros's Win32 support is modeled off of, along with a number of the wine DLLs

Now to the next genius that suggest crippling this device, because at the moment its pointless to install Ros on this device. Or if you suggest that wine is in some way windows. God help you, and hope that I don’t hunt you down j/k!!!
Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Post by Haos »

Not "very" same. WINE is known to hackfix several issues instead of coding them properly, for example GDI. ROS on the other hand needs clean and proper implementation. Yes, we do import plenty from WINE, but it requires additional rewriting/fixing, and sadly is often a source of our bugs.
linuxgx
Posts: 170
Joined: Wed Mar 29, 2006 4:18 pm

Post by linuxgx »

Thank you Haos, as I agree. May I stand corrected. Your wisdom on such topics is always welcomed.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Haos wine and Reactos made the same mistake on ok hack this fix it latter.

Wine has strict rules against it these days. Of course cleaning out many years of badly coded code takes time.

Reactos is really not in a place to complain about hack fixs.

Biggest existing hack fix in wine is that there are no users. Boy does that cause problems.
z180
Posts: 197
Joined: Sat Mar 10, 2007 7:58 pm

Post by z180 »

I also think that xandros is ok for the eee
but we are in the reactos forum and some guys already installed
alternative os as a test what can be done with the subnotebook.
Does anyone have already the eee.
I think its possible to test a restricted reactos on the eee.I can not make
a tutorial because i have no eee (perhaps soon).
you should first install it on a pc (set right video driver and mode for eee)and then copy the created directories
to the eee.That is not all because the bootsector is not there and
some drivers are not set up.you need to copy the fat32 bootsector
to the beginnig of your harddisk and for the drivers i recommend
testing the files in your eee xp cd because i cant test reactos on
SATA hardware.you still may have missing usb support!.
Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Post by Haos »

oiaohm, dont compare ROS to WINE in code quality. WINE has several times more developers, as well it deals with substantialy minor area than ReactOS.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Sorry to say Haos. Its not as minor as you might think. WINE has several times more developers but has a very large code base to take care of. As well many years of Mistakes to fix. The same types of mistakes in Reactos code base slowed development too.

Wine is after clean and proper implementations these days. Same way Reactos is after proper implementations to what it hacked up in the past. This is not comparing the code bases Haos. Basically same mistake is the same mistake if its made by 1 developer as 1000 developers so numbers of developers are not the issue. Now having a skilled enough developer to fix some of the hacks in the wine or reactos code base that should not be there can be kinda hard to find.

Note wine is slowly growing its own form of a NT kernel. Different from reactos due to two facts. Number 1 its usermode. Number two its maping to existing linux interfaces. First stage of usb mapping will appear in next version of wine.

Support area covered by Wine and Reactos will be the same. One is on top of Linux one is native.

The less sharable bits of wine that cannot match up to what ROS need perfectly are the parts that have to be built different or directly chosen different. Best one directly chosen not usable in ros is wine's text based registry. Really handy for debugging.
Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Post by Haos »

Oh cmon, oiaohm. WINE is all usermode. They dont need to take care about kernel mode, hal, loader, drivers, win32k, stacks... is it enough?

Its just the Win32 userland, plus translation layer, to direct Win32 API calls to linux native. Linux takes it over then. ROS codebase is much larger than WINE`s. Also remember Gsoc. How many times WINE was chosen compared to ROS? What about WINE developers?

Number of authors in 2002: 185
Number of authors in 2003: 167
Number of authors in 2004: 183
Number of authors in 2005: 212
Number of authors in 2006: 195
Number of authors in 2007: 218

Cmon! Ten times more than us. Project with a smaller codebase and commercial support!! Their code should be clean and ellegant. They have time, manpower and resources to make sure about it! Quite a team. Reactos barely exceeded 20 devs, most of those years. Number of developers IS an issue. If you have plenty of people to do easier parts, you can concentrate more skilled devs on harder projects. You cant defend the approach that number of devs has no effect on the project pace.

Is WINE really after clean and proper implementation? I think some of our devs would strongly disagree. You should ask Greatlord sometime how WINE devs treat our reports for on bad implementations in GDI or Dx...
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Pull your head out sand Haos. Due to wine have a working Linux kernel has altered the order of need. Long term is not different.

winedevice service was added for the direct reason of running windows drivers. Copy protection drivers first since they are at the most need.

Usb will be the first start of bridge between Linux hal and windows hal.

Driver support is long term requirement to run more applications. Note the first form of winedevice was a wrapped Reactos kernel.

GDI is one of these sections that the care of it in wine looks at it knows it needs fixing. Problem is fixing it without breaking lots of support in the process.

Out of the 218 developers there are less than 3 with the skill level to attempt deal with the GDI problems. Note the word attempt. GDI cause a lot of performance and other problems in wine. Nice up there is Starcraft. I can bet on at least 5 people a month with problems with it due to the GDI system.

Working with a operational code base is far more complex than Reactos. Ie you just cannot bring the complete thing to a dead stop to fix problems. There are many places doing that would be nice with wine.

Note Greatlord and the lead wine DX developer work with each other. Most of Greatlord issue has not been with the Lead wine DX developer.

Project lead of wine requires test cases and confirmation of need before changing functions too. There is a reason for this. Focus developers on need bits first. So without somethings get bounced.

You need to wakeup. There is a lot more to wine code base problems than number of developers same with problems in Reactos. Its not always possable to get developers to fix some problems. Under 1000 developers is not a lot really. Same problem not enough right skilled people.

Commercial Support is useful to a point. Note Commercial support wants the most application support as soon as able. So some sections get delayed.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

Seriously, you two. Stop arguing over this.
Haos
Test Team
Posts: 2954
Joined: Thu Mar 22, 2007 5:42 am
Contact:

Post by Haos »

Pull your head out sand Haos. Due to wine have a working Linux kernel has altered the order of need. Long term is not different.
And your point?
winedevice service was added for the direct reason of running windows drivers. Copy protection drivers first since they are at the most need. Usb will be the first start of bridge between Linux hal and windows hal.
Sandboxed and in usermode. Its also their choice. They could work on fixing bugs instead.
Driver support is long term requirement to run more applications. Note the first form of winedevice was a wrapped Reactos kernel.
Cool. It was till we were unjustly accused of using win2k leakage? What are they using now? I tend to doubt that they dropped our code completely and started researching NT kernel themselves...
GDI is one of these sections that the care of it in wine looks at it knows it needs fixing. Problem is fixing it without breaking lots of support in the process. Out of the 218 developers there are less than 3 with the skill level to attempt deal with the GDI problems. Note the word attempt. GDI cause a lot of performance and other problems in wine. Nice up there is Starcraft. I can bet on at least 5 people a month with problems with it due to the GDI system.
Do we have more GDI devs? I can name 2 - Jim and Timo. 3 if you count GreatLord as well. The difference is that we do not have additional 215 devs to take care of other issues. Another one - i`m almost certain that those 5 devs are working on WINE full time, whereas others have a day job... Yet we are able to perform a sound GDI rewrite, that is already taking place. Where is WINE with all its resources we lack?
Working with a operational code base is far more complex than Reactos. Ie you just cannot bring the complete thing to a dead stop to fix problems. There are many places doing that would be nice with wine.
This part assumes that ReactOS code is NOT operational... I`ll leave this without comment.
Note Greatlord and the lead wine DX developer work with each other. Most of Greatlord issue has not been with the Lead wine DX developer.
Again, please do talk with GreatLord privately about this, instead of assuming things. I can name at least one situation, upon which i stumbled by pure accident, that WINE was rejesting proper, proved and test-cased implementation, only because they failed to observe this issue. I doubt this was a single accident.
Project lead of wine requires test cases and confirmation of need before changing functions too. There is a reason for this. Focus developers on need bits first. So without somethings get bounced.
No wonder, the sheer amount of devs working on WINE forces such solutions on code management. Ours, due to a lot lesser number of devs is more informal. This doesnt change a thing. If you reject the dev no. argument, have this one:

Number of commits in 2002: 3094
Number of commits in 2003: 3283
Number of commits in 2004: 3851
Number of commits in 2005: 6006
Number of commits in 2006: 8431
Number of commits in 2007: 9513

Total: 34178 <- in 5 years, on a smaller codebase. They also didnt have countless WINE SYNCS like us...
You need to wakeup. There is a lot more to wine code base problems than number of developers same with problems in Reactos. Its not always possable to get developers to fix some problems. Under 1000 developers is not a lot really. Same problem not enough right skilled people.
I am awake. Partially I can agree. The difference is, again, that we sometimes do not have enough developers at any level. Not enough to take care even of some basic issues. We are lucky to have (also had) many very talented and skilled coders, but they are heavily outstreached. WINE doesn`t have such problems. Also, as i already mentioned, WINE works mostly in usermode. If they have kernel issues, they can use large and well organized group of Linux kernel devs. Does ROS have such ability? Nope. You mention wine version of registry... Still it is done inside *nix. You dont have to replicate CM... Wine has no problem with memory management, cache controler, no memory corruption issues, no random timing related kernel bugs... ONLY NT usermode and translation layer. You still say that this is more difficult than replicating whole NT arch, both user and kernel mode?
Commercial Support is useful to a point. Note Commercial support wants the most application support as soon as able. So some sections get delayed.
You somehow missed the point of this situation. The point in being able to get key devs on payroll, enabling them to work on WINE fulltime, whereas we cannot afford such a luxury.
oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm »

Reactos code is 100 percent gone from the winedevice system these days. Prototype winedevice due to Reactos GPL limitation was dropped. Yes they do have research and test cases.

That case was interesting with Greatlord sorry to say Haos I was partly involved with that. I went hunting a application that matched up to the problem. Note test cases alone are not what is require do spend time fixing a api fault in wine. Application usage is required with wine. Priority stuff yes its a little more complex dealing with wine. Fixing bugs in api that effect applications is taken over api error correction. Idea if error is used by nothing no need to fix at this stage in wine development.

You are missing the critical point just because someone is prepared to pay developers to work on wine that does not mean its not without conditions. Reactos progress many have been slower and worse if more of the lead programmers were paid. Company controlled limitations.

Other key thing you keep on missing. Ros rebuilding GDI ended up with quite a few non operational trunks. Non operational is not a option wine has without critical need.

Wine has limitations due to its active user base. Reactos does not have this issue. It what makes the difference in my mind between a operational program and a non operational one. You would not see Reactos at moment used in business so if you screw a few things up no major problems. Wine on the other hand doing that really causes big issues. GDI is kinda in the problem level of the direct x rewrite that happened back in 0.9.16 in wine. It has to hit a wall before it can be focused on.

GDI is a level ten pain to find developer to do in wine. Alterations have to go all the way threw to the X11 virtual video card driver in wine. Now person not only needs skills in Windows GDI also needs skills in X11 coding to work on it in wine. So really Reactos should have a lot simpler time finding the developers to do Reactos GDI no double skill set required. Note the same applies to DX developer. Direct3d development is sucking up most of Wine's developers with the needed skill set to work on GDI. Wine is just as short handed in some sections of there code base.

The other thing you are not seeing that even with wine support its developers are stretched to there limits. Between api faults needed by applications now. Fixing up device access support for applications like itunes to work.

Linux kernel developers rarely help with wine. Most common source of assistance from outside projects is samba. Same relationship in time
would be good for Reactos to setup.

You keep on calling wine a smaller code base. Lot of sections of wine enter reactos without major alterations. Device and service management and other key parts of wine don't enter reactos at all. Remapping Direct X to Opengl is 100 percent nasty job. Yes other OS kernels is under wine takes out some ring 0 level work. But it does cause its fair share of problems.

Ok sorry to say wine does have some major memory issues. Of course different ones to Reactos. Wine runs on OS X, Freebsd, Solaris and Linux. Linux developers have give Wine some custom memory location hooks to fix some problems. Others OS X, Freebsd Solaris don't so yes this still has to be fixed to match up with what a NT memory manager would do. Memory corruption issues yep do happen more often than not something trying to write to a non allocated address somewhere. Most of these with Memory corruption are fixed on Linux platforms due to the extra memory management hooks. Other platforms still living nightmares.

Ok random timing equal problem is there. To run some copy protection drivers you need almost exact timing matches to windows. Lovely annoyance is different gcc versions generate different timing code. Reactos has not started facing this nightmare yet.

Does this give you some kinda clues why Wine developer are kinda flat stack.

NT usermode on a system that is not NT is not exactly what you call friendly.

A usermode running NT kernel setup is needed more and more in wine to run applications. So really whole NT arch is needed in both. That is what you cannot see. Due to wine having ring 0 stuff provided by OS kernels they have been able to hack over things Reactos has to code to work now. These over hacks most of them will have to be removed from the wine code base over time to get the most operational applications.

Ie Wine has started at the top heading down. Reactos has started at the bottom working up. So wine has just delayed taken on some issues that Reactos has to get over just to work. Also makes wine priorities a lot different to Reactos's. The end point of both projects is close to the same. Just does not always look that way.

Both projects have there nightmares. Since you are not working around with wine alot(It kinda shows). You don't see the nightmares that are eating developer time hand over fist. Dealing with some of the issues in wine double the developers would really help.

Of course with Reactos problems having wine number of developers would be good too but the numbers would still be short for good development speed. So while neither project has over 1000 developers is still under resourced in developers. Yes Reactos is just a worse off than wine. But wine is still 100 percent stressed to limit.
linuxgx
Posts: 170
Joined: Wed Mar 29, 2006 4:18 pm

Post by linuxgx »

:? O keep going I knew you two would go at it sometime.

Honestly though Wine's kicking us in the ass, they are making several additions and bug checks that are sure to prove successful in crushing us. My goal was to see a replacement of windows, it seems that Ros is doomed to become nothing more than an example of NT architecture.

All thats left for WINE is to Add a Explorer GUI and a slim linux kernel and there going to start calling it WINEdows, just wait I'll put money on it. It would effecitly destroy anyone who supported us as a posable working OS.
Z98
Release Engineer
Posts: 3379
Joined: Tue May 02, 2006 8:16 pm
Contact:

Post by Z98 »

Right. And Wine is going to get support for kernel mode Windows drivers from where now? Cause the Linux kernel devs are not going to provide any such support. And since when was this a competition with Linux?

All of you, get it through your heads. The developers are not working on ROS solely because they think there's a demand for it, they're working on it because they want to use it.

Now I suggest all of you take some time to cool off. Both of you have made your points so leave it at that.
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Google [Bot] and 43 guests