Revert "[PSDK][AFD][VGADDI] Further build and MS PSDK compatibility fixes."
This reverts commit 99efc2ae50.
Revert "[PSDK] Sync winresrc.h with wine-8.20"
This reverts commit 3e83562aa7.
Revert "[OSK][PROGMAN] Fix resource file build."
This reverts commit 84e4ad0a82.
Revert "[PSDK] Use the new .rh files in winresrc.h"
This reverts commit f6fb7c48c9.
- windows.h:
* should define _WINDOWS_ and _INC_WINDOWS instead of _WINDOWS_H
* include winresrc.h if RC_INVOKED and not NOWINRES (Wine also agrees
with that)
* also, some .h included from there should _not_ be included if their
respective NO*** flags are defined.
- batclass.h: Use correct _WINDOWS_ guard.
- winsnmp.h:
* should define _INC_WINSNMP instead of _WINSNMP_H
* use _INC_WINDOWS instead of _WINDOWS_H
- afd.h, vgaddi.h: Use the correct guards.
- winnt.rh: Define the (SUB)LANG_* exactly as they are in the winnt.h,
otherwise we get macro redefinition compile errors.
NOTE: Ideally these .rh files should be auto-generated from their
corresponding .h files.
- afxres.h: Do not include the whole windows.h, but instead, only
the winres.h file, and only if RC_INVOKED is defined.
NOTE: Both afxres.h and winres.h do not really belong to the PSDK,
but belong instead to MFC. The reason why we have them here is twofold:
1. Wine used to have also winres.h (from where we got ours). This is
because the .rc resource files of some non-MFC modules were generated
with Visual Studio, which always includes afxres.h for these, and the
solution was to use a slightly less MFC-specific header: winres.h
(Wine commit cb08c82244673f26842e7a0766de90f091b5a493).
However, this winres.h has been since removed from Wine tree
(Wine commit 197f4059ab2af5f13f9c56faa26e3b4af902f869).
2. Few of our modules either use afxres.h or winres.h in their resource
files, and we still want to be able to compile them.
It is also compatible with MS PSDK file.
NOTE: I have observed that at least one .rh file (commctrl.rh) we have
from Wine, is not yet fully compatible with its MS PSDK counterpart
(for example it misses the TBSTYLE_* defines).
Note that this file is already in sync with wine-8.20
NOWINMESSAGES, NOWINSTYLES, NOCLIPBOARD, NOMENUS, NOSYSCOMMANDS,
OEMRESOURCE and NOICONS #ifndef guards should not be present in the
.rh file, contrary to the .h file.
However, #ifndef NONCMESSAGES guard should be present.
Finally, remove the useless SC_SIZE redefinition
("At least HP-UX defines it in /usr/include/sys/signal.h" -- like,
what the hell, we are developing ReactOS...)
... addendum to commits 072965eb0 and 6cdaad13b.
Due to the wrapping of these defines within an #ifdef OEMRESOURCE block
in winuser.h (for MS PSDK compatibility), these defines became unavailable
in user32.rc resource file. Thus, during user32 resources compilation,
the resource compiler fell back to the behaviour of considering these
resource IDs as literal string IDs (not numerical ones).
Thus, whenever code was trying to refer to these resources via their
numerical IDs, these resources could not be found now, rendering ReactOS
unusuable.
Follow-up to #5994. Reduce the lag and the
cost of drawing on large image.
- Introduce partial image history on
SmoothDrawTool and ShapeTool.
- We can draw with pen smoothly even
when the image is huge (10000x10000).
CORE-19237
Fix build by commit 072965eb0 for modules:
EXPLORER, COMCTL32, IERNONCE, URLMON, USER32_(API|WINE)TESTS
Note that some of these modules (from Wine) already have the OEMRESOURCE
defined; however, only in one of their files. But we have added
precompiled headers for them where we have included either windows.h
or winuser.h in them, without OEMRESOURCE. The result is, that when
compiling these modules with PCH support, the OEMRESOURCE define was
_not_ satisfied and thus, compile errors arose.
Fix this by adding #define OEMRESOURCE before the windows headers also
in the precompiled headers we have added for these modules.
Keep compatibility with MS PSDK ddraw.h file by using WINNT instead of
_WINNT_ in the preprocessor conditional test.
Incidentally this allows also removing those #define NT_BUILD_ENVIRONMENT
in the win32ss modules.
See commit 5fcfaf2e1 (r42346).
- Return CR_INVALID_POINTER if pszVetoName is NULL and ulNameLength is not zero
- CM_Request_Device_Eject_ExA: Allow ulNameLength to be zero when pszVetoName is not NULL
Verified with Windows 2003 SP2.
Based on KRosUser's netcfx_alt.patch.
- Remove WS_GROUP flag of IDC_NODHCP control.
- Fix the extent of a groupbox.
- Half-implement TcpipAltConfDlg function.
CORE-19331
Co-authored-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Introduce the initial changes needed to get other processors up and into kernel mode.
This only supports x86 as of now but is the first real step towards using other system processors.
Sometimes repairing a broken hive with a hive log does not always guarantee the hive
in question has fully recovered. In worst cases it could happen the LOG itself is even
corrupt too and that would certainly lead to a total unbootable system. This is most likely
if the victim hive is the SYSTEM hive.
This can be anyhow solved by the help of a mirror hive, or also called an "alternate hive".
Alternate hives serve the purpose as backup hives for primary hives of which there is still
a risk that is not worth taking. For now only the SYSTEM hive is granted the right to have
a backup alternate hive.
=== NOTE ===
Currently the SYSTEM hive can only base upon the alternate SYSTEM.ALT hive, which means the
corresponding LOG file never gets updated. When time comes the existing code must be adapted
to allow the possibility to use .ALT and .LOG hives simultaneously.
As we iterate over the chunk hive data pointer for hive bins that we are going
to enlist, we might encounter one or several bins that would get corrupted
during a premature abortion of a registry writing operation such as due to
a power outage of the system, hardware malfunction, etc.
Corruption at the level of hive bins is nasty because they contain actual cell
data of registry information such as keys, values etc. Assuming a bin is corrupt
in part we can fix it by recovering some of the bin properties that, theoretically,
could be fixed -- namely the signature, size and offset.
For size and offset we are more or less safe because a bin typically has a size
of a block, and the offset is the coordinate index of where a hive bin should lay at.
If FreeLdr performed recovery against the SYSTEM hive with a log, all of its data is only present in volatile memory thus dirty. So the kernel is responsible to flush all the data that's been recovered within the SYSTEM hive into the backing storage.
The newly implemented code for registry recovery makes the FreeLdr binary to grow
in size, to the point that it would BSOD because the PE image is too big.
For now we have to temporarily disable any of the newly added code, until
either FreeLdr is split into a basic PE bootloader image itself and a
"FreeLdrlib" that is used by the PE image to access various bootloader APIs
or another proper solution is found.
Validate the SYSTEM hive with CmCheckRegistry and purge volatile data with the same function when initializing a hive descriptor for SYSTEM.
Also implement SYSTEM recovery code that takes use of SYSTEM log in case something is fishy with the hive. If hive repair doesn't have fully recovered the SYSTEM hive, FreeLdr will load the alternate variant of the SYSTEM hive, aka SYSTEM.ALT.
If FreeLdr repairs the hive with a LOG, it will mark it with HBOOT_BOOT_RECOVERED_BY_HIVE_LOG on BootRecover field of the header. All the recovered data that is present as dirty in memory will have to be flushed by the kernel once it is in charge of the system.
Otherwise if the system boot occurred by loading SYSTEM.ALT instead, FreeLdr will mark HBOOT_BOOT_RECOVERED_BY_ALTERNATE_HIVE, the kernel will start recovering the main hive as soon as it does any I/O activity into it.
Thanks to CmCheckRegistry, the function can perform volatile data purging upon boot which this removes old hacky CmPrepareHive code. This also slightly refactors HvInitialize making it more proper.
=== DOCUMENTATION REMARKS ===
This implements (also enables some parts of code been decayed for years) the transacted writing of the registry. Transacted writing (or writing into registry in a transactional way) is an operation that ensures the successfulness can be achieved by monitoring two main points.
In CMLIB, such points are what we internally call them the primary and secondary sequences. A sequence is a numeric field that is incremented each time a writing operation (namely done with the FileWrite function and such) has successfully completed.
The primary sequence is incremented to suggest that the initial work of syncing the registry is in progress. During this phase, the base block header is written into the primary hive file and registry data is being written to said file in form of blocks. Afterwards the seconady sequence
is increment to report completion of the transactional writing of the registry. This operation occurs in HvpWriteHive function (invoked by HvSyncHive for syncing). If the transactional writing fails or if the lazy flushing of the registry fails, LOG files come into play.
Like HvpWriteHive, LOGs are updated by the HvpWriteLog which writes dirty data (base block header included) to the LOG themselves. These files serve for recovery and emergency purposes in case the primary machine hive has been damaged due to previous forced interruption of writing stuff into
the registry hive. With specific recovery algorithms, the data that's been gathered from a LOG will be applied to the primary hive, salvaging it. But if a LOG file is corrupt as well, then the system will perform resuscitation techniques by reconstructing the base block header to reasonable values,
reset the registry signature and whatnot.
This work is an inspiration from PR #3932 by mrmks04 (aka Max Korostil). I have continued his work by doing some more tweaks and whatnot. In addition to that, the whole transaction writing code is documented.
=== IMPORTANT NOTES ===
HvpWriteLog -- Currently this function lacks the ability to grow the log file size since we pretty much lack the necessary code that deals with hive shrinking and log shrinking/growing as well. This part is not super critical for us so this shall be left as a TODO for future.
HvLoadHive -- Currently there's a hack that prevents us from refactoring this function in a proper way. That is, we should not be reading the whole and prepare the hive storage using HvpInitializeMemoryHive which is strictly used for HINIT_MEMORY but rather we must read the hive file block by block
and deconstruct the read buffer from the file so that we can get the bins that we read from the file. With the hive bins we got the hive storage will be prepared based on such bins. If one of the bins is corrupt, self healing is applied in such scenario.
For this matter, if in any case the hive we'll be reading is corrupt we could potentially read corrupt data and lead the system into failure. So we have to perform header and data recovery as well before reading the whole hive.
In addition to that, in some functions like CmFlushKey, CmSaveKey and CmSaveMergedKeys we must validate the underlying hives as a matter of precaution that everything is alright and we don't fuck all the shit up.
CmCheckRegistry is a function that provides the necessary validation checks for a registry hive. This function usually comes into action when logs have been replayed for example, or when a registry hive internals have changed such as when saving a key, loading a key, etc.
This commit implements the whole Check Registry infrastructure (cmcheck.c) in CMLIB library for ease of usage and wide accessibility across parts of the OS. In addition, two more functions for registry checks are also implemented -- HvValidateHive and HvValidateBin.
Instead of having the CmCheckRegistry implementation in the kernel, it's better to have it in the Configuration Manager library instead (aka CMLIB). The benefits of having it in the library are the following:
- CmCheckRegistry can be used in FreeLdr to fix the SYSTEM hive
- It can be used on-demand in the kernel
- It can be used for offline registry repair tools
- It makes the underlying CmCheckRegistry implementation code debug-able in user mode
CORE-9195
CORE-6762
This implements cmheal.c file which provides the basic registry self-heal infrastructure needed by the public CmCheckRegistry function. The infrastructure provides a range of various self-heal helpers for the hive, such as subkey, class, values and node healing functions.
Add these NTSTATUS codes in the CMLIB library. STATUS_INVALID_PARAMETER will be used mostly for HvInitialize function, STATUS_REGISTRY_IO_FAILED for whatever routines that deal with reading or writing into a hive file.
