for Aleksey - ARWINSS

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

zefklop
Developer
Posts: 114
Joined: Sat Feb 11, 2006 8:47 pm

Re: for Aleksey - ARWINSS

Post by zefklop » Thu Oct 01, 2009 7:57 pm

I'd say that ROS is much more missing features than in an "alpha" stage.

One has to be careful with the goal of this project:
To be an OS (meaning being the one of the first software layers above the hardware, and permitting other softwares to launch and providing some way to drivers to control the hardware) COMPATIBLE with windows (windows drivers and applications).

Guess what : Reactos is an OS, and if someone said : "ok, let it that way, let drivers/apps writer adapt their products to this platform", this would be possible without too many effort from the ros team. In this POV, Ros is in beta (to me at least). Someone could write some 3D rendering lib and tell graphics hardware builder what to do with it, as it was done for X11 or opengl on unix.

The other, and main goal of the project is to provide an alternative to windows. As it still lacks some of the features needed, then you can call it alpha/beta/whatever, it is just not ready to do it. Look at wine, they released 1.0, and the latest release if far more complete than the 1.0... (to me, they make a big mistake in continuing to keep compatibility with win9x, but that's an other story)

I don't think wikipedia articles can be pertinent with a project as ReactOS...

hto
Developer
Posts: 2193
Joined: Sun Oct 01, 2006 3:43 pm

Post by hto » Thu Oct 01, 2009 9:54 pm

asd1! wrote: While there is a progress, the question is: how many of such bugs still needs to be fixed, and how much of new ones will appear in the process?
How much time is it all going to take?
Tons. A lot.
Perhaps the whole approach is wrong, and has to be changed?
“What is the most important thing in the world? It is people, it is people, it is people.”

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: for Aleksey - ARWINSS

Post by vicmarcal » Fri Oct 02, 2009 12:23 am

zefklop wrote:I'd say that ROS is much more missing features than in an "alpha" stage.
(..)
I don't think wikipedia articles can be pertinent with a project as ReactOS...
Well,following the different definitions of Alpha state i can find in the Net.(Wikipedia is almost as valid as any other Information Source), ReactOS is alpha state without doubt.
Alpha state apps are not pretended to be working at 100% neither at 40%.Alpha software usually are internal apps and not released to Users at all, but as we are following GPL rules, we are releasing it (and its code).
When a first release is done then you are moving to another state called Beta and it is released to obtain feedback from users. Feedback can be quite bad or quite good, but feedback from users anyway with the idea of filling and resolving Bugs. ReactOS Bugzilla has been with us for some time now ;)
Of course the frontier from Alpha to Beta is blurred in a GPL project since one of the main differences is the public release(which happens in Beta stage and not in Alpha), and ReactOS is releasing since the first day.
Anyway the best way is helping to move forward..
I wont continue kidnapping this thread with this big offtopic :)
Image

b4dc0d3r
Posts: 148
Joined: Fri Sep 28, 2007 1:17 am

Re: for Aleksey - ARWINSS

Post by b4dc0d3r » Fri Oct 02, 2009 11:24 pm

Back to the original post: "It’s harder to read code than to write it."

I've heard that a lot, but I grew up learning code from other samples, mostly open source (a few books, but always supplemented with open source). I find it easier to read code, because I study code. People who find reading harder than writing usually spend most of their time writing. Since developers are paid to develop, not sit idly reading, it makes sense that they would spend more time doing that. Lots of people I've worked with are write-only. I tend to read as much as I can, so I can have many different ideas to choose from.

So here's where I disagree with Joel. In general, he's right, there's little benefit to rewriting and developers tend to try to make things their own way. Some like OOP, some like basic C, some like reusing components, some like custom components. It's easier to convert code to your way of thinking, there's no doubt. Here's where I disagree. If you can't read code BETTER than you write it, you have some personal development to do. Read other code, analyze it, point out pros and cons, decide which ideas to steal. In other words, do your homework.

