Re: [ros-dev] Pale Moon drops ReactOS support

[Alex Ionescu]

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


On Tue, May 17, 2016 at 4:44 PM, Javier Agustìn Fernàndez Arroyo
<elhoir(a)gmail.com> wrote:
>   "companies and such support NT5?"
>
>  where "support NT5", i meant "drop support for NT5", sorry
>
>  On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo
>  <elhoir(a)gmail.com> wrote:
> >  
> >  And why does few developers, companies and such support NT5? Because MS
> >  dropped support for those systems. But if ReactOS revives that support,
> >  maybe companies will support us.
> >
> >  On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti
> >  <riccardo.kyogre(a)live.it> wrote:
> > >  
> > >  I'd like to drop my two cents, just because I really believe in this
> > >  project's filosofy. Since things have gotten pretty hot in the past,
> > >  especially when someone who is not a developer intervened in a discussion,
> > >  let me apprise you that my only intention it to bring in the point of view
> > >  of a potential user that really wants to see ReactOS happen and isn't
> > >  emotionally attached to the work that has been done.
> > >
> > >  The reality is that very very few manufacturers and developers still
> > >  support NT5 and all of them are going to drop support in the next few years.
> > >  This is just a fact. NT5 is legacy software and there's nothing no one can
> > >  do about that.
> > >
> > >  I've followed this project and this mailing list for the past five years
> > >  and in this time I've upgraded all of the computer systems of my father's
> > >  business to Windows 7 and then to Windows 10, because all the pieces of
> > >  software they run dropped support for NT5, one after another. They still
> > >  have a single machine in the whole building running Windows XP, for legacy
> > >  software, and honestly they don't use it very often. In my school, pretty
> > >  much the same. And even if someone, for whatever reason, intends to run NT5
> > >  for 10 more years, why should (s)he re-setup all the systems again to run
> > >  ReactOS instead of keeping Windows XP?
> > >
> > >  The point is, you can either implement the architecture that runs all of
> > >  the computer in building, or the architecture that runs that one legacy
> > >  machine. And even that would happen if and only if you can achieve 100%
> > >  compatibility with all of NT5 and Windows XP bugs and quirks and give people
> > >  a really good reason to reinstall the OS on such machines, and sorry that's
> > >  just not gonna happen.
> > >
> > >  I get why some of you may want to stick to NT5, but you have to be aware
> > >  that if you do that ReactOS will never be used in the real world. No reason
> > >  to stick to NT5 is good enough, since no one out there needs or wants NT5.
> > >  Hell, it would probably be easier for a business to switch from NT6 to
> > >  GNU/Linux than to go back to NT5.
> > >
> > >  Again, these are just the two cents of a guy that works in the field.
> > >
> > >  Best regards,
> > >  --- Riccardo Paolo Bestetti
> > >
> > >
> > >  Il 16/05/2016 16:42, Ged Murphy ha scritto:
> > >
> > >  But you’re missing the point. The problem is that modern software is
> > >  leaving XP behind and focusing on Win7 as a minimum recommended requirement.
> > >
> > >  What use is ReactOS if none of the modern browsers or applications will
> > >  run on it? It limits the OS to being a compatibility solution for older
> > >  software, or a POS device. No one really wants to see that.
> > >
> > >
> > >
> > >  I think the best solution to start with is to keep reporting as 5.2 in
> > >  the kernel, but allowing developers to start moving to the NT6 model. An
> > >  mish-mash of NT5 and NT6 can co-exist as long things are done sensibly. e.g.
> > >  adding IO cancelation to our NT5 kernel isn’t going to make us incompatible
> > >  for XP’s drivers, but it allows us to implement an NT6 feature which hugely
> > >  benefits the OS. Other obvious candidates are unimplemented areas such as
> > >  the fltmgr . Why implement the 2k3 fltmgr when we can implement a later
> > >  fltmgr model which still loads older filter drivers.
> > >
> > >
> > >
> > >  Usermode should also still report as win2k3 (at least in the short term),
> > >  but start to add NT6 APIs directly into the codebase instead of using a
> > >  shim. We then maintain a whitelist of processes that don’t run on ros due to
> > >  a minimum requirement issue, and they get a modified result from
> > >  VerifyVersionInfo (and friends) to a later OS version.
> > >
> > >
> > >
> > >  The above changes keep things pretty simple to start with, and allow us
> > >  to move forward almost immediately with very little infrastructure work.
> > >
> > >
> > >
> > >  Ged.
> > >
> > >
> > >
> > >
> > >
> > >  From: Ros-dev [mailto:[e-mail]] On Behalf Of Javier
> > >  Agustìn Fernàndez Arroyo
> > >  Sent: 15 May 2016 22:55
> > >  To: ReactOS Development List <ros-dev(a)reactos.org>
> > >  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
> > >
> > >
> > >
> > >  "Being runnable only on old computers"
> > >
> > >  I think this is a bad understanding of the problem....
> > >
> > >  By such statement, it seems that ReactOS will only work on old computers.
> > >  And thats not true.
> > >
> > >  ReactOS may work in any computer where there is hardware drivers for.
> > >  And, as such, any software written for XP/2k3/ReactOS will work in that
> > >  computer.
> > >
> > >  And afaik, manufacturers are still releasing drivers compatible with XP
> > >  :) (nVidia, for example....)
> > >
> > >
> > >
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Magnus Johnsson]

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.

