Pierre recommended this workaround for 0.4.8rls before.
Avoids "GetVolumeInformation now fails on NFS volume"
This workaround was recurrently applied for all releases
0.4.8, 0.4.9, 0.4.10, 0.4.11, 0.4.12, 0.4.13.
I never got any reply in the regression-ticket and recurrently
applying this over and over again is a waste of time.
So I decided to commit to master today, but will leave
the ticket unresolved, so when a proper fix will arrive in the future,
the existing ticket will remind us to undo this workaround.
Please note that I replaced #if 0 with #if 1
as discussed with Pierre. That's different to the patch in ticket.
which implements the required functionality.
ntdll and ntoskrnl now have a wrapper for this, with SEH.
This protects the function against malformed / bad images,
whilst still being able to use the code in freeldr et al.
Idea from Thomas.
CORE-14857
The code is mostly unchanged. This includes the following changes:
* Move all wine code to crt/wine to keep it separated from our own code
* Add a minimal winternl.h
* Remove the asm macros from wine/config.h
* Include wine/asm.h where required
* Fix the names of the exported functions (GCC uses thiscall now and no wrappers are used anymore)
The autogenerated name has the format:
"ATL:<hexadecimal_digits_of_pointer><NULL-terminator>"
and the number of hex digits in 0xABCD1234 (for 32-bit == 4-byte)
pointers (without the '0x') is 8 == 4*2, and for 64-bit == 8-byte
pointers (e.g. 0xABCDEF0123456789) is 16 == 8*2.
Dynamically check for sys/types.h and pid_t in wine config.h
Use TARGET_xxx defines instead of _X86_ as this is undefined by GCC
Add some sense in include directories management by using interface
libraries
This adds an evil hack to persuade libstdc++, which tries to import __acrt_iob_func from a DLL.
This can only be solved cleanly by adding a GCC-compatible C++ standard library to our tree later.
This fixes the crashes in HvpGetCellMapped on Windows Server 2003 when booting from Freeloader, as mentioned in maharmstone/btrfs#16.
When the bootloader loads the system hive, it cleans the data pertaining to any volatile keys. The Windows bootloader does this by setting SubKeyCounts[Volatile] to 0. After boot, the kernel marks any cell where this is 0 but SubKeyLists[Volatile] isn't HCELL_NIL as dirty, meaning that the sanitized version will then get flushed to the disk.
Because Freeloader sets SubKeyLists[Volatile] to HCELL_NIL straightaway, Windows thinks the cell is clean, and can unload it without flushing. If it then reads it from the disk, it will crash in HvpGetCellMapped due to the stale volatile pointers.
If you break on nt!CmpInitializeSystemHive on Windows and "gu" to the let the function run, you'll see that DirtyVector of the HHIVE has only the first 8 bits set. If you run it using the official bootloader, it'll have a lot more than that.
- kernel32!BaseCreateStack() is compatible with ntdll!RtlpCreateUserStack().
- When checking whether a stack guard page can be added, its size has to
be accounted for in the checking logic.
- We have to satisfy the PEB::MinimumStackCommit constraint.
- We cannot use PEB::GuaranteedStackBytes in BaseCreateStack() since it is
nowhere initialized (default is 0). It gets initialized to a non-zero
value when the user manually calls SetThreadStackGuarantee().
https://www.installsetupconfig.com/win32programming/windowsthreadsprocessapis7_6.html
- RtlpCreateUserStack(): Fix memory leak in failure case.
- RtlpFreeUserStack() doesn't need to return anything.
See also commit 1bc59379 (r59868).
CORE-11319
Fixes GCC 8 warning:
sdk/lib/crt/misc/i10output.c:83:25: error: '%d' directive writing between 1 and 11 bytes into a region of size 6 [-Werror=format-overflow=]
sprintf(format, "%%.%dle", prec);
^~
sdk/lib/crt/misc/i10output.c:83:21: note: directive argument in the range [-2147483648, 2147483646]
sprintf(format, "%%.%dle", prec);
^~~~~~~~~
sdk/lib/crt/misc/i10output.c:83:5: note: 'sprintf' output between 6 and 16 bytes into a destination of size 8
sprintf(format, "%%.%dle", prec);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes GCC 8 warning:
sdk/lib/fslib/vfatlib/check/boot.c:173:27: error: '%02x' directive writing between 2 and 8 bytes into a region of size between 0 and 15 [-Werror=format-overflow=]
sprintf(buf, "%s%u:%02x/%02x", first ? "" : ", ",
^~~~
sdk/lib/fslib/vfatlib/check/boot.c:173:16: note: directive argument in the range [0, 2147483647]
sprintf(buf, "%s%u:%02x/%02x", first ? "" : ", ",
^~~~~~~~~~~~~~~~
sdk/lib/fslib/vfatlib/check/boot.c:173:3: note: 'sprintf' output between 8 and 31 bytes into a destination of size 20
sprintf(buf, "%s%u:%02x/%02x", first ? "" : ", ",
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(unsigned)(p - (uint8_t *) b), *p, *q);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes GCC 8 warning:
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:521:5: error: this 'for' clause does not guard... [-Werror=misleading-indentation]
for (i=(int)uReadSize-3; (i--)>0;)
^~~
sdk/lib/3rdparty/zlib/contrib/minizip/zip.c:529:7: note: ...this statement, but the latter is misleadingly indented as if it were guarded by the 'for'
if (uPosFound!=0)
^~
These are required by latest mingw-w64 stl and we are mixing this with our crt headers.
Define _CRT_NO_POSIX_ERROR_CODES in all modules that define their own constants.
hid.dll and hidparse.sys must understand the same HID preparsed data,
so use the same code in hid.dll and in hidparse.sys
At the same time, this permis implementation of some HidP_* functions.
Interface between both is not anymore the HidParser_* functions, but
the HidP_* functions and the AllocFunction/FreeFunction/DebugFunctions/
ZeroFunction/CopyFunction.
- Modify atldef.h for non-ReactOS environments.
- Update ATL testcase project files (from v120_xp to v140_xp).
- #define HAVE_APITEST and use it.
- s/NULL/0/
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
This fixes the following compiler errors:
../sdk/lib/crt/stdio/stat64.c:7:13: error: inline function 'release_ioinfo' declared but never defined [-Werror]
inline void release_ioinfo(ioinfo *info);
^~~~~~~~~~~~~~
../sdk/lib/crt/stdio/stat64.c:6:16: error: inline function 'get_ioinfo' declared but never defined [-Werror]
inline ioinfo* get_ioinfo(int fd);
^~~~~~~~~~
../sdk/lib/crt/stdio/file.c:186:5: error: 'init_ioinfo_cs' is static but used in inline function 'get_ioinfo' which is not static [-Werror]
init_ioinfo_cs(ret);
^~~~~~~~~~~~~~
../sdk/lib/crt/stdio/file.c:183:19: error: 'get_ioinfo_nolock' is static but used in inline function 'get_ioinfo' which is not static [-Werror]
ioinfo *ret = get_ioinfo_nolock(fd);
MSVC was previously given a "result" variable to copy the fscale result from st(0). This led to another "fld" FPU stack push at the very end without popping the source value from the FPU stack.
Moreover, this copy isn't even needed: A simple "fstp st(1)" at the end pops an element from the FPU stack while effectively storing the result in st(0), the register used for returning a double value.
This problem didn't affect GCC, as it is only given the "fscale" instruction and does all necessary stack operations itself.
However, looking into the CRT sources, I found many other i386 implementations with inline assembly suffering from the same problem.
Fortunately, they have been replaced by pure assembly implementations a while ago, so it's time to finally remove them.
ldexp would have also been a candidate for a pure assembly implementation, but the required check for NaN and setting errno (verified on Win2003) already outweighs the benefits.
And we cannot just do a NaN check with FUCOMI as this is an i686/pentiumpro instruction while we're still targeting i586/pentium.
I'm also using this opportunity to clean up the ldexp.c header and only put in the remaining contributors as returned by "git blame".
Thanks to NightWolve1975 for reporting the problem! (https://twitter.com/nightwolve1975/status/1099042477531643912)
Clang-CL does not support #pragma function like CL. The alternative to this approach is to disable all intrinsics for this single source file, but that is not trivial to do, as it can only be done by removing a compiler switch, which we have no CMake support for. Therefore this solution is simpler and as good.
Running out of pool is likely at least during kmtest:ExPools.
There is a chance of crashing when dereferencing these null pointers -- but
worse, there's also a chance of overwriting the IVT or BDA if a VDM BIOS
call is in progress, which can lead to crashes in non-obvious places later.
* [WIN32K] Fix handle calculation in DbgGdiHTIntegrityCheck
* [NOTEPAD] Fix MSVC warnings
* [PSDK] Simplify *PROC definitions in windef.h
* [VIDEOPRT] Don't try to use NtVdmControl on x64
* [FREELDR] Fix some macros
* [CRT] Make qsort 64 bit compatible
* [NTOS] Use #ifndef _WIN64 instead of #ifdef _M_IX86 around C_ASSERTs
* [FAST486] Fix 64 bit warnings and change DWORD to ULONG, so it can be used in kernel mode
* [APPHELP_APITEST] Fix 64 bit issue
CORE-12671
- The default format is used when no format name is specified: this is
the one we use so far in ReactOS:
<debug_class>:(<file>:<line>) <message>
with "debug_class" being "trace", "warn", "err".
- The "wine" format is the one used by Wine. It can be used when trying
to diff-compare traces for a module with the corresponding one
obtained from a Wine run. It can also be useful because the logging of
Wine-synced code assumes that the function names are automatically
added by the helper macros "FIXME()", "TRACE()", "WARN()" or "ERR()",
and not manually inside the logging string given to these macros:
for example:
FIXME("(%params) message\n", params);
displays:
fixme:<module>:SomeFunc(params) message
- The "extended" (or "ext") format is very noisy and tries to output a
lot of information; it is a hybrid of the previous two formats:
<debug_class>:(<file>:<line>):<channel>:SomeFunc <message>
Support for displaying the current process ID is added in
addition to the already existing support for thread ID.
And, don't emit \r\n when an \r alone is encountered.
This fixes the problem of extra newlines appearing when redirecting
"more" output to a file.
CORE-14592
GAS uses ".double" symbol for declaring floating-point constants and
".quad" symbol for declaring 64-bit numbers.
This is not compatible with our macro for MASM and introduces bugs.
Now 64-bit constants are supposed to be declared using ".quad" macro.
This is required, since newer versions of MSVC demand that non-member operator new/delete are in the global namespace and neither static nor inline. See https://msdn.microsoft.com/en-us/library/mt723604.aspx ("Overloaded operator new and operator delete")
Otherwise fall back to the computed argv[0].
This is expected by some applications, for example Git.
Code is adapted from Wine.
Many thanks to Stanislav Motylkov for having investigated this bug!
CORE-12931 CORE-13892 CORE-13898 CORE-14066
Our implementation had a bug that could be triggered while
building our USBD library on ReactOS: the compare function
could be called with a NULL pointer instead of a valid value.
With this bug fixed (and the cmd hack in CORE-14648), ReactOS
can totally selfhost :-)! I was able to build LiveCD and BootCD
without any trouble, crash, deadlock or whatever.
(Next step: having a buildbot slave hosted on ReactOS ;-)).
Enjoy: https://twitter.com/HeisSpiter/status/1002880397103988737
CORE-14680
In working on some problems with Time Zone adjustments in ReactOS I found that the RtlQueryTimeZoneInformation function is partially broken and wrote an apitest to capture the failures.
Patch by Doug Lyons.
CORE-14658
Instead of loading systemcompatible.manifest as the implicit activation context, load forwardcompatible.manifest
Add a new assembly containing all apisets called ReactOS.Apisets and make it a dependency to forwardcompatible.manifest
Import the following Wine commits:
* ea2798f1ce9 Iván Matellanes: msvcrt: _setmode should check if file descriptor is valid.
* 9b495caacfd Carlo Bramini: msvcrt: Call SetFilePointer() with correct parameters.
* 13f34481b26 Carlo Bramini: msvcrt: Use MSVCRT_xxx macros instead of the same ones from GLIBC.
* 781b069ed81 Piotr Caban: msvcrt: Don't close HANDLE if stdout or stderr is sharing it.
Import Wine commits by Piotr Caban:
* 6ed69c107f8 msvcrt: Avoid using global critical section while allocating new file descriptors.
* 725e4733cf8 msvcrt: Remove no longer needed global lock from functions using fd critical sections.
Import Wine commits by Piotr Caban:
* 417b6056877 msvcrt: Fix possible deadlock in dup2 function.
* e7fc2370885 msvcrt: Don't use fdend in create_io_inherit_block.
Import Wine commits by Piotr Caban:
* c7b0fb51543 msvcrt: Use fd critical section in _dup2.
* b052afd4afa msvcrt: Use fd critical section in msvcrt_free_fd.
* 16285f5700f msvcrt: Use fd critical section in read.
* 9ce2a8a60c1 msvcrt: Use fd critical section in create_io_inherit_block.
* f00b7f40584 msvcrt: Use fd critical section in _setmode.
* ba757eaec74 msvcrt: Use fd critical section in _write.
* eec7a565bec msvcrt: Don't lock __badioinfo.
Import Wine commits by Piotr Caban:
* 6c2d4f1092d msvcrt: Use fd critical section in _fstat64.
* 9278190d468 msvcrt: Use fd critical section in _futime64.
Import Wine commits by Piotr Caban:
* 4508e665c07 msvcrt: Use fd critical section in _commit.
* afc6962a24a msvcrt: Use fd critical section in _close.
* 9a4cfbc3edc msvcrt: Use fd critical section in _eof.
* ffdd16cc0d7 msvcrt: Use fd critical section in _locking.
* fa6de597700 msvcrt: Use fd critical section in _lseeki64.
* f2f45d5fe67 msvcrt: Use fd critical section in _chsize_s.
- 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
(So the fun begins)
In spite of what VFATLIB headers pretend, there's not magic in FAT boot sector.
The 3 first bytes are just the jump instruction (to the boot code). No jump, no boot.
Also, some (many?) FAT implementations rely on the jump code to help detecting that
a FAT volume is really a FAT volume. Like MS FastFAT. Or our own FAT recognizer in FS_REC.
The story is that, up to that commit, we zeroed the 3 first bytes; leading to broken
FAT volumes.
This got hidden in most cases by the fact that during setup, when we install boot
loader, we erase parts of the boot sector, including the jump instruction, making the
volume valid again. But that wouldn't fix secondary volumes where the boot loader isn't
installed.
And, also, imagine a scenario where you want to install ReactOS on a newly formatted volume
with MS FastFAT instead of our own implementation... That would simply not work to
the fact that the driver wouldn't recognize the fresh formatted volume!
(So the non fashion begins)
Fix this by putting a not that valid jump into the boot sector when formatting our
partitions. That way, our volume is always regarding a FAT view point. But, instead of
putting values that mean (nearly) nothing. We should also put a dummy bootloader
displaying the user and error message, as done by dosfstools.
(So the hope begins)
This opens the way for trying to install ReactOS with MS FastFAT (doesn't work yet).
CORE-11819
CORE-14362
[NDK]: Document latest RTL_BSD_DATA as of RS3 based on ext.dll WinDBG
extension "!blackboxbsd" which outputs the entire structure field by
field :).
[NDK]: Update RTL_BSD_ITEM_TYPE thanks to ole32 symbols
[RTL]: Move system volume APIs to sysvol.c
[RTL]: Fill out BsdItemTable based on actual field offsets/sizes and not
hardcoded magic numbers which we won't ask where they came from.
[RTL]: Make RtlCreateBootStatusDataFile use an appropriate structure for
initializing the buffer instead of "UCHAR Buffer[12] = {0xC,0,0,0,
1,0,0,0, 1, 0x1e, 1, 0};" which appears like magic knowledge.
[RTL]: Rename "WriteMode" to "Read" in RtlGetSetBootStatusData since
it's much less confusing.
[RTL]: Some formatting fixes, SAL updates.
- Start to doxygenate the library, focusing in great details on the
functions of the "outstream" module.
- Add a K32LoadStringEx function that expands (K32)LoadString by
allowing a LanguageId parameter to be able to load strings from other
languages than the current one.
- Add "ConResMsg*" helper functions to be able to (format and) print
message strings with inserts that come *NOT* from a message table (as
usual) *BUT* from resource string tables.
Will be helpful for CORE-14265 in particular.
[CMD] Fix the call to ConMsgPrintfV().
- Add missing error code to DDK/NDIS
- Fix error code in IP driver
- Patch MSAFD to reply correct WSA error code
- Fix IcmpSendEcho function
- Fix returning error code in ICMP_ECHO_REPLY (see MSDN)
- Fix returning host address (using GetBestInterface and GetIpAddrTable functions)
- Fix GetBestRoute function (it is used by GetBestInterface)
Relates to #318 and CORE-14241
As code grows, this will allow for better maintenance of the console
stream code. In particular the input stream module will contain special
code for handling TTYs, and this is something not all console programs
will need. Having this code in a separate module will allow for the linker
to possibly remove this code when it is unused.
It's critical not to perform any write on a volume without an exclusive lock on it.
That lock is only acquired if ChkDsk is started in RW mode.
Also added an assert in write routine, to make sure that when we're about to perform
a write operation, we're really allowed to do so.
This will avoid volume corruptions when a simple "chkdsk" is issued from cmd.
To put it simple: check will really check now, and won't attempt any repair.
CORE-14119
For instance, when repair is required, we can ask the caller whether we should
continue or not in case locking failed.
Also, introduced a hack for 1st stage where IopParseDevice() hack is in usage
so that broken NTSTATUS is diverted to appropriate status.
That way, usetup will properly continue even if locking failed (due to its
callback stub!)
CORE-14087
The cFileName member of WIN32_FIND_DATA is an array of MAX_PATH(260). Using strcpy/wcscpy with the target buffer being smaller is potentially bad. Corresponds to CID 1401198 and 1401195.
