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

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.

Comments

SQL Server runs and I'm in!

[fraxinus-tree]

version 2008 is OK for me.

Re: SQL Server runs and I'm in!

[0xdeaddead]

He'll, I'd be happy with 7.0 .... but I'll take 4.21!

Re: SQL Server runs and I'm in!

[dintech]

Fusion ReactOS. Every time I read about it, it always appears that it will be fully complete and operational in about 10 years from now.

A nice step forward.

[Anonymous Coward]

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.

Re:A nice step forward.

[Anonymous Coward]

Boot sector viruses will not be expecting EXT flavor filesystems. I am curious how they did the SID to linux user topology mapping to make EXT flavor OSes work with the NT security model. NT flavor security has many features not present in Linux security design, and significantly more permissions flags.

This is actually quite welcome news, given the issue with windows 10 being (in some cases) forcibly installed on people's computers without their consent by microsoft's update loaders.

Sadly, ReactOS is still alpha level software. Give it time though. I will sip something aged and expensive should they ever manage to steal win32 market share the way Linux won server markets away from Unix.

Re:A nice step forward.

[Anonymous Coward]

You are incorrect.

ReactOS shares code with the WINE foundation for usermode libraries and programs, because there is no need to reinvent the wheel. The kernel mode goodies that run underneath are genuine NT flavor kernel. Remember kids, NT is a modular kernel with more than one subsystem type that it can service. While not given much love over the years, one of those is the posix subsystem. ReactOS supplies real NT surrogates wherever and whenever possible to provide the NT kernel services that user mode WINE libraries link to, instead of the wine surrogates used by the wine foundation. When that is not possible, it can use the posix flavor subsystem to provide glue. It is still NT.

ReactoOS is not a fork of wine. It is a sister project, that shares code with wine.

Re:A nice step forward.

[KiloByte]

The NT POSIX subsystem has been completely removed as of Windows 8.1 (and was in a sorry state since XP).

Re:A nice step forward.

[Anonymous Coward]

Indeed, But IIRC, ReactOS still has a functioning Posix identity module. The fact that MS does not think that POSIX support is good, does not mean ReactOS need think the same. Having a functioning POSIX subsys will in no way harm the WIN32 subsys.

Re:A nice step forward.

[Anonymous Coward]

You are incorrect.

Remember kids, NT is a modular kernel with more than one subsystem type that it can service. While not given much love over the years, one of those is the posix subsystem.

And remember that Microsoft owned XENIX and wrote NT to replace it, so it is bound to be UNIX-like heritage in there.

Re:A nice step forward.

[unixisc]

Does ReactOS have a microkernel OS? If it did, it could have something like separate win32, win64, win16 and use FreeBSD or NetBSD for support

Re:A nice step forward.

[Pseudonym]

Does ReactOS have a microkernel OS?

It has a similar structure to ntoskrnl, so it does have a microkernel which is relatively separate to the other parts of the kernel (e.g. virtual memory, object manager), but they're all linked together. Just because it's a microkernel doesn't mean it's easy to emulate other OSes on top of it.

Re:A nice step forward.

[TheRaven64]

The problem with the POSIX subsystem on NT is that it works in roughly the same way as syscall emulation on *NIX systems. On FreeBSD, for example, you can run a Linux binary and it will have a Linux syscall table instead of a FreeBSD one. Unfortunately, it then can't make FreeBSD syscalls. That's not usually a problem, because if you're actually porting code from Linux to FreeBSD and want to use FreeBSD-specific features then you probably recompile it. With NT, you have the same issue, but there it actually matters: you can either issue POSIX system calls or Win32 ones, but not both from the same program. If you want to use the GUI, then you have to use the Win32 subsystem. If you want to also use POSIX APIs then you had to split your program into two parts and communicate via some IPC channel. This made it largely useless and is why MinGW, Cygwin, and SFU all use the Win32 subsystem and map library calls to Win32 syscalls.

Great work

[LichtSpektren]

I'm glad to see progress on ReactOS. Good job!

Re:Great work

