ReactOS Future cross-compatibility

[alexei]

Of course, it's rather early to go ito details, but eventually ROS would need highly developed application compatibility layer, which would probably be extended to provide driver compatibility too. What I mean is that it's inevitable that ROS would have to offer each application and driver to run in some compatibility environment (Win200, Win2003, Win7, etc.). It may be slower running Win 7 applications, or Win 200 drivers, but that would serve the goal of "total" application compatibility.
Such approach may help with internal imcompatibilities and give more freedom to ROS developers in making architectural decisions. As extreme example it would be possible to run Linux (heresy ) kernel in a VM to support some "exotic" device and make it visible as a "normal" Win driver
BTW, I see no reason to duplicate whole MS OS management mechanichs (which would be very laborous). In my opinion command line management utilities wraped with WEB interface are much better. You don't need to use WEB-server, just manipulate DOM document in a browser / feed renderer with HTML. I've done some stuff this way. It's so easy. Please let me know if you interested - I'll create a new topic about that.

[PurpleGurl]

Of course, it's rather early to go ito details, but eventually ROS would need highly developed application compatibility layer, which would probably be extended to provide driver compatibility too. What I mean is that it's inevitable that ROS would have to offer each application and driver to run in some compatibility environment (Win200, Win2003, Win7, etc.). It may be slower running Win 7 applications, or Win 200 drivers, but that would serve the goal of "total" application compatibility.
Such approach may help with internal imcompatibilities and give more freedom to ROS developers in making architectural decisions. As extreme example it would be possible to run Linux (heresy ) kernel in a VM to support some "exotic" device and make it visible as a "normal" Win driver
BTW, I see no reason to duplicate whole MS OS management mechanichs (which would be very laborous). In my opinion command line management utilities wraped with WEB interface are much better. You don't need to use WEB-server, just manipulate DOM document in a browser / feed renderer with HTML. I've done some stuff this way. It's so easy. Please let me know if you interested - I'll create a new topic about that.

From what I've seen in two posts, we think a lot alike. I don't have the coding skill to attempt it, but I've entertained the idea of a driver compatibility layer. That could bridge the gap when you are stuck with only certain drivers. With Microsoft products, you generally have to use the drivers provided by the vendor which are written for the exact flavor. You can probably attempt tricks to force it to use different ones, which may or may not work. Now what if we had a layer similar to HAL, for instance to act as a go between for drivers intended for various Windows NT versions? Drivers that Rectos could use natively would bu run as such. Other drivers could be ran in a virtual layer. It would not be ideal, but it would work.

Of course, I admit that supporting a driver synthesis project may be a better option. Overall, Reactos would be best served by keeping things as simple as possible, and creating driver virtualization layers could complicate things. Now, driver synthesis projects are working on ways to take either data from spec sheets, pre-existing drivers, hardware specifications gleaned from the chipset of whatever peripheral, or brute force analysis of the devices, and then converting that information into drivers of the appropriate OS version. Such projects are promising, but not mature yet. The downsides are that generated code is generally much harder to debug, and that the generated code is not always complete. That way, we could support things where the support ended at Windows 2000 or as far back as 95/98/ME. We would not be able to run 95/98/ME/Linux drivers, but if a driver creator tool were available, the old drivers could be used for device analysis to create new drivers. If the driver maker tool could produce multi-threaded code, it could even make code that performs better than the original drivers for older machines did, since the created drivers could use modern resources.

[Z98]

No, we are not likely to support any kind of driver "compatibility" layer. Count your blessings that the NT6 line has not resulted in further fragmentation of the driver API as compared with NT5.