The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/disk/)
Synched with commit 3428c5feaac7c1a5e2a09db0ed93392f7568f9e6
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
clang-cl 10:
'.../Completion.h(4,2): warning: 'COMLPETION_H__INCLUDED_' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]'
Addendum to bf1b057 (r1507).
CORE-14306
clang-cl 10:
'.../attrib.h(32,9): warning: 'ATTRIB_H' is used as a header guard here, followed by #define of a different macro [-Wheader-guard]'
Addendum to 5f2bebf.
CORE-7499 CORE-14306
'int128' arguments are NOT almost always GUID, as was claimed, and the
usage of the wine_dbgstr_guid() function to display them would require
the presence of yet another wine-specific header.
Instead, define a "MyInt128" typedef, local to the stub file being
generated, as the structure of two __int64's (lower and upper), and
print this "MyInt128" as the couple of these two __int64's.
Besides, display the __int64 numbers prefixed with "0x" (together with
the PRIx64 formatter).
Finally, when generating the debug-print function calls, it is useless to
explicitly cast the 'aX' variables with their types, because their types
are already known from the prototype of the stub-function!!
Therefore we can use the same `fprintf(file, "a%d", i);` for all the
ARG_LONG, ARG_PTR, ARG_STR, ARG_WSTR, ARG_DBL, ARG_INT64 and ARG_FLOAT.
Only in the case of ARG_INT128 we output "a%d.lower, a%d.upper" .
The source code is licensed under MS-PL license, taken from Windows Driver Samples
repository (https://github.com/microsoft/Windows-driver-samples/tree/master/storage/class/classpnp/)
Synched with commit 88541f70c4273ecd30c8c7c72135bc038a00fd88
The driver is written for Windows 8+, so we compile it with ntoskrnl_vista
statically linked and with NTDDI_WIN8 defined
CORE-17129
Sorry, something went terribly wrong with the CORE-ID
in my head 2 times, one time in the commit comment
and one time in the code!
Addendum to 0.4.15-dev-663-g
cd7db5df89
More forwards to LocalSpl and LocalMon. At sometime will be merged together.
Bug fixes.
Printer Driver code is a wine hack. (WIP)
Added information for shell tray icon notifications.
Sync wine WinSpool driver tests. Unplugged from build.
RtlGetNtProductType comes into two variants: one in user-mode that is exported for use from NTDLL layer and the kernel-mode that is used exclusively by the NT kernel. The kernel-mode variant of the function is not exported.
- Some "PartitionInfo->PartitionNumber = 0;" are ROS-specific hacks for
xHalIoAssignDriveLetters(), that should be fixed... Mark them as such.
- Un-hardcode some "magic" values (partition IDs, max number of
partition table entries, etc.).
- Use NULL instead of '0' for null-pointers.
- Fix some typos in comments.
..\ntoskrnl\vdm\vdmmain.c(91,34): warning: expression does not compute the number of elements in this array; element type is 'unsigned short', not 'char' [-Wsizeof-array-div]
UNICODE_STRING PhysMemName = RTL_CONSTANT_STRING(L"\\Device\\PhysicalMemory");
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\ROS\reactos\output-clang\sdk\include\psdk\ntdef.h(1542,15): note: expanded from macro 'RTL_CONSTANT_STRING'
sizeof(s) / sizeof(_RTL_CONSTANT_STRING_type_check(s)), \
~ ^
..\ntoskrnl\vdm\vdmmain.c(91,34): note: place parentheses around the 'sizeof (_RTL_CONSTANT_STRING_type_check(L"\\Device\\PhysicalMemory"))' expression to silence this warning
C:\ROS\reactos\output-clang\sdk\include\psdk\ntdef.h(1542,15): note: expanded from macro 'RTL_CONSTANT_STRING'
sizeof(s) / sizeof(_RTL_CONSTANT_STRING_type_check(s)), \
^
1 warning generated.
Clang will not let us use SSE intrinsics at all when compiling for a
target that doesn't support SSE. Since this test is a special case,
we can simply fix this by changing the options for one function.
The alternative would be to use our own inline functions for the
intrinsics instead of the builtins, like we do for GCC.