[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.

Re:Great work

[NJRoadfan]

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.

Re:Great work

[Sax Russell 5449D29A]

I just don't understand why anyone would want to use a Windows-ish OS that has poor compatibility with both Windows-based and Linux/*BSD software. 20 something years in the making and still in a prealpha, or something, state is also kind of slow progress. Or maybe your comment was ironic. Who knows

Re:Great work

[Anonymous Coward]

Take a deep breath.

Now. Look at Microsoft. How many developers do they hire every windows development cycle?

Now-- Look at the development credits for ReactOS. See something missing? Like say-- a few hundred names?

That's why development speed is slow. Linux kernel has a small army of developers. Reactos? Not so much.

Considering the shoestring budget, the small dev pool, and the constant flame-hate against their project, they have an IFS driver for EXT filesystems that runs on NT kernels, that is both read and write. They have a functioning scheduler, and memory management component. They have a shitload of things that they have working or partially working.

And you complain like a bitch with sand in his man-gina? Grow up.

Re:Great work

[Anonymous Coward]

We live in a container and VM world now, drivers are not nearly as much of a concern as is 100% compatible user and kernel space application support.

Re:Great work

[fizzer06]

Wouldn't boot on my hardware either. Disappoint

Re:Great work

[Anonymous Coward]

End users do not use VMs.

Re:Great work

[Anonymous Coward]

Great, they're small and scrappy. Now tell me why I'd want to run it.

Re:Great work

[DrXym]

That's the issue with chasing a moving target, particular when you're in a pedal car and the target is a bullet train.

ReactOS will never catch up to windows. The best it could hope for is that one day it might be roughly analogous to W2K or XP which might be enough for a lot applications which don't need any more. Then it might gain a reputation akin to FreeDOS as something you can throw on old hardware, or a VM to get some software going without worrying about OS licenses. Maybe it could even serve as some kind of docker for Windows - bundle up a Windows application and run it from anywhere with its own environment.

It should really focus on those uses.

Re:Great work

[BronsCon]

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).

Re:Great work

[BronsCon]

And neither does the supervisor under which the VMs and containers run. It is clear that the poster of the "container and VM" comment is a very short-sighted thinker and didn't stop for long enough to realize that everything, even virtualized hardware, must run on real hardware and that real hardware requires drivers in one form or another. Hell, even virtualized hardware requires drivers, there are simply fewer of them.

People like this are the reason I won't work for someone else again; and I will never hire someone like this. My interview process includes questions intended to weed out people who believe that virtualized infrastructure is de-facto better than bare-metal solutions, because they fail to realize that a virtualized solution requires bare-metal to run in on the first place. The right tool for the job, people; sometimes that's a virtualization solution, sometimes it's not. Oh, and it always involves drivers, at some level.

Re:Great work

[Megol]

Where do you get the idea it have to be a copy of the newest NT iteration to be useful?

Re:Great work

[DrXym]

Where did you read anything I wrote which implied it did?

Re:Great work

[jfdavis668]

If your system had SATA drives, it wouldn't. That support is now included in this version.

Re:Great work

[Anonymous Coward]

Your full of shit! ReactOS has mostly complete UI and could run windows software long before they started collaborating with WINE.

Re:Great work

[NJRoadfan]

The problem wasn't storage related.. ReactOS 0.3.17 uses the UniATA 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 release a shot, hopefully they fixed the problem.

Re:Great work

[Sax Russell 5449D29A]

I wasn't asking why development is slow, it was an observation. Reasons may differ but are also inconsequential to the end result.

And you complain like a bitch with sand in his man-gina? Grow up.

It's easy to shout from the bushes as an AC, not using your own name. Man up and register an account.

Re:Great work

[Anonymous Coward]

Well, the counter-argument could be that there are few enough things for which the performance advantages of running close to the metal outweigh the security+flexibility of virtualization. I don't think you're wrong about what you say (per se) but I would like to hear you develop this thesis.

Re:Great work

[BronsCon]

High-volume data storage. There is a reason Google uses so many low-power machines instead of virtualizing everything.

And your counter-argument really doesn't make sense in context. You can't virtualize a supervisor, the VMs need a bare-metal machine to run on; that is what I was pointing out. In that context, your argument is that you can virtualize the hardware your VMs run on, which we both know is false; it can't be VMs all the way down. There has to be physical RAM, CPU, and storage somewhere.

Re:Great work

[unixisc]

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:Great work

[ChunderDownunder]

Well someone was complaining the other day that Windows 7 and later had poor compatibility with programs written for XP and earlier versions dating back to DOS.

ReactOS could fill such a niche.

I've personally found Wine in the past useful for bug fixing where problems would only occur on various revisions of windows, different from my developer workstation. Running Windows in a VM is one diagnostic; wine and ReactOS provide another.

