0.3.11 September

[RaptorEmperor]

Umm, the GUI is not tightly coupled with the kernel. In the original design it never was. MS made the decision later on to push the Win32 subsystem into the kernel for strategic/performance reasons. The result is that it's tightly coupled, but nothing about the NT kernel requires it to be.

Oh, I didn't know that. Mistake noted.

[ljenux]

strategic/perfomance issues?

that means, their strategy is to make system slower and they surely succeded.

[Z98]

Ironic that you claim that, cause Vista, the Windows version that everyone kept claiming was incredibly slow, was the version that moved so much of the Win32 subsystem back out of kernel mode. But looking at your other posts so far, I'm not surprised that you would claim this.

[greenie]

In my experience with many users of vista is that it is slow because it loads so much crap. On a fresh install of vista its something like 400+mb ram usage on boot. Alot of the time with vista on 512mb machines. Which is often advertised as vista ready computers. you open 1 IE and bang your using virtual memory. changing themes does not improve much.
I automatically downgrade 512mb. For 1 gb ram question people how often they will use it.
I have used vista on a medium computer not powerful, with 2gb ram and not had an issue with speed. apart from start up and shut down. Which is unbelievably slow.

[RaptorEmperor]

I have the same issue that Greenie does with Vista. I have Windows Vista Ultimate and it gobbled up a 20 gig hard drive, even before installing all the updates. What is really bad is that Vista Ultimate considers all the software installed with the OS as system components. Don't want Windows Movie Maker? Can't remove it, it's a system component. Don't want Solitaire? System component, too. It even considers software that doesn't come with lower-grade versions of Vista to be system components. I didn't have any performance issues per se, but that's because I have 3 gigs of RAM and a pretty good graphics card. Vista didn't recognize my graphics card out-of-the-box either, I should add.

In comparison, I have a 1.5 gig hard drive that I managed to install Windows XP in, and I'm currently running ReactOS off of now. They both deal with 512 megs of RAM pretty good, too.

On the bright side, Windows 7 is far less bloated with BS software and has far better compatibility than Vista. I'm feeling confident about it.

By the way, are there any plans to include more drivers in ReactOS? It seems like right now you need to have all of your drivers on-hand right now, since ReactOS doesn't come with any. If we want a good out-of-box experience, we'll need to include more drivers for more hardware at install.

[Haos]

Bundling drivers is NOT a solution. It is cumbersome and puts too much strain on team.

[RaptorEmperor]

Bundling drivers is NOT a solution. It is cumbersome and puts too much strain on team.

I'm not saying that the ReactOS devs should write drivers. If others are writing open-source Windows drivers, all the better for them to write them and leave the OS-writing to the ReactOS devs. If we could find open-source drivers that others have already written then I don't see any real loss by not bundling them with ReactOS. If open-source drivers are found, they could be tested by us compatibility testing guys and if they pass testing they could be included. It could become some of the most useful testing we do. ReactOS already looks for drivers at install, and I don't think that putting some in the install disk is rocket science when the framework is already in place.

I fully understand that writing the OS itself is far more important than pre-packaging drivers. I was just curious if prepackaged drivers were being taken into account, since it's not something that should be overlooked. Linux was dogged for years over a lack of drivers,and I'm not confident that all computer users are smart enough to go to the manufacturer's website to look up the drivers on their own. I'm not telling anybody when we should start bundling drivers, but it's something that'll have to be addressed sooner or later to ensure users have a good out-of-box experience.

[Z98]

Keep things in perspective. If ROS ever reaches a point where it is widespread, OEMs would likely be the ones putting it onto computers and they'd probably include all the necessary drivers anyway. With the ROS copy distributed from this site, you would only download it if you wanted to install it on a computer running a different OS. In that case, if you don't have the drivers for it and can't get it, well, then chances are the company that produced said hardware is either out of business or has end-of-lifed that particular product. At that point, it's far outside the purview of this project.

[Lone_Rifle]

OEMs

