Modify font enumeration code to deal with failure to read the registry key. Also change the registry key being queried to match the one used on Windows. Patch by Ricardo Hanke.
CORE-8203
svn path=/trunk/; revision=65621
* Followup to t65603. Fixes the start menu themeing regression (when running explorer in windows 2003).
CORE-8898 #resolve
svn path=/trunk/; revision=65618
Ach! Wir können noch nicht mit dem ID öffnen!
So far, bail out when we are requested to open a file with its MFT index instead of its name.
nfi triggers this a lot. Likely to be implemented ;-)
CORE-8725
svn path=/trunk/; revision=65613
My dear Pierre, in FSCTL_GET_NTFS_FILE_RECORD, you have METHOD_BUFFERED (yes, read well ;-)).
So if you want it to work, you HAVE to return the size of the data you wrote to the output buffer...
This makes FSCTL_GET_NTFS_FILE_RECORD finally working in ReactOS...
nfi.exe finally goes a bit farther, displays some files names and dies. Definitely still needs love.
CORE-8725
svn path=/trunk/; revision=65612
* Use LoadLibrary instead of GetModuleHandle in the wrapper of WinList_Init.
* Shdocvw was never loaded till that point so WinList_Init was not called.
* Should fix Opening link location in windows.
svn path=/trunk/; revision=65611
* Cleanup variable names and fix a few typos along the way.
* Refactor the start button code into a CStartButton class.
NOTE: There is a known regression with start button themeing, which I'm working on. The missing notification icons are not caused by this.
CORE-8898
svn path=/trunk/; revision=65603
Implement the downward fashion of FSCTL_GET_NTFS_FILE_RECORD and always return a file record which is in use
CORE-8725
svn path=/trunk/; revision=65601
* Make SetWindowStyle and SetWindowExStyle simple wrappers around SHSetWindowBits. There is no reason to reinvent the wheel.
svn path=/trunk/; revision=65599
THE oneliner....
Properly read the information from the IRP to get the reparse tag. This fixes the handling of reparse mount points in ReactOS.
To make it short and crystal clear: reparse points from NTFS now work in ReactOS.
Demonstration with a Windows 7 volume read inside ReactOS with our NTFS driver and the "Documents and Settings" directory pointing to Users.
IopDoNameTransmogrify() properly gets the reparse data and extracts the mount point:
(../../ntoskrnl/io/iomgr/file.c:178) IopDoNameTransmogrify(B074DB98, B022BC28, B0226068)
(../../ntoskrnl/io/iomgr/file.c:232) Old name: '\Documents and Settings\'
(../../ntoskrnl/io/iomgr/file.c:266) Reparsed name: '\??\C:\Users'
Then.... http://www.heisspiter.net/~Pierre/rostests/NTFS_Reparse.png
First, I attempt to open "Documents and Settings" on my NTFS volume, it fails as "C:\" drive is hardcoded in the reparse point.
So, I create the Users directory on C:\ and a dummy file in it.
Then, I cd again which works now.
And dir properly shows the dummy created file :-).
svn path=/trunk/; revision=65596
Fix the implementation of the reparse point handling. This takes into account our $FILE_NAME attribute not being aware it's a reparse point...
We now fully get into Io and fail miserably as it seems I forgot one place where reparse points support has to be added.
D'oh!
svn path=/trunk/; revision=65594
On FCB creation, merge file attributes from $FILE_NAME and from $STANDARD_INFORMATION
Not sure it's fully legal, but it allows us to catch them all!
svn path=/trunk/; revision=65592
- Use a timeout to send WM_COPYDATA.
- Recall reading, while being sent to a thread that is hung indefinitely or blocked, it will not return properly. This seems to be the case for CORE-8779. Play it safe and use a timeout.
svn path=/trunk/; revision=65589
- Implement NtfsReadFCBAttribute() which is responsible for reading an attribute from a file which is referenced by its FCB. It will first read the file record in the MFT and then read the attribute, if found.
- Use NtfsReadFCBAttribute() to implement support for reparse point in NtfsCreateFile(). Once a reparse point is found, we attempt to open its data. Given their layout, we directly hand them to the Io manager. Just make sure that we return something consistent on disk. Only handle IO_REPARSE_TAG_MOUNT_POINT so far.
Next question to answer is: what to do when a reparse point is encountered during path traversal?
svn path=/trunk/; revision=65586
Implement support for (some) reparse points in Io manager. Ob should be already fine.
- Implement the IopDoNameTransmogrify() function. This one is responsible for checking the correct data for the reparse point and to update the path name in the file object. It will also free the memory buffer allocated by the driver to communicate the reparse information.
- Fix the support for reparse points in IopCompleteRequest(). If we receive reparse status + reparse tag we know, we call IopDoNameTransmogrify() to update file objet.
- Fix the support for reparse points in IopParseDevice() (oh! you again? :-)). When we complete the IRP ourselves, act as in IopCompleteRequest(). Then, we properly update objects manipulated by Io for the create request and we return STATUS_REPARSE so that Ob can update and recall us afterwards so that we complete.
Some parts are left unimplemented when it comes to reparse tags which are not IO_REPARSE_TAG_MOUNT_POINT. But still less than previously ;-).
svn path=/trunk/; revision=65584
Replace the old "My Computer" icon with a new one.
New icon by: Ismael Ferreras Morezuelas.
CORE-8890 #resolve #comment Committed in revision r65583. Thanks!
svn path=/trunk/; revision=65583
- Add german resource file.
- Convert all others to UTF-8.
- Add manifest file and modify DOIALOG to DIALOGEX + changing default font to MS Shell Dlg. Hello themed keyboard ^^
TBD: Sizes are WAY too small IMO...
svn path=/trunk/; revision=65572