Re:Great work

[Anonymous Coward]

Windows ceased being a moving target when Windows 10 was released. If ReactOS can reach parity with Vista/7, that will be all that anyone needs.

Re:Great work

[DrXym]

Windows 10 is still a moving target. And my experience of using ReactOS 0.4 suggests it is about W2K at present. It's impressive how much has changed between 0.3 and 0.4 but it's never going to reach Windows 7 let alone 10. Better to stabilize it and think about pitching it as a container solution for apps which don't need the bloat / baggage / licensing that goes with real windows.

Re:Great work

[Anonymous Coward]

You can't virtualize a supervisor, the VMs need a bare-metal machine to run on; that is what I was pointing out. In that context, your argument is that you can virtualize the hardware your VMs run on, which we both know is false; it can't be VMs all the way down. There has to be physical RAM, CPU, and storage somewhere.

I am sure you have a meaningful reason to say this, but as is it's just kinda an obvious statement bordering on the tautological. I mean no disrespect; I am actually quite sure that your knowledge and experience greatly exceeds my own. You're just stopping short with half an explanation here.

Re:Great work

[BronsCon]

A tautology, it was, right down to my (slightly embarrassing) use of "supervisor" instead of "hypervisor", a mistake I made in that post, as well as the one before it.

So, why make such an obvious statement? A few posts up, you'll see why the statement was originally made: someone claimed that drivers are becoming less important because everything is VMs and containers now, to which someone replied that end users don't use VMs. I replied to that, in agreement, and expanded on the point, a the original poster was clearly missing that bit of the picture.

Why repeat it? Because my assertion that there must be bare metal somewhere is not only not intrinsically wrong, it's note wrong at all; someone who would say it's "not wrong per se" clearly missed that point and needed it explained again, in slightly different terms. Three different ways in this case, so I know I won't have to come back and explain it yet again. You seem to have gotten it this time, so I'd say it worked.

Re:Great work

[Anonymous Coward]

Okay, but you're suggesting that it is wrong to say that virtualization is de-facto better than bare metal. Why? The strongest argument (in my experience) for bare metal is performance, which is not necessarily a strong factor and can usually be alleviated by throwing more hardware at the issue. VMs can achieve a certain level of isolation and fault tolerance, and while the hypervisor does need to talk to the hardware directly, the VM/container often does not, and can be happily moved to another instance without driver issues. As with all nontrivial issues in tech, there is an argument to be made either way. I don't have much of an opinion either way, but I can think of more plusses than minuses on the virtualization side. I would much rather have each service on a server segregated in some way (container/vm/chroot/jail) than have everything all mucking about with the same files and libraries. I'm good enough at trashing systems that I want dependencies to be as isolated as possible, and I'm a mediocre programmer who by virtue of working on sufficiently trivial problems has yet to exceed even the most minimal hardware requirements. You have more experience and have arrived at a position which strongly opposes mine. I'd appreciate the benefit of your wisdom and experiences on the virtues of non-virtualization.

Re:Great work

[BronsCon]

I gave the salient example a couple posts up but, since it seems to be a theme here, I'll repeat myself: High-volume data storage.

It's not trivial to simply throw more hardware at an RBDMS, you have to handle primary key collisions and no, UUID is not a solution as not only are collisions still possible, using massively non-sequential data as a primary key is absolute murder on database performance, meaning you must throw even more hardware at the problem to compensate. And, even if that were sufficient, the redundancy, isolation, and fault tolerance "benefits" (all of which you can gain with properly configured bare metal systems, as well) go out the window on a write-heavy system, due to something commonly known as propagation delay. Isolation simply means a separate running environment for each application (or part thereof, depending on how fine-grained you want to get), which can be had with physical hardware as well; it often doesn't make sense if you're running low-load, low-traffic stuff, which is where virtualization steps in, but it's not per se a benefit of virtualization, just a good general engineering principle. Fault tolerance is introduced through various means; running multiple instances of the same service with the same data (e.g. hot spares) and maintaining up-to-the-moment current backups (e.g. realtime data replication) are the two most common, both heavily overlapping the other mentioned benefit, redundancy, and both possible with physical hardware; therefore, not benefits of virtualization. If you're generating data faster than you can replicate it to your hot spares or backups and the system goes down, you're boned regardless.