Also, there is a big difference between real bug fixes and quick fixes. A rewrite should include the real fixes, and address all of the quick fixes which could have been done better. I have put in hacks to minimize the impact of a change, so I have less paperwork to do - these are the quick fixes which need rewriting. So yes you're losing all of the bugfix history, but you're re-designing parts to allow better solutions for those quick fixes.

Some day, you'll have to maintain or update or port your code... if you can't read what YOU wrote and make sense of it, you are either learning very quickly or brain damaged. Forgetting is acceptable, but something you created not making sense to you should be a warning sign. Other people's code, if you know lots of techniques and styles, should be a very similar experience - pretend you FORGOT what you wrote, and try to understand it that way.

Formal study might expose you to complex code examples, but there's no substitute for reading real-world code. I learned so much from reading MAME code back in the day I can't even begin to describe. Not saying it was all good examples, but it was full of tips and tricks.

The more you know, the better you are, because you have more options and alternatives to choose from. To choose the best sword, you have to see all of the swords.

Anyway, part of the fun of programming is pulling things apart and putting them together in unexpected ways. If you're NOT doing this from time to time, I would ask serious questions. You have an XML pipeline, can you substitute Microsoft's XML tools for your own? Can you replace an Oracle backend with MySQL? Can you change your data source from a database to an HTML scrape? (not recommended, but a fun challenge). If you can substitute components, especially when the goal is to be binary compatible (using MS .dll files instead of ROS, or the other way), your design is probably solid. In this case, a huge part of ROS code is from WINE, so.... why not? Not all programming output should be for keeps, as long as you learn something.