[Riccardo Paolo Bestetti]

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/

[Alberto Vaudagna]

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.kyogre(a)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(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Javier Agustìn Fernàndez Arroyo]

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.vaudagna(a)gmail.com&gt; 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.kyogre(a)live.it&gt;gt;:
>
> >   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(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>

[Neal Gompa]

On Tue, May 17, 2016 at 2:58 PM, Riccardo Paolo Bestetti
<riccardo.kyogre(a)live.it> wrote:
>  
>  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. 
I had to jump in on this, because this is becoming a repeated fact
that isn't true. Microsoft killed Windows Server 2003 support last
July[1]. It is most certainly dead to Microsoft. Please stop
perpetuating the idea that Microsoft supports a variant of a
15-year-old (!!!) operating system.

[1]: https://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Riccardo Paolo Bestetti]

Ah, good to know! Looks like I'm even more right :-).

It was about time.

Regards,
--- /Riccardo Paolo Bestetti/


Il 17/05/2016 22:57, Neal Gompa ha scritto:
>   On Tue, May 17, 2016 at 2:58 PM, Riccardo Paolo
> Bestetti
>  <riccardo.kyogre(a)live.it> wrote:
> >   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. 
>  I had to jump in on this, because this is
> becoming a repeated fact
>  that isn't true. Microsoft killed Windows Server 2003 support last
>  July[1]. It is most certainly dead to Microsoft. Please stop
>  perpetuating the idea that Microsoft supports a variant of a
>  15-year-old (!!!) operating system.
>
>  [1]: https://www.microsoft.com/en-us/server-cloud/products/windows-server-2003/
>

[Ged Murphy]

Okay, considering no other devs are chiming in on this, and Alex and I had a similar view,
I'd like to propose that we move towards a more hybrid system and remove the rule that
APIs that weren’t in 2k3 shouldn't be added.

Proposal:
  1) Add all user mode APIs directly into the code base, and do away with the
'kernel32_vista' libraries we have.
  2) Start to add kernel APIs which aren’t reliant on a particular feature. Rtl APIs are
the  obvious one as Alex highlighted, missing syscalls or enums for 'get/set info'
APIs are another obvious one.
  3) Features from later versions of NT can be added (e.g. IO cancelation, UEFI, ASLR,
etc). The supporting APIs should only be added when the underlying support is in place.
(i.e. don't stub NT6 APIs)
  4) Continue to report as NT5.2/win2k3 for now. We can consider bumping usermode to
report something newer at a later stage.
  5) In the short term add a simple compatibility mode which can provide a different OS
version for whitelisted processes. The front end could be similar Win7's '
compatibility tab in the file properties, however it wouldn't use shimeng.dll,
apphelp.dll, etc, it would just modify the versioning APIs.

IMO the above is a quick win to get newer apps running. Apps that check for OS version by
looking for APIs should now be happy due to #1. Apps which call VerifyVersionInfo /
GetVersion / etc can be tricked into thinking they're running on a later OS due to #5

David mentioned a compatibility shim would open the doors to NT6, but I don't think we
should be using it for this purpose. A compatibility shim should behave more like the
Windows one, that is it should provide 'hacks' to a more modern codebase to get
older apps to work (e.g. 9x APIs, missing flags, bugs some apps rely on, etc).
I do think the compatibility shim is worthwhile technology to add, but I think we should
use it as intended instead of trying to make it look into the future as well as the past.
(btw, didn't Alex write a tool for dumping the shim db in Windows which shows all the
'hacks' MS apply??)

Comments please.

Ged.


-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Alex Ionescu
Sent: 17 May 2016 19:05
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

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


