[ros-dev] Reactos and MinWin

Gerard Murphy to the ros-dev-mailing-list:

I’ve recently been taking an interest in MinWin, especially as it’s now visible in Windows 7, and I want to bring up the possibility of introducing something similar into ReactOS.

I know some of you will be familiar with WinWin and I know at least one of you will know quite a bit more about it than I do, but for those who don’t here’s an overview.

What is WinMin?

MinWin is an internal project at Microsoft that manifested around the time of the Vista rewrite. Very basically explained, the aim is to detangle the very core components from the full operating system, resulting in something which can be built separately and leaving just enough components for a working system. This minimal operating system can then boot and be tested separately or be built as part of the full OS and tested in internally as before.

The main problem in doing this, and one of the main benefits in solving it, is module dependencies. By simply cutting out the bottom part of the OS you’re left with modules which potentially call out to other modules which may now be missing. If these dependencies aren’t understood you have the possibility of an unstable OS as you never know where a code path may lead. It also means you need to build more components to get the thing to link, which also undermines one of the reasons for doing it.

What Microsoft did is to draw up a dependency tree and structure it in a layered hierarchy. Modules were then rearranged to make architectural sense according to the NT design and a top layer was decided upon. API call were then rewritten within this hierarchy such that anything in one layer would only call API’s in the layers below it. Therefore if something in layer 8 called something in layer 7 which then called something in layer 12, the APIs would be fixed to only use APIs at or below its level according to the hierarchy. You’re then left with a clean line where nothing calls out and you have a tightly bound core OS which is completely independent from anything.

What is essentially left in Microsoft’s WinMin is what people class as Cutlers NT along with supporting components to get a bootable system. The main components are:

The kernel (main kernel, not the full ntoskrnl module), parts of the executive, memory manager, networking, a file system driver and core drivers (basc IO and Bus, etc)

This is then exposed in usermode by 2 dlls, ntdll.dll and the new kernelbase.dll. On top of this you have a console for issuing commands.

This comprises of the full OS and amounts to about 25Mb on disk and has around a 40Mb working set.

Let’s quickly explain the new kernelbase dll.

As many of the API’s in the lower level dlls such as kernel32 and advapi32 were targeting functionality which wasn’t in WinMin, it was decided to pull out any of the API’s which were required to exercise WinMin and put them into kernelbase. This dll could then be used when building a running WinMin to provide all the functionality this kernel offered. The dlls which had their APIs removed now forwarded their call onto kernelbase so from a user perspective, nothing had changed.

Microsoft went a step further and designed a new technology around virtual dlls. They split functionality of dlls into ‘api sets’  These can now be seen in Win 7 in the system32 dir with the prefix ‘api-ms-win-core--<num of>-1-0.dll’. WinMin components now link against these virtual dlls which load up the real libs listed in apisetschema.dll.

However this involves modification to the loader and I don’t think it’s something worth us considering right now.

What are the reasons for doing this?

For a start, it’s a much better design from an engineering perspective.

The more software you have running on a system the more noise is created and the more things can interfere with each other.

It gives us a base to innovate with without worrying about affecting anything outside.

It gives us a more reliable base for the OS and a better platform to run comprehensive and efficient tests.

It makes us more attractive to external companies as we would have a slick NT compatible kernel ready for companies to build their products on, especially embedded applications.

With a few more additional items such as the base win32 subsystem, we’d have something along the lines of a stripped out ServerCore or Windows PE.

This is only a quick overview for discussion purposes, but it outlines the main design and goals of WinMin.

Comments, questions, concerns and gripes welcome J

Ged.

_____________________________

Ros-dev mailing list
Ros-dev@reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

Regarding UserAccounts in ReactOS

Hi,

many of you know we don't even support multiple Users at all, but I made some thoughts these days what way would be the best. I looked at the Linux and Windows ways and see pros and cons in both. Lets Compare them.

Linux uses one root account with all rights you can get and as much restricted ones as you want. This has the problem that you need for some apps root rights to get them install/run and as soon as these apps have these rights, they could easily kick your ass and kill the whole PC. So here I miss the softer differences between accounts. A root/User separation is not enough, we need steps in between.

Windows has a System Account with full rights, Admin Accounts with rights almost anywhere, Normal Users Accounts which only have access to their own and shared files and the Guest Account with NO rights at all. This is already much better, but I see problems here too. IMO the System Account has to be usable too to get things done, which fails on normal Admin Accounts. (Know these funny non deletable folders and files?!) The Admin Accounts are alright in theory. All Apps run there, so lets keep them for now. The next Problem is the User Account. You can't install any apps there which need a bit too much access to files. This can be bypassed of course, but only over a Admin Account which gives you the rights. IMO a good idea would be a Sandbox for files a setup wanted to replace and has no right to. The setup gets its files in place and they even work, but no Files from the main System are replaced at all. The funny aspect is, all files are usable like on a real Admin Account, so a virus could even work there and force you to reboot the PC because it fails BADLY. But there's the good aspect of the sandbox. You go into a recovery mode and say, kill the sandboxed files and the virus is GONE.

This sandbox aspect could be enhanced in a billion ways. A backup system which makes a System files Sandbox every week and you can switch between them.

Make apps only use a Sandboxed Version of important Files you made. This prevents Viruses to kill the Originals.

etcetc. Of course its just a thought of me. We could just use a powerful access System, too. Some ppl still might know WinPooch Watchdog. This app makes it possible to badly restrict any accesses to files and folders and that in a really hardcore way. It hooks in some Kernel APIs and thus restricts file/registry and whatever access for specific apps and users. This would be a nice thing for our accounts too.

Source: http://dreimer.dr.funpic.org/sblog/ - thx dreimer!