(maybe I'll come back and make this more coherent later)

reub2000
Posts: 100
Joined: Fri Dec 03, 2004 5:54 pm
Location: Evanston, IL, US

Re: for Aleksey - ARWINSS

Post by reub2000 » Sun Oct 04, 2009 7:10 am

Netscape might have tanked, but I wouldn't call the rewrite a failure. Far from it.

RaptorEmperor
Posts: 247
Joined: Mon Jun 26, 2006 12:04 pm
Location: Baltimore, Maryland, United States

Re: for Aleksey - ARWINSS

Post by RaptorEmperor » Sun Oct 04, 2009 10:12 am

asd1! wrote:vicmarcal
By Alpha, I meant: an OS that is stable enough for everyday use.
I've checked the latest ReactOS release, and it clearly isn't.

I read the newstellers, and most of the time I see minor stuff that been fixed, like cursor bugs, or some specific sound problem, etc.
While there is a progress, the question is: how many of such bugs still needs to be fixed, and how much of new ones will appear in the process?
How much time is it all going to take?

Perhaps the whole approach is wrong, and has to be changed?
That's what ARWINSS is for, isn't it? To try out a new thing.
Asd1!, your profile states you've been on the forums since July 2009. I've been testing ReactOS since 2005/2006, and it might seem slow from month to month, but over time those little changes build up. Even in the past year the operating system has become far more stable than it used to be. I still remember when ReactOS would lock up constantly and couldn't render the colors on Firefox properly, and that wasn't too long ago. The project plods along, but things do get fixed. All it takes is a little patience. Hopefully by this time next year we'll have the new Explorer up and running, have even better software and hardware support, and be anxiously waiting for 0.4.9 or 0.5.

Regarding ARWINSS, in my opinion, if Fireball wants to toy around with something on the side, that's his business, just as long as it doesn't have any detrimental impact on his work as project lead of ReactOS proper. If he learns something by working with the Wine code that could solve problems with ReactOS, great. If it goes in a different direction and someone else decides to maybe spin off a ReactOS derivative based off of ARWINSS instead of our default Win32, fine. This is an open-source effort. Everyone is a volunteer.
reub2000 wrote:Netscape might have tanked, but I wouldn't call the rewrite a failure. Far from it.
Agreed. I'm using Firefox right now. ;)

The123king
Posts: 242
Joined: Mon Jun 16, 2008 6:51 pm

Re: for Aleksey - ARWINSS

Post by The123king » Sun Oct 04, 2009 10:56 am

RaptorEmperor wrote:I've been testing ReactOS since 2005/2006, and it might seem slow from month to month, but over time those little changes build up. Even in the past year the operating system has become far more stable than it used to be. I still remember when ReactOS would lock up constantly and couldn't render the colors on Firefox properly, and that wasn't too long ago.)
Seconded. I started following the project ~0.3.4 and you try running that. It's near impossibble to run that for any period of time...

fireball
Developer
Posts: 358
Joined: Tue Nov 30, 2004 10:40 pm
Location: Moscow, Russia
Contact:

Re: for Aleksey - ARWINSS

Post by fireball » Tue Nov 03, 2009 1:20 pm

Thanks for all opinions, I really do respect our present win32 subsystem developers very much. It was not really possible to do arwinss back then, when the project started. If you look at Wine source code back a few years, it's quite a mess of 16 bit code, which is often done vice versa (like, ntdll functions calling kernel32.dll), and with a mysterious "window" module whose purpose is unclear.

But, have a look now. User32 and Gdi32 are distinct modules with very small Wine specifics (I removed it in Arwinss), which use an abstract high-level graphics API and Wine Server calls. It's quite logical to implement such a native driver as a win32 kernel component (which uses native Windows-compatible low-level video driver for high-performance graphics output), and implement parts of Wine server (a subset, which deals with windows, desktops, atoms, win32 objects, without ugly process/threads/waiting parts - they are offered by our native kernel) in win32k.sys.

Considering Wine is developed by hundreds of people, tested by thousands of people and application compatiblity database contains more than 10 thousand entries, I very much believe in success of Arwinss as a working solution.

The only disadvantage is that it's nothing near Windows's 2003 implementation. But, unlike the NT kernel, win32 subsystem is quite different in Vista, different in Windows 7. Is it really a disadvantage?

Also, with an abstract high-level graphics driver, it is possible to implement a Windows7-alike composite window manager for ReactOS right now, without any hacks: it just fits Arwinss/Wine architecture, which needs a client window manager for managing Windows.

Lone_Rifle
Test Team
Posts: 802
Joined: Thu Apr 03, 2008 2:17 pm
Contact:

Re: for Aleksey - ARWINSS

Post by Lone_Rifle » Tue Nov 03, 2009 2:07 pm

I say, if you ever finish work on arwinss, and merge any relevant improvements back to trunk, don't mind me if I fork it off to a separate SVN repository and hook it up to a Wine autosync script. I'm interested in the notion of having a NT-compatible OS that requires very little developer maintenance, never mind that some of the devs rightfully say that the Wine architecture is fundamentally different from Windows' and hence incorrect.

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: for Aleksey - ARWINSS

Post by vicmarcal » Tue Nov 03, 2009 3:20 pm

My opinion about this:

When a joined ReactOS i did because i was searching a GPL OS able to run Windows Apps+Windows drivers. At the beginning i thought that the architecture would be quite different, since Windows is closed, and that ReactOS was following a compatible implementation and not a perfect stone-by-stone implementation to reach these objectives.
So for me,as an user, i dont mind if you are using a perfect win32 subsystem or the UserMode of the Hell or Arwinss.As an user i just want to have my drivers and apps working.

Also when i joined i thought that ReactOS was using all the User Mode (or at least 90%) of the Wine User Mode project, and that the main point and the strongest point in ReactOS is the Kernel side.Because Kernel side is the one which runs the Drivers and because there isnt any other project (until now) able to run Windows drivers.So i thought that ReactOS were using a Hacked-Wine User Mode implementation and focused in the Kernel side.And this thought didnt make me run away.

I was surprised when i discovered we werent hacking Wine User mode to run on the Kernel Mode.And that we were splitting our efforts on creating a Win32 proper subsystem and creating the NT Kernel Mode. Surprised because we dont have enough manpower to split them in both sides,imo.

And now the future...

We have to attract Users, that is the point.An OS without users is like a Sea without water. When an OS attracts users, also attracts developers,testers,translators and companies.If Arwinss can attract users giving us an OS able to run the 80% of the Apps that Wine is able to run, plus the beneficts of running Windows drivers,all in less than one year,then continue with the work.Users or Companies doesnt mind about if it is following exactly NT-architecture, they just look the results.

And our results nowadays are: Linux+Wine usability > ReactOS usability


But i think the proper-Win32 subsystem that Physicus,Jimtabor and the other Devs are creating and have been creating for years shouldnt be thrown away or get forgotten.ARWINSS can be a fast way to obtain a better Apps compatibility, but in a long run ARWINSS cant fight against a proper Win32 implementation.This is one of the reasons that we have used to say that ReactOS (one day and thanks to follow a proper implementation) will be more compatible with Apps than Wine.

From the tester point of view having two different User Mode implementations can show us commun bugs, if they are commun it means the issue is in the Kernel side.So it can help to find bugs easily.Also, if Arwinss is following closely Wine implementation(plus some hacks) and an App is not working or crashing on ReactOS but working on Wine, it will make more easy to find where the bug is in the Kernel side.


So for me Arwinss could be a nice solution for this project but it isnt going to be a solution in a long-term plan.It can boost our usability while we continue developing our proper User mode.A developing which can be boosted thanks to this Arwinss implementation.


Thanks because arriving until here :)






