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

  • #21
    Originally posted by mrg666 View Post
    Linux+Wine is almost at the finish line in the race for replacing Windows. But I am most probably missing something. And I am sure all their effort is creating better understanding of Windows internals for Wine as well. Good luck to the project. They are tackling an immense challenge.
    you have thousands of devices that only work on windows, a very large amount of applications that require direct access to (sometimes said) hardware that wine cannot facilitate. in reality, wine only covers a single subset of desktop usage, and is nearly totally unusable for industrial use.​

    Originally posted by Daktyl198 View Post
    they're still only really targeting Windows 95/2000 compatibility which is just kinda useless.
    I missed this when I originally commented, ReactOS Longhorn has been an unofficially project for a long time, and has recently officially started working on NT6 userland stuff too which is windows 7+

    Comment


    • #22
      Originally posted by Quackdoc View Post

      you have thousands of devices that only work on windows, a very large amount of applications that require direct access to (sometimes said) hardware that wine cannot facilitate. in reality, wine only covers a single subset of desktop usage, and is nearly totally unusable for industrial use.​
      I knew I missed something, thanks!

      Comment


      • #23
        WINE is a great project, but it still misses a lot of stuff, the people saying WINE is nearly complete haven't used it for applications IMHO. WINE hasn't got support for domain features/LDAP/AD/and a bunch of other low level APIs. It's also still got problems with DirectX 5/6 Applications which still don't run in Virtual Machines due to 3D requirements which simply aren't supported by any of the Virtual machines. I tried to pass through a Voodoo 2 PCI card to a VM and it didn't work. That said, Windows has a massive library of applications including 2D image editors which Linux simply lacks. I recently was image editing in GIMP and rapidly hit the limits of what it could do. This was in the new 3.0 Alpha builds trying to work with shapes. ReactOS and WINE will always have a place on computers as long as Linux continues to have holes in its software line-up, ReactOS is a good project and I wish them luck and success at improving compatibility. I'd like to see ReactOS gain remote desktop server/client and domain controller functionality. Remote Server Admin Tools is another package I'd love to see it support.

        Comment


        • #24
          Originally posted by DMJC View Post
          WINE is a great project, but it still misses a lot of stuff, the people saying WINE is nearly complete haven't used it for applications IMHO. WINE hasn't got support for domain features/LDAP/AD/and a bunch of other low level APIs. It's also still got problems with DirectX 5/6 Applications which still don't run in Virtual Machines due to 3D requirements which simply aren't supported by any of the Virtual machines. I tried to pass through a Voodoo 2 PCI card to a VM and it didn't work. That said, Windows has a massive library of applications including 2D image editors which Linux simply lacks. I recently was image editing in GIMP and rapidly hit the limits of what it could do. This was in the new 3.0 Alpha builds trying to work with shapes. ReactOS and WINE will always have a place on computers as long as Linux continues to have holes in its software line-up, ReactOS is a good project and I wish them luck and success at improving compatibility. I'd like to see ReactOS gain remote desktop server/client and domain controller functionality. Remote Server Admin Tools is another package I'd love to see it support.
          qemu 3dfx + wined3d or the softgpu can help a lot for the old dx applications. vmware's compatibility modes can help loads too.

          Comment


          • #25
            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.

            Comment


            • #26
              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.

              Comment


              • #27
                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.

                Comment


                • #28
                  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.

                  Comment


                  • #29
                    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.

                    Comment


                    • #30
                      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).

                      Comment

                      Working...
                      X