The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at 3a3ef631d1
The driver is written by Lee Jae-Hong, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11040
The upstream driver is not maintained and the file system itself
is in a semi-abandoned state.
Originally imported at e308102f4a
The driver is written by Mark W Piper, updated by Bo Brantén.
ReactOS porting made by Peter Hater and Pierre Schweitzer.
Follow updates at http://www.acc.umu.se/~bosse/
FS Recognizer code is left to keep the FS support as an
installable driver.
CORE-11005
MUI entries can have the same ID pointed by TextID member of MUI_ENTRY structure. For this matter, altering a certain entry such as deleting a portion of text with MUIClearStyledText() only removes that portion of text when the given ID argument and the retrieved ID match.
However, MUIClearStyledText() only removes the first instance of text in the console leaving other entries with the same ID as is. Therefore we must ensure that we also iterate over other entries with the same ID as well. Besides the aforementioned function, do the same with MUIClearText(), MUISetText() and MUISetStyledText() too.
CORE-17545
Fix Clang warning:
base/setup/usetup/lang/de-DE.h:1099:24: warning: illegal character encoding in string literal [-Winvalid-source-encoding]
"die Partition <E4>ndern, die derzeit als aktiv markiert ist.",
^~~~
Instead of PlugPlayControlResetDevice, PlugPlayControlStartDevice should
be used for a newly installed device.
For usetup, add a device status check before starting attempt, so we're
not touching devices which are already started.
CORE-17463 CORE-17490
The AsciiChar of the ESCAPE key should be 0x1B instead of zero; however
this is not the case due to the hacked keyboard layout currently being
used. This will be fixed later ...
- Use NT values for uninitialized handle values.
- Cache the STD_INPUT_HANDLE.
- Free the console if GetConsoleScreenBufferInfo() fails in CONSOLE_Init().
- Use PnP storage class drivers
- Make partmgr an upper filter driver for Disk class
- Fill upper filters in txtsetup and usetup/devinst
- Add cdrom driver to the critical device database
CORE-6264
Add two hacks in UpdateDiskLayout() and WritePartitions() so that the
disk partition style is consistently set to a known value MBR, especially
when that disk was previously new and uninitialized (RAW).
A proper fix will be developed later when support for GPT is added.
so that they wrap the needed init steps for formatting/chkdsk'ing.
These helpers now accept a PPARTENTRY, together with the usual
formatting/chkdsk parameters. The helpers now determine the actual
NT path to use, and can perform the init steps on the partition
before performing the actual operation.
In particular, FormatPartition() is now made GPT-compliant. The
partition type retrieved by FileSystemToMBRPartitionType() is now
used as a hint for choosing FAT32 over FAT12/16, and only in the
case of a MBR partition that is *NOT* a recognized OEM partition,
it is used for updating the corresponding partition type. (OEM
partitions must retain their original type.)
The OEM partition types we (and NT) can recognize are specified
e.g. in the Microsoft Open-Specification [MS-DMRP] Appendix B
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-dmrp/5f5043a3-9e6d-40cc-a05b-1a4a3617df32
Introduce an IsOEMPartition() macro to help checking for these types
(its name is based on the Is***Partition() macros from ntdddisk.h,
and from a dmdskmgr.dll export of similar name).
Instead of providing an MBR partition type to InferFileSystem(), make
it call IOCTL_DISK_GET_PARTITION_INFO(_EX) to determine whether the
partition pointed by the path/handle is MBR or GPT. Then, only if it's
MBR, we retrieve its partition type in order to "guess" an adequate file
system name, in case the latter was not recognized already via regular
ways (via GetFileSystemName() / NtQueryVolumeInformationFile()).
- Remove the GetFileSystemNameByHandle() and InferFileSystemByHandle()
functions. Instead, make the other GetFileSystemName*() and
InferFileSystem*() functions accept a HANDLE as an alternative to the
already-existing partition path string. These parameters are exclusive
to each other.
- Rename SetPartitionType() -> SetMBRPartitionType(),
and FileSystemToPartitionType() -> FileSystemToMBRPartitionType()
in order to really clarify what they do (since this code is meant
for MBR partitions only, not GPT ones).
[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.
The formatter will select it anyway as soon as the partition size
permits it. We make it available internally however so as to "emulate"
FMIFS functionality.
Now rely on the partition filesystem for InstallVBRToPartition() instead
of the unreliable and deprecated partition type.
- Move the actual VBR bootcode installation helpers into fsutil.c
(they depend on the selected filesystem).
- Introduce InstallBootCodeToDisk() and InstallBootCodeToFile()
and bootcode.c helpers, in order to replace the several functions
that were duplicating the same code.
CORE-17312
Hide everything under the same foreground & background colors, so that
the actual color and text blanking reset does not create a visual "blinking".
Then, blank the text and finally reset the actual foreground &
background colors.
We do this because we cannot do the screen scrolling trick that would
allow to change both the text and the colors at the same time (the
function is currently not available in our console "emulation" layer).
Dedicated to the hard work of Joachim Henze! xD
This reverts part of commit 043a98dd (see also commit b2aeafca).
Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:
- the events must be treated from the oldest to the newest ones, for
consistency, otherwise this creates problems, as shown by e.g. CORE-16103;
- the system singled-linked lists only offer access to the top of the
list (like a stack) instead of to both the top and the bottom of the
list, as would be required for a queue. Using the SLISTs would mean
that only the newest-received events would be treated first, while the
oldest (which were the first received) events would be treated last,
and this is wrong.
Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.
Translations for:
- Applications: clipbrd, dxdiag, rapps,
- cmdutils: attrib, find, help, label, reg, xcopy
- usetup
- dlls: browseui, shell32, syssetup
- Add Spanish translation for Accesibility Utility (utilman).
Update for the "Choose product options" strings in syssetup:
Originally "ProductType" and "ProductSuite" (typesetted without spaces) were the registry value names where these settings would go, but since it's meaningless to show these values it's better instead to use human-readable names with correct translation and spacing.
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
Updating translation for:
notepad, reactos, usetup, explorer, netshell, msgina, setupapi, shell32.
- Complete and Fix the SPANISH TRANSLATION on Setup
- Correct the random names, fixing the denominations, translate of the English words, and fixing random and incorrect denominations like "Cabinet" or "distribuciones".
- Fixed the notepad shortcuts of "Save" (Ctrl+g) and "Replace".
Correct the random names, fixing the denominations, translate of the English words, and fixing random and incorrect denominations like "Cabinet" or "distribuciones".
This PR enables the developers to include the CJK standard fonts into ReactOS by adding them in Folder modules/optional. This feature is for test purpose only. You may not use the fonts illegally.
The embeddable font files are: mingliu.ttc, simsun.ttc, mssong.ttf, msgothic.ttc, msmincho.ttc, gulim.ttc and batang.ttc.
CORE-9619
CORE-12683
Supersedes PR #612.
* [USETUP] Implement the internal MUI routines for text manipulation based on its ID and implement text resource based IDs
USETUP (the 1st stage text mode setup module) bases upon MUI (Multilingual User Interface) sub-component of USETUP which is responsible for the ability into translating the MUI pages (each page having corresponding properties like X, Y coordinates, text flags and text string buffer) in various languages.
The only problem, as of now, is that whenever you want to modify a certain property of a page, such as removing a text from the said page in the screen, you've got to rely on using CONSOLE_* specific functions and calling with hardcoded parameters, namely the coordinates.
This can become a problem as not every localized (translated) MUI page has the same properties for each language and this could lead to various issues. Therefore, assigning each entry with an ID you can remove a text by only giving its ID (and the entry page number) without having the need to specify the coordinates
as the internal MUI routine, MUIGetEntry(), automatically retrieves the entry with respective data fields.
The following commit implements:
- MUIGetEntry()
- MUIClearText()
- MUIClearStyledText()
- MUISetText()
- MUISetStyledText()
- Now the X and Y coordinate members of MUI_ENTRY are of SHORT integer type, for the sake of the general code as most of the coordination values, even the COORD structure itself, has the coordination points as SHORTs and not BYTEs.
The following MUI functions will be used to manipulate text based resources depending on their ID from the corresponding MUI entry.
* [USETUP] Make CONSOLE_ClearTextXY function public so that we can use across other files.
* [USETUP] Implement the IDs for each text MUI entry in locale files.
This mechanism follows the same principle of resource IDs in Win32 applications. Static text is merely a resource that doesn't get changed programmatically for whole of its lifetime whereas dynamic resources can change during the lifetime of the program depending on the algorithm (for example, hide that piece of text and set another one, etc.).
* [USETUP] Remove the "Press ENTER to continue" message prompt when the partition formatting begins.
CORE-15901
This fixes display reset transition when an external module acquired
INBV ownership and then released it, similarly to what was done in
commit 0ad65796 for VIDEOPRT.
For this a backup screenbuffer is used to store the contents of the
screen just before an INBV screen acquire transition, and these contents
are restored when it is detected that INBV ownership has been released.
Also, the active text font associated with the active console code-page
is restored, as well as the cursor state and shape.
In addition, any user of BLUE.SYS is now required to explicitly issue
a new IOCTL_CONSOLE_RESET_SCREEN to either enable or disable the screen.
This allows avoiding nasty unwanted screen mode switches when a handle
to the \Device\BlueScreen device is opened but no screen mode switch was
actually wanted - This "fixes" this annoyance on ReactOS and Windows,
when these are running witha VGA-compatible video driver and one wants
to look at properties of the \Device\BlueScreen device using
Sysinternals' WinObj.
Following this, we don't need to check anymore for explicit INBV
ownership by issuing calls to InbvCheckDisplayOwnership(), but instead
we check whether the screen has beeen manually enabled using the
aforementioned IOCTL. This partly supersedes commit 8b553a4b, and allows
fixing the second bug, namely that if we start ReactOS without the
/NOGUIBOOT option (and thus, INBV is active during boot), USETUP would
not show up anything because BLUE.SYS wouldn't display anything on screen.
See CORE-15901.
[USETUP][CONSRV] Call IOCTL_CONSOLE_RESET_SCREEN to tell BlueScreen device to enable the screen.
CORE-16274
SETUPLIB:
=========
- Find the system partition initially when we create the list of
partitions.
- Split the old CheckActiveSystemPartition() helper in two helpers:
FindSupportedSystemPartition() and SetActivePartition(). This allows
simplifying slightly the former one, and allows the user, in an
interactive situation, to decide whether the "supported system
partition" found can actually be used or not.
- Remove the "OriginalSystemPartition" hack in the PARTLIST structure.
- Add a note regarding the SystemPartition member in PARTLIST.
USETUP:
=======
- Use the introduced helpers from above. If the "system" partition we
are going to use, in case we install ReactOS on a fixed disk, is *NOT*
the same as the original one (e.g. because it is detected to be not
supported by ReactOS...), display an informative screen to the user
and let him confirm whether or not he wants to change the partition.
If we install on a fixed disk, try to find a supported system partition
on the system. Otherwise if we install on a removable disk, use the
install partition as the system partition instead.
This allows providing a fix for CORE-16274.
SETUPLIB:
=========
- Remove useless HiddenSectors member in PARTENTRY structure.
- InsertDiskRegion() helper returns a BOOLEAN success.
- CreateInsertBlankRegion() helper sets LogicalPartition.
- Simplify the InitializePartitionEntry() helper so that its PartEntry
parameter is clearly the one that is being initialized (i.e. converted
from a blank region to) an actual partition, and use the helper
CreateInsertBlankRegion(). The calculations for the StartSector and
SectorCount are exactly equivalent with the old version of this
function. Also make it return a BOOLEAN success instead.
+ Add some extra validation checks.
+ Adjust CreatePrimaryPartition(), CreateExtendedPartition() and
CreateLogicalPartition() in this regard.
- Better handling of "RAW"-mounted partitions: treat them as
"Unformatted" only if they are RAW *AND* their PartitionType is one of
those associated with FAT file-system. Otherwise we cannot decide
whether they are indeed unformatted or have an unknown file-system on
them, therefore treat them as the latter.
In this regard, the IsSupportedActivePartition() helper should not
look for FileSystem == RAW but instead only look whether the partition
is Unformatted.
This should help with situations similar to the one described in CORE-16274
where a partition with a genuine file-system but not recognized by
ReactOS (because we currently do not have the EXT2/3/4 filesystem
driver loaded during 1st-stage setup due to commit 5a650f6b) and
therefore mounted as RAW, was thought to be unformatted.
USETUP:
=======
- Use the "global" SystemPartition pointer: this is the "system"
partition we will actually use. It can be different from the actual
one of the computer, for example when we install ReactOS on a
removable disk. This allows also to simplify the code.
- Remove the single-used DestinationDriveLetter variable.
- Remove BuildInstallPaths() helper and use InitDestinationPaths()
directly instead.
- Always mention the disk where the partition being formatted is.
- Cleanup old code comments, add assertions here & there...
Helvetica must be font substitute to Arial font.
- Change some Helvetica substitutes to "Arial" from "Liberation Sans". Not all Helvetica. Some languages are lacking support.
Add "Lucida Console" fonts. CORE-16264
- Add "Lucida Console" font by duplicating "DejaVu Sans Mono" font and renaming it.
- Delete some "Lucida Console" font substitutes.
- Add LICENSE file.
I used FontForge to rename it. Its family name is "Lucida Console". Its display name is "Lucida Console". Its font filename is lucon.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add "Trebuchet MS" fonts. CORE-16272
- Add "Trebuchet MS", "Trebuchet MS Bold", "Trebuchet MS Bold Italic" and "Trebuchet MS Italic" fonts by duplicating "Open Sans" fonts and renaming them.
- Delete some "Trebuchet MS" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Trebuchet MS". Their display names are "Trebuchet MS", "Trebuchet MS Bold", "Trebuchet MS Bold Italic" and "Trebuchet MS Italic". Their font filenames are trebuc.ttf, trebucbd.ttf, trebucbi.ttf and trebucit.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add "Times New Roman" fonts. CORE-16272
- Add "Times New Roman" and "Times New Roman Italic" fonts by duplicating "Liberation Serif" fonts and renaming them.
- Delete some "Times New Roman" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Times New Roman". Their display names are "Times New Roman", "Times New Roman Bold", "Times New Roman Bold Italic" and "Times New Roman Italic". Their font filenames are times.ttf, timesbd.ttf, timesbi.ttf and timesi.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add "Franklin Gothic Medium" fonts. CORE-16272
- Add "Franklin Gothic Medium" and "Franklin Gothic Medium Italic" fonts by duplicating Alexei Vanyashin's "Libre Franklin" fonts and renaming them.
- Delete some "Franklin Gothic Medium" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Franklin Gothic Medium". Their display names are "Franklin Gothic Medium" and "Franklin Gothic Medium Italic". Their font filenames are framd.ttf and framdit.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Alexei Vanyashin's "Libre Franklin" fonts are available at https://github.com/alexeiva/Libre-Franklin .
Add "Palatino Linotype" fonts. CORE-16272
- Add "Palatino Linotype", "Palatino Linotype Bold", "Palatino Linotype Bold Italic" and "Palatino Linotype Italic" fonts by duplicating "DejaVu Serif" fonts and renaming them.
- Delete some "Palatino Linotype" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Palatino Linotype". Their display names are "Palatino Linotype", "Palatino Linotype Bold", "Palatino Linotype Bold Italic" and "Palatino Linotype Italic". Their font filenames are pala.ttf, palab.ttf, palabi.ttf and palai.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add "Geogia" fonts. CORE-16272
- Add "Geogia", "Geogia Bold", "Geogia Bold Italic" and "Geogia Italic" fonts by duplicating FreeSerif fonts and renaming them.
- Delete some "Geogia" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Geogia". Their display names are "Geogia", "Geogia Bold", "Geogia Bold Italic" and "Geogia Italic". Their font filenames are georgia.ttf, georgiab.ttf, georgiaz.ttf and georgiai.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add "Courier New" fonts. CORE-16272
- Add "Courier New", "Courier New Bold", "Courier New Bold Italic" and "Courier New Italic" fonts by duplicating FreeMono fonts and renaming them.
- Delete some "Courier New" font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Courier New". Their display names are "Courier New", "Courier New Bold", "Courier New Bold Italic" and "Courier New Italic". Their font filenames are cour.ttf, courbd.ttf, courbi.ttf and couri.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
Add Arial fonts. CORE-16272
- Add "Arial", "Arial Bold", "Arial Bold Italic" and "Arial Italic" fonts by duplicating Liberation Sans fonts and renaming them.
- Disable some Arial font substitutes.
- Add LICENSE file.
I made these font files by using FontForge. Their family name is "Arial". Their display names are "Arial", "Arial Bold", "Arial Bold Italic" and "Arial Italic". Their font filenames are arial.ttf, arialbd.ttf, arialbi.ttf and ariali.ttf. The Underline Positions are hacked by adding an integer value for workaround of FontForge's bug.
By removing font substitution for 'Microsoft Sans Serif'.
Thanks to the patches author Katayama Hirofumi MZ.
This is a partial revert of the guilty rev
master guilty 0.4.13-dev-9-g
811faed421
RC guilty 0.4.12-RC-13-g
8d3def0529
VBox test result:
https://reactos.org/testman/compare.php?ids=68497,68499
The same fix has been applied before to 0.4.12-RC-44-g
ca0e00e8af
- Windows requires 16 bytes of response data.
- Add the PLUGPLAY_CONTROL_USER_RESPONSE_DATA type.
- Usetup and Umpnpmgr must fail if NtPlugPlayControl(PlugPlayControlUserResponse) does not return STATUS_SUCCESS.
Fixes GCC 8 warning:
base/setup/usetup/usetup.c:3407:78: error: '%S' directive writing up to 521 bytes into a region of size 200 [-Werror=format-overflow=]
"Setup is currently unable to check a partition formatted in %S.\n"
^~
base/setup/usetup/usetup.c:3406:9: note: 'sprintf' output between 128 and 649 bytes into a destination of size 260
sprintf(Buffer,
^~~~~~~~~~~~~~~
"Setup is currently unable to check a partition formatted in %S.\n"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"\n"
~~~~
" \x07 Press ENTER to continue Setup.\n"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
" \x07 Press F3 to quit Setup.",
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PartEntry->FileSystem);
~~~~~~~~~~~~~~~~~~~~~~
Eliminate some bugs about font enumeration. CORE-15755
- Add "Microsoft Sans Serif" font substitution.
- Fix and improve the treatment of the nominal font names.
- Split IntGetFontFamilyInfo function from NtGdiGetFontFamilyInfo.
- Add DoFontSystemUnittest function for font system unittest to GDI32.
- Call DoFontSystemUnittest function at CreateFontIndirectW first call.
Nowadays more and more people try to install ReactOS from removable
drives (e.g. USB sticks) onto fixed HDDs, or try to install it into
USB sticks too.
Both fixed and removable drives, as well as partitions on these, are
represented in NT using the same device name format:
\Device\HarddiskM\PartitionN ,
with an increasing disk number M. Using this number for building the
corresponding firmware-specific ARC multi(x)disk(y)rdisk(z) path used
by the NT/ROS loader (FreeLdr, ...) is then prone to error since there
may have been removable drives inserted and accounted for in the
calculation of the disk number. These drives must be correctly
subtracted in order to generate the correct ARC path, valid once all
the removable drives have been ejected (which should also be the
situation seen from the BIOS when booting up, except of course if you
boot on a USB stick).
This problem is now solved. Note that it matters only for the disks
that have also been enumerated by the firmware (BIOS; Int 13h). We
don't have to care about the other drives, since the ARC path will be
of a different format and will not use the disk number (instead, the
SCSI coordinates are used).
We also try to enumerate all the disks found in all the possible disk
adapters and controllers enumerated in the Hardware registry tree
(and that are visible by FreeLdr) in order to cover all.
Finally, we detect whether a disk reports as a "super-floppy", i.e.
an unpartitioned disk with a valid VBR. This is indeed how a standard
floppy disk looks like, or how USB sticks are partitioned on Windows.
Such disk is reported has having only one single partition starting at
the beginning of the disk, with partition number == 0, its type being
FAT16 non-bootable.
This allows us to forbid creating any new partitions on such disks.
Note that accessing either \Device\HarddiskN\Partition0 or Partition1
on such a disk returns the same data.
Note also that on the contrary, regular MBR-partitioned disks would
report at least four partitions entries, instead of just one.
The other improvements are:
- Do *NOT* write any MBR on a disk partitioned as "super-floppy".
CORE-13703
- Fix the computed disk identifier, of format: %08x-%08x-%c .
The numbers are respectively the checksum of the first sector, and
the disk signature. The terminating letter is A or X, depending
whether the first sector ends with 0x55AA/0xAA55 or not (see also
commit 5053f1f5).
- Warn if the user attempts to install ReactOS on a disk that is not
visible by the firmware of his computer, because it may not be
bootable.
- Add also some validation ASSERTs and simplify the code here and there.
- The installation partition is called "InstallPartition", while the
global "CurrentPartition" is the disk region currently selected in
the partition UI list, on which prtitioning operations are effectued.
- Extend CheckActiveSystemPartition() to use an optional alternative
disk or partition in case the actual system partition (present in the
first disk) cannot be used, e.g. because we don't support writes on it.
- Find or set the active system partition only once, when we start the
formatting stage. If the system partition is to be created in some
non-partitioned space, we create it.
- A file-system check is always scheduled for both the system and the
installation partitions.
- If the system partition was already formatted (which usually means
that it already existed on the system), don't ask for formatting it.
CORE-13205
- For each partition to be formatted, the file-system menu list is
re-created, in order to display only the FSes that are compatible
with the selected partition, and allow to give the user the choice
to keep the existing file-system only if the selected partition was
already formatted.
- Check whether the user attempts to delete the partition on which
the installation source is present, only if it is not "new" and is
formatted.
- Check first whether the current partition is the system partition,
before displaying the CONFIRM_DELETE_SYSTEM_PARTITION_PAGE.
- Make some partitioning functions not dependent on the selected "CurrentPartition".
- Add some sanity checks.
- Improve some of the "is-partitioned" checks.
Similarly to FMIFS this structure should be private. Instead file-system
names are passed to the helper functions, allowing to use the names
returned by the FS drivers. The names are then internally mapped to the
corresponding FS providers.
In particular this allows to handle the "RAW" file-system and to assign
the 'Unformatted' flag to partitions having this FS.
Finally this helps us refining the checks performed to see whether the
current "active" system partition uses a supported file-system.
- Within the function's body code, check the status values returned by the called functions.
- Change the BuildInstallPaths's function type to NTSTATUS instead of VOID (and check the status of InitDestinationPaths() as well.
By default, we still fallback to FAT if nothing asked, or if there
is an invalid input.
0 is FAT, 1 is BtrFS. This can be grown as soon as we add more IFS.
[REG][REACTOS][EXPLORER][APPWIZ][CONSOLE][INETCPL][INPUT]
[INTL][OPENGLCFG][TIMEDATE][DEVCPUX][COMCTL32][COMDLG32]
[MSGINA][NETCFGX][NETID][SETUPAPI][SHELL32][SYSSETUP]
Update Simplified and Traditional Chinese translations.
- The converter is code7bit I made. code7bit: https://github.com/katahiromz/code7bit
- This converter converts non-clean characters in string literals.
- However I couldn't erase a ton of codepage C4819 warnings.
- CORE-15447
You can edit an European source file as follows:
- Right click the file in the Solution Explorer.
- Select "Open With...".
- Choose "C++ Source Code Editor (with encoding)".
- Choose "Central European (Windows) - Codepage 1260".
- Add checks for GPT disks and either fail or ignore the disk,
depending on the operation being executed.
[USETUP][REACTOS] Display the disk style more accurately.
CORE-7749
- Correctly insert discovered partitions in sorted order of StartSector,
and verify that they do not overlap (-> check for broken partitioning).
May help for CORE-10898.
- Use the correct reported partition numbers that may be modified after
partitioning changes, and that need to be used when opening
\Device\Harddisk'M'\Partition'N' files. This is achieving by
retrieving the returned value of the IOCTL_DISK_SET_DRIVE_LAYOUT call.
Distinguish them from the "on-disk" partition numbers that are the ones
that enumerate the partition in partition-table order (and is the order
known by e.g. the BIOS), and that should be used to construct the
destination ARC path.
May help for CORE-4870, CORE-13205.
- Simplify a lot of duplicated code by using helper functions.
Always perform the partition validity checks when creating new
primary/extended/logical partitions, and also when a new partition
is automatically created when unpartitioned space is selected for
ReactOS installation.
CORE-12246
This will allow compatibility with modern OSes and
modern disk management utilities.
It will also improve performances by properly aligning
partition start.
And it will let enough room at the begin of the disk
for 3rd party bootloaders.
WARNING: this is not compatible with previous partition
model, and old one will likely not be compatible. You'll
have to erase your whole partition table and start from
scratch.
Simplified implementation of the proposed solution by George Bișoc
and revised by Victor Perevertkin from PR #952.
NOTE: For whatever reason ERROR_INSTALL_BOOTCODE and ERROR_WRITE_BOOT
seem to be redundant with each other. To be investigated...
Most of Linux filesystems have the MBR ID assigned as 0x83 and when the user chooses BTRFS upon partitions page wizard, we're thinking of the partition as having Ext2 filesystem which is wrong and misleading.
- Interface the TreeList code and populate it with the list of
discovered disks and partitions. Code is adapted from USETUP.
Also display the names of the disks.
- Display some installation settings summary, before doing the
installation proper.
- Force the user to select a checkbox when (s)he acknowledges that
ReactOS is alpha-quality software and may break on his/her computer
or corrupt his/her data.
- Improve wizard pages transitions and buttons enabling/disabling.
- Press Shift-F10 to start a command-line (as in the 2nd-stage setup
in syssetup.dll).
- Use some explicit UNICODE functions/macros.
Add the TreeList control from Anton Zechner and Sébastien Kirche
from https://github.com/sebkirche/treelist (under GPL-3.0+) as a
*TEMPORARY* solution until a better-suited control for ReactOS is
developed.
- Compilation fixes for the TreeList control.
- SETUPLIB and USETUP: Convert PARTENTRY::DriveLetter to WCHAR.
- SETUPLIB: Retrieve volume label.
- SETUPLIB and USETUP: Move the partition types (IDs) table from
USETUP to SETUPLIB so that they can share it with the 1st-stage
GUI installer too. Also take the opportunity to update the table
with information from http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
and cross-checked with the list from Paragon Hard-Disk Manager.
- USETUP: Simplify PrintPartitionData().
- Add some code comments.
This increases performance for each time the SETUPLIB calls (using NT paths)
Win32 SetupAPI functions which of course only accept Win32 paths.
- Handle also the fact that a NT path to convert may start with
\Device\HarddiskX\PartitionY\..., which can be a symlink to
\Device\HarddiskVolumeN\... on some systems. In that case, the
Win32 path mapping should be done slightly differently.
- Add support for network mapped drives.
- Improve UI usage and wizard transitions (Work In Progress).
- Add interfacing code that display installation status.
- When the user attempts to cancel the installation during file copying,
pause the file copying, and restart it if the user changes it mind and
wants to continue the installation. Otherwise file copying is properly
halted.
- BOOTDATA: Use standard INF signature string, so that they can be
opened successfully using ReactOS' or Windows' setupapi.dll with
the INF_STYLE_WIN4 style.
- SETUPLIB: Use the correct INF_STYLE_* INF styles in SpInfOpenInfFile() calls.
- REACTOS : Switch thread locale to user-specified LocaleId when calling
SetupOpenInfFileW(), so that the correct localized strings are used.
- In PrepareCopyInfFile(), explicitly use AddSectionToCopyQueueCab()
to retrieve the files from the CAB INF.
Otherwise if one continued to use and rely on AddSectionToCopyQueue()
to do this job instead, bad things could happen like, re-enumerating
twice or more (and adding them to the file queue) the same files.
This is because in the new code AddSectionToCopyQueue() can be called
many times to deal with different SIF file sections. The old code then
called AddSectionToCopyQueueCab() in turn, but on the same list...
Now the steps performed are clear, and everything works as intended.
- Simplify the code that computes the full source and destination paths
for the files to be copied and directories to be created, using helper
functions.
- Compute the source file and target location from the TXTSETUP.SIF
entries in a NT-compatible manner.
- Use adequate access flag when opening symbolic links.
- Simplify the prototype of UpdateRegistry() since now both Setup INF
handle and settings lists are inside the USETUP_DATA structure.
This means, call in the correct order the user callback with the correct
parameters (in particular the correct paths for file copy operations),
and check also for the callback returned value to know whether or not to
continue the file operations.
This allows using some of the SetupApi.dll functions when SETUPLIB is
used in the (Win32) GUI 1st-stage installer "REACTOS", while using the
custom implemented NT-aware functions in "USETUP".
- Add support for delete and move/rename operations, which are needed
for implementing ReactOS upgrading support.
- Use cabinet contexts.
- Use standard LIST_ENTRY structures for implementing the lists.
- Move the path-building hack code in SetupCommitFileQueueW() that had
been introduced in r66604 (97bb83f) out of the file-queues code.
- Make the function prototypes compatible with win32's setupapi functions.
- Fix the format of the data passed to the custom notification handler.
- Adjust the file-copy callback to correctly use its arguments (setupapi-compatible).
- Move a great deal of global variables into the USETUP_DATA structure
(the SetupInf, the SetupFileQueue, the generic lists...).
- Place the common setup initialization code into an InitializeSetup()
routine, and the cleanup code into FinishSetup().
- Implement the setup-code part support for the TXTSETUP.SIF setup
source path override variables "SetupSourceDevice" and "SetupSourcePath"
(see CORE-9023); support for them in SETUPLDR will be added later.
- In the 1st-stage GUI setup, display the list of existing discovered
NTOS installations, with its name, installation path and vendor name,
and an associated icon.
svn path=/branches/setup_improvements/; revision=75544
[SETUP:REACTOS] More interfacing of the 1st-stage GUI installer with the setuplib.
- Add a ConvertNtPathToWin32Path() helper function that allows converting
NT paths like: \Device\CdRom0\i386\txtsetup.sif file into a Win32 path
that the Win32 versions of the SetupApi functions (e.g. SetupOpenInfFileW)
can accept.
Note that RtlNtPathNameToDosPathName() cannot be used here because this
function only works for NT paths within the \DosDevices\ (or \??\) NTObj
directory, and not in other directories.
- Use this helper function in the implementation of SetupOpenInfFileExW.
Now the txtsetup.sif function can be loaded by setuplib *when being used*
by the 1st-stage GUI installer!
- Remove deprecated code.
svn path=/branches/setup_improvements/; revision=75668
svn path=/branches/setup_improvements/; revision=75721
svn path=/branches/setup_improvements/; revision=75750
