Addendum to commit 32e6eed760 (r63715)
CORE-5982
The function assumed that the directory path name to be created
always starts with a harddisk-partition root device name of the form:
\Device\HarddiskX\PartitionY\
Indeed, it can be (when using the volume manager) of the form:
\Device\HarddiskVolumeN\
and could even have a different format if trying to install ReactOS
on an external removable drive or other weird device.
Since the format of this prefix is not 100% always the same,
a different way to create the sub-directories is needed.
The nested-directory creation algorithm is changed as follows:
Suppose that the directory to be created is:
\Device\HarddiskVolume1\ReactOS\system32\drivers
The function first loops backwards each path component in order
to find the deepest existing sub-directory: it will try to verify
whether each of the following sub-directories exist, successively:
\Device\HarddiskVolume1\ReactOS\system32\drivers
\Device\HarddiskVolume1\ReactOS\system32\
\Device\HarddiskVolume1\ReactOS\
\Device\HarddiskVolume1\
(Notice the trailing path separators kept in this step.)
In principle, this root device FS directory must exist (since the
volume has been formatted previously). Once found, the function will
then create each of the sub-directories in turn:
\Device\HarddiskVolume1\ReactOS
\Device\HarddiskVolume1\ReactOS\system32
\Device\HarddiskVolume1\ReactOS\system32\drivers
----
An alternative to the fix could be to always specify the root device
name in a separate parameter, but this hasn't been pursued here so as
to not modify all the callers of this function.
It was introduced in commit 703eb5e8c9 (r7756) in order to hack around
the "dot"-path added in the reactos.dff generator file by the earlier
commit 3bd689f185 (r7269).
Its aim was to describe the installation directory itself, instead of
one of its sub-directories.
That _invalid_ "dot"-path was removed later by commit 027e2bfa3a (r15423);
however the '\.' hack stayed for quite a while in our code.
The correct way to describe the installation directory itself is to use
instead "\", compatible with Windows' setup, as was originally done in
txtsetup.sif, and fixed in reactos.dff(.in) in commit 97bb83fcd9 (r66604).
The variadic DisplayMessage(V) helpers display a message box, where
both the title and message can be specified either as explicit strings
or via resource IDs. It also supports the message to be a printf-like
format string, in which case the additional formatting arguments are
subsequently specified.
It will be used to determine how the bootloader has to be installed, etc.
Currently hardcoded for XBOX, or rnutime-determined for NEC PC-98 and BIOS-based PC-AT.
More thorough runtime determination will be added in the future.
Fix a typo in "ジドウテキニ" word: `\274\336\304\336\263\303\306` (ジドウテニ)
that was introduced in 2009 year (commit 379ce6f163).
The word "ジドウテキニ" is "自動的に" in Kanji, means "automatically".
CORE-6149, CORE-6179, CORE-9529
See also commits d329fbebf (r66995), 7c3f4c94a (r68307), and 16daf6700.
The function verifies that each path component of the directory is
a valid 8.3 name, not . or .. nor empty. This behaviour is compatible
with what can be observed from Windows XP/2003 installer.
(To reliably test this with the Windows installer, you need to modify
the TXTSETUP.SIF DefaultPath value in the [SetupData] section.)
Reverts the IsValidPath() move done in commit 9c64b57dc.
- Turn IsValidPath() into a IsValidInstallDirectory() helper function
available in the setuplib, so that it can also be used in the GUI setup.
- Introduce a IS_VALID_INSTALL_PATH_CHAR() macro.
The idea is reminiscent of the SetupCommitFileQueue() function:
filesystem volume operations are "queued" and processed via a
"commit queue".
The commit queue uses a user-specified callback, that is used to
interact with the user whenever an operation (filesystem formatting,
checking) is started, ended, or fails, for example by displaying
appropriate UI screens and choices, etc.
If East Asian people were unable
to see the Latin characters, it
becomes a barrier to mutual
understanding.
FontLink will break that barrier.
JIRA issue: CORE-9616
JIRA issue: CORE-15480
- Modify font substitutes.
- Unify the lock variables.
- Add FONTLINK and
FONTLINK_CHAIN structures.
- Add FontLink_Create and
FontLink_Destroy functions.
- Add FontLink_Chain_Init,
FontLink_Chain_Free,
FontLink_Chain_LoadReg,
FontLink_Chain_Populate, and
FontLink_Chain_FindGlyph
functions.
- Implement FontLink.
- Add font file DroidSansFallback.ttf
for LiveCD.
See commits ebcf3cf38 and c9c6902f0 (PR #5837)
In addition, correctly set the type of extended partition being used,
depending on whether it is contained below or above the 1024-cylinder
boundary (tested on NT).
CORE-19575
For the time being, don't add read-only attribute for ease of testing
and modifying files, but it won't always stay this way.
For example, Windows sets its boot.ini (as well as NTLDR, NTDETECT.COM
etc.) as read-only (+ hidden and system) during its 1st-stage setup.
2nd-stage setup makes some adjustments in boot.ini but doesn't restore
its read-only attribute.
Windows tools that can modify boot.ini (i.e. msconfig.exe, bootcfg.exe,
and sysdm.cpl) **ALL** know how to remove the read-only attribute for
modifying boot.ini, before restoring it if needed.
The BootDrive and BootPartition values are deprecated, and support
for them will soon be removed from FreeLoader.
Add an helper function to migrate these values during ReactOS
(re)installation / update.
The support is so far enabled only for INI files (freeldr.ini, boot.ini).
May be subject to further improvements in the future.
Usage examples:
- When finding existing ReactOS or Windows installations, the boot store
should exist and is opened in read-only mode. Closing the boot store
doesn't store any temporary modifications made to it.
- When doing a clean installation, freeldr.ini is created in read-write
access.
- When installing with an existing freeldr.ini or boot.ini, they are
opened as existing files in read-write access.
- QueryBootStoreOptions(): De-duplicate code.
- SetBootStoreOpt(): Respect the FieldsToChange flag.
- BOOT_STORE_OPTIONS: Remove unused Version field and distinguish
between "Current" and "Next" BootEntryKey.
- If a section already exists, return the existing one. This allows
avoiding different section entries with the same name in the cache.
If an INI file has separate sections with the same name, their
contents (key-values) get merged into a unique section.
- If a key-value already exists, update its data value and return the
existing one. (Note that this may be subject to behaviour change in
the future.)
Retrieve the current ambient language and keyboard layout, that has been
chosen in the "General language and keyboard layout selection" dialog
when starting the LiveCD.
A more robust solution will be developed later.
- Make the Create*Partition helpers take a size in bytes, not in sectors.
This allows them to be easier to use by the caller, alleviating the
need for making the size conversion into sectors. Instead it is done
internally by the helpers.
- Introduce helper macros to easily retrieve the size of a partition
entry or a disk in bytes, from their internal representation in number
of sectors.
- The 'AutoCreate' variable being USETUP-specific, remove it from the
PARTENTRY structure and use instead a flag set into the 'New' member.
- Rename IsDiskSizeValid to IsPartitionLargeEnough, to better describe
what the function is for.
The reason is to avoid enforcing the usage of a specific list
container by the users of the setup library. This is a departure
of what I originally thought would be the best, in commits
92692eae3 (r74553), 8f2c4f7a6 (r75700)
This should actually make some parts of the GUI setup code simpler
(e.g. using the win32 comboboxes to store the list contents).
LangID is a LANGID and LayoutID is a KLID: keyboard layout ID.
See terminology at http://archives.miloush.net/michkap/archive/2004/11/27/270931.html
These tables of MUI_LAYOUTS for each language, correspond to the
intl.inf LCID map:
```
; List of locales.
; <LCID> = <Description>,<OEMCP>,<Language Group>,<langID:HKL pair>,<langID:HKL pair>,...
```
where:
- each MUI_LANGUAGE entry corresponds to one such locale description;
- each MUI_LAYOUTS entry corresponds to a <langID:HKL pair>.
See http://archives.miloush.net/michkap/archive/2006/10/14/825404.html
for some details.
NOTE: IDS_ADMINISTRATOR_NAME translation excluded for the time being.
It should be "Администратор", but bg-BG translation missing in samsrv.dll,
therefore don't translate it because otherwise this would introduce a mismatch
(samsrv falls back into english when translation is missing).
Co-authored-by: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito@reactos.org>
