Suppose dwFlags == 1 | 4 (i.e. skipping the flag 2).
Then the while-loop would only run once, because at the second iteration
(after dwWhich >>= 1; has been executed once), dwWhich value == 2, but
dwWhich & 0x1 == 0, which makes the while-loop condition false.
Instead the loop should run, but the handling of the extension should be
skipped.
- Add as well the undocumented 0x40 dwFlags value from shlwapi!PathFileExistsDefExtW()
to the list.
- Fix a bug (also present in Win2k3) in PathResolveW() where, specifying
the PRF_DONTFINDLNK flag, would also erroneously exclude checking for
the .cmd extension as well (which was obviously NOT the original
intention, from the name of the flag and the documentation as well:
https://docs.microsoft.com/en-us/windows/win32/api/shlobj_core/nf-shlobj_core-pathresolve
).
Addendum to 3a822e4f.
This reverts
0.4.13-dev-284-g 74be88ac47
The logging is helpful to alert us when we should really
recalculate the base addresses for performance reasons.
Spams a bit sometimes, sure, but it's worth it!
MSI on 2k3sp2 hides empty CD-ROM, and hides CD-ROM with iso mounted.
MSI on 2k3sp2 hides VBox shares, both: writable and read-only-ones.
MSI on 2k3sp2 hides floppy drives with a floppy img mounted.
MSI on XPSP3 hides a mounted writable USB stick.
Thanks to the patches author Doug Lyons.
This patch supersedes
0.4.15-dev-2651-g 864e20b881 (CORE-14432)
and we are also better than Wines
0dd0d879a1
We decided to check a bit different than Wine currently does.
Wine checks for
if (GetVolumeInformationW(ptr, NULL, 0, NULL, 0, &flags, NULL, 0) && flags & FILE_READ_ONLY_VOLUME)
to exclude read-only-media while we (for now) check for
if (GetDriveTypeW(ptr) == DRIVE_CDROM)
For now this gives us the benefit of covering also CDROM drives, that do not have
a CD put into it.
That does not work properly for us with the Wine patch yet, but it does for Wine!
So this maybe points to some other bug in ros, maybe in our CDROM(FS)-drivers?
In the future we should also test this on other read-only-media in Windows e.g.
a read-only USB stick to decide whether we want to stick with our current solution
or whether we want to switch to Wines solution or whether we want to logically OR
both conditions!
Thanks to Doug Lyons for providing what *currently* does work best for us!
VBox https://reactos.org/testman/compare.php?ids=77537,77546 (no change)
KVM https://reactos.org/testman/compare.php?ids=77531,77541 (no change)
The About dialog banner will now show the correspondent Product version selected on install.
This will make it easier to tell which edition of ReactOS is installed.
CORE-17545
Addendum to commit d635ce0c.
dll/cpl/sysdm/general.c:156:25: warning: variable 'hCreditsDC' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (hDC == NULL)
^~~~~~~~~~~
dll/cpl/sysdm/general.c:216:25: note: uninitialized use occurs here
if (hCreditsDC != NULL) DeleteDC(hCreditsDC);
^~~~~~~~~~
and the same for hLogoDC:
dll/cpl/sysdm/general.c:215:25: note: uninitialized use occurs here
if (hLogoDC != NULL) DeleteDC(hLogoDC);
^~~~~~~
CORE-17545
Addendum to commit d635ce0c.
- Move the HDC variables initialization via function calls, out of
the variables declaration block.
- Fix warnings (and identical for base/system/userinit/livecd.c):
dll/cpl/sysdm/general.c:72:9: warning: variable 'hLogo' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized]
if (hDC == NULL || hDCLogo == NULL || hDCMask == NULL)
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dll/cpl/sysdm/general.c:130:9: note: uninitialized use occurs here
if (hLogo != NULL) DeleteObject(hLogo);
^~~~~
and similar for hMask too:
dll/cpl/sysdm/general.c:129:9: note: uninitialized use occurs here
if (hMask != NULL) DeleteObject(hMask);
^~~~~
Alias CHSTRING_WCHAR to unsigned short and use inline wrappers
to be able to use the thing with modern compilers
Put the GCC aliases into the public header.
Enable build with clang-cl
Do a sanity check onto the dialog box type before terminating it. As it stands now, a call of PostQuitMessage() is invoked even when the dialog box is modal. This is illegal due to the fact that the shutdown dialog box is initiated by the "Security" main window thus WlxDialogBoxParam.
A call to PostQuitMessage onto a modal dialog box leads to a undefined behaviour, as it'll not just terminate the thread but also eventually killing the Winlogon process whose the thread belongs to.
CORE-17535
