Revision tags: 0.4.14-release |
|
#
34593d93 |
| 11-Jun-2021 |
Victor Perevertkin <victor.perevertkin@reactos.org> |
[FORMATTING][NTOS][HAL][DRIVERS][SDK] Fix trailing spaces
|
#
8d3e80e4 |
| 22-Nov-2020 |
Hermès Bélusca-Maïto <hermes.belusca-maito@reactos.org> |
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions.
[AUTOCHK] Add also support for scanning FATX volumes.
The Format()
[FSLIB][FMIFS][AUTOCHK][SETUPLIB] Use more Windows-compatible (but not fully compatible yet) Format() and Chkdsk() ULIB functions.
[AUTOCHK] Add also support for scanning FATX volumes.
The Format(), FormatEx(), Chkdsk(), ChkdskEx() functions exposed by the U*.DLL user-mode FS library dlls are different (and have different prototypes) than the similarly-named functions exported by FMIFS.DLL .
In particular, what we used to call "xxxChkdskEx()" and "xxxFormatEx()" in our U*.DLL libraries actually correspond more, from their arguments, to the "Chkdsk()" and "Format()" functions in Windows' U*.DLL . Their *Ex() counterparts instead take most of the parameters through a structure passed by pointer.
On FMIFS.DLL side, while FMIFS!Chkdsk() calls U*.DLL!Chkdsk() and FMIFS!ChkdskEx() calls U*.DLL!ChkdskEx() (and we do not implement these *Ex() functions at the moment), both FMIFS!Format() and FMIFS!FormatEx() call U*.DLL!Format() instead, while FMIFS!FormatEx2() calls U*.DLL!FormatEx() (that we do not implement yet either) !!
To improve that, refactor the calls to these U*.DLL functions so as to respect the more compatible prototypes: They contain the correct number of parameters in a compatible order. However, some of the parameters do not have the same types yet: the strings are kept here in PUNICODE_STRINGS, while on Windows they are passed via an undocumented DSTRING struct, and the FMIFS callback is instead a MESSAGE struct/class on Windows. Finally, the MEDIA_TYPE parameter in U*.DLL!Format() is equivalent, yet not fully 100% in 1-to-1 correspondence, with the FMIFS_MEDIA_FLAG used in the corresponding FMIFS.DLL functions.
One thing to notice is that the U*.DLL!Format() (and the Ex) functions support a BOOLEAN (a flag resp.) for telling that a backwards-compatible FS version should be used instead of the (default) latest FS version. This is used e.g. by the FAT FS, where by default FAT32 is selected (depending also on other constraints like, the disk and the partition sizes), unless that bit is set in which case, FAT16 (or 12) is used.
show more ...
|
Revision tags: 0.4.15-dev, 0.4.14-RC, 0.4.13-release, 0.4.14-dev, 0.4.13-RC, 0.4.12-release, 0.4.12-RC, 0.4.13-dev, 0.4.11-release, 0.4.11-RC, 0.4.12-dev, 0.4.10-release, 0.4.11-dev, 0.4.10-RC, 0.4.9-release, 0.4.10-dev, 0.4.9-RC, 0.4.8-release, 0.4.8-RC, 0.4.9-dev, 0.4.7-release, v0.4.7, 0.4.8-dev, 0.4.7-rc1 |
|
#
c2c66aff |
| 03-Oct-2017 |
Colin Finck <colin@reactos.org> |
Git conversion: Make reactos the root directory, move rosapps, rostests, wallpapers into modules, and delete rossubsys.
|
Revision tags: backups/GSoC_2017/rapps@75905, ReactOS-0.4.6, backups/ros-branch-0_4_6@75728, 0.4.7-dev, ReactOS-0.4.5, backups/ros-branch-0_4_5@74569, ReactOS-0.4.4-CLT2017, backups/ReactOS-0.4.4-CLT2017@74182, ReactOS-0.4.4, backups/ros-branch-0_4_4@74002, ReactOS-0.4.4-FOSDEM2017, backups/ReactOS-0.4.4-FOSDEM2017@73667, ReactOS-0.4.3, backups/ros-branch-0_4_3@73437, backups/sndblst@72664, ReactOS-0.4.2, backups/ros-branch-0_4_2@73087, ReactOS-0.4.1, backups/ros-branch-0_4_1@71718 |
|
#
321bcc05 |
| 24-Apr-2016 |
Pierre Schweitzer <pierre@reactos.org> |
Create the AHCI branch for Aman's work
svn path=/branches/GSoC_2016/AHCI/; revision=71203
|