This will not have any advantage, since it will always load all DLLs,
unless delay loading is used, which doesn't work for ntdll and kernel32.
Also it won't provide the version specific environment, if you export
all functions from kernel32.
I really don't see why we should not put all functions into the core
DLLs, since IMO it's not the NT6+ APIs that are compatibility hacks, but
the win2k3 environment we only use to make up for missing functionality.
Timo
Am 20.05.2016 um 17:00 schrieb Love Nystrom:
Excuse my extremely late thoughts on this issue..
Perhaps they're moot already.
Regarding pt.3 in Timo's very succinct post (a year ago),
I see a possibility in a "proxy" scheme as follows..
The "standard" dlls knows the 6.x APIS, while implementing the "base"
5.2 functions, and forward newer APIs incrementally to versional
"add-on" dlls.
This ought to avoid bloat, both RAM and disk-wise.
// "Proxy" kernel32.dll knows APIs up to X.Y
kernel32.dll!Some52API_1 :: Built-in // "Base" APIs
kernel32.dll!Some60API_2 -> rkernel32_60.dll // Additional APIs only
kernel32.dll!Some61API_3 -> rkernel32_61.dll // Additional APIs only
For DLL_PROCESS_ATTACH the ROS loader could provide
kernel32.dll et.al. with version info, gleaned from the exe,
through lpvReserved, in case version specific init is needed.
In case the exe has no version info, fall back to 5.2.
Dito for the other "standard" dlls.
Was this what you had in mind?
(PS. I'm not privvy to the mechanics of SxS,
but I think they replace the entire dlls, wholesale.. right?)
Best Regards
// Neo
On 2016-05-20 17.57, ros-dev-requ...@reactos.org wrote:
From: Ros-dev [mailto:ros-dev-boun...@reactos.org] On Behalf Of Timo Kreuzer
Sent: 18 May 2016 20:28
To: ReactOS Development List<ros-dev@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: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
>
--
There is one thing stronger than all the armies in the world,
and that's an idea whose time has come. [Victor Hugo]
_______________________________________________
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
