NTFS now supported in ReactOS LiveCD | Hacker News Reader

NTFS now supported in ReactOS LiveCD

reboot.pro

158 pointsjeditobe46 comments

I think a lot of people ignore the fact that the ReactOS and Wine projects have a symbiotic relationship. Work on ReactOS will lead to improvements on Wine, and vice versa.

So it's still a useful project for the common user, even if the final product of a fully functional Windows NT clone is still far from being realized.

But actually - there's another, even more interesting use for ReactOS that I'm surprised has yet to be attempted.

A lot of people seem to praise the NT kernel on an architectural level for its microkernel-like features and object system, but it's buried between the cruft that forms the rest of the Windows stack. A free software reimplementation like ReactOS could actually allow for people to exploit the untapped potential of the NT kernel by fusing it with other userlands. Think in the vein of GNU/kFreeBSD. Perhaps a FreeDOS one? Either way, the novelty value is certainly high.

From what I've seen the past few years, ReactOS just picks up what WINE does. I don't think they're contributing much. Its pretty much a pet vanity project and has been for a decade.

I've been given the impression that NT's superior kernel architecture is why they are doing this. But they also want other people to care so they also try to get Windows apps working on it too.

I love the idea of ReactOS but it is moving so slowly that I don't see how they can ever be a relevant alternative to Windows. Is my impression wrong?

Honestly I was thinking the same. I've heard of this project years ago, but today it's only still reading NTFS volumes? For a project attempting to re-implement Windows?

I'm also curious about the two Program Files folders I see, identically named in the same folder.

The second one should be Program Files (x86). Perhaps the (x86) part is wrapped to a third line and not visible due to another window on top. Or perhaps the ReactOS Explorer shell's UI just cuts off the (x86) part (incorrectly). Probably not an issue in the NTFS implementation.

My understanding is that NTFS support is fairly low on the priority chain; most windows features work just fine with FAT. I booted ReactOS into a VM a few months ago, and it ran many programs just fine out of the box, so it's come a long way since the previous time I tried it.

It's taken a long time for Linux to support NTFS fully as well. Not surprisingly, ReactOS has taken some time also. I think that's fair enough, unless you particularly enjoy filesystem corruption.

Could someone explain why this is a particularly difficult technical problem?

I think from the book "Show Stopper! The Breakneck Race to Create Windows NT and the Next Generation at Microsoft" by G. Pascal Zachary he mentions that NTFS was developed by an intern for the Microsoft PC system, on hardware that wasn't entirely finished, so, inexperienced file system developer + raw unbaked hardware + time pressures. This is going on an old memory, I haven't read that book since the late 90's.

Also throw in the fact that its proprietary and there is no specification or official test suite that I'm aware of outside of Microsoft.

I believe the idea is to provide an alternative to older versions of Windows. There's legacy apps running on top of those. Open source Windows compatible OS with support for modern hardware might be interesting.

I don't think the goal is to be an alternative to Windows. There are many situations where you might want to run Windows apps but don't need everything Windows has to offer. Like others have mentioned, supporting legacy apps is one example of this. There is also research value in having a Windows-compatible OS which is open source.

Which is why we have WINE. There's no reason for ReactOS to exist, especially considering the speed at which it develops.

WINE and ReactOS have been known to share code, in both directions. It's not a zero-sum game.

There are some legacy industrial software we had to keep (for cost reasons) that run on ReactOS with little to no configuration changes that completely break in WINE or run glacially slow on compatibility mode on Windows 7.

So how does wine handles Windows drivers?

