Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Emulation (Games) Open Source Upgrades Windows

ReactOS 0.4 Brings Open Source Windows Closer To Reality (techrepublic.com) 141

Posted by timothy from the almost-beta-level dept.
jeditobe was one of several readers to point out the newest major release of Windows NT-inspired ReactOS, which has just hit version 0.4, brings open source Windows compatibility a little bit closer. The new release includes out-of-the-box support for ext2, ext3, and ext4, as well as (remember, it is NT based) read-only support for NTFS. What else? Support was generally improved for third-party device drivers, making it substantially easier to install and use real hardware, as opposed to just virtual machines like VirtualBox. The internal WINE library was updated to improve support for Win32 programs. Support for Python 2.7 was added, making it possible to use python scripts in ReactOS. A substantial number of visual changes were added, with a vastly improved shell and file explorer, newer icons throughout ReactOS, improved support for fonts, and customizable visual themes. Even with these improvements, ReactOS 0.4 is still generally considered alpha-level software, though Alexander Rechitskiy, the innovation manager for ReactOS, notes that 0.4.1 may be almost beta-level software.
This discussion has been archived. No new comments can be posted.

ReactOS 0.4 Brings Open Source Windows Closer To Reality More

ReactOS 0.4 Brings Open Source Windows Closer To Reality

