This function has an important role
for new ShellExecute implementation.
JIRA issue: CORE-19278
- Add evalcmd static library into
dll/win32/shell32/evalcmd.
- Implement
SHEvaluateSystemCommandTemplate
in evalcmd.
- Link evalcmd to shell32 and shlwapi.
- Modify shell32.spec and shlwapi.spec.
- Add prototype to <shellapi.h>.
- Add
SHEvaluateSystemCommandTemplate
testcase.
- Define PathIsAbsolute inline
function in <shlwapi_undoc.h>
and use it.
Add the tests of "Tricky Pointer" (the pointer that is
non-null and IS_INTRESOURCE(...) is true).
JIRA issue: CORE-20467
- Directly call AssocQueryStringA/W functions
without using GetProcAddress.
- Use ASSOCF_NONE instead of zero.
- Add the tests of "Tricky Pointers" handling.
For some reason on Vista x64 0xdeadbeef isn't detected as an invalid handle and the whole thing crashes. INVALID_HANDLE_VALUE on the other hand is detected as an invalid handle, so use that.
We will continue with this stuff when we can understand the root issues better
* Revert "[NTDLL_APITEST] Relicense implicit tls tests as MIT"
This reverts commit ec6bae2b31.
* Revert "[NTDLL:LDR] Add Implicit Thread Local Storage Support (#7594)"
This reverts commit 23043ce0b8.
Before Windows Vista, TLS directories were ignored by Ldr* in any module loaded after process creation, which meant that the TLS index in any delay-loaded module remained 0. This means that when running an application targeting Vista and above and its delay-load modules have TLS directories, the following events can happen:
One or more delay-load modules claim ThreadLocalStoragePointer idx 0, resulting in data corruption and possible buffer overflows as data intended for one of the immediate-load modules is overwritten.
None of the immediate-load modules has a TLS directory, so ThreadLocalStoragePointer is not initialized. This means that the program crashes when one of the delay-load modules attempts to access its TLS data.
Adding implicit TLS support improves support for NT 6.x/10 user-mode applications, including all contemporary major web browsers.
JIRA issue: CORE-19413
---------
Co-authored-by: Justin Miller <[email protected]>
Re-enable in ps_i.h the stubbed probing info values for thread information
classes, that were disabled in commit 60aad33ed0 (PR #8487), and adjust
the test code in probelib.c so that the failures for these non-implemented
classes are correctly taken into account.
- [USER32_APITEST_MENUUI] Return an empty test list when called with --list
NOTE: The better way to fix this is to move this executable to \reactos\bin\suppl. But that requires some refactoring of tests already in our source tree.
CORE-10935
- This reverts commit 522e9f6dd3.
- Implement Mark's suggestion given in PR #7784,
https://github.com/reactos/reactos/pull/7784#pullrequestreview-2722604928
Build three binary versions of the delayimp_apitest, named:
delayimp_nohook_apitest, delayimp_globalhook_apitest, and delayimp_runtimehook_apitest,
that respectively are:
- "nohook": delayload is used, but neither of the hook/failurehook is defined;
- "globalhook": delayload is used, and the hooks are assigned at global scope;
- "runtimehook": delayload is used, and the hooks are assigned at runtime.
- Since the delayimp apitests are self-contained, don't use the separate
testlist.c file. It is temporarily unused, until other SDK-specific tests
are added in this directory.
## Testing observations:
GCC build (tested with KVM x86): binutils doesn't create specification-compliant
`IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT` table for delay-loaded imports, and as a
result, the tests show:
```
delayimp.cpp:472: Tests skipped: No IMAGE_DIRECTORY_ENTRY_DELAY_IMPORT found,
some advanced features might not work!
```
Additionally, both `SymGetOptions` and `MapAndLoad` tests are skipped "until
CORE-6504 is fixed", as claimed. _**This doesn't happen for MSVC builds.**_
Suppress warning about infinite recursion, because that is the whole point of this test.
C:/ReactOS/reactos/modules/rostests/apitests/ntdll/StackOverflow.c: In function 'infinite_recursive':
C:/ReactOS/reactos/modules/rostests/apitests/ntdll/StackOverflow.c:23:1: error: infinite recursion detected [-Werror=infinite-recursion]
23 | infinite_recursive(void)
| ^~~~~~~~~~~~~~~~~~
C:/ReactOS/reactos/modules/rostests/apitests/ntdll/StackOverflow.c:58:5: note: recursive call
58 | infinite_recursive();
| ^~~~~~~~~~~~~~~~~~~~
Fixes GCC 13 warning:
C:/ReactOS/reactos/modules/rostests/apitests/crt/crtdata.c: In function 'Test___badioinfo':
C:/ReactOS/reactos/modules/rostests/apitests/crt/crtdata.c:75:20: error: the comparison will always evaluate as 'true' for the address of '__badioinfo' will never be NULL [-Werror=address]
75 | ok(__badioinfo != NULL, "__badioinfo is NULL\n");
| ^~
C:/ReactOS/reactos/modules/rostests/apitests/crt/crtdata.c:74:28: note: '__badioinfo' declared here
74 | _CRTIMP extern ioinfo* __badioinfo[];
| ^~~~~~~~~~~
Fixes GCC 13 warning:
C:/ReactOS/reactos/modules/rostests/apitests/iphlpapi/GetNetworkParams.c: In function 'test_GetNetworkParams':
C:/ReactOS/reactos/modules/rostests/apitests/iphlpapi/GetNetworkParams.c:171:28: error: the comparison will always evaluate as 'true' for the address of 'HostName' will never be NULL [-Werror=address]
171 | ok(FixedInfo->HostName != NULL, "FixedInfo->HostName is NULL\n");
| ^~
The test used the obsolete CRT. The test doesn't provide much value anyway, because we test all the used code already through msvcrt_apitest, ntdll_apitest, etc. The only real benefit was testing and working outside of reactos.
I kept the build file around, which could be revived with msvcrt_static or libcntpr, but that needs some work.
Katayama Hirofumi MZ