just a side note... NT5.0 is Win2k.... we are targetting NT5.2.... On Tue, May 17, 2016 at 9:09 PM, Alberto Vaudagna < alberto.vauda...@gmail.com> wrote:
> Alex also does the NT5.0 kernel not have patch guard support? > It should be a good "secure" feature to add? > So there is not that many change on karnel side between 5.0 and win10 one > a part from the secure kernel stuff? > > > > 2016-05-17 20:58 GMT+02:00 Riccardo Paolo Bestetti < > riccardo.kyo...@live.it>: > >> Il 17/05/2016 20:23, Magnus Johnsson ha scritto: >> >> I am an utter scrubnub, but has followed this mailing list for.. more >> than a few years. Its not unheard of to get an angry response to a commit >> saying that its an API that is newer than the targeted version. >> >> Being a scrubnub lurker I can't help but think that being somewhat >> agressive on compatibilty modes would be nice, but.. I'll shut up now :'). >> Just wanted the "people are angry when non-targeted versions of API's are >> implemented" thrown in there. >> >> +1 to this, forgot to mention it. >> >> >> Il 17/05/2016 20:04, Alex Ionescu ha scritto: >> >> The project doesn't have to be hard-coded to NT5. For example, I am >> building a UEFI loader/bootmgr based on Windows 10, because 2003 >> doesn't boot on UEFI systems. >> >> That being said, I don't see any good reason for us not to still >> mainly focus on 2003 for the kernel. The kernel is NOT what's >> preventing apps from working, or hardware from working. What's >> preventing that from working is: >> >> 1) Lacking user-mode APIs, and in some cases Rtl APIs (sure, implement >> Win 10 ones!) >> 2) Lacking hardware support for things like UEFI (I'm working on it), >> AHCI (we have a student working on it), USB 3 (someone can implement >> this...but USB 2 barely works), etc..etc..etc.. >> >> Find me a single device driver that *only* works on NT 6... Server >> 2003 is still a support MS OS, so by definition there's still drivers >> for it. >> Best regards, >> Alex Ionescu >> >> Hello Alex, >> >> You can definitely focus on 2003 for the kernel, however keep in mind >> that you would be re-implementing 14 years that is an advanced state of the >> process of migration towards new software. >> Yes, user-mode APIs and lacking hardware support is what prevents apps >> from working now. Lacking kernel support is what will prevent apps from >> working in a few years. >> >> A clear example: most of new Windows application are being written >> against the .NET libraries, and the last version of .NET has already >> dropped Windows XP support. I doubt you can run .NET 4.5 on a 2003 type of >> kernel even if you implement the last user-mode interface (and afaik you >> can't even do that unless you implement some parts of NT6), so this is >> already significant portion of apps that ReactOS will never be able to run >> if you stick to NT5. Unless you want to reverse .NET 4.5 too and rewrite >> the it to run on NT5... The same goes for all other examples of this kind, >> both from Microsoft and from 3rd party vendors. >> >> I've also found an example of a device driver that only works on NT6, and >> in fact I didn't even have to look for it: it was the first device I saw on >> my desk. Elgato Game Capture HD, and that's pretty much the entire YouTube >> and Twitch gaming business (a multi-million dollar industry, for those who >> aren't familiar with it). >> Also, some of the newer printers in my father's business, as well as the >> GPS navigation system map update driver for some of his trucks, to give >> some "job industry" examples. >> >> Windows Server 2003 is definitely supported by Microsoft (which doesn't >> mean it is supported by others, and it mostly isn't), but it is almost >> dead, and it would only do harm to deny that. >> Implementing NT5 with the "NT6" user-mode API would lead to an Open >> Source Windows Vista, without the "wow Aero looks so cool" factor. Please >> don't waste all the magnificent work you've done so far like this. :) >> >> Best regards, >> --- *Riccardo Paolo Bestetti* >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev@reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev@reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >
_______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