Comments Filter:
  • version 2008 is OK for me.

  • A nice step forward. (Score:5, Funny)

    by Anonymous Coward on Wednesday February 17, 2016 @09:35AM (#51527103)

    This version contains improved compatibility for most major rootkits and boot sector viruses, as well as emulation for most security vulerabilities all the way through NT4.0 SP2.

  • Great work (Score:5, Insightful)

    by LichtSpektren ( 4201985 ) on Wednesday February 17, 2016 @09:37AM (#51527121)
    I'm glad to see progress on ReactOS. Good job!

    • Re: (Score:1)

      by Anonymous Coward

      "Great work"? Huh? Let's be real about this, they haven't done much at all. This project goes back almost 20 years, and it still only has read-only support for NTFS, despite that being its native filesystem! Much of the UI is just WINE, which is a separate project mainly created by other developers! "Great work" is not how to describe this project. At best, it's some people pulling together the work of numerous other open source projects as a hobby.

      • The read-only support for NTFS is due to patent issues. It's the same reason NTFS-formatted hard disks sold for use with Macs include an NTFS driver; the Mac can read the disk just fine, but requires the driver to write to it due to patent issues for which Apple does not with to pay licensing (and rightly so).

        • >>> The read-only support for NTFS is due to patent issues. >>>

          I can write to NTFS from Ubuntu using Midnight Commander.

          • I can write to NTFS in Ubuntu from any application running on the system, just like any other mounted disk. Ubuntu, however, does not ship with this ability out of the box; you have to enable 3rd-party sources in order to download the patent-encumbered libraries to enable it. I suggest reading me entire comment and not just the part you quoted; I never said it was impossible and, in fact, gave a popular example of how it is often worked around.

        • The read-only support for NTFS is due to patent issues. It's the same reason NTFS-formatted hard disks sold for use with Macs include an NTFS driver; the Mac can read the disk just fine, but requires the driver to write to it due to patent issues for which Apple does not with to pay licensing (and rightly so).

          Why not extend NTFS to a 64-bit file system that is backward compatible w/ Microsoft's NTFS - THAT wouldn't be patent protected. So the OS could write files which could then be transparently read by anything from Windows 7-10.

          • Re: (Score:2)

            by Curate ( 783077 )

            Why not extend NTFS to a 64-bit file system that is backward compatible w/ Microsoft's NTFS

            Could you explain what you mean by 64-bit file system, specifically? Because what you said doesn't really mean anything without more context. And are you implying that NTFS-3g is not 64-bit (whatever that means) while Microsoft's NTFS is?

        • This isn't a global problem, since only some countries recognize software patents (one reason I don't want treaty-based harmonization). I'd expect F/OSS developers in software-patent-free countries to read and write NTFS freely.

    • Re:Great work (Score:5, Informative)

      by NJRoadfan ( 1254248 ) on Wednesday February 17, 2016 @10:19AM (#51527409)
      Hopefully this release will actually boot on real hardware. The last 0.3 release wouldn't even boot on circa 2007 Core2Duo hardware! This isn't cutting edge stuff as far as drivers are concerned.
      • Wouldn't boot on my hardware either. Disappoint
      • If your system had SATA drives, it wouldn't. That support is now included in this version.
        • The problem wasn't storage related.. ReactOS 0.3.17 uses the UniATA [alter.org.ua] driver, which I confirmed working with my hardware under various versions of Windows NT. Both machines tested were in legacy mode, not AHCI. The setup program ran on one machine after I artificially limited the RAM to 256MB (Dell BIOS had the setting). After it completed the first stage install and rebooted...... nothing, just the initial boot loader ran and likely froze when the machine switched to protected mode. I'll give this latest rel
  • Remember it is NT "based"? This is supposed to be a clean room OS, supporting the API calls to Windows and comparing what happens when code makes calls to Windows APIs, isn't it. They say it has a WINE implementation, but they don't call it "WINE-based". And what's the point of including a variation of Python 1.7? How hard it is to uninstall? And why only a read-only NTFS implementation?
    • It is a clean room OS, focused on supporting NT APIs. As for Python, we'll read on. Seems like CMD.exe is not implemented yet and is not a prime concern.

      And, NTFS is really tricky to write to. Linux and BSD still don't have (and possibly won't ever have) a writable kernel implementation. "NTFS3G" driver is user-space.

      • Re: (Score:1)

        by Anonymous Coward

        What are you talking about? CMD.EXE has been implemented for ages in ReactOS-- Since at least the 2.x days.

        What is probably missing is CSCRIPT.EXE and WSCRIPT.EXE

        Vastly different ponies those ones.

      • Why not take this opportunity to improve?

        A Windows API compatible OS on top of a ZFS root? Sign me up.

      • And, NTFS is really tricky to write to. Linux and BSD still don't have (and possibly won't ever have) a writable kernel implementation. "NTFS3G" driver is user-space.

        Linux has had a read-write NTFS driver for a few years now; I think since shortly before 3.x. The user-space driver is no longer the recommended driver.

    • Re:Confusing summary is confusing (Score:5, Informative)

      by Anonymous Coward on Wednesday February 17, 2016 @09:57AM (#51527257)

      ReactOS reimplements the NT flavor Installable File System (IFS) driver model. This model is very.... complicated. There is a reason why read-write EXT mounting is not a thing on windows systems, despite there being vastly more developers working on that filesystem.

      ReactOS SHARES code with WINE. Patches move both directions through both codebases. As such, the libraries used by ReactOS *ARE* WINE libraries. It is not based on WINE, it literally *IS* the usermode components of WINE. They did this, because WINE project is focusing already on a compatible win32 (and win64) user mode.

      What ReactOS works on, is the reimplemented NT kernel underneath. Unlike the Wine package for Linux, it does not use wrappers to call POSIX kernel features. It recreates actual NT kernel interfaces, the way NT kernel does on windows. THAT IS WHY NT DRIVERS CAN LOAD AND RUN.

      It is theoretically possible that an intrepid person could hack on REAL windows' NTFS.SYS driver, and have real read-write NTFS support. In fact, I expect that this has already been done when testing the read-only driver through debugging, to better know how and what that driver does, so that it can be reimplemented.

      Please stop spreading ignorant FUD.

      • How am I spreading FUD? Nothing I said was anywhere close to spreading fear, I expressed that I was uncertain and that the summary was unclear, and as for doubt, the only real doubt is over to what degree the summary reflects reality.

      • Re:Confusing summary is confusing (Score:4, Informative)

        by Rob Y. ( 110975 ) on Wednesday February 17, 2016 @10:59AM (#51527677)

        It seems to me that read-write ext filesystem support on Windows would be a more important accomplishment - enabling ext-formatted SD cards to be used on mobile devices and eliminating one of the more egregious bits of Microsoft patent blackmail. Obviously, nobody uses FAT for any other reason than Windows compatibility. Besides the silliness of allowing a patent on what is essentially a kludgy workaround for an ancient filesystem, the thing is a de-facto standard (see above - nobody would use it on the merits). If it must be patentable, then if ever there were a case for a FRAND licensing requirement, this is it. It boggles the mind that the license paid by the SD card manufacturer isn't enough to cover actually using the card - but our patent system boggles the mind in many ways...

        In any case, a reliable ext driver for Windows would make it practical for device manufacturers to use the free ext filesystems.

        • Re: (Score:2)

          by Rukia ( 1306257 )
          Something like this?

          https://sourceforge.net/projec... [sourceforge.net]

          "Ext2Fsd is an open source Linux ext2/ext3 file system driver for Windows systems (2K/XP/VISTA/WIN7/WIN8, X86/AMD64)."

          • Yes, like this, but preferably something that has been updated in the last 5 years, and in particularly tested with Windows 8 and 10, can read and write a journal, and doesn't have "Data corruption issue" at the beginning of their most recent changelog.
      • In the past they have discussed their relationship with WINE. One of the problems they have with WINE is it has a very different purpose to ReactOS. WINE is trying to run Windows programs on another platform. ReactOS is trying to make a Windows implementation.

        Some libraries in WINE cannot be used because they rely on functionality of the base OS, or X Windows. Others pieces of Windows functionality are none existent in WINE since they are only needed by the OS, but they have some functionality that ReactO
    • Python 1.7 is not included. Python 2.7 and Python 3 version are available for download and installation via ReactOS application manager.
      • Typo: I meant 2.7 like it says in the summary, which says it is included, not that it can be installed via an application manager.
        • it is included but via via an application manager and not on disk
          • Different concepts of what "included" means? If the Tower of Babel is based off something that really happened, I suspect something like everyone slowly drifted apart on what words mean what, but they didn't have people studying the phenomenon like we have today. There are situations where person A understands person B, who understands person C who understands person D, but person A won't understand person D.
            But back to the matter at hand, it seems to me that calling something included that is accessed by

    • Well there's the kernel, with scheduler, etc (Score:5, Informative)

      by raymorris ( 2726007 ) on Wednesday February 17, 2016 @10:18AM (#51527403) Journal

      > They say it has a WINE implementation, but they don't call it "WINE-based".

      Right. It's an operating system, including a kernel, init system, etc. About 9 million lines of code in total.

      Wine is a library which provides some of the API functions which are exposed to userland. Wine is about 2.8 million lines of code. Not that Wine is much smaller than operating system it runs on. ReactOS uses the Wine for many functions, Windows Vista uses the IE library for many functions. ReactOS isn't Wine-based any more than Windows is IE-based.

      > And what's the point of including a variation of Python 1.7

      You mean 2.7. Python is useful for scripting all sorts of things. As you may have noticed, Microsoft comes out with a completely new scripting environment every few years; apparently they don't think they got it right and they ned to start over from scratch. Some people agree, and Python is a very reasonable way to script things.

      > And why only a read-only NTFS implementation?

      Because safely writing to NTFS is hard. The damn thing was designed by /Microsoft/. Until the code for writing is safe (as safe as NTFS can be), read-only is better than nothing, and much safer than a buggy read-write implementation.

      • Re: (Score:2)

        by jabuzz ( 182671 )

        There has been reliable NTFS writing using open source code on platforms other than Windows for years now. It is perhaps not the most performant implementation, but it would in my view make more sense than an ext? driver.

      • > And why only a read-only NTFS implementation?

        Because safely writing to NTFS is hard. The damn thing was designed by /Microsoft/.

        You forgot to add that NTFS is undocumented, so most of the actual work in reading/writing NTFS has been done by reverse engineering. The only "documenation" after a brief search on Google confirms it [dubeyko.com].

  • If it's Windows-compatible enough to run the sea of Windows-based malware then it will definitely be a bad thing. And given that a lot of endpoint protection apps can be picky about the platforms they run on, then it's just possible that these things could get infected without any adequate protection.

    That having been said, I've played with ReactOS before. It looks quite good. But I can't really see why you would want to use it compared to (say) Ubuntu or CentOS which are very polished and usable these day

    • > But I can't really see why you would want to use it compared to (say) Ubuntu or CentOS which are very polished and usable these days.

      Later, if and when ReactOS is more mature, several use cases make sense. Right now, the primary use case I can think of is if your business, or something important to you, depends on a complex Windows application which can't reasonably be re-written. Perhaps you don't want to use Windows for a million reasons, especially an old version of Windows.

    • There are SCADA systems still in use today that run DOS/Win 3.11 and NT because they still work. Obviously Microsoft doesn't support these nor do their original designers. They could theoretically move their system to newer hardware if they switched to ReactOS. Whether it would be cheaper than scrapping it for a newer system or not depends on the system.
  • the innovation manager for ReactOS, notes that 0.4.1 may be almost beta-level software

    Not even close
  • I want to corect interpretation of my words! ReactOS 0.4.1 is will not be called as beta! 0.4.1 may be almost _look and feel like_ beta-level software while still having alpha status!

  • Support for Windows 10 APIs? (Score:4, Insightful)

    by Merk42 ( 1906718 ) on Wednesday February 17, 2016 @09:58AM (#51527265)
    By the time this is stable, no one will write programs using those Windows APIs anymore anyway.
    • They may be useful to some people just for running the legacy software. And if it gains traction because of that, there will be more incentive, and more potential contributors, for supporting the modern APIs.
    • People still write applications using those APIs. Win32 really hasn't gone away. Once you can expose a fully functional Win32 API, you can quickly add the Win10 stuff on top of it. It wouldn't be open source but you could just deploy Microsoft's .Net framework onto the OS.
      • And even then, Mono does a reasonable job emulating .Net's framework.
        • Yes so if we have ReactOS to run native Win32 applications and Mono to run .Net applications, it gives people who are trapped in the Microsoft ecosystem a chance to escape. This is good for everybody because it will increase competition in the marketplace.

    • Re: (Score:1)

      by drewsup ( 990717 )

      Took the words right out of my mouth ! He originally started this because of all the old Windows dependencies left out there, and wanted a more secure open project to run them, I know its just a handful of devs, and kudos to them for working on an obvious labor of love, but really, by the time its in beta, everyone will have moved on... great idea, but taking too long to implement!

    • By the time this is stable, no one will write programs using those Windows APIs anymore anyway.

      yeah, i'm looking forward to the year of the linux desktop too! ;)

  • Please read the official announce at reactos.org
    https://www.reactos.org/projec... [reactos.org] - release notes
    https://www.reactos.org/wiki/C... [reactos.org] - change log

  • Real news article (Score:2, Informative)

    by Anonymous Coward

    https://www.reactos.org/project-news/reactos-040-released

    I don't understand why slashdot didn't link to the actual news article on the reactos website?

  • Inaccurate article (Score:5, Informative)

    by fireballrus ( 1000626 ) on Wednesday February 17, 2016 @10:24AM (#51527441) Homepage
    Alas, the TechRepublic article is rather inaccurate. Please read the official news [reactos.org] on our website about ReactOS 0.4.
    • I've heard of reactOS, but I didn't realize the project was making such good progress. Kudos good job and my congratulations to you and your team! This is some nice work.

  • Will inherit NTFS support from GNU Hurd (Score:5, Funny)

    by jfdavis668 ( 1414919 ) on Wednesday February 17, 2016 @11:28AM (#51527849)
    Someday they will copy in the NTFS read-write support from GNU Hurd to solve the problem.
    • There is nothing about NTFS that is GPL 3, so it's unlikely that it'll EVAAAR be supported by GNU HURD

  • who cares? (Score:3)

    by ooloorie ( 4394035 ) on Wednesday February 17, 2016 @12:49PM (#51528533)
    Does Windows still matter these days? Sure, a lot of people are running it, but most of the end-user app development now takes place on Android and iOS, and server and high performance computing is largely Linux.

    The only thing Windows still has a lead in is as a gaming platform, and it's unlikely that ReactOS will be useful for addressing that.

    • Re: (Score:1)

      by Anonymous Coward

      Windows still has the lead in CAD. Yes, there are freeware CAD packages for Linux and commercial CAD packages for OS/X, but most of the major extensions/bundles are still Windows only.

  • Wine on Linux vs. Wine on ReactOS (Score:5, Interesting)

    by wjcofkc ( 964165 ) on Wednesday February 17, 2016 @01:52PM (#51529135)
    I remember when Wine was such a joke that many people including myself saw it as unnecessary and going nowhere useful. You could run things like notepad.exe and calc.exe. It was for many an intriguing passing interest and likely an impossibility as far as ever being really useful. A few months ago I found myself in a real pinch. I absolutely had to install and use some Windows software (a very, very rare event). Yet, I am not running a single instance of Windows nor do I have a copy or interest in pirating it. So, not expecting much, I installed Wine for the first time in many years. Well shit. The software installed and ran flawlessly. Kind of amazed, I spent a good day throwing a ton of Windows software of varying complexity at it. Roughly 80% installed and worked perfectly. More recently I found myself staring down a badly and rapidly decaying Ubuntu system (you know what I mean). It also just so happened that there was a DVD burning imperative. The whole dependency subsystem for burning was shot to hell. Brasero, k3b, command line, it didn't matter, nothing was going to work. This was also the worst dependency hell I have ever seen. There was no uninstalling and reinstalling of anything, and I mean anything at all. It wasn't my system and I was soon to nuke it anyway so I wasn't about to take extreme measures. Fortunately I had previously installed Wine on this system. Downloaded and installed... whatever popular Windows DVD burning software. Worked fine. Nuked the system and gave a lecture on how to not blow up Ubuntu.

    So that is my Linux\Wine anecdote

    I am not about to ditch Linux, but I am going to give the almost beta ReactOS a fair try with a Windows app by app comparison against Linux. Might even be worth writing an article over.

    • Wine works pretty well these days, unless you're trying to run the latest and greatest games. But it's best to isolate these things; you may run into a situation where due to conflicting requirements, your wine installations get just as FUBAR'd as that Ubuntu install. I would recommend using PlayOnLinux: it provides a nice way to manage wine versions and wineprefixes, and often times it has scripts to set up the application you want to run.

      I'm thinking about giving ReactOS a try in a VM. I'm not in a hurry

      • Re: (Score:2)

        by wjcofkc ( 964165 )
        Not a gamer but thanks for the tip on managing instances. I see that coming in more than handy. Personally I would like to see Wine ported to OS\2 Warp and maybe an upgraded network stack. I still have a boxed copy : P
        • A project called Odin [netlabs.org] had the goal of porting WINE to OS/2, but it looks like nothing significant has been done in a decade or so.

          There's an interesting Reddit thread here [reddit.com] which has some updated information.

          TL;DR: Some aborted projects exist out there on the Interwebs, but someone would have to pick them up, dust them off, and provide some TLC.
  • it is a pitty that they didn't go with full JFS support but prefered NTFS. There is a lot of open source knowledge from OS/2 croud.

Slashdot Top Deals

The reason that every major university maintains a department of mathematics is that it's cheaper than institutionalizing all those people.

Close