Announcement

Collapse
No announcement yet.

ReactOS "Open-Source Windows" Making Good Strides On SMP CPU Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Developer12
    replied
    Originally posted by Daktyl198 View Post
    Wine is purely userspace, and is designed to work with a linux core. That includes things like systemd, and other linux alternatives to Windows processes. There are hundreds if not thousands of Windows OS components that live below userspace, but not in kernel space, that Windows applications rely on just like Linux. My idea was to have the Linux Kernel, with maybe an out-of-tree patchset that implements Windows kernel APIs using existing Linux codepaths as best you can, then re-make all of the "OS layer" tools as well. Wine libraries can be used for userspace, just like ReactOS is doing it, but not Wine itself. Otherwise, there'd be no reason for ReactOS.
    Do you have any idea how wine even works? Wine already emulates everything from the application down to and including the kernel itself, the entire windows stack, in userspace. It's not hard. Windows applications never invoke the kernel directly but instead use a DLL that wine provides a replacement for.

    Nothing you have suggested will ever allow you to run windows drivers, a core advantage of reactos. The linux kernel has a very, very strong policy of NEVER EVER exposing a stable driver interface, rendering the loading of windows drivers categorically disallowed. This is still true even if someone was willing to put in the legwork to implement the windows driver interface.

    Originally posted by Daktyl198 View Post
    And "jumping" to Windows 10 is not stupid. The most popular apps on the platform do not utilize older APIs, or at the very least do not utilize APIs as old as what ReactOS is targeting. If they did, then newer applications would still work on Windows XP (and ReactOS). While implementing older APIs would be necessary for 100% compatibility, most actively updated apps use modern APIs introduced to Windows in the Windows 8/8.1 era for interacting with the OS, with the exception of a few key Win32 APIs that are more performant than their modern counterparts.
    What you have totally, utterly failed to comprehend is that THEY'RE THE SAME APIs. Microsoft often hasn't completely replaced APIs, merely extended them. That's what they do. They rarely introduce new APIs and instead massage existing ones by adding new arguments and additional calls that operate on the same objects. That means you have zero choice but to implement the whole API every time. You can't get away with "just implementing the latest ones" because 90% of the APIs currently in use started life in win2000.

    Originally posted by Daktyl198 View Post
    As for Window's "fanatical" backwards compatibility, it's just not true. The vast majority of Windows XP software will not work on Windows 10 without tweaks, even with it's "compatibility tools". Even Windows 7 applications don't work most of the time. Microsoft implements the minimum compatibility that is necessary for some enterprise customers, and that's it. Hell, they've been publicly trying to kill the Win32 API in Windows since Windows 8.
    700 pages of blog posts on dumb shit microsoft has done to preserve backwards compatibility disagree.


    Did you know that every time you start an application, windows checks if it's adobe acrobat 2013? If it is, it inserts a shim that lies about the color of the text in the title bar and says it's white, even when it isn't. Otherwise, every page in the PDFs you open will be black.
    Last edited by Developer12; 13 May 2024, 07:08 PM.

    Leave a comment:


  • Ironmask
    replied
    Originally posted by jindam View Post
    i am wondering, whether project is receiving funds from US corporations
    It's kind of a hard pitch. "Hey boss, check this OS out, after two decades of development it only crashes most of the time instead of immediately at boot!"
    It's much cheaper and more sane to just port old systems to modern platforms, since if your infrastructure is based on Windows XP, it's probably modern enough to be ported. Or better yet, just rewrite it all since if your infrastructure is 20 years old it's either probably isolated enough to be a timeless black box, or already the victim of an attack due to security vulnerabilities.
    If I were running a company and I looked at my aging infrastructure and my dwindling venture capitalist funds, I would rather just port it or emulate it, but definitely not pour it into what only appears to be some esoteric bottomless pit of a hobby project. The other big tech companies don't need it, because: Google has Linux, Meta has Linux, Microsoft is Microsoft, Apple has macOS, Oracle has Linux. And the US government doesn't need it because they just pay Microsoft to keep supporting Windows XP anyway.
    It would help if ReactOS has a Red Hat of it's own to be it's business and support, that's how Linux became usable in the business world. But it doesn't have that. And one of the biggest reasons companies use software is for it's support. Windows XP may be out of support, but it's not like ReactOS simply existing while it also has no support makes it any more attractive.

    Leave a comment:


  • Quackdoc
    replied
    Originally posted by jindam View Post
    i am wondering, whether project is receiving funds from US corporations
    they should be, considering how many people are still relying on windows xp era stuff, a drop in replacement should be highly desirable

    Leave a comment:


  • jindam
    replied
    i am wondering, whether project is receiving funds from US corporations

    Leave a comment:


  • Ironmask
    replied
    Originally posted by ayumu View Post
    They don't. It is very possible to have bugs in code that's written in rust. It's a little harder, is all.

    A much better way to prevent mistakes is formal methods. Sure, these do not scale; It is really hard to develop with formal methods. But that's where compartmentalization helps.

    seL4 is one such microkernel. It is simple and small, it is fast, and it does its job isolating processes and providing guarantees, even in the time domain.

    seL4 takes care of the really hard work. A good system can be developed much more by leveraging the unbreakable guarantees seL4 offers.

    A bigger kernel, even if written in a somewhat better language like rust, will not be able to provide these guarantees.
    I didn't mean to imply Rust completely prevents mistakes, I'm not sure if that's philosophically possible to make a language that prevents mistakes. I'm not even sure if one can definitively quantify all possible "mistakes" and what does not constitute as a "mistake".
    But what I did mean is essentially what you said, compartmentalization. Languages that prevent as many mistakes as possible makes it much easier to spot the remaining mistakes that do manifest, and make it easier to prevent them in the future by having less to remember.
    Security through policy, as we have seen thousands of times now, does not work if those policy systems have flaws, and they seem to always have flaws. Buffer overruns, arbitrary code, remote access, misconfiguration, mistakes we know about but a lot of languages virtually encourage (including Java if you remember Log4Shell, which is why I'm slightly against JITs that let you have access to their APIs from within the language now).
    I feel more like policy systems and self-recovering systems are, as I mentioned, an extra layer of security over having a traditionally secure base. It can be good for computers that cannot be repaired, but for us consumers, we should have more sophisticated solutions to computer faults (backups, spare parts, secure networking, the good old reset button).

    Leave a comment:


  • DMJC
    replied
    Originally posted by Quackdoc View Post

    qemu 3dfx + wined3d or the softgpu can help a lot for the old dx applications. vmware's compatibility modes can help loads too.
    You are an absolute legend! Thanks, I've been wanting something like this for years.

    Leave a comment:


  • Daktyl198
    replied
    Originally posted by NotMine999 View Post

    The most logical way to tackle a big problem like Windows compatibility is to break it down into a series of much smaller problems. In other words, start at some much older and quite well known (in terms of public domain knowledge of features, bugs, workarounds, etc.) Windows release then work forward, much like the way Windows evolved. Going right to the top, or next to the top simply makes the problem gi-normous and scares many developers away.

    Cuz if you think Windows 10 or 11 were complete re-writes, I got a few uncollapsed bridges to sell ya CHEEP.
    Windows 10/11 are a ship of Theseus. It was never a complete rewrite, but by the time you get to them, pretty much everything prior to vista is gone minus just a few Win32 APIs.

    Leave a comment:


  • ayumu
    replied
    Originally posted by Ironmask View Post
    Good languages prevent mistakes altogether
    They don't. It is very possible to have bugs in code that's written in rust. It's a little harder, is all.

    A much better way to prevent mistakes is formal methods. Sure, these do not scale; It is really hard to develop with formal methods. But that's where compartmentalization helps.

    seL4 is one such microkernel. It is simple and small, it is fast, and it does its job isolating processes and providing guarantees, even in the time domain.

    seL4 takes care of the really hard work. A good system can be developed much more by leveraging the unbreakable guarantees seL4 offers.

    A bigger kernel, even if written in a somewhat better language like rust, will not be able to provide these guarantees.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by cl333r View Post

    I think they both need to get morphologically more modular. Rewrite them in Rust, put them down in a Node.js container and smash them hard with a big rock.
    You forgot to run them over a few times with a court room full of open source license patent lawyers ... for good measure.

    Leave a comment:


  • NotMine999
    replied
    Originally posted by Daktyl198 View Post
    I love seeing ReactOS make progress. I wish them nothing but luck, as it would be extremely beneficial to have an open source Windows compatible OS. That being said, even with the progress they've made, they're still only really targeting Windows 95/2000 compatibility which is just kinda useless.

    I wonder if somebody will start a new project targeting Windows 10 compatibility. It might pop off, with it's upcoming demise and all that. I wonder how hard it would be to use the Linux kernel, but write an ecosystem on top of it that provides Windows compatibility?
    The most logical way to tackle a big problem like Windows compatibility is to break it down into a series of much smaller problems. In other words, start at some much older and quite well known (in terms of public domain knowledge of features, bugs, workarounds, etc.) Windows release then work forward, much like the way Windows evolved. Going right to the top, or next to the top simply makes the problem gi-normous and scares many developers away.

    Cuz if you think Windows 10 or 11 were complete re-writes, I got a few uncollapsed bridges to sell ya CHEEP.

    Leave a comment:

Working...
X