On Tue, May 17, 2016 at 4:44 PM, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>
wrote:
>   "companies and such support NT5?"
>
>  where "support NT5", i meant "drop support for NT5", sorry
>
>  On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo 
>  <elhoir(a)gmail.com> wrote:
> >  
> >  And why does few developers, companies and such support NT5? Because 
> >  MS dropped support for those systems. But if ReactOS revives that 
> >  support, maybe companies will support us.
> >
> >  On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti 
> >  <riccardo.kyogre(a)live.it> wrote:
> > >  
> > >  I'd like to drop my two cents, just because I really believe in this 
> > >  project's filosofy. Since things have gotten pretty hot in the past, 
> > >  especially when someone who is not a developer intervened in a 
> > >  discussion, let me apprise you that my only intention it to bring in 
> > >  the point of view of a potential user that really wants to see 
> > >  ReactOS happen and isn't emotionally attached to the work that has been done.
> > >
> > >  The reality is that very very few manufacturers and developers still 
> > >  support NT5 and all of them are going to drop support in the next few years.
> > >  This is just a fact. NT5 is legacy software and there's nothing no 
> > >  one can do about that.
> > >
> > >  I've followed this project and this mailing list for the past five 
> > >  years and in this time I've upgraded all of the computer systems of 
> > >  my father's business to Windows 7 and then to Windows 10, because 
> > >  all the pieces of software they run dropped support for NT5, one 
> > >  after another. They still have a single machine in the whole 
> > >  building running Windows XP, for legacy software, and honestly they 
> > >  don't use it very often. In my school, pretty much the same. And 
> > >  even if someone, for whatever reason, intends to run NT5 for 10 more 
> > >  years, why should (s)he re-setup all the systems again to run ReactOS instead of keeping
> > > Windows XP?
> > >
> > >  The point is, you can either implement the architecture that runs 
> > >  all of the computer in building, or the architecture that runs that 
> > >  one legacy machine. And even that would happen if and only if you 
> > >  can achieve 100% compatibility with all of NT5 and Windows XP bugs 
> > >  and quirks and give people a really good reason to reinstall the OS 
> > >  on such machines, and sorry that's just not gonna happen.
> > >
> > >  I get why some of you may want to stick to NT5, but you have to be 
> > >  aware that if you do that ReactOS will never be used in the real 
> > >  world. No reason to stick to NT5 is good enough, since no one out there needs or wants
> > > NT5.
> > >  Hell, it would probably be easier for a business to switch from NT6 
> > >  to GNU/Linux than to go back to NT5.
> > >
> > >  Again, these are just the two cents of a guy that works in the field.
> > >
> > >  Best regards,
> > >  --- Riccardo Paolo Bestetti
> > >
> > >
> > >  Il 16/05/2016 16:42, Ged Murphy ha scritto:
> > >
> > >  But you’re missing the point. The problem is that modern software is 
> > >  leaving XP behind and focusing on Win7 as a minimum recommended requirement.
> > >
> > >  What use is ReactOS if none of the modern browsers or applications 
> > >  will run on it? It limits the OS to being a compatibility solution 
> > >  for older software, or a POS device. No one really wants to see that.
> > >
> > >
> > >
> > >  I think the best solution to start with is to keep reporting as 5.2 
> > >  in the kernel, but allowing developers to start moving to the NT6 
> > >  model. An mish-mash of NT5 and NT6 can co-exist as long things are done sensibly. e.g.
> > >  adding IO cancelation to our NT5 kernel isn’t going to make us 
> > >  incompatible for XP’s drivers, but it allows us to implement an NT6 
> > >  feature which hugely benefits the OS. Other obvious candidates are 
> > >  unimplemented areas such as the fltmgr . Why implement the 2k3 
> > >  fltmgr when we can implement a later fltmgr model which still loads older filter
> > > drivers.
> > >
> > >
> > >
> > >  Usermode should also still report as win2k3 (at least in the short 
> > >  term), but start to add NT6 APIs directly into the codebase instead 
> > >  of using a shim. We then maintain a whitelist of processes that 
> > >  don’t run on ros due to a minimum requirement issue, and they get a 
> > >  modified result from VerifyVersionInfo (and friends) to a later OS version.
> > >
> > >
> > >
> > >  The above changes keep things pretty simple to start with, and allow 
> > >  us to move forward almost immediately with very little infrastructure work.
> > >
> > >
> > >
> > >  Ged.
> > >
> > >
> > >
> > >
> > >
> > >  From: Ros-dev [mailto:[e-mail]] On Behalf Of 
> > >  Javier Agustìn Fernàndez Arroyo
> > >  Sent: 15 May 2016 22:55
> > >  To: ReactOS Development List <ros-dev(a)reactos.org>
> > >  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
> > >
> > >
> > >
> > >  "Being runnable only on old computers"
> > >
> > >  I think this is a bad understanding of the problem....
> > >
> > >  By such statement, it seems that ReactOS will only work on old computers.
> > >  And thats not true.
> > >
> > >  ReactOS may work in any computer where there is hardware drivers for.
> > >  And, as such, any software written for XP/2k3/ReactOS will work in 
> > >  that computer.
> > >
> > >  And afaik, manufacturers are still releasing drivers compatible with 
> > >  XP
> > >  :) (nVidia, for example....)
> > >
> > >
> > >
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > >
> > >
> > >
> > >
> > >  _______________________________________________
> > >  Ros-dev mailing list
> > >  Ros-dev(a)reactos.org
> > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> >  
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>  
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