.
Last edited by vicmarcal on Tue Nov 03, 2009 8:30 pm, edited 1 time in total.
Image

Aeneas
Posts: 463
Joined: Sat Oct 10, 2009 10:09 pm

Re: for Aleksey - ARWINSS

Post by Aeneas » Tue Nov 03, 2009 4:14 pm

One thing that has been going through my mind, maybe I should start a thread for that in its own right:

How do you think of running emulators ON ReactOS? In particular, the newest version of Wine? - This newest version, as far as I read, can run Cygwin. - So, you would profit twice: All the apps that do not work in ReactOS but do in Wine, and besides, all the stuff that is working in Cygwin. While I know that is definitely not the final goal, it might be a way to attract users (users being in my perception attracted by USEFULNESS). Even Dosbox might be helpful, too, though the testing report on it is not all too encouraging.

One problem - I did not see anywhere a recent build of Wine for Windows, only some quite outdated versions. But maybe the Wine people could help?

JPLR
Posts: 80
Joined: Tue Oct 14, 2008 4:58 pm

Re: for Aleksey - ARWINSS

Post by JPLR » Tue Nov 03, 2009 8:16 pm

Hi all,

@Vic: The world is changing ever and ever. Windows 3.5 had a graphic kernel in user land then Windows 4 put it in the kernel.
Many people claimed it was a mistake.
Windows 4 was supposed to be a rock solid OS but at the end there was many Service packs in NT4, then in 2K then in XP then in Vista.
Nowadays Windows developers are not of the first generation and they feel something should be done so because this situation is not tenable.
So a lot of Win NT4 kernel tasks are pushed back in user land, for example the UDMF driver framework.
And more and more user code should be managed code (C#)
That's the way of the future.

And I feel that even when one speak about the Win32K code in Reactos, look at the sources in Reactos 0.1, it is adapted from Wine.
For example this code that still exists in Wine:
http://source.winehq.org/source/dlls/gd ... ine-1.1.24
and reactos 0.1/subsys/win32k/bezier.c
The "old" Reactos graphics subsystem is since the beginning a derivative work, there is nothing magic in it.

@Fireball: My feeling is that you are doing the best thing to Reactos since years, please continue!

vicmarcal
Test Team
Posts: 2732
Joined: Mon Jul 07, 2008 12:35 pm

Re: for Aleksey - ARWINSS

Post by vicmarcal » Tue Nov 03, 2009 8:22 pm

Aeneas wrote:One thing that has been going through my mind, maybe I should start a thread for that in its own right:

How do you think of running emulators ON ReactOS? In particular, the newest version of Wine? - This newest version, as far as I read, can run Cygwin. - So, you would profit twice: All the apps that do not work in ReactOS but do in Wine, and besides, all the stuff that is working in Cygwin. While I know that is definitely not the final goal, it might be a way to attract users (users being in my perception attracted by USEFULNESS). Even Dosbox might be helpful, too, though the testing report on it is not all too encouraging.

One problem - I did not see anywhere a recent build of Wine for Windows, only some quite outdated versions. But maybe the Wine people could help?
Well we can run Vbox and some of the qemu machines inside ReactOS (if i recall correctly), so there you can install Ubuntu and on it Wine and on it any Windows app.But well..we are trying to avoid it ;).
I was surprised about the existence of Wine version for Windows, since it seems at first sight something...¿stupid?..Who is going to install on Windows an app (Wine) to make Windows compatible with Windows apps?But maybe there is something hidden that scapes from my low OS skills..
DosBox is currently regressed,and seems it will be regressed until 0.3.12.
I´m sure that our Devs will cut one leg before adding Wine to the release :)
Image

