Slashdot Mirror


ReactOS Now Runs Abiword

martijn-s writes "Reactos will now run, amongst other programs, AbiWord, IrfanView and its own Explorer clone. Screenshot here. I keep getting amazed by the quality of the code that is coming out of this project..."

6 of 62 comments (clear)

  1. Nice to see it coming along by squiggleslash · · Score: 5, Informative
    ReactOS, for those unaware, is an attempt to create a free (as in freedom) Win32 compatable OS.

    While I'm no great fan of the copy-cat mentality parts of the FOSS community are infused with, I must admit I think ReactOS is a good idea. It's ok to clone a Windows interface when the underlying operating system is Windows, the whole "Let's make GNOME just like IE!" thing has always worked terribly because the underlying OS is not Windows and doesn't look or work anything like Windows. The NT generation of Windows (NT, 2000, XP, 2003) is a reasonable design for an operating system too, so if you're going to start somewhere...

    That's my 2c. Coming up, a skateboarding rabbit. That's after a word from our sponsors.

    --
    You are not alone. This is not normal. None of this is normal.
  2. Re:ReactOS by FlipmodePlaya · · Score: 3, Insightful

    I think the point is to make a free Windows. The idea is having a free way to run Windows applications perfectly, the copycat interface is probably just a way to attract those farmiliar with Windows who do not wish to pay for it. Aso, Wine Is Not an Emulator...

  3. Re:ReactOS by ComputerSlicer23 · · Score: 4, Insightful
    Remember the goals here. First, it's they are trying to be binary compatiable with Windows, so applications and drivers will work exactly the same.

    In particular the version of Windows they are working on is old, and has been EOL'ed. So you can no longer get support for it. It'd be novel to have a version that was fully compatible, and you could have the source to keep up to date with bug fixes.

    Second, they aren't trying to be like Wine. The Wine project is orders of magnitude harder then ReactOS (in some ways). Wine is attempting to make a translation layer from Win32 calls into a Posix/UNIX/Linux environment. That's a whole heck of a lot harder in a number of ways. Things are set absolutely in stone, and can't be changed. On top of all that, at points they get stuck because they are attempting to emulate kernel space functionality in a userspace application a lot of the time.

    ReactOS, can make map kernel space things to kernel space things. They can map user space things to user space things. They already have the entire design, and a known model to follow. That's a lot easier then Wine in terms of implementation. Wine is attempting to live withing a much harder set of constraints then ReactOS. However, ReactOS does have to actually implement an entire OS (so it might be a wash). I know I'd rather try and make ReactOS go, then attempt to make Wine work the way it does.

    Finally, part of the reason Wine has so many problems, is it started out as a Win3.1 or 3.11 tool, doing 16-bit applications. Now it's moved on to covering a half dozen versions of Windows (at least that many). They also support multiple platforms, and are attempting to be reasonable portable.

    The other thing I'll be interested to see is if the ReactOS guys can manage to make it run on MIPS, Sparc, x86, x86-64, Alpha, and any other random platform you can think of. It'd be interesting to see what all they can come up with.

    Kirby

  4. Ummm . . . by erikharrison · · Score: 4, Interesting

    Well. To clarify I guess . . .

    Wine and ReactOS *are* sharing code and ideas. Wine is really a reimplementation of the Win32 API, and ReactOS is working with them both to improve the Wine DLLs as well as port those DLLs to the ReactOS kernel.

    Wine does work with native Windows DLLs, and so will ReactOS (may now, not sure). As for how hard it is to emulate Windows, it's hard. The Windows runtime is a twist maze of libraries all alike, and it's not just source compat were after here, its binary compat.

    And as for lusers and their software, the disadvantages of a closed system have been widely discussed here on /. This could allow companies to upgrade at their own pace, rather than at Microsoft's, and allows public code review for security holes. This isn't just lusers, this is large corporate installs of NT gaining a signifigantly different and more flexible upgrade path.

  5. Repost of a previous comment: by truefluke · · Score: 4, Insightful
    Some others have asked the same question as others have here: Essentially: "Why Bother?"

    Here's the URL of my answer (a comment), (the comment)... from an article preceeding slashdot's posting by several days... I'll even paste it (my reply) for you if you're adverse or too lazy bother to visiting signalnine.com...

    I still think the POTENTIAL for having a 'free' platform to EASILY port your code to is a good thing. We have no idea what might become of Windows (as we know it) once Longenhurden manifests. This project, I think, offers a small amount of comfort to businesses (think enterprise and small biz, too) who have invested exorbitant amounts of programmer-time and dollars on in-house, 'vertical applications'. They may not need the lastest whiz-bang Microsoft 'features' (that MS says we can't do without). Even if they can't implement all of say, DirectX for gamers; or .Nyet, (I say this because of the potential of land-mine-infested patents...c'mon you KNOW MS isn't benign, ADMIT IT!), running a 'cheap' Delphi application that does your check processing/imaging on NT 4 or Win2k is a VALID REASON for this effort ('what we have right NOW works just FINE, thank you'). There might yet be good cause to dread at what's coming up on the horizon. Just my 2 cents. Was that rambling? I tried to write something lucid and coherent. Sorry if I failed. I'm very tired as I write this.

    --
    spam, spam, spam, spam, e-mail, news and spam.
  6. Re:Olds? by GvG · · Score: 5, Informative

    The code we re-used from Wine certainly helps to speed up development. But we can't re-use everything and have to develop a lot of stuff ourselves. For example, Wine uses X11 primitives to do BitBlts (bitmap copying). Since ReactOS is not X11 based we had to write that stuff ourselves. Also, in Wine, everything is in userspace, while ReactOS follows the NT4 (and later) design where there is a split between userspace and kernelspace, with most of the work actually being done in kernelspace. Still, we try to co-develop as much stuff as possible with Wine. Ofcourse, since Wine has been around much longer and the number of Wine contributors is larger than the number of ReactOS contributors most of the shared code originates in Wine. Ge van Geldorp, ReactOS developer.