[Timo Kreuzer]

Looks like I have to chime in here.

We have been discussing this before and I wonder that Alex is not 
heavily opposing the idea of randomly adding new exports to our user 
mode DLLs. It is a well known fact that applications check for existance 
of exports to decide how to behave, so ... not going to go over this again.

To addess this issue I suggested to implement a compatibility layer. And 
there was a detailed discussion about that on this mailing list. 
https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html

Please take your time to read the whole thread again so we can avoid 
wasting time, talking about the same things again.

Timo

...

Did you read it? Ok, then we can continue ;-)

Some remaining questions:
1. Does our SxS / ActiveCtx work properly, and does it work with 
registry/appcompat db? Otherwise what do we need to make it work? Aleksey?
2. How do we organize the DLLs? I would suggest to unite some core DLLs 
into "ros-kernelbase.dll" or something and gdi32/user32 into 
ros-win32.dll and export all functions from those, using forwarder DLLs 
through SxS. At the same time we should reorganize the code, organizing 
it the way that MS API sets do it. And also move the stuff out of the 
"dlls" folder into "win32core" or something.
3. How do we handle ntdll? Can we use SxS for ntdll as well? Obviously 
we cannot load the original ntdll with it, but we can probably load 
versioned wrapper ntdlls and resolve imports to those.

Timo

