- 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.
