Announcement

Collapse
No announcement yet.

Haiku Had A Very Busy March Improving Hardware Support & More

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

  • #31
    Originally posted by tuxd3v View Post
    I would love to see a very good support for ARM.
    I think for them x86 should be optional, since they don't have the man power to support both arch's correctly.
    x86 can't be optional, at least for R1 -- R1 is meant to be a drop-in replacement for BeOS 5.0, and be binary compatible with it. Not supporting x86 would be... outright abandoning that. R2, though, R2 isn't going to be compatible, so who knows there.

    Originally posted by Nozo View Post
    Haiku isn't in a much better position, over 20 years in development and yet to release a stable version, and as it's apparently a single user OS it won't stand a chance in the enterprise or professional market, multi-user capabilities are the core of business administration, And considering the state of community-driven operating systems, Linux distros remains the most successful within that niche.
    That's not Haiku's goal. Haiku has only ever been a personal OS for home users focusing on multimedia and the like. As someone that daily-drove R1/b2 back in 2020-21 on a Pentium M 1.6GHz, it's an excellent experience that I think has its niche in extending the life of older computers. Puppy Linux was too heavy for the specs I had (1.25GB RAM, 40GB hard drive, PM 1.6GHz) and Windows XP is... Windows XP. Haiku felt snappy even in general, almost RISC workstation-like, but got a boost by overclocking my panel to 85Hz, leading to an experience like no other for light home use.

    Comment


    • #32
      Originally posted by Volta View Post

      You're hopeless and your broken windows. Linux actually succeeded, but you have to be something more than amoeba to understand this. Haiku on the other hand is nothing more than a toy.
      Linux desktop's market share is below 1% (and includes BSD's), "broken" Windows market share is what? 80-90%?

      Let them have their "toy", its enriching FOSS ecosystem. Its childish to be butthurt about it and revert to demagogic lies and false propaganda each time you think your "favorite toy" doesnt get attention "you think it deserves"..
      Last edited by aht0; 20 July 2022, 07:11 AM.

      Comment


      • #33
        Originally posted by Waethorn View Post

        They DID NOT run "in DOS", "on DOS", "depend on DOS" or anything of the like. This is a complete misconception of the OS and CPU architecture. It is a command prompt environment with similar commands - nothing more. It would be more analogous to compare it to Plan 9 vs Linux. Completely different operating systems, where Plan 9 has a GUI baked in that is optional to use, and any shell on top of Linux can be completely stripped out. Plan 9 originally ran on hardware that isn't compatible with x86.
        Well, lemme satisfy your nitpicking then: customized version of MS-DOS acted as a boot-loader for Windows 95. DOS processed CONFIG.SYS, launched COMMAND.COM - which in turn ran AUTOEXEC.BAT, in turn running WIN.COM (VMM running 32-bit virtual machine manager). Magic inside WIN.COM ended up turning off EMM386 and switched into protected mode we think of as "real windows". At that point MS-DOS was shut-off. That's very simplistic description of what happened but as you can see existence of MS-DOS was required for Windows 95 boot process. In that sense it did "depend on DOS".

        Comment


        • #34
          Originally posted by aht0 View Post

          Well, lemme satisfy your nitpicking then: customized version of MS-DOS acted as a boot-loader for Windows 95. DOS processed CONFIG.SYS, launched COMMAND.COM - which in turn ran AUTOEXEC.BAT, in turn running WIN.COM (VMM running 32-bit virtual machine manager). Magic inside WIN.COM ended up turning off EMM386 and switched into protected mode we think of as "real windows". At that point MS-DOS was shut-off. That's very simplistic description of what happened but as you can see existence of MS-DOS was required for Windows 95 boot process. In that sense it did "depend on DOS".
          Your understanding of the fundamentals is completely wrong.

          Comment


          • #35
            https://devblogs.microsoft.com/oldne...24-00/?p=24063
            now stfu

            Comment


            • #36
              He's wrong and he started Microsoft well after Windows 9x was discontinued. The Windows 9x developers already debated this. What he writes is truthiness, and he even states a disclaimer in his article.

              Also, he worked for the CCP army, so take what he has to say with a grain of salt.

              Comment


              • #37
                Originally posted by Waethorn View Post

                He's wrong and he started Microsoft well after Windows 9x was discontinued. The Windows 9x developers already debated this. What he writes is truthiness, and he even states a disclaimer in his article.

                Also, he worked for the CCP army, so take what he has to say with a grain of salt.
                Isn't the only source describing things this way..
                https://www.quora.com/What-was-the-r...-in-Windows-95
                MS-DOS, in effect, was used as a bootloader to provide an environment to get the Windows 95 executables loaded, as described above, but played no role in the operation of the system at all once Windows was running.
                https://www.betaarchive.com/forum/viewtopic.php?t=30383
                Windows 95 not only required DOS to operate (there were still multitudes of DOS interrupts used in the system), but it was also a backward compatibility thing, something MS had a hard on for. If you remember using Windows 3 in its day, half of the applications/games were still DOS. They wouldn't want to flat out cut off that compatibility for the people moving/upgrading to Windows 95. Even hardware drivers ran from DOS mode (looking at you Sound Blaster Live SB16 compatibility driver and MPEG hardware decoder cards)
                https://news.ycombinator.com/item?id=13260688
                Much has been written on the system call interface in NT (INT 2E, later SYSENTER), but there is surprisingly little documented about the 9x system call interface. So I disassembled its kernel32.dll and looked at where the function calls went... they all eventually end up at a far call: "call far [BFFC9734]" with EAX containing what looks like the syscall number, arranged by major/minor code --- and some of the numbers look suspiciously like the same as for the original DOS INT21 services.

                Comment


                • #38
                  Don't mistake backwards compatibility with the dependence of a completely different OS - they are NOT the same thing. MS-DOS has no configuration manager for Plug-and-Play, yet this is part of the boot environment for Windows 9x well before the GUI launches. There is nothing in Windows 9x that mandates that backwards compatibility is required aside from legacy hardware or software support. Such is the case with Windows Me where sole access to the command prompt ("Restart in MS-DOS Mode" in former versions) and at boot time is removed.

                  Comment


                  • #39
                    You are correct when it comes to later versions of Windows but 95/98 did really depend on existence of DOS to get going.

                    Comment

                    Working...
                    X