Am 18.05.2016 um 17:01 schrieb Ged Murphy:
>   Okay, considering no other devs are chiming in on
> this, and Alex and I had a similar view, I'd like to propose that we move towards a
> more hybrid system and remove the rule that APIs that weren’t in 2k3 shouldn't be
> added.
>
>  Proposal:
>     1) Add all user mode APIs directly into the code base, and do away with the
> 'kernel32_vista' libraries we have.
>     2) Start to add kernel APIs which aren’t reliant on a particular feature. Rtl APIs are
> the  obvious one as Alex highlighted, missing syscalls or enums for 'get/set info'
> APIs are another obvious one.
>     3) Features from later versions of NT can be added (e.g. IO cancelation, UEFI, ASLR,
> etc). The supporting APIs should only be added when the underlying support is in place.
> (i.e. don't stub NT6 APIs)
>     4) Continue to report as NT5.2/win2k3 for now. We can consider bumping usermode to
> report something newer at a later stage.
>     5) In the short term add a simple compatibility mode which can provide a different OS
> version for whitelisted processes. The front end could be similar Win7's '
> compatibility tab in the file properties, however it wouldn't use shimeng.dll,
> apphelp.dll, etc, it would just modify the versioning APIs.
>
>  IMO the above is a quick win to get newer apps running. Apps that check for OS version by
> looking for APIs should now be happy due to #1. Apps which call VerifyVersionInfo /
> GetVersion / etc can be tricked into thinking they're running on a later OS due to #5
>
>  David mentioned a compatibility shim would open the doors to NT6, but I don't think
> we should be using it for this purpose. A compatibility shim should behave more like the
> Windows one, that is it should provide 'hacks' to a more modern codebase to get
> older apps to work (e.g. 9x APIs, missing flags, bugs some apps rely on, etc).
>  I do think the compatibility shim is worthwhile technology to add, but I think we should
> use it as intended instead of trying to make it look into the future as well as the past.
> (btw, didn't Alex write a tool for dumping the shim db in Windows which shows all the
> 'hacks' MS apply??)
>
>  Comments please.
>
>  Ged.
>
>
>  -----Original Message-----
>  From: Ros-dev [mailto:[e-mail]] On Behalf Of Alex Ionescu
>  Sent: 17 May 2016 19:05
>  To: ReactOS Development List <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
>
>  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
>
>
>  On Tue, May 17, 2016 at 4:44 PM, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>
> wrote:
> >   "companies and such support NT5?"
> >
> >  where "support NT5", i meant "drop support for NT5", sorry
> >
> >  On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo
> >  <elhoir(a)gmail.com> wrote:
> > >   And why does few developers, companies and such
> > > support NT5? Because
> > >  MS dropped support for those systems. But if ReactOS revives that
> > >  support, maybe companies will support us.
> > >
> > >  On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti
> > >  <riccardo.kyogre(a)live.it> wrote:
> > > >   I'd like to drop my two cents, just because I
> > > > really believe in this
> > > >  project's filosofy. Since things have gotten pretty hot in the past,
> > > >  especially when someone who is not a developer intervened in a
> > > >  discussion, let me apprise you that my only intention it to bring in
> > > >  the point of view of a potential user that really wants to see
> > > >  ReactOS happen and isn't emotionally attached to the work that has been done.
> > > >
> > > >  The reality is that very very few manufacturers and developers still
> > > >  support NT5 and all of them are going to drop support in the next few years.
> > > >  This is just a fact. NT5 is legacy software and there's nothing no
> > > >  one can do about that.
> > > >
> > > >  I've followed this project and this mailing list for the past five
> > > >  years and in this time I've upgraded all of the computer systems of
> > > >  my father's business to Windows 7 and then to Windows 10, because
> > > >  all the pieces of software they run dropped support for NT5, one
> > > >  after another. They still have a single machine in the whole
> > > >  building running Windows XP, for legacy software, and honestly they
> > > >  don't use it very often. In my school, pretty much the same. And
> > > >  even if someone, for whatever reason, intends to run NT5 for 10 more
> > > >  years, why should (s)he re-setup all the systems again to run ReactOS instead of keeping
> > > > Windows XP?
> > > >
> > > >  The point is, you can either implement the architecture that runs
> > > >  all of the computer in building, or the architecture that runs that
> > > >  one legacy machine. And even that would happen if and only if you
> > > >  can achieve 100% compatibility with all of NT5 and Windows XP bugs
> > > >  and quirks and give people a really good reason to reinstall the OS
> > > >  on such machines, and sorry that's just not gonna happen.
> > > >
> > > >  I get why some of you may want to stick to NT5, but you have to be
> > > >  aware that if you do that ReactOS will never be used in the real
> > > >  world. No reason to stick to NT5 is good enough, since no one out there needs or wants
> > > > NT5.
> > > >  Hell, it would probably be easier for a business to switch from NT6
> > > >  to GNU/Linux than to go back to NT5.
> > > >
> > > >  Again, these are just the two cents of a guy that works in the field.
> > > >
> > > >  Best regards,
> > > >  --- Riccardo Paolo Bestetti
> > > >
> > > >
> > > >  Il 16/05/2016 16:42, Ged Murphy ha scritto:
> > > >
> > > >  But you’re missing the point. The problem is that modern software is
> > > >  leaving XP behind and focusing on Win7 as a minimum recommended requirement.
> > > >
> > > >  What use is ReactOS if none of the modern browsers or applications
> > > >  will run on it? It limits the OS to being a compatibility solution
> > > >  for older software, or a POS device. No one really wants to see that.
> > > >
> > > >
> > > >
> > > >  I think the best solution to start with is to keep reporting as 5.2
> > > >  in the kernel, but allowing developers to start moving to the NT6
> > > >  model. An mish-mash of NT5 and NT6 can co-exist as long things are done sensibly. e.g.
> > > >  adding IO cancelation to our NT5 kernel isn’t going to make us
> > > >  incompatible for XP’s drivers, but it allows us to implement an NT6
> > > >  feature which hugely benefits the OS. Other obvious candidates are
> > > >  unimplemented areas such as the fltmgr . Why implement the 2k3
> > > >  fltmgr when we can implement a later fltmgr model which still loads older filter
> > > > drivers.
> > > >
> > > >
> > > >
> > > >  Usermode should also still report as win2k3 (at least in the short
> > > >  term), but start to add NT6 APIs directly into the codebase instead
> > > >  of using a shim. We then maintain a whitelist of processes that
> > > >  don’t run on ros due to a minimum requirement issue, and they get a
> > > >  modified result from VerifyVersionInfo (and friends) to a later OS version.
> > > >
> > > >
> > > >
> > > >  The above changes keep things pretty simple to start with, and allow
> > > >  us to move forward almost immediately with very little infrastructure work.
> > > >
> > > >
> > > >
> > > >  Ged.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  From: Ros-dev [mailto:[e-mail]] On Behalf Of
> > > >  Javier Agustìn Fernàndez Arroyo
> > > >  Sent: 15 May 2016 22:55
> > > >  To: ReactOS Development List <ros-dev(a)reactos.org>
> > > >  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
> > > >
> > > >
> > > >
> > > >  "Being runnable only on old computers"
> > > >
> > > >  I think this is a bad understanding of the problem....
> > > >
> > > >  By such statement, it seems that ReactOS will only work on old computers.
> > > >  And thats not true.
> > > >
> > > >  ReactOS may work in any computer where there is hardware drivers for.
> > > >  And, as such, any software written for XP/2k3/ReactOS will work in
> > > >  that computer.
> > > >
> > > >  And afaik, manufacturers are still releasing drivers compatible with
> > > >  XP
> > > >  :) (nVidia, for example....)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > >
> > > >
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> > >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev

