EPIC WIN!

[Jedi-to-be]

The Works 8 and Works 9 don't really look like epic wins, do they?

I did not even think about that.

Go to system information. There is a check box for workstation mode. Try the works 9 setup again then.

Trying that now.

Please, fill bug-reports in jira.reactos.org

[Jedi-to-be]

[ external image ]

[henrytang5247]

ReactOS Applications run on Windows 7 SP1 well!

[ external image ]

[EmuandCo]

Anything else would be really shocking ^^ We code a Windows here

[ArmyMan007]

Wait... shouldn't it work the other way around? Meaning working Windows 7 software on ReactOS?

[vicmarcal]

Wait... shouldn't it work the other way around? Meaning working Windows 7 software on ReactOS?

Just if Windows 7 software doesn't use .Net and friends.

[Swyter]

Looks like pschweitzer is sorting out the NTFS bugs at a good rate and now directory listing sort of works.
Pretty impressive if you ask me! This is unbelievable!

The latest commit as of now: http://git.reactos.org/?p=reactos.git;a ... e448935e67
All of the NTFS-related changesets: http://git.reactos.org/?p=reactos.git&a ... %5Bntfs%5D

Code: Select all

[NTFS]
Bugfixing... Part 5/X:
- Actually, we don't care about the name in the file index. We don't need it to read the data attribute, it's unnamed. And the returned name was buggy (this still needs work though)
- When we are getting a file record which is a directory, there is NO data attribute. Don't attempt to read it. This prevents failure on directory entry return.

These fixes enable NTFS directory listing in ReactOS!
Even though, more fixes are required. So far, the metadata of the files are kind of broken. Explorer seems to be unable to list files.
This keeps anyway being a major step forward, as this was totally impossible a month ago ;-).

For these willing to see NTFS in action in ReactOS: http://www.heisspiter.net/~Pierre/rostests/NTFS_listing.png

[ external image ]

[manuel]

Looks like pschweitzer is sorting out the NTFS bugs at a good rate and now directory listing sort of works.
Pretty impressive if you ask me! This is unbelievable!

The latest commit as of now: http://git.reactos.org/?p=reactos.git;a ... e448935e67
All of the NTFS-related changesets: http://git.reactos.org/?p=reactos.git&a ... %5Bntfs%5D

Code: Select all

[NTFS]
Bugfixing... Part 5/X:
- Actually, we don't care about the name in the file index. We don't need it to read the data attribute, it's unnamed. And the returned name was buggy (this still needs work though)
- When we are getting a file record which is a directory, there is NO data attribute. Don't attempt to read it. This prevents failure on directory entry return.

These fixes enable NTFS directory listing in ReactOS!
Even though, more fixes are required. So far, the metadata of the files are kind of broken. Explorer seems to be unable to list files.
This keeps anyway being a major step forward, as this was totally impossible a month ago ;-).

For these willing to see NTFS in action in ReactOS: http://www.heisspiter.net/~Pierre/rostests/NTFS_listing.png

[ external image ]

NTFS work (or partial) in reactos now?

[Black_Fox]

"NTFS directory listing in ReactOS", that means you can say "dir" in a NTFS volume and you will see what's inside. That is how it currently partially works. Anything already implemented is also read-only, this is very basic so far (but it's great that Pierre took up the challenge!).

[Pi_User5]

IceWeasel 3:

[ external image ]

[ external image ]

[fLuXx]

For NTFS progress, I just want to say thank you to Pierre. I know how complicated it is (actually I don't, if I did, I would perhaps be able to help), and I as an individual appreciate the effort you put in it, even if you don't succeed entirely. Thanks!

[Pi_User5]

For NTFS progress, I just want to say thank you to Pierre. I know how complicated it is (actually I don't, if I did, I would perhaps be able to help), and I as an individual appreciate the effort you put in it, even if you don't succeed entirely. Thanks!

Good luck!

[hbelusca]

http://svn.reactos.org/svn/reactos?view ... sion=64836

Author: pschweitzer
Date: Sun Oct 19 21:38:32 2014
New Revision: 64836

URL: http://svn.reactos.org/svn/reactos?rev=64836&view=rev
Log:
[FASTFAT]
- Implement vfatPrepareTargetForRename() that prepares for renaming. It tries to open target and deletes it if it exists and if allowed. And then, it opens the parent directory.
- Implement VfatSetRenameInformation() that actually does the renaming (call as SetInformationFile). It handles cases we we have (or we don't have) TargetDirectory provided. It sends notifications as appropriated on demands.
- Implement vfatRenameEntry() that renames an entry in place. So far, it only supports FATX entries renaming. FAT entries are a bit more complex. It falls back to vfatMoveEntry() in later cases.
- Implement VfatMoveEntry() that will move an entry accross directories (or in place for FAT). Its principles are simple: it deletes the entry in old parent, and recreate it in new parent, keeping file metadata & data.
- Modify VfatDelEntry() and VfatAddEntry() so that they can handle deleting an entry without touching its data and adding an entry with an already provided FCB and thus use the given metadata.
- Implement vfatDelFCBFromTable() which is just old code moved to new routine to allow reuse. It deletes a FCB entry from hash table. Doesn't deal with references!
- Implement vfatMakeFullName() which is mostly old code moved to new routine to allow reuse. It allocates buffer and copy data for FCB full name.
- Implement vfatUpdateFCB() that will update a FCB with new names and parent. It will remove anything related to old name and will recreate using new data. It will adjust references count.
- Modify vfatMakeFCBFromDirEntry() so that it calls vfatMakeFullName().
- Modify vfatReleaseFCB() so that it calls vfatDelFCBFromTable().
- Revert VfatOpenFile() to its previous features.
- Modify VfatCreateFile() to reimplement support for SL_OPEN_TARGET_DIRECTORY. It is way less hackish than previously. It also properly opens parent now, by incrementing its handle count and by setting appropriate access rights.

[KERNEL32]
- Rewritten MoveFileWithProgressW() to implement all the missing features that are used in Windows 2k3 including links and reparse points.
- Implemented BasepMoveFileDelayed() to replace deprecated add_boot_rename_entry(). This functions is matching the features implemented in SMSS.
- Implemented BasepMoveFileCopyProgress() which is used in MoveFileWithProgressW().
- Stubbed BasepNotifyTrackingService() which is not use at the moment (FastFAT, even in Windows doesn't provide such feature).
- Reimplemented ReplaceFileA(), MoveFileWithProgressA() to quit Winisms and use our internal helpers.
- Make MoveFileX() use MoveFileWithProgressX() directly.
- Fixed a few prototypes.

TL;DR:
This (huge) commit implements file and directory renaming in FastFAT driver. This allows getting rid of old implementation in kernel32 where files were force copied.

A feature is still missing, but Jérôme should implement it anytime soon (he prototyped it already): moving directories across volumes. This requires some work in BasepCopyFileExW().

Kudos to all the devs who helped me on this: Christoph, Hervé, Jérôme, Thomas.
This finally allows killing CR-52... It was about time!

Judge by yourselves

[Swyter]

http://svn.reactos.org/svn/reactos?view ... sion=64836

Judge by yourselves :D :D

So many exciting commits lately. Improvements all around, almost daily. :)

[Pi_User5]

UltraISO:

[ external image ]