What is the ultimate goal of react os?
Moderator: Moderator Team
-
- Posts: 1
- Joined: Mon Aug 13, 2018 2:23 pm
What is the ultimate goal of react os?
hii,
I just found out about this yesterday and looked in to it. I've seen it described as a clone attempt for windows 2003, and also just windows in general. I'm not sure which it is, are they going to stop if they get 2003 compatibility or are they aiming for say windows 10 compatibility?
I just found out about this yesterday and looked in to it. I've seen it described as a clone attempt for windows 2003, and also just windows in general. I'm not sure which it is, are they going to stop if they get 2003 compatibility or are they aiming for say windows 10 compatibility?
Re: What is the ultimate goal of react os?
The immediate goal, which likely means in a few years, seems to be a stable single core 32 bit Windows NT circa 2003 compatible operating system with a maximum addressable real memory of 4 GB. Note in 2003 Windows had 64 bit and multi core capability. So the goal is mostly to be stable 32 bit on a single core as a subset of Windows circa 2003. Which if it didn't take so long, would be great. I wish some donor would help these guys, they need more developers imo.
Re: What is the ultimate goal of react os?
I'm trying to help Ancient
ReactOS Donator ~ $5.00 | Linux Mint Donator ~ $1.00 in BTC
Re: What is the ultimate goal of react os?
You can always use internet and type in "what is reactos?"
It would have shown you this:
https://reactos.org/wiki/ReactOS
It would have shown you this:
https://reactos.org/wiki/ReactOS
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: What is the ultimate goal of react os?
Kudos to you. I'm an old long retired operating system developer. Worked on VM/67 and VM/370 and some other operating systems. Thus my handle Ancient. All 370 instruction set, 370 was 24 bit, 67 was 32 bit. I haven't worked in x86 assembler language, but am familiar with C. Unfortunately my retirement efforts are directed elsewhere, and it would take time to come up to speed on both X86 and NT internals.
These guys do need help, maybe a gofundme. Their problem is the goal sought isn't being closed in on fast enough and eventually their software will become meaningless. Sort of like many older operating systems. Going to multi core is better understood than it used to be, but race conditions, flags and what not, particularly with parallel IO, shadow prefetch and partial speculative execution with multiple cache layers require someone familiar with assuring all cache and I/O are properly synchronized where flags are required. As this must be very scalable in light of 32 and 64 core CPU's today or in our near future, it's going to be tough to go multi core unless the software was fully reentrant to begin with.
Personally I think this is solved by Linux, and would attempt to use a Linux kernel to drive the NT kernel more directly than is done with a Windows emulator. It seems a modified Linux Kernel could be used with Windows API extensions built in. Saving the need for a lot of the address, I/O and multi core issues. It would be easier if using a Linux Kernel to just use supported Linux file systems. Really the Windows shell and API's are most important. If the API's that need to get hooks directly into a Linux Kernel, maybe it would be easier to implement a functional Windows 32 and 64 system without worrying about address space, page table management, even interrupt management.
A list of NT kernel API interfaces if established could be easier to add to a Linux kernel than writing one from scratch.
However, these guys are very far along a long path, and it isn't likely the time to stop and redirect. They took a good path, many years ago, unfortunately times have changed a bit.
-
- Posts: 215
- Joined: Wed Feb 21, 2018 3:46 pm
- Location: Somewhere in France
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: What is the ultimate goal of react os?
We are not using a "Windows emulator." We are writing a kernel that interacts with drivers like Windows. How it works on the inside will be different. Now, we do use emulators in testing since that provides a consistent testing interface, and we could run a virtual machine in Linux to emulate a real machine to install. But that is only for testing. We will have a Windows-compatible kernel that uses real Windows drivers of that version. There won't be any emulation or layers, just natively running the drivers essentially the way Windows does.
A common mistake newcomers make is to assume that because we use parts of Wine that we must have some sort of Linux underneath. No, it is our own kernel that tries to behave the same as the Windows kernel. That is why we only use part of Wine. We use only the parts of Wine that could be theoretically used in Windows without modifying Windows or adding any sort of extensions. The "lower" part of Wine maps to Linux/Posix calls whereas we make direct NT calls. The parts that map Wine to Linux (instead of to NT) are of no use to us.
As for multi-core, well XP supported multi-core. As for software, if individual programs don't support it, the scheduler just assigns each a core and the entire program uses that one core. But you still have advantages from multi-core since a CPU-intensive, single core application won't impact the other things running (as much) or try to compete with the kernel. Let's say you try to do file-sharing, convert many or gigantic archive files, browse the web, and listen to music all at once. On a single-core system, you won't be able to do all that. At the least, the playlist would skip and the browser wouldn't be too responsive. But with 2 cores, the .mp3s would be more likely to play seamlessly, and the browser should be more responsive, even if all the programs involved are single-core. In that case, 1-2 programs would use one core, and 2-3 would use the other one.
A common mistake newcomers make is to assume that because we use parts of Wine that we must have some sort of Linux underneath. No, it is our own kernel that tries to behave the same as the Windows kernel. That is why we only use part of Wine. We use only the parts of Wine that could be theoretically used in Windows without modifying Windows or adding any sort of extensions. The "lower" part of Wine maps to Linux/Posix calls whereas we make direct NT calls. The parts that map Wine to Linux (instead of to NT) are of no use to us.
As for multi-core, well XP supported multi-core. As for software, if individual programs don't support it, the scheduler just assigns each a core and the entire program uses that one core. But you still have advantages from multi-core since a CPU-intensive, single core application won't impact the other things running (as much) or try to compete with the kernel. Let's say you try to do file-sharing, convert many or gigantic archive files, browse the web, and listen to music all at once. On a single-core system, you won't be able to do all that. At the least, the playlist would skip and the browser wouldn't be too responsive. But with 2 cores, the .mp3s would be more likely to play seamlessly, and the browser should be more responsive, even if all the programs involved are single-core. In that case, 1-2 programs would use one core, and 2-3 would use the other one.
Re: What is the ultimate goal of react os?
Use Linux drivers, they're already done.shunesburg wrote: ↑Tue Aug 14, 2018 9:49 amNo it's not possible. Not because it's impossible, but because the goal is the compatibility with the applications and drivers of "Windows".
Re: What is the ultimate goal of react os?
Gawd blimey - the uneducated masses - gawd bless 'em.
Skillset: VMS,DOS,Windows Sysadmin from 1985, fault-tolerance, VaxCluster, Alpha,Sparc. DCL,QB,VBDOS- VB6,.NET, PHP,NODE.JS, Graphic Design, Project Manager, CMS, Quad Electronics. classic cars & m'bikes. Artist in water & oils. Historian.
Re: What is the ultimate goal of react os?
what a painfully nonsensical thread.
Re: What is the ultimate goal of react os?
It's been done before... and nobody cared enough about it for it to take off. I forget the exact name of the system that did it... but they were doing syscall emulation of Windows on Linux.Ancient wrote: ↑Tue Aug 14, 2018 2:48 pmUse Linux drivers, they're already done.shunesburg wrote: ↑Tue Aug 14, 2018 9:49 amNo it's not possible. Not because it's impossible, but because the goal is the compatibility with the applications and drivers of "Windows".
Also to the guy above.. having 1k posts you ought to realise that if you were nicer to people we'd probably have more people developing on ReactOS than we do now. Same problem over at Haiku people need be nice.
-
- Posts: 531
- Joined: Thu Jan 10, 2013 6:17 pm
- Contact:
Re: What is the ultimate goal of react os?
Are you talking about Longene? https://en.wikipedia.org/wiki/Longene
There was also coLinux, but it was more like two VMs paravirtualized and running next to each other...
Re: What is the ultimate goal of react os?
LOLAlso to the guy above.. having 1k posts you ought to realise that if you were nicer to people we'd probably have more people developing on ReactOS than we do now. Same problem over at Haiku people need be nice.
Real programmers (what matters for ReactOS) code, they don't care about emotions.
-
- Posts: 1790
- Joined: Fri Aug 07, 2009 5:11 am
- Location: USA
Re: What is the ultimate goal of react os?
Concerning the opening question, there is no straightforward answer. The goal right now is just XP/2003 compatibility, as much as possible. Beyond that, it's hard to speculate, and it is best to wait until we get there. I'd love for there to be a point where they could mostly freeze the 2003 compatible version (except for occasional fixes) and start a new compatibility line (like Vista/7 or something).
I had been pondering, taking the above further, why not a version that could run on a wide variety architectures and use a wide range of drivers. Now, I don't mean some sort of kludgy workaround such as some bulky driver layer to make up for using the wrong drivers for whatever kernel version. But why not let the installer install whatever kernel that's the most compatible with the architecture detected (and whatever other necessary code) and report that version. Then for the software side, do the forward compatible shims like now, etc.
I had been pondering, taking the above further, why not a version that could run on a wide variety architectures and use a wide range of drivers. Now, I don't mean some sort of kludgy workaround such as some bulky driver layer to make up for using the wrong drivers for whatever kernel version. But why not let the installer install whatever kernel that's the most compatible with the architecture detected (and whatever other necessary code) and report that version. Then for the software side, do the forward compatible shims like now, etc.
Re: What is the ultimate goal of react os?
Yes! I couldn't remember what it was called for the life of me and google wasn't helping.karlexceed wrote: ↑Tue Aug 14, 2018 6:06 pmAre you talking about Longene? https://en.wikipedia.org/wiki/Longene
There was also coLinux, but it was more like two VMs paravirtualized and running next to each other...
Who is online
Users browsing this forum: Yandex [Bot] and 48 guests