[Ged Murphy]

I read the mail, and while it's definitely an elegant and well-engineered solution,
I'm not convinced we need to go to that extent to support newer applications.

IMO applications checking for the existence of exports is not the massive problem it's
always made out to be. We all know this happens, but do we have any use cases we can use
to back it up? Can anyone point out any apps that would have a problem or is this all
hypothetical?

Possible scenarios:
1) App checks for an export, finds it and uses it. Everyone is happy, and we're
supporting a newer app. Yey! :)
2) App checks for an export and doesn't find it. It likely falls back onto an older
(XP) solution which we'll likely support. Still happy, and we now have the option to
implement support for this missing feature to make the app/user even happier.
3) App checks for an export, finds it and assumes a minimum OS. It therefore assumes a
certain design/architecture and acts upon it (e.g. session 0 are system processes only).
Okay so this is our pain point, and while it's clearly an issue in theory, does it
actually exist in the real world? And if so, how often would we see it? Could we work
around it using compatibility shims? This is what compatibility shims were designed for.

Most popular software is written by good engineers, and if good engineers are going to
make design decisions based on the OS they're running on, they'll normally use the
versioning APIs instead of trying to load an export that only exists on some boxes. So
again I'm wondering how often scenario 3 actually exists in the real world.

Let's not forget that nobody uses reactos. No one is paying us for support, and we
don't answer to anyone. Therefore if there's one misbehaving app out of 1000, is
it really such a big issue, especially if we're now providing support for more modern
apps that previously didn't work due to a Win7 requirement. If it's a popular app
that everyone needs, can we work around it using the compatibility shim engine? 

There has to be a trade-off somewhere as we have such low resources in terms of manpower,
money and time. The solution I presented is a quick win, and once we've taken a
reasonable step towards Win7 APIs, we could even report usermode as being win7 (with the
kernel still reporting as 5.2).

You presented your solution to the list over a year ago and we're still having this
discussion. Is anyone looking at it? Is it close to being finished? Will we still be
having this discussion this time next year?

Our other option is to go with a simpler solution which we can move to almost immediately.
We can deal with any problem apps if they actually materialize using compatibility shims,
which are being worked on and may soon be ready so solve our problems when they appear.

We have to start adding new APIs at some point to move forward, otherwise we'll be in
2020, still reporting win2k3 and implementing everything via your compatibility layer.

Ged.

p.s. Apologies for the slightly long mail, hopefully you got this far without switching
off ;)



-----Original Message-----
From: Ros-dev [mailto:[e-mail]] On Behalf Of Timo Kreuzer
Sent: 18 May 2016 20:28
To: ReactOS Development List <ros-dev(a)reactos.org>
Subject: Re: [ros-dev] Pale Moon drops ReactOS support

Looks like I have to chime in here.

We have been discussing this before and I wonder that Alex is not heavily opposing the
idea of randomly adding new exports to our user mode DLLs. It is a well known fact that
applications check for existance of exports to decide how to behave, so ... not going to
go over this again.

To addess this issue I suggested to implement a compatibility layer. And there was a
detailed discussion about that on this mailing list. 
https://www.reactos.org/pipermail/ros-dev/2015-March/017216.html

Please take your time to read the whole thread again so we can avoid wasting time, talking
about the same things again.

Timo

...

Did you read it? Ok, then we can continue ;-)

Some remaining questions:
1. Does our SxS / ActiveCtx work properly, and does it work with registry/appcompat db?
Otherwise what do we need to make it work? Aleksey?
2. How do we organize the DLLs? I would suggest to unite some core DLLs into
"ros-kernelbase.dll" or something and gdi32/user32 into ros-win32.dll and export
all functions from those, using forwarder DLLs through SxS. At the same time we should
reorganize the code, organizing it the way that MS API sets do it. And also move the stuff
out of the "dlls" folder into "win32core" or something.
3. How do we handle ntdll? Can we use SxS for ntdll as well? Obviously we cannot load the
original ntdll with it, but we can probably load versioned wrapper ntdlls and resolve
imports to those.