That was my impression in 2011 already. Back then I wrote a blog post (in my then-much-worse English) with, admittedly, a bit of Microsoft hatred[1]. However, most of the points I mention are still valid, I think. Of course there have been new releases since 2011, but nothing exactly groundbreaking, at least in the eye of a casual follower like me. Relatively recently, they have run a IndieGoGo campaign and have made this[2], but to be honest (and I admit I haven't looked very deep), as a first impression, it seems it is more the result of web development, design and social media work, than work on the hard part, i.e. the operating system itself. It'd be nice if someone could clarify whether that's really the case.

As others have mentioned, perhaps the idea is to offer support for legacy software on newer hardware, when that software doesn't need everything Windows has to offer... but I'm not sure how big is the audience for that, if one takes into account that some of the need is fulfilled by running Windows XP in a VM, using Microsoft's own tools for legacy compatibility ("compatibility mode" has solved all the compatibility problems I've had so far, but then again, I'm not a heavy user of such functionality), or running XP on real hardware (isolated and where applicable; it's not like Windows XP won't run on modern hardware, except possibly due to UEFI, or the like, and in that case I doubt ReactOS is of much help either).

[1] http://gbl08ma.com/reactos-will-they-ever-get-somewhere/

[2] http://community.reactos.org/

It is nice to see that ReactOS are still developing, but I think that their time to make a big impression was 7 years ago. The world has moved on from being a Microsoft-centric place.

Perhaps if the Chinese or Russians decided to use it as an alternative OS, it would have worked?

Considering the swath of (mostly pirated) XP installs still floating around China[1], I wonder if many of them would be willing to try this instead. Most of their apps should run just fine too.

[1] http://www.pcworld.com/article/2103680/chinas-windows-xp-use...

Apart from being able to run legacy software, wouldn't it being open-source be of value? I know several people who use Windows because they need the Windows-only software (new or old). With ReactOS they would be able to use those applications with an open-source OS. (Though the pros and cons of open-source can be a separate, credible discussion).

The problem is that the development seems to go too slowly to be something more than a curiosity. It looks outdated and cannot replace Windows in a worplace for the moment and it seems like it will be like that forever. I really want this to succeed but I do not think it will.

> Relatively recently, they have run a IndieGoGo campaign and have made this[2], but to be honest (and I admit I haven't looked very deep), as a first impression, it seems it is more the result of web development, design and social media work, than work on the hard part, i.e. the operating system itself. It'd be nice if someone could clarify whether that's really the case.

I think they made that just to convince people to give them money which is so desperately needed for development. Probably because they previously made a Kickstarter which failed to meet its goals.

What ReactOS needs is some large business to sponsor its development.

While it might be true that ReactOS moves slowly, I love the fact that it's still moving. In the age of Windows 10, OS X and impending mobile domination, there are still people who care about reimplementing Windows NT. I don't know if there are many users out there, but even if there is a single one, working on ReactOS must be gratifying for its developers.

Windows 10 is still a "Windows NT", given the fact that it has an NT kernel.

I would be so happy if I could just get a bug-free open-source NT4. While ReactOS will probably never be a competitor to the most current Windows, surely it will catch up to NT4, given enough time.

I feel the exact same. It feels as though ReactOS, if it is ever released, will serve a similar function FreeDOS[1]. When I first stumbled upon the project, I had really high hopes for it but the development team hasn't made up any ground. They're unable to implement features faster than Microsoft is producing new iterations of their system (and with it, new or updated features). If it ever sees the light of day, I would give it a try but until I see more progress I think I will stick with something I can use now.

[1] https://en.wikipedia.org/wiki/FreeDOS

IMPORTANT INFORMATION.

NTFS support will NOT be included into the upcoming 0.3.17 release. As this support is a bit raw.

The real benefit of ReactOS is things like security and support for legacy proprietary medical applications for hardware interfaces into medical devices that on only run on old Windows machines, that can't be updated anymore.

I wouldn't want to risk legacy proprietary medical applications for hardware interfaces into medical devices to be running on an API re-implementation layer that could easily be missing functionality, quirks and bug-for-bug compatibility.

This.

As for most security cases, the best security is at the network level. Endpoint protection can protect after detection, while a good firewall will burn anything that moves in the wrong way.

The funny thing is that this scenario exists already in the OS/2 software world: http://www.ecomstation.com/

Why? "Legacy" implies "not a moving target." If you know the software you need to run, you can QA your API compatibility layer until it works with exactly that software.

CrossOver Office (the commercial version of Wine) is basically authored by picking particular versions of particular software that they want to get working, and then treating them as unit tests to write code against. When the program works, the library works. No more or less is needed.

I think that the point is that using this method with MS Office is one thing. Using it with medical software is a whole other ballpark. Using the medical software as a black box and 'getting it to run' on ReactOS might not be up to the level of rigor we would expect for a device that someone's life may depend on...

Depends on what your alternatives are. If the medical software isn't going to be rewritten, and the only alternative is an MS OS with a serious bug that's not going to be patched, you start looking around.

I think that the point is that using this method with MS Office is one thing. Using it with medical software is a whole other ballpark.

According to what an ex-coworker told me, you only wish all medical software using Windows as an OS was remotely well maintained, tested, and vetted as MS Office.

Moving to a different platform with possibly unknown compatibility issues could trigger bugs in the code that were lying dormant.

For example, I worked for a company that was still coming across data corruption issues from time to time after a move between a platform where all memory was zeroed by default to Linux (where it isn't). Plenty of places were memory was allocated, and just used without zeroing it, and then jamming the whole thing into a database as a string.

I follow ReactOS and other alternative operating systems like Haiku and AROS to see if they made enough progress to use them to replace Windows.

I'd like to see them at a level where the average person can use a DVD or USB stick and install it on their main PC and get apps for it to do what they want.

They haven't gotten that far yet.

I donated to the ReactOS Indiegogo and Kickstarter campaigns, but they never raised enough money for the Community edition. One feature I did want to see was NTFS support so a LiveCD of ReactOS can run an Antivirus scanner to clean an Infected PC that uses NTFS.

While I agree with other commentors that ReactOS in general is slowly becoming irrelevant, I do believe making NTFS a read and write file system via open source would be a useful addition. I did a hunt a little while ago for ways to read and write NTFS on Linux and Mac, and didn't find many options (commercial or open). The most common response (beyond "reformat!") was to just mount the filesystem in a windows box (or windows running in a VM) and share it over a network connect, which abstracts away the file system, though adds overhead.

(BTW: For mac, I found Tuxera and Paragon, and the "built in" non-supported approach to writing NTFS. For linux, NTFS-3G (with proper fuse support) was the go to, but I found corruption under load in my minimal tests, which probably reflect my setup and lack of experience more than problems with the software)

Have you guys found preferred ways to R/W mount an NTFS volume or partition or USB drive without having to do a network mount for Linux or MacOS? Could this work in ReactOS become the seed? Or is considered a solved problem?

Try ntfs3g, it works like a charm. http://www.tuxera.com/community/ntfs-3g-download/

Yeah I haven't had this problem since at least 2010. NTFS3g should be preinstalled on Ubuntu. Not sure about other distros/Mac, though.

Nice, speed, memory and performance wise is ReactOS more efficient then XP or nlited XP on virtualbox or qemu? For example, if efficient you could run it on a cheap android tablet onder bochs, qemu or dosbox and use it as a workstation if lxde/xfce linux would not be good enough.

Runs smooth, but I had problems getting VirtualBox to connect to the internet, so I couldn't do any serious testing. Installation took less than a minute (not kidding).

I've been seeing this project since around 1999 or something. It was listed on a page of emulators and open source OSes that I visited frequently. Glad to see that it's still alive.

Is this infringing on any of Microsoft's patents? And if not, why is Microsoft allowed to collect royalties from Android OEMs who support the FAT file system?

You are allowed to do anything. Microsoft tried to collect royalties and OEMs let them. You could try too. Good luck!

It's quite possibly infringing, but it's unlikely to become a target for a lawsuit unless it starts making a lot of money or starts hurting a good percentage of sales of MS products.

Reply on news.ycombinator.com