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:ros-dev-boun...@reactos.org] On Behalf Of Alex Ionescu
Sent: 17 May 2016 19:05
To: ReactOS Development List <ros-dev@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
<elh...@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
<elh...@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.kyo...@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:ros-dev-boun...@reactos.org] On Behalf Of
Javier Agustìn Fernàndez Arroyo
Sent: 15 May 2016 22:55
To: ReactOS Development List <ros-dev@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@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
_______________________________________________
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