The real benefits of virtualization include the ability to run several lower-traffic virtual hosts on a single physical machine rather than several separate machines which are likely overpowered for their respective tasks (in the case of virtualizing on your own physical hardware), and the ability to quickly scale an application to massive size (in the case of virtualizing on someone else's hardware). The former certainly represents significant cost savings, which is a benefit in and of itself, while the latter represents extreme flexibility. The reason scalability isn't a benefit of virtualizing on your own hardware should be clear, but I'll state it anyway; you aren't saving anything if you have to have the hardware on-site, configured, and standing by anyway.

I'm not knocking virtualization and container solutions at all, here; they have their uses and I utilize them extensively. The only systems I don't virtualize are my personal systems and my NAS, because it makes zero sense to do so; I also don't run any write-heavy or high traffic data storage (other than the NAS), so even my databases are virtualized at this point. That may not always be the case, though.

Re:Great work

[david_thornley]

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

[BronsCon]

Please allow me to apologize for the tone with which I opened the above response; I had not yet finished reading your entire post when I started my reply, which was irresponsible of me (but also apparently common practice here in Slashdot). I now see that you're actually interested in learning and not simply trying to be dense. Please understand that the latter is much more common than the former here.

Re:Great work

[Curate]

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?

Re:Great work

[unixisc]

I agree w/ the GP. ReactOS ain't targeted at touchscreens - it's for laptops only, and one doesn't HAVE TO use the touchscreen, even if there IS one. And the application support for Windows 7 is just fine. We don't need Universal Apps to run on ReactOS - there ain't too many quality ones anyway. Once ReactOS is complete - whenever that is - and can support that, it would work for most computers out there.

Re:Great work

[Anonymous Coward]

The best it could hope for is that one day it might be roughly analogous to W2K or XP which might be enough for a lot applications

Yes, I believe that's the entire point. This isn't a replacement for the latest and greatest spyware-ridden, contact-the-mothership version of windows.

Re:Great work

[Anonymous Coward]

You don't know what you're talking about. The UI is completely custom and has nothing to do with Wine.

Confusing summary is confusing

[hackwrench]

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?

Re:Confusing summary is confusing

[fraxinus-tree]

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:Confusing summary is confusing

[Anonymous Coward]

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.

Re:Confusing summary is confusing

[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.

Re:Confusing summary is confusing

[hackwrench]

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

[0100010001010011]

Why not take this opportunity to improve?

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

Re:Confusing summary is confusing

[Rob Y.]

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:Confusing summary is confusing

[Anonymous Coward]

Got a an IFS for ZFS? If so, just try it on reactos and see if it works!

If not, there's your reason.

Re:Confusing summary is confusing

[Rukia]

Something like this?

https://sourceforge.net/projec...

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

Re:Confusing summary is confusing

[Anonymous Coward]

I don't see why they don't use UFS as a universal filesystem.

Re:Confusing summary is confusing

[TemporalBeing]

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

[fph il quozientatore]

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.

Researtch

[Anonymous Coward]

It wood make more sence to some researtch before releasnig the update on differant compters to see what works and wich ones has dificultys. Like I try instal a Linx OS on and old laptop and it tunred to tty and I could not restrat to the desktop. Same thing with Raect OS, it should be test with differant compters. I expect the responce to be better than last React realese. At lease this not phone# home to Redmon.

Re: Researtch

[Anonymous Coward]

Is your keyboard broken or are you just incompetent?

Re:Researtch

[Anonymous Coward]

You seem to be having a stroke in progress. I'd suggest you get to your nearest hospital ASAP.

Re: Researtch

[Anonymous Coward]

I'll have a stab. He's someone who doesn't have English as his mother tongue, probably weren't taught it too well and is quite possibly dyslexic as the proverbial cherry on top. Now, did you actually have anything to say to him, other than stroking your own ego?

Re: Researtch

[Anonymous Coward]

Porque no los dos?

Re: Researtch

[Anonymous Coward]

That is not how a non-English speaker would write. The post has purposeful misspellings and the author is a troll.

Re: Researtch

[Anonymous Coward]

Or is an Indian troll.

Re: Researtch

[Anonymous Coward]

Was ist los?

Re: Researtch

[Anonymous Coward]

Yo mama!

Re: Researtch

[Anonymous Coward]

Is your keyboard broken or are you just incompetent?

Jus incompetince

Malware?

[Dynamoo]

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 days.

Re:Malware?

[ArhcAngel]

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.

Re:Malware?

[Anonymous Coward]

Maybe in the case of NT, but not so much DOS/Win3.11. Fortunately, we have FreeDOS for the latter. Of course, why take risks with possibly buggy, unpolished open source software when there is closed source software that just works? I mean, I like open source as much as the next guy, but a lot of these systems are mission-critical, and a seemingly minor bug could mean the difference between life and death. They continue to use old OSes because they just work, and bizarrely, I've even heard of cases where running anything other than the exact OS version they are running can lead to bugs and compatibility issues, even if it's an otherwise similar OS.

I don't think so

[TheRealMindChild]

the innovation manager for ReactOS, notes that 0.4.1 may be almost beta-level software

Not even close

Re:I don't think so

[Anonymous Coward]

WINE has always been broken and always will be, chiefly because of project management issues ...

Re:I don't think so

[Anonymous Coward]

The ReactOS team don't claim it is, just this inaccurate techrepublic article slashdot linked to

faint praise much?

[Anonymous Coward]

Alexander Rechitskiy, the innovation manager for ReactOS, notes that 0.4.1 may be almost beta-level software.

Thank you for buying ReactOS brand hot dogs. We apologize for how many anuses are in the meat. Rest assured, however, that every pack you buy helps us to lower the anus-to-cheek-meat ratio, until eventually we reach our goal of 1:4.

UPD. 0.4.1 is will not be called as beta

[jeditobe]

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!

Re:UPD. 0.4.1 is will not be called as beta

[Anonymous Coward]

Well, "almost beta" is enough to make me take another look, anyway.

Support for Windows 10 APIs?

[Merk42]

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

Re:Support for Windows 10 APIs?

[Katatsumuri]

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.

Re:Support for Windows 10 APIs?

[edtice1559]

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.

Re:Support for Windows 10 APIs?

[phantomfive]

And even then, Mono does a reasonable job emulating .Net's framework.

Re:Support for Windows 10 APIs?

[drewsup]

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!

Re:Support for Windows 10 APIs?

[edtice1559]

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:Support for Windows 10 APIs?

[Gravis Zero]

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! ;)

Python actually is not included

[jeditobe]

Python 1.7 is not included. Python 2.7 and Python 3 version are available for download and installation via ReactOS application manager.

fuse, ntfs 3g

[Anonymous Coward]

Fuse support is still missing from ReactOS. Otherwise ReactOS would have NTFS RW years ago. For some reason there was a strong hesitation against fuse, as they prefer kernel based drivers. They prefer kernel based drivers so much that they would rather have no read write NTFS instead of one in user space.

Re:fuse, ntfs 3g

[Anonymous Coward]

FUSE is a usermode linux filesystem driver framework.

Why and how do you expect this to work on an NT kernel?

Windows uses the IFS framework. That is also what ReactOS uses. ReactOS's EXT filesystem driver is based on several open sourced EXT IFS drivers that have been basically abandoned for ages, with some added love.

If you want something you can put in the bank today-- if their EXT IFS driver is fully read-write, and is reasonably stable, you could install it on real windows, and use EXT there as well.

THAT is the kind of thing ReactOS brings to your table. Stop complaining that reimplementing NTFS from the ground up is hard, and that it does not let you write files yet, M'kay-- they already did a pretty damned impressive thing getting an EXT IFS driver that does that.

Please read the official release notes

[jeditobe]

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

You rely on a complex legacy Windows app, for now

[raymorris]

> 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.

Real news article

[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?

Well there's the kernel, with scheduler, etc

[raymorris]

> 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:Well there's the kernel, with scheduler, etc

[jabuzz]

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.

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

You really don't want to actually install an OS other than Windows on a NTFS partition with a userspace based NTFS driver like ntfs-3g.

I haven't used ReactOS in a long time but I'm pretty sure you can mount NTFS partitions with write support manually if needed.

Re:Well there's the kernel, with scheduler, etc

[goarilla]

You really don't want to actually install an OS other than Windows on a NTFS partition with a userspace based NTFS driver like ntfs-3g.

No but you can look at its code to help you implement a kernel mode implementation. Or is that not allowed ?

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

Why would you want to use an inferior filesystem like NTFS?

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

>No but you can look at its code to help you implement a kernel mode implementation. Or is that not allowed ?
Of course you can.

Even with a NTFS kernel driver, there might be other limitations with NTFS that could make it unsuitable for a root partition. I'm not knowledgeable enough about file systems to and the ReactOS architecture tho.

Have a nice day.

Re:Well there's the kernel, with scheduler, etc

[present_arms]

Actually and believe me I'm no MS fan, however NTFS is actually along with the kernel of windows are the only 2 things in the whole of windows that's any good, if you want a shit file system, look at macs HPFS which is a dog, and I mean 'fat' as in fat 16,32, like dog. ext4 is fine and has ACLs ala windows too (if you learn how to use them) as well as UID/GID permissions. sheesh some people, yes in the days of NT4, NTFS was crap, now-a-days it's a stable file system as any of them.

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

And yet NTFS still has a 255 character limit for path names (combined directory, subdirectory and filename) length. I run into it all of the time when I use a system with NTFS. I guess it's a less common issue for people who just randomly pile all of their files into the root directory of their drives, but I like organization.

NTFS is years behind ext4 and decades behind ZFS.

Re:Well there's the kernel, with scheduler, etc

[ausekilis]

> 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.

Re:Well there's the kernel, with scheduler, etc

[lgw]

And yet NTFS still has a 255 character limit for path names (combined directory, subdirectory and filename) length

Nope- it never has had that limit. Legacy win32 APIs have that limit, but the work-arounds are documented in MSDN (something like //?/C/long/path/...

NTFS supports most things you'd want a filesystem to support, and some odd things most filesystems don't (multiple data streams).

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

Nope- it never has had that limit. Legacy win32 APIs have that limit, but the work-arounds are documented in MSDN (something like //?/C/long/path/...

Sorry, you don't have a clue what you are talking about. I run into the problem of having too long path names in modern versions of Windows all of the time. I end up having to truncate file names and directory names into less useful things because of it.

Go on, try to make a series of subdirectories that extends further than 255 characters for the full path. You can't.

Re:Well there's the kernel, with scheduler, etc

[Anonymous Coward]

BeFS handled multiple data streams almost 20 years ago. It also handled arbitrary metadata, something that NTFS still can't do.

Re:Well there's the kernel, with scheduler, etc

[Megol]

What lgw pointed out was that the limitation in in the Win32 subsystem, not the NTFS.

Re:Well there's the kernel, with scheduler, etc

[Megol]

Of course it can! Just encode it in a data stream.

Re:Well there's the kernel, with scheduler, etc

[lgw]

https://social.msdn.microsoft....

First useful google hit for me. There are many more. \\?\ and you're good.

Inaccurate article

[fireballrus]

Alas, the TechRepublic article is rather inaccurate. Please read the official news on our website about ReactOS 0.4.

Re:Inaccurate article

[phantomfive]

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.

Hats off to everyone involved !

[Anonymous Coward]

Well done to the whole ReactOS team. I've got lots of very good, very usable Windows programs that I use daily. Some of which have been in use since Win98 days.

I also have quite a bit of hardware which doesn't have drivers post XP so I'm currently stuck running XP. And I am *ABSOLUTELY NOT* replacing several thousand pounds worth of perfectly working, perfectly good hardware because Microsoft decide they no longer wish to support the XP era drivers or the manufactureres don;t want to provide updated Windows 7 drivers.

Not to mention the fact that Windows is now a totally dead platform due to being riddled with spyware. You'd have to be a complete submissive, masochistic, imbecile to run Windows 10.

One day I hope I can run my programs/drivers under ReactOS so hats off to everyone concerned !

Re:Python actually is not included

[hackwrench]

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.

Will inherit NTFS support from GNU Hurd

[jfdavis668]

Someday they will copy in the NTFS read-write support from GNU Hurd to solve the problem.

Re:Will inherit NTFS support from GNU Hurd

[unixisc]

There is nothing about NTFS that is GPL 3, so it's unlikely that it'll EVAAAR be supported by GNU HURD

Does it work yet?

[Anonymous Coward]

Last time I tried reactos, I got it installed, installed firefox with the package manager, tried opening it, and the computer bluescreened every time I tried opening it. It's no good if I can't access the internet with it.

Re: Does it work yet?

[Anonymous Coward]

Sounds like the Windows experience from the XP days, so ReactOS must be on the right track.

Re:Python actually is not included

[jeditobe]

it is included but via via an application manager and not on disk

Re:You rely on a complex legacy Windows app, for n

[Anonymous Coward]

If it's just an application, you'll probably do just as well with Wine. The real case for ReactOS is when you have an application which works with a particular (specialist, expensive) device, which needs a special driver, and that driver is not supported on current Windows versions (e.g. driver last updated for WinXP). If the driver and application work with ReactOS it's worth it's weight in gold.

Re:I don't think so| Misinterpetation!!!

[jeditobe]

That was Misinterpretation of my words
I want to correct interpretation of my words!

ReactOS 0.4.1 will not be called as beta!
0.4.1 maybe _ will look and feel like_ almost beta-level software while still having alpha status!

who cares?

[ooloorie]

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:who cares?

[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

[wjcofkc]

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.

Re:Wine on Linux vs. Wine on ReactOS

[Tenebrousedge]

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 to let alpha-quality software touch bare metal, though.

Re:Wine on Linux vs. Wine on ReactOS

[wjcofkc]

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

Re:Wine on Linux vs. Wine on ReactOS

[Anonymous Coward]

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.

If that doesn't work, next time use an official test VM image: https://dev.windows.com/en-us/microsoft-edge/tools/vms/

Re:Wine on Linux vs. Wine on ReactOS

[Anonymous Coward]

As an active lo sec PVPer I can confirm EVE Online actually works almost perfectly in wine. The only problem is the new launcher which has intermittent issues, but once the game is running it's smooth.

A lot of games work well in wine now.

Re:Wine on Linux vs. Wine on ReactOS

[sydbarrett74]

A project called Odin 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 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.

ReactOS Uses Parts of WINE, Not All Of It

[HannethCom]

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 ReactOS needs, so it is a combination of WINE and new ReactOS code. In the previous case the code will not be pushed back to WINE, but that difference needs to be maintained for ReactOS. Then there are times that ReactOS has implemented code that can be useful to WINE, so they post a commit to the WINE project.

While WINE and ReactOS do share some code, it is correct to say that parts of the usermode are based on WINE. If you were to compile the WINE components and try to just drop them in ReactOS, many would not be functionally equivalent to ReactOS version of the component.

Re:Python actually is not included

[hackwrench]

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 a program that downloads it over the internet isn't that far removed from calling everything that is free in an app store for a particular OS included with that OS.

write to NTFS using Midnight Commander

[jjohn_h]

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

I can write to NTFS from Ubuntu using Midnight Commander.

Re:write to NTFS using Midnight Commander

[BronsCon]

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.

Re:write to NTFS using Midnight Commander

[jjohn_h]

The ntfs-3g driver to read and write to NTFS from Linux is built-in into the kernel.

http://www.tuxera.com/communit...
http://ubuntuforums.org/showth...

Re:write to NTFS using Midnight Commander

[BronsCon]

Interesting info; the FUSE driver that came with my wife's Toshiba external driver included documentation to the contrary. Still learning things here, that's why I keep coming back.

Not So.

[gerald.edward.butler]

The guy hired by Microsoft to write NT was one of the developers of VMS. NT is based more on ideas from VMS than anything Unix-Like.

Re:Not So.

[Anonymous Coward]

Actually as far as I remember was more than one guy from the VNS team.

Re:Not So.

[RuffMasterD]

I think Microsoft hired a whole committee to write Vista.

Re:Not So.

[david_thornley]

There's a hint in the name. Take VMS and add one to each letter (the reverse of IBM->HAL), and you get WNT: Windows NT.

"Closer to reality"

[Anonymous Coward]

No dissing those putting in what I'd imagine is quite a bit of effort to get this far but it's unfortunate that the headline is quite so vague.

I think my rather lovely new shirt brings my tempestuous affair with Scarlett Johansson closer to reality. But it's still never going to happen.

Re:Great work - report the bug

[jeditobe]

please report the bug, if it does not work

Battling it out with Hurd

[Anonymous Coward]

ReactOS is driving towards a 2050 GA release! It's neck and neck with Gnu Hurd, who will be first? Stay tuned, this is a nail-biter folks!!

Windows 10.

[Anonymous Coward]

I'll switch from Windows 10 to ReactOS 0.4. Windows 10 is almost beta-level.

JFS

[FithisUX]

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.

100% grain fed anus beef

[RuffMasterD]

No thank you. I only buy 100% pure anus beef.