To detract from the original thread a bit, how about pitching to DMP? They manufacture a line of low-power low-performance x86 processors that finds use in x86-compatible devices also made by them and used largely by developing countries and embedded applications. They have the time to maintain their own Linux and Windows Embedded distros (scroll down to Operating Systems Support), so I would imagine they would have the expertise and may have the spare capacity and motivation to contribute to us. Especially given that we offer an NT-compatible OS with lower overheads.

[Aeneas]

As to the drivers, I suggest the following three alternative ideas:

1. Contact the manufacturers! I could imagine that they actually allow ReactOS the distribution of the drivers, and the drivers do not have to be open source actually - at this stage anyway. Include the most popular drivers on the CD. The manufacturers in fact could even indirectly profit from that, after all, you are trying to imitate Windows, so their investment in driver development does not go to waste.

2. Make ReactOS upon installation check the hardware and suggest the download of necessary drivers. This means, naturally, that your network card drivers or mobile link drivers must work in a limited way already. You can circumvent this by providing e.g. some "ReactOS driver helper application" that will run on an Windows or Linux, and it will analyse your hardware, suggest the drivers for download, then download them and create a little... zip or iso with them, whichever you prefer. Then you can copy them to a USB-stick and install ReactOS, plugging in the USB-stick during installation. This variant is the one I most prefer, as the drivers are publicly available and you would not actually distribute them, but instead just distribute a program that collects them.

3. This variant uses Windows, so you must have a valid and licensed copy of Windows: You have a program that determines which drivers Windows is actually using and copies those drivers to the USB stick. Again, when installing ReactOS, you also just plug in the USB stick. ReactOS then just uses Windows' drivers. Please note, you do not actually disassemble them or anything, you just - and purely optionally - use them.


As you notice, the underlying pre-condition always is that ReactOS actually CAN use Windows drivers. The thought behind my suggestions is that they "shield" the user from hunting drivers.

[zefklop]

2 and 3 are not applicable,as they require third party OS. Do you really think that people would download reactos if there is a sticky on it : needs linux kernel 2.6 on HDD to be installed. 1 would be applicable in the best of the world.

ReactOS has to bundle some generic drivers (mostly network) and maybe someone will write an app to fetch all the other ones that are needed.

Although I fear that one would have to port CUPS to windows, as many printer manufacturers drop support for newer versions of windows, which actually has an impressive number of printer drivers bundled.

[Lone_Rifle]

With regards to the driver discussion, third parties usually publish driver packs allowing users to slipstream those into their backup copies of Windows installation disks. The devs are more concerned with getting ReactOS to reach compatibility with Windows - other parties are free to fork and release their own distros, with added drivers, driver search tools or whatever these parties feel would be useful. As mentioned before, the devs are analogous to the linux kernel dev team, who are themselves least concerned about helping the user find drivers, or bundling drivers with the kernel itself.

[Z98]

In regard to #1, "popularity" is highly subjective and would not work as a metric. In fact, the PC world is filled with so many variations that we couldn't use popularity to decide what to include and what not to. This is also ignoring the fact that adding in drivers would significantly increase the size of the install CD and hosting the drivers ourselves would be very expensive from a bandwidth perspective.

[zefklop]

With regards to the driver discussion, third parties usually publish driver packs allowing users to slipstream those into their backup copies of Windows installation disks. The devs are more concerned with getting ReactOS to reach compatibility with Windows - other parties are free to fork and release their own distros, with added drivers, driver search tools or whatever these parties feel would be useful. As mentioned before, the devs are analogous to the linux kernel dev team, who are themselves least concerned about helping the user find drivers, or bundling drivers with the kernel itself.

You seem to forget that the linux kernel team includes third party drivers if they judge them acceptable. It could be an non-issue for reactos, as windows kernel does keep the driver API (almost) stable, whereas linux does not.

[Z98]

The Linux developers need to include a lot of drivers due to a problem of their own creation, their unwillingness to create a stable ABI for drivers. If they didn't take a direct role in developing and maintaining drivers, then breakages would be a lot more severe in between kernel versions.