Re: System utilities on ROS
Posted: Wed Jul 09, 2014 10:18 am
Why should we??!zydon wrote:ps - ROS project should be redefined not as Binary compatible, but as a Core and it's Environment compatible to the NT OS.
Why should we??!zydon wrote:ps - ROS project should be redefined not as Binary compatible, but as a Core and it's Environment compatible to the NT OS.
Wow. Making such a big wish shows your enormous confidence in ReactOS's eventual success, zydon.zydon wrote:ps - ROS project should be redefined not as Binary compatible, but as a Core and its Environment compatible to the NT OS.
Perhaps. Or he thinks you ReactOS devs are supermen, gods of programming!erkinalp wrote:He most probably forgets that ReactOS is developed by thousandth of man-time of MS Windows division and wants more than API/ABI/UX of Windows.
Because what has been produced so far, was more than what was claimed as a binary and driver compatible.EmuandCo wrote:Why should we??!zydon wrote:ps - ROS project should be redefined not as Binary compatible, but as a Core and it's Environment compatible to the NT OS.
Uuuh, nope. We don't aim for APP compatibility, but driver support, too. Your idea will make that impossible. We need low level compatibility with Windows and that's what we try to get. And nope, you cant fully copyright a UI, especially basic elements like a start menu or windows for apps.zydon wrote:Because what has been produced so far, was more than what was claimed as a binary and driver compatible.
ROS should have it's own UI and it's own API architecture. Not a copies of MS Windows system binaries which is exchangeable between ROS and Windows. What should be happened when ROS run Win32 apps is it interpret those Win32 API calls and use it's own API engine to get the job done. The different is ROS should have an API Interpreter take charge when running Windows Application.
Those MS DLL alike files just a bunch of API interpreter script (or ROS owned API translator opcode) and just doesn't work under Windows system.
While the UI should be a different resulted a careful research and development that how ROS UI should be to match the idea of naming it ReactOS. ReactOS should have ReactUI. Not MS Windows UI. Isn't that MS Windows UI is copyrighted?
I guest, I don't have to say more why I suggest it should be redefined...
Yes, it is more. Mainly because the mission statement explicitly says more is expected: it is not just API/ABI compatible, but retains the Windows look and feel.zydon wrote: Because what has been produced so far, was more than what was claimed as a binary and driver compatible.
Then why not *insert your favorite kernel and userland* + WINE? The mission statement is quite clear: ReactOS is here to fill a niche, as every software is. ReactOS' niche is that of a free implementation of a Windows NT OS. This means applications should be able to run unmodified, natively, at the very least, and the possibility full, unnoticeable (except for trademarks), constant learning curve migration from a Microsoft Windows OS. If you change the goal to just being able to run Windows programs, then your niche is already full: WINE currently does a better job at that, and Linux currently does a better job at being stable enough to use WINE on top of it.ROS should have it's own UI and it's own API architecture. Not a copies of MS Windows system binaries which is exchangeable between ROS and Windows. What should be happened when ROS run Win32 apps is it interpret those Win32 API calls and use it's own API engine to get the job done. The different is ROS should have an API Interpreter take charge when running Windows Application.
The desktop metaphor can't be copyrighted, AFAIK. And again, if you go too flexible, you go where the niche is full, and that kinda dooms the project to oblivion, as there are currently working solutions that people will look under a better light than ReactOS.While the UI should be a different resulted a careful research and development that how ROS UI should be to match the idea of naming it ReactOS. ReactOS should have ReactUI. Not MS Windows UI. Isn't that MS Windows UI is copyrighted?
That could be a source of conflict, though, as one advantage of ReactOS could be for developers to avoid paying a Windows license. Picture this situation: I develop mainly on Linux, but I try to keep my apps cross-platform. This means I need to test on Windows, or something close enough. My application works in ReactOS. Although it is not a 100% guarantee that it will work on Windows, I can be sure that if it does work in one but not in the other, it's either ReactOS' or Microsoft's fault. However, if ReactOS has its own extensions, then just testing on ReactOS won't cut it: I might have accidentally assumed some ReactOS specific feature is actually a Windows feature, and I made use of it. I'll state my app runs on Windows based on the fact it worked marvelously on ReactOS, just to find my inbox full of hatemail the next day.erkinalp wrote:However, it is possible to do whatever GNU did:Windows API/ABI+ReactOS specific extensions. You have to be sure you have not subtracting anything from Windows API otherwise binaries designed for Windows will fail.
That doesn't exist, and it never will.alexei wrote: I don't want "security updates", I want secure and stable system that does not need them.
Actually, it isn't. Aside from small parts, there is no unmodified BSD pieces in OSX. The kernel, contrary to what the BSDs use, is a microkernel based in the Mach architecture. It does run some subsystems based on those of the BSD kernel. Then, most of the big pieces of userspace (init system, display server) are in-house creations. The init system was open sourced just a few months ago, and even though some users like it and are porting it, there is no BSD distribution that I know of that plans to make it the official choice. What they DO have in common that is important is that they prefer the BSD license and other liberal licenses when it comes to pieces they want to open source, as opposed to GPL and other copyleft licenses.karlexceed wrote:OSX is a copy of BSD with it's own executables running on top
It is impossible to have zero learning curve transistion between two different (albeit similar) things. However, extra features will get the same documentation as regular ones(meaning they will be documented in detail) so the learning curve will remain almost straight and be very short. Ones having a hard time would seek for ReactOS Product Keymrugiero wrote:For the rest of the post, although I do like the idea, I think that belongs to the distributions. "Official" ReactOS should, IMO, be minimal and be closely compatible in all of usability. Added features, ... a learning curve they do not want, and customizability means variability they don't want, as it's easier to troubleshoot a strict setup, and it's easier to do that the default and then let the distributors who want something different to add the extra features than to expect the other one to remove them.