This fixes a race condition, where the message thread was still running when InstallReactOS returned and syssetup.dll was unloaded by the caller (setup.exe).
- Improved Italian translation for USETUP, WELCOME, REACTOS, EXPLORER.
- Completed translation in SYSSETUP.
- Correct some characters encoding and text alignment in USETUP.
- "(sdk/lib/rtl/heappage.c:1329) corrupted suffix pattern"
detected at
"dll/win32/syssetup/wizard.c:2672 (InstallWizard)"
- Add an ASSERT(), as hinted by Mark Jansen.
- Read the driver settings from the registry.
- Write the driver settings to the registry.
- Make the read-only edit control for the input buffer length look like a non-read-only one because it is controlled by the up-down control.
- Make sure the DWLP_* values are correct on _WIN64
- Don't use the DWL_* constants, they are not portable. Enforce this by removing them entirely from winuser.h
- Make sure Get/SetWindowLong*Ptr* is used and pointers are not truncated to LONG
Wine's comctl32 somehow fails to load an 24bpp image with ImageList_LoadImageW
when crMask is CLR_NONE so use a color that doesn't exist in the bitmaps until
comctl32 gets fixed.
I prefer to add this silly hack in a non critical dll than make a hasty change in the
critical comctl32 until some proper tests are written for this absurd failure.
Such a manifest is meant to be activated by the caller of the exports of the dll.
This means that the user of syssetup which is setup.exe is the one that should do the proper handling of the manifests.
Since setup.exe is the one that needs to do the right thing, add a CREATEPROCESS_MANIFEST_RESOURCE_ID to it and avoid
dealing with ISOLATIONAWARE_MANIFEST_RESOURCE_ID altogether (which is supposed to be used by activating the activation context
before calling the exports of the dll that has it). We don't really use ISOLATIONAWARE_MANIFEST_RESOURCE_ID correctly in any
place in the tree so let's rely on CREATEPROCESS_MANIFEST_RESOURCE_ID for now.
This fixes one part of CORE-14228 where no image was shown in the theme selector buttons. This happened because comctl32 was
statically linked and calling ImageList_LoadImage ended up creating an image list with comctl32 v5. Then we passed this image
list to a button created with comctl32 v6 and as a result the image list was unusable. This is yet another issue that needs
to be addressed in the future. Namely, it seems that in windows comctl32 v6 can use image lists created by comctl32 v5 whereas
we cannot.
This fix is not a hack but cleverly works around these two bugs that need to be addressed some time in the future.
CORE-14228