Timo

Am 18.05.2016 um 17:01 schrieb Ged Murphy:
>   Okay, considering no other devs are chiming in on
> this, and Alex and I had a similar view, I'd like to propose that we move towards a
> more hybrid system and remove the rule that APIs that weren’t in 2k3 shouldn't be
> added.
>
>  Proposal:
>     1) Add all user mode APIs directly into the code base, and do away with the
> 'kernel32_vista' libraries we have.
>     2) Start to add kernel APIs which aren’t reliant on a particular feature. Rtl APIs are
> the  obvious one as Alex highlighted, missing syscalls or enums for 'get/set info'
> APIs are another obvious one.
>     3) Features from later versions of NT can be added (e.g. IO cancelation, UEFI, ASLR,
> etc). The supporting APIs should only be added when the underlying support is in place.
> (i.e. don't stub NT6 APIs)
>     4) Continue to report as NT5.2/win2k3 for now. We can consider bumping usermode to
> report something newer at a later stage.
>     5) In the short term add a simple compatibility mode which can provide a different OS
> version for whitelisted processes. The front end could be similar Win7's '
> compatibility tab in the file properties, however it wouldn't use shimeng.dll,
> apphelp.dll, etc, it would just modify the versioning APIs.
>
>  IMO the above is a quick win to get newer apps running. Apps that 
>  check for OS version by looking for APIs should now be happy due to 
>  #1. Apps which call VerifyVersionInfo / GetVersion / etc can be 
>  tricked into thinking they're running on a later OS due to #5
>
>  David mentioned a compatibility shim would open the doors to NT6, but I don't think
> we should be using it for this purpose. A compatibility shim should behave more like the
> Windows one, that is it should provide 'hacks' to a more modern codebase to get
> older apps to work (e.g. 9x APIs, missing flags, bugs some apps rely on, etc).
>  I do think the compatibility shim is worthwhile technology to add, but 
>  I think we should use it as intended instead of trying to make it look 
>  into the future as well as the past. (btw, didn't Alex write a tool 
>  for dumping the shim db in Windows which shows all the 'hacks' MS 
>  apply??)
>
>  Comments please.
>
>  Ged.
>
>
>  -----Original Message-----
>  From: Ros-dev [mailto:[e-mail]] On Behalf Of Alex 
>  Ionescu
>  Sent: 17 May 2016 19:05
>  To: ReactOS Development List <ros-dev(a)reactos.org>
>  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
>
>  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
>
>
>  On Tue, May 17, 2016 at 4:44 PM, Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com>
> wrote:
> >   "companies and such support NT5?"
> >
> >  where "support NT5", i meant "drop support for NT5", sorry
> >
> >  On Tue, May 17, 2016 at 4:43 PM, Javier Agustìn Fernàndez Arroyo 
> >  <elhoir(a)gmail.com> wrote:
> > >   And why does few developers, companies and such
> > > support NT5? Because 
> > >  MS dropped support for those systems. But if ReactOS revives that 
> > >  support, maybe companies will support us.
> > >
> > >  On Mon, May 16, 2016 at 10:22 PM, Riccardo Paolo Bestetti 
> > >  <riccardo.kyogre(a)live.it> wrote:
> > > >   I'd like to drop my two cents, just because I
> > > > really believe in 
> > > >  this project's filosofy. Since things have gotten pretty hot in the 
> > > >  past, especially when someone who is not a developer intervened in 
> > > >  a discussion, let me apprise you that my only intention it to bring 
> > > >  in the point of view of a potential user that really wants to see 
> > > >  ReactOS happen and isn't emotionally attached to the work that has been done.
> > > >
> > > >  The reality is that very very few manufacturers and developers 
> > > >  still support NT5 and all of them are going to drop support in the next few years.
> > > >  This is just a fact. NT5 is legacy software and there's nothing no 
> > > >  one can do about that.
> > > >
> > > >  I've followed this project and this mailing list for the past five 
> > > >  years and in this time I've upgraded all of the computer systems of 
> > > >  my father's business to Windows 7 and then to Windows 10, because 
> > > >  all the pieces of software they run dropped support for NT5, one 
> > > >  after another. They still have a single machine in the whole 
> > > >  building running Windows XP, for legacy software, and honestly they 
> > > >  don't use it very often. In my school, pretty much the same. And 
> > > >  even if someone, for whatever reason, intends to run NT5 for 10 
> > > >  more years, why should (s)he re-setup all the systems again to run ReactOS instead of
> > > > keeping Windows XP?
> > > >
> > > >  The point is, you can either implement the architecture that runs 
> > > >  all of the computer in building, or the architecture that runs that 
> > > >  one legacy machine. And even that would happen if and only if you 
> > > >  can achieve 100% compatibility with all of NT5 and Windows XP bugs 
> > > >  and quirks and give people a really good reason to reinstall the OS 
> > > >  on such machines, and sorry that's just not gonna happen.
> > > >
> > > >  I get why some of you may want to stick to NT5, but you have to be 
> > > >  aware that if you do that ReactOS will never be used in the real 
> > > >  world. No reason to stick to NT5 is good enough, since no one out there needs or wants
> > > > NT5.
> > > >  Hell, it would probably be easier for a business to switch from NT6 
> > > >  to GNU/Linux than to go back to NT5.
> > > >
> > > >  Again, these are just the two cents of a guy that works in the field.
> > > >
> > > >  Best regards,
> > > >  --- Riccardo Paolo Bestetti
> > > >
> > > >
> > > >  Il 16/05/2016 16:42, Ged Murphy ha scritto:
> > > >
> > > >  But you’re missing the point. The problem is that modern software 
> > > >  is leaving XP behind and focusing on Win7 as a minimum recommended requirement.
> > > >
> > > >  What use is ReactOS if none of the modern browsers or applications 
> > > >  will run on it? It limits the OS to being a compatibility solution 
> > > >  for older software, or a POS device. No one really wants to see that.
> > > >
> > > >
> > > >
> > > >  I think the best solution to start with is to keep reporting as 5.2 
> > > >  in the kernel, but allowing developers to start moving to the NT6 
> > > >  model. An mish-mash of NT5 and NT6 can co-exist as long things are done sensibly. e.g.
> > > >  adding IO cancelation to our NT5 kernel isn’t going to make us 
> > > >  incompatible for XP’s drivers, but it allows us to implement an NT6 
> > > >  feature which hugely benefits the OS. Other obvious candidates are 
> > > >  unimplemented areas such as the fltmgr . Why implement the 2k3 
> > > >  fltmgr when we can implement a later fltmgr model which still loads older filter
> > > > drivers.
> > > >
> > > >
> > > >
> > > >  Usermode should also still report as win2k3 (at least in the short 
> > > >  term), but start to add NT6 APIs directly into the codebase instead 
> > > >  of using a shim. We then maintain a whitelist of processes that 
> > > >  don’t run on ros due to a minimum requirement issue, and they get a 
> > > >  modified result from VerifyVersionInfo (and friends) to a later OS version.
> > > >
> > > >
> > > >
> > > >  The above changes keep things pretty simple to start with, and 
> > > >  allow us to move forward almost immediately with very little infrastructure work.
> > > >
> > > >
> > > >
> > > >  Ged.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  From: Ros-dev [mailto:[e-mail]] On Behalf Of 
> > > >  Javier Agustìn Fernàndez Arroyo
> > > >  Sent: 15 May 2016 22:55
> > > >  To: ReactOS Development List <ros-dev(a)reactos.org>
> > > >  Subject: Re: [ros-dev] Pale Moon drops ReactOS support
> > > >
> > > >
> > > >
> > > >  "Being runnable only on old computers"
> > > >
> > > >  I think this is a bad understanding of the problem....
> > > >
> > > >  By such statement, it seems that ReactOS will only work on old computers.
> > > >  And thats not true.
> > > >
> > > >  ReactOS may work in any computer where there is hardware drivers for.
> > > >  And, as such, any software written for XP/2k3/ReactOS will work in 
> > > >  that computer.
> > > >
> > > >  And afaik, manufacturers are still releasing drivers compatible 
> > > >  with XP
> > > >  :) (nVidia, for example....)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev
> > > >
> > > >
> > > >
> > > >
> > > >  _______________________________________________
> > > >  Ros-dev mailing list
> > > >  Ros-dev(a)reactos.org
> > > >  http://www.reactos.org/mailman/listinfo/ros-dev 
> > >  
> >  _______________________________________________
> >  Ros-dev mailing list
> >  Ros-dev(a)reactos.org
> >  http://www.reactos.org/mailman/listinfo/ros-dev
> >  
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev
>
>
>  _______________________________________________
>  Ros-dev mailing list
>  Ros-dev(a)reactos.org
>  http://www.reactos.org/mailman/listinfo/ros-dev 



_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev