Using linux drivers in reactos !

[Z98]

What I see is an extremely naive interpretation of the micro-kernel architecture. The security benefits you speak of come at a considerable performance cost, something like 30% last time I read up on the topic. Operating systems seeking to use that model are generally designed to fit that model to begin with, not retroactively converted, because such conversions are generally infeasible because too many assumptions were made about shared resources being accessible. And this is assuming that the inter-system communication Windows drivers expect to be present are even possible in a micro-kernel environment. My instinct is pretty much a "maybe if we are damn lucky," but we're long past the point of trying such an experiment. What you propose would require a rewrite of at minimum the entire kernel, if not also the entire user land. We're not going to drop 15 years of work to chase an idea that may not even be possible.

[EmuandCo]

I still dont get it. One of the main approaches of ROS is to use Windows drivers, because they are generally easier to obtain. If you wanna use Linux drivers, then you should use Linux + Wine

[Aeneas]

If we wanted to use Linux, we would (and I do and it works just great).

But the world is FULL of Linux, while ReactOS is something "special".

Z98 replied above that using Linux' drivers would NOT be a shortcut - so thank you for the clear answer.

But this thing of "ReactOS is not suitable for everyday use" I deem is no more a very acceptable venue* : WHEN will it be suitable? The 20 years barrier should really be considered - we are now at 15 for all I read here. ReactOS actually IS pretty useable right now - you can write texts and do office work, and you can browse the internet. It is not too stable, allright; but so was Windows for 20 years.

What a bit remains is:

a) to connect fancy hardware, "fancy" being UMTS sticks, graphics cards, keyboars, mice, USB-sticks, cameras, scanners and printers - fine, some gas chromatographer or thelike will not work, but 95% of the potential user base would not care about that;

b) to get UEFI going, so you can handle future disks;

c) IPv6 - "modern times".

64 bit + loads of RAM: sounds cool but is actually not necessary, ReactOS will most likely not be used for such programs anyway. (Nobody really needs a 64bit DOS either.)

You either handle the drivers issues "now", or you make a really interesting project in the style of "recreating OS 360" or "resurrecting UNICOS". If this is impossible, then I think most urgent would be a PDF-printer - and the rest can be handled by "Linux as firmware", on top of which ReactOS could run (for those who just don't want ANOTHER "Linux plus Wine").

---

* Unless you want to stay in "hobbyist forever"-land; that would be perfectly fine - personally, I build acoustic couplers for fun, but I do not expect any "great recognition"; and the ReactOS devs apparently DO expect it, and you have a community very willing to actually give it to you.

[Z98]

ReactOS, as an OS, cannot run "on top of Linux," nor was Linux designed to be used in such a way. Please stop trying to suggest it as a feasible development route, unless you think it would be faster to gut ROS and try to extend Linux at the same time.

[hto]

ReactOS, as an OS, cannot run "on top of Linux"

He means, in a virtual machine.

[BlackRabbit]

IMO, the biggest reason, by far, that ReactOS has not reached general use is not lack of features (drivers/applications/etc.) but lack of stability.

Which of the two following aircraft would you rather fly from London to New York?

• A customized Boeing 777 with:
  • 20 LCD TV''s
  • Bose surround-sound
  • Choice of XBOX, PS4, Wii, etc.
  • 1000-title movie library
  • 100-title game library
  • robotic massaging chairs
  • billiards
  • cigar lounge
  • wet bar+wine cellar
  • fully-stocked galley
  • flight crew made of Brazilian models
  • Jacuzzi
  • showers
  • 25% chance of exploding, instantaneously, in mid-air
• A customized long-range Cessna 172 with
  • bag of peanuts
  • water (optional)

You would take the second option, of course; No amenity trumps not-being-dead.

Even if every other feature of the Boeing 777 were perfect, you would still take the second option, because an unreliable aircraft is simply not useful, no matter how many features it has.

An unreliable operating system is not useful, not matter how many features it has.

However, if ReactOS were made stable, at the core, with almost no features, meaning almost no device drivers, then it would become VERY useful, because the people who write device drivers for a living would not be blocked from providing device drivers for it.

Stability first. Features later.

[Z98]

ReactOS, as an OS, cannot run "on top of Linux"

He means, in a virtual machine.

At which point what is the benefit over Linux+Wine? Cause he's basically ditched the key defining aspect of ReactOS, the ability to use Windows hardware drivers.

[hto]

Hardware support is still not good — not even mice always work, people complain. What he is saying is that Linux + VM could serve as ‘firmware’, sufficient for the time being to create the pretence of a working system. Someone might want to use it, even if there is no benefit over Wine.

[BlackRabbit]

Isn't it true though, that if the ReactOS HAL, kernel, and other critical components were stable, the drivers that already exist for XP could be used?

[Z98]

Hardware support is still not good — not even mice always work, people complain. What he is saying is that Linux + VM could serve as ‘firmware’, sufficient for the time being to create the pretence of a working system. Someone might want to use it, even if there is no benefit over Wine.

People out there are already running ReactOS on vm software on Linux. What difference is there between his proposal and the status quo?

[PascalDragon]

I still dont get it. One of the main approaches of ROS is to use Windows drivers, because they are generally easier to obtain. If you wanna use Linux drivers, then you should use Linux + Wine

Think about the x86_64 and ARM ports here. For the former its less likely to get drivers for older hardware and for the latter even more (mostly thinking about USB devices here). So if someone (not necessarily someone of the ReactOS devs) manages it to use Linux drivers on ReactOS or even Windows itself, why not use it?

Oh and one could say the same for Linux some years ago when WiFi support wasn't the best. Why not use Windows instead? But to solve the problem someone came up with NDISwrapper, which is basically running Windows (NDIS) drivers in Linux.

Regards,
Sven

[Z98]

Because the ability to use Linux drivers requires that the underlying native hardware driver stacks in ReactOS already be complete. If that was the case, we would already be able to run Windows drivers. Any approach that tries to shove in a Linux hardware stack instead of just drivers themselves would require essentially a rewrite of the kernel and reducing compatibility with Windows drivers. We are never going down that route.

[Black_Fox]

Isn't it true though, that if the ReactOS HAL, kernel, and other critical components were stable, the drivers that already exist for XP could be used?

I guess. More importantly for the community (or so it seems), the version number could be bumped from 0.3.x

[Aeneas]

@ Z98:

What difference is there between his proposal and the status quo?

The difference is: right now, the USER has to set up the virtualisation environment. He has to take care of installing Linux, and on top of Linux some virtualisation software, and only THEN can he use the image that ReactOS provides. My proposal targets a "packaging" solution.

The difference to "Linux + Wine" is that the user does not actually have to deal with Linux - he stays in a nice "protected" environment inside ReactOS.

As a bonus, you could easily offer "system restore" possibilities by storing a backup of ReactOS somewhere in the "upper" Linux layer.

Fine, Z98, if you do not like this idea, then - what is yours? "Wait until we are done?" That would be great but: how long would that be? You say I deny an advantage, but I must counter, an advantage currently simply not observeable. My proposal may be denying a theoretical advantage that to some point people no more wish to wait for. The advantage for YOUR project would clearly be "broader market penetration", with potentially less work. I mean, look at OpenVMS: many people still wish to continue using it, and no, they do not want to buy Itanium - and there are SEVERAL virtualisation providers. It is an accepted solution. You are a highly respected developer and certainly more knowledgeable about the whole picture than I am, so if you reject my proposal, I am actually very willing to hear yours - so, what is your view on the further progress?

[EmuandCo]

Check the wiki test sites and recent forum post regarding the upcoming release and then dare to tell, there is no progress. My trout is waiting to slap ya ^^