 Это огромное удовольствие для меня, чтобы поговорить здесь. Как many of you have already heard about ReactOS? Президентно. О, это довольно много. Ок, так. Эта история будет довольно... Не так много технических, но я покажу несколько технических деталей. Так что это не будет просто, как ReactOS. Но мы начнем с этого. Так что эта история будет интервью. Потом мы увидим реакцию системы, как это сделано. Потом мы поговорим о ReactOS kernel. Потом будет лодр, который я работал активно в последний раз. Потом мы сделаем небольшой сомнер. И в конце концов, мы закончим реакцию системы. Так что давайте начнем. Что это реакция? Это началось около 10 лет назад, как и для того, чтобы сделать то же самое, что Линус Торвальс делал с Unix. Потому что в 70-х годах, реакция системы была Unix. И он решил провести приятную реакцию системы в Unix, и называем ее Линус. Мы делаем что-то подобное, потому что мы проводим оперативный систем, который способен с Windows NT, оперативным системами. Реакция системы полностью от скровечи не используется. Она не используется на Линус kernel, как многие видят. Реакция системы вообще не используется. 100% компетенции с Windows. Так что это не только на Unix kernel, это весь оперативный систем. Реакция системы используется на GPL, как вы думаете, это довольно хорошо. И сейчас мы имеем около 20 активных разработчиков, которые работают в этом проекте. И, конечно, реакция системы очень disponима для всех. Это не вообще никакая компетенция, которая поддерживает что-то, потому что это совершенно свободная инициатива. Давайте посмотрим на реакцию системы. Как вы видите, это классический дизайн в Windows NT kernel. Реакция системы и, в принципе, нужно полностью поменять в Windows NT kernel. Интернартная архитектура, публичные интерфейсы, дровище и аппликация. Так что наш системы полностью компетенции. Как вы видите, это обычная вещь для Windows NT kernel. Это не связано с Linux в любом случае, с архитектурой. Давайте посмотрим, что kernel consist of. В принципе, kernel consist of a few files. It's kernel itself. It's hardware abstraction layer. It's device drivers. Also, we have to provide some components to the system, which are needed for it. So this is Win32 subsystem, which provides application program interface for Windows applications, actually. Then we provide network drivers, complete network stack, because it's not possible to go without it. We provide GDI, user interface, we provide DirectX and OpenGL libraries for graphic support. Of course, we use, where it's possible, we use open source projects. For example, in networking, we use a complete TCP IP stack implementation from library OSKit TCP. In OpenGL, we use Mesa, of course. And in DirectX, we share some work with Wine project. So let's see, what is hardware abstraction library. It is done as a DLL file, which is referenced by the kernel itself, until it's kernel. And technically, we try to make it so, that exported APIs correspond to the ones of Windows 2003, Service Pack 1 Windows. But this is not exact copy. So there are a couple of specific functions. And hardware abstraction layer and kernel interfaces are not compatible with Windows in TFM. As of now, we have UP and MP versions. But right now, the most actively worked on, on a single processor-based version of hardware abstraction library. As a proof of concept, we made also an Xbox version of hardware abstraction layer, which provides a unique ability to work on Xbox game console. Because even Microsoft did not plan to make Windows working on Xbox, but ReactOS already works. So what is MTA's kernel like there? It's actually what is called the kernel itself. Physically, it is done as a portable executable, which references a few other DLLs, like hardware abstraction layer, debugger interfaces, and boot video support and some others. Our kernels developed completely from scratch. As I already said, it's not based on Linux or any kernel code. And bootloader does, actually, all the work on loading kernel is DLLs, setting up hardware trees and stuff like that. So let's see. Architecture is the kernel. As of now, we make our goal to make the kernel compatible to Windows 2003. It's the most up-to-date, and, as we said, the best kernel out there of Windows NT family. So it works evenly. So exported APIs correspond to this version of kernel and all internal structures, which are more or less referenced by device drivers or by debuggers, also correspond to this kernel. About... There are some questions about methods of development of our kernel. And certainly we base our work mostly on the legally available sources of documentation, like books and some other internet resources, like OpenRCE, where they provide code chains and things like that. So the kernel itself consists of a few modules. They are usually referenced by two or three letters, and they provide all this architecture, which is behind this kernel. So we will see what they are. First of all, there are cache controllers, which manages cache prefetching and all operations related to file system support. This is currently not implemented in ReactOS. This is CM. This is configuration manager. Simply speaking, it's support for registry. It's in the kernel. This is high-level routing to manipulate with registry. ReactOS have a quite simplified implementation, which is not optimized for speed or for size, but just does its work. Then there are debugger interfaces, file system support. Executive systems and boot-video support. Also there are quite a few more subsystems. I will not make an accent of them. I think the most important here are memory manager. Again implemented differently than Windows NT version. And object manager, which is like a base of all kernel. It's implemented compatibly with Windows. Of course, we have runtime library, which is shared between kernel, bootloader and a few other libraries. And some other windows, modules, which are not implemented in ReactOS. So what we have about kernel compatibility? Bootloader currently in Z3 it is unable to actually load Windows by using our bootloader. So it is considered as incompatible. But some work has been done to make it more compatible and to actually try to load Windows NT4. Hardware abstraction layer, as I already said, it's really not compatible with Windows, but architecturally it's almost the same thing. And for the kernel you can see we have a few models, which are almost almost maximally done. It's 90% compatibility, which is quite good. But we lack compatibility in memory manager, in configuration manager, and for example ZC cache controller is not compatible at all. Which means we have an IFS installable file system driver right now. So that's it for the kernel, let's see bootloader. What actually does it do, this bootloader thing, and why I would want to make such an accent on it. Actually it should be quite simple. Prepare environment for the kernel and load the kernel and pass control to it. It should be quite simple. And for example we take an example as Lilo. It's known that it has four stages. It actually loads the kernel, passes control to it. Nothing actually too complex. But in case with the reactors and of course with Windows NT it's not that simple. And since we want to implement it comparatively, we want to make it do it the same way as Windows. But we don't have any documentation. This process is quite poorly documented even in Windows internal or any other series books. So freeloader is the actual bootloader which loads the reactor as kernel. Its main features are that it has a completely unique design again. It's not similar to grub, it's not similar to Microsoft NT loader, it's not similar to Lilo. But it has a portable architecture which makes it possible to make freeloader working on usual PC, X86 architecture on Xbox, on PowerPC and we plan to support other platforms too. But the aim is as always to provide the same environment to the operating system kernel which the same environment which NT loader provides so that we would be compatible. But we use a different technology here. Let's see so what's that complex in this loader. Because it should be quite simple. We load the kernel first we have to load the kernel from the disk, switch to protected mode and pass control to it. So that should be simple. However, we have a problem. We have a problem about file system support. Kernel consists of a few files. It's not just one file as a link. It's a few portable executables linked together. We have to provide a memory manager implementation. We have to do a hardware detection in the boot loader. And finally we have to support a to provide the same memory model as Windows loader tells. And also do some miss preparations like loading registry and national language support. So let's see what the boot process consists of. First of all they free loader actually into the memory and initialize its memory manager. Then we load settings from a new file and show a menu to user. This thing looks like typical loader does. Then when user selects to boot some operating system and the kernel set to Windows because free loader allows to boot Linux and other operating systems we have to distinguish this. So this is load and boot windows. This is actually the main function which provides the booting process. So the steps. First it is an opening file system where kernel resize. It gets parameters if user pass. It allocates the loader parameter block structure which is passed to the kernel and has all needed lists hardware detection results memory management mapping and everything there. Then we perform hardware detection. Then we load NTOS kernel hardware abstraction layer. Scan import distributor tables to load any reference DLLs. Compile a boot time drivers list and load them. Then we load boot drivers initialize loader parameter block structure and do this memory management thing which is the most complex in this boot loader. Because the actual kernel is quite picky about the structure of memory. Let's see this. So this is about the memory. Because Windows NT kernel memory manager is very sensitive to the memory map which is given to it by bootloader. So, by a number of experiments I compiled some requirements which Windows would need. So, it wants a memory descriptor list which maps the whole memory. Then it needs page directory entry and page table entries which describe all stuff located during the boot process and the memory actual. Then we need a special hardware structure there page table entry for special mapping like PCR and TSS. And we need to switch CPU to protect it more in page mode, of course. So, but we have to obey to some rules. Because only the first 16 megabytes can be allocated and mapped to PE. If we map more or less we will not boot. Then memory descriptor list must cover all available memory in the system. So, it's not related to the actual mapping. And the last rule is that the quantity of memory descriptors in the list must not be over 30. Otherwise kernel bar checks. I don't know why Microsoft put this limitation, but maybe it was due to historical reasons, I don't know. So, lower 2 gigabytes of virtual address space are identity and contagious and mapped as physical memory as user space. And higher 2 gigabytes are called as kernel space and mapped only actually what is really allocated there. So, we have user space is contagious and kernel space has some holes. The last thing we have to properly fill selectors so start with GDT and IDT tables then we have to set CSDS and TSS to proper values then we have to TSR, FLIR, GS and point FS to PCR. And only once we have done all this we can actually boot the kernel and it should work. So, back to ReactOS. This is how it looks like back into reality. As you see it looks like actual real windows replacement we even made an explorer replacement which has quite similar interface you see this start menu we have ABI word installed we have mirk installed which is just from the internet set up there Firefox of course works all this So, let's summarize a bit what taking a bit back step ReactOS is 100% windows replacement. It doesn't need any other special applications or drivers something like this like Linux needs because Linux is only the kernel but ReactOS is operating system As for architecture we aim to be completely compatible with windows we do not want to implement something better if it's not implemented the same already So, we have to do first reference implementation and then better but of course the end result would be that we implement something better because for example right now overall speed of ReactOS is not that fast but in some tests we made some optimization we outperform windows but that's a pretty small area right now So, what is ReactOS current status and its current roadmap ReactOS currently even despite it's already 10 years in development but it's still in alpha stage It's due to a number of reasons but early years was very complex because we had to do many things from ground up and actual people and non-developers could not notice our progress because it was so much amount of work to do before we even get a simple common prompt on the screen as soon as we could load some simple console application since it became going a lot faster because we have got some publicity and new developers joined then another milestone was when we switched to graphical user interface then we really got a lot more developers and development again started to be increasing the speed so now we we released 0.3 which is quite low on version but your releases are not that stable but they are more like proof of concept so I'm going to demonstrate actually what reactors can do well and then we will have some Q&A section let's react to its booting I already installed it so it's preinstalled right now it found a VGA display controller of Q&A but I'm not going to install threads so we have common interpreter we can now start testing yeah it looks pretty much similar to windows one so we have quite a few processes here only one application but this is application which is react to as compiled I will show you an application downloaded from from internet let's see for example this is Mirk my favorite IFC client it's exactly without any modification and of course since it's closed source it cannot be ported to any architecture but we are able to run it like on windows closed yeah that's it sorry Ion ran 2 cores of it yeah a bit slow because it's QEM it's not real hardware so in the meanwhile it works let's do a Q&A section I would be glad to answer any questions ok speaking about legal problems yeah this is pretty much sensitive topic because even if we want to do this as close to windows as possible there are laws and there are patents which we have to avoid so we analyze this situation very thoroughly and we we copy only which cannot be copyrighted or cannot be patented all patented implementations we have to avoid this because it's that's it but as for architecture as for design as for public games all this cannot be copyrighted and of course we use it at this early stage of development how can we help to perfect the operating system because I assume it's not ready for testing applications yet I didn't really understand what do you think yeah thank you for the question yes because when people see this releases they start to think that we already provide a system which is usable for everyday use and can actually be used but that's more even a proof of concept because it's not stable, it's not feature complete it may easily crash but as of now I am demonstrating it only in QM because I do not want to install it on this laptop on real hardware because it's not production stage yet but as a developer we have quite a good advantage because there are some components and testing them on our target windows for example this some control panel applets it's empty but it shouldn't be anyway some control panel applets were developed right on windows and then just when reactor started it was important some necessary shell32 functions and colorctl32 we just moved this application into reactor s3 and it works the same can be said about device drivers they can be developed on windows and then just integrated into reactor s without any modifications the only components which are quite tied together these are core components which should be developed only inside reactor s everything else can be developed outside just imported so any more questions yes Do you think that reactor s is going to be in the position that Linux is in now where it's actually in use in the corporate world and if so where I think reactor s is going to actually we have quite a wide niche in the market for the operating system of this time because there are a vast majority of win32 applications and right now on the windows and linux plus wine can run there but there are no free and open source operating system which would support win32 api the same can be said about native api of windows again as for device drivers support because as we know unfortunately not all hardware renders provide drivers for linux so it can be a problem reactor s avoids this problem too Is the current user base equal to the number of developers or other any other people using this operating system of choice Other people using it as well as the developers Actually we have quite a few people interested but of course we cannot say right now about users of operating system because this operating system cannot be used right now so it's mainly we call these people as test stars because they mainly test our results but our developers and testers number differ a lot we have only as I said only 20 active developers but as a number of people interested in reactors I can say we have about 5000 unique visitors on our website every day People are interested Yes Have you implemented the blue screen of death and how? Absolutely Have you implemented the blue screen of death Oh yes, of course When I wanted to backcheck it does not want to work So when I will demonstrate one more thing which should be interesting No blue screen It doesn't come to show So in my talk I mentioned a work on bootloader which should be compatible with windows and should be loading windows I will demonstrate one thing which I never showed yet This is anti-order I boot Free loader and then I boot windows anti-kerner by using free loader You see it's windows anti-4 quite slow but low and we have windows anti-server booter That's it There are no currently no bootloader which is able to directly boot windows anti-kerner I think this work could be used in Linux BIOS For example, to directly boot not only Linux but windows too from BIOS and maybe some other places Before you were talking about crossover office there is also wine which does the same thing and it's also open source So what's the difference between using wine and using ReactOS? Yes we share a lot of code with wine but the Linux plus wine solution would not work in long term Wine is a compatibility layer It will never be a complete replacement for operating system but ReactOS is a complete replacement so we would not have this slowness in invoiting we would not need we have a completely written from scratch piano and completely written from scratch Win32 subsystem so all this in the long run should get us faster speed and maximum possible compatibility which is always limited to some layer sometimes they have problems with applications linking directly to Intel with kernel with that and for some drivers too but also wine plus Linux solution does not solve the problem of device drivers which ReactOS does What's the status of the source code audit on ReactOS? What's the source code of state? Because you suspected some Microsoft source code in ReactOS Since we are so so close to architecturally and technically we are so close to Windows NT family that there are some suspicions suspicions some people who think that we could use illegally obtained documentation sources including the famous leaked source code but this question is answered quite simple even before this public Windows source code ReactOS already worked and already worked the same way so but because we accept patches from anyone who says his real name and wants to submit a patch which works into the tree we have to be quite suspicious about this code we decided to perform a full audit of the code so we have all real names of developers we have all documentation sources related to this code so we just do this for fusion so we should not end up in court with Microsoft we better make some actions right now to prevent this this is the last question you are aiming at 2003 kernel у вас есть как трудно к другим версиям Windows особенно для убедительных версий да по различным версиям для некоторых ReactOS Windows NT4 kernel и, в принципе, наш девайсдрайвер стекл но мы решили make a move to 2003 Windows kernel compatibility because right now it's the most advanced kernel of Windows and we do not want to actually to make any catch-up games so we're just in 2003 right now I don't think we'll change this for a few current years does that answer the question yes actually it should not be that hard because we even had a few people interested in so called ReactOS embedded project but since our kernel is not actually stable yet no serious work has been done but we really aim this embedded market because ReactOS can be used in some point of sales machines or in some others I don't know how they are called machines like ATMs or something like this which use currently which currently license Windows but they could move to ReactOS but still have their software in so we really aim to this embedded thing but right now we didn't make any force to it so we just have this source code base which can be tuned to real machine demands so thank you very much ok thank you so the next talk in here is on the Linux file