fireball
Developer
Posts: 358
Joined: Tue Nov 30, 2004 10:40 pm
Location: Moscow, Russia
Contact:

Re: for Aleksey - ARWINSS

Post by fireball » Tue Nov 03, 2009 8:34 pm

For now, there is no proper implementation of Wine for Windows. Cygwin version is seriously limited, and it's quite unlikely it's going to work properly. There are too many problems, look:
Win32 application
V V V
Wine layer
V V V
Cygwin
V V V
X Windows Server
V V V
Host Win32 API to display X Windows's windows
V V V
Bugs in ReactOS Win32 API + bugs in ReactOS networking API
V V V
User-visible result.

This is ugly. Instead, Arwinss implements Wine on Windows in a friendly way, removing all those layers where bug and slowdown occur:
Win32 application
V V V
Wine-based subsystem
V V V
Native video driver
V V V
User-visible result.

This is what I explained in previous emails.

RaptorEmperor
Posts: 247
Joined: Mon Jun 26, 2006 12:04 pm
Location: Baltimore, Maryland, United States

Re: for Aleksey - ARWINSS

Post by RaptorEmperor » Tue Nov 03, 2009 9:32 pm

Vicmarcal sums things up pretty good. To elaborate on what he started, though, I would personally factor in Windows.

Windows usability > Linux+Wine usability > ReactOS usability

We need to get as good as Linux + Wine, and then as good as Windows.

The whole argument for using ARWINSS to cross-analyze with the main ReactOS branch is kind of interesting. When ARWINSS is ready, perhaps we could have the installer ask whether to install the default Win32 subsystem or ARWINSS. That way, testers like me can have two virtual machines running default branch and ARWINSS and be able to come to easier conclusions for testing. If a program acts odd in default Win32 but not in ARWINSS, we can see what's going wrong in default and what ARWINSS is doing right. If the reverse should happen, we can simply see what ARWINSS (and by default, Wine) is doing wrong. We might even be able to return Wine the favor of using their code with our compatibility testing. If we do that, though, it might be wise to include another parameter in the Compatibility Database to differentiate between ARWINSS tests and default Win32 tests, though.

I think some people are exaggerating Wine's abilities compared to ReactOS, though. I tested Cave Story, had it running, and could technically play the game, albeit with minor flaws. I tried running Cave Story on Wine and I had to do a hard reset of the system because it froze. Under Wine Cave Story took ten minutes to get to a title screen, and even then I barely had control of the game. I haven't done as much testing on Wine as I have on ReactOS, but if it's a pattern there could be areas where our implementation of Windows is already more solid than Wine's.

I know I always mention testing Cave Story, but it's free, easy to obtain, and works with some basic Windows gaming functionality. The components Cave Story uses aren't too basic, but not so advanced as to being out of reach to fix in the near-term.

In response to Aeneas's suggestion about Wine on ReactOS, I'm not sure if that would work so well. To the best of my knowledge, Wine on Windows is somewhat experimental at this point, and testing it on ReactOS would just be too complicated. If one or the other freezes then you have to find out whether it's ReactOS's fault or Wine's fault, whereas if you were to simply run it in Windows you would know it was Wine's fault if something bad happened. Testing prototype software on prototype software is by definition not very logical.

We shouldn't have to run Cygwin on Wine, since it's meant for Windows. Cygwin installers for Windows should work just as well in ReactOS, at least in theory.

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 2 guests