- Use a more descriptive "unknown hard error" string than Windows' one.
- Improve the computation of the buffer size for the hard error message
by using _vscwprintf() instead of just "guessing" which size the fully
printf'ed message could be.
- In UserpCaptureStringParameters(), always capture the parameter
strings with a terminating NULL. Also, no need to convert them to
ANSI if they are used with a STATUS_SERVICE_NOTIFICATION message.
- Determine within UserpFormatMessages() the message box flags to be
used, either from the message parameters (if STATUS_SERVICE_NOTIFICATION)
or from the proposed response options and message status severity.
These flags are then used by both UserpShowInformationBalloon()/UserpShellHardError()
and by UserpMessageBox().
- Improve Message validation (especially for STATUS_SERVICE_NOTIFICATION).
- Try to display the hard error status number if it's an unknown one.
- Make UserpFormatMessages() always succeed by falling back on
static string buffers if allocating large string buffers fail due to
lack of memory. Then the hard error popups will have truncated
strings, but at least something will be displayed instead of nothing,
thus alerting the user that something went wrong anyway.
- Simplify a bit the code by moving the NtOpenProcess(),
UserpCaptureStringParameters() and UserpFreeStringParameters() calls
inside UserpFormatMessages(). This also allows simplifying its
prototype.
- Cache localized hard error message components: the status severity,
the system process name and the unhandled exception debug strings.
- Try not to fail too much. In particular, don't fail if a string could
not be correctly captured in UserpCaptureStringParameters() (we then
use a default empty string). The next aim is to make UserpFormatMessages()
not failing at all.
- Use RtlStringCbPrintf(Ex)W where possible so that one can use counted
(and not NULL-terminated) UNICODE_STRINGs where possible. This allows
using counted resource strings without having to allocate memory.
- If available, prepend the window title of the application that
triggered the hard error to the hard error message box caption.
In particular do not always fail as soon as there is an error, because they may be the sign of an OS problem and this is precisely in this case that we want to display a hard-error.
- Use hard-error captions depending on the status code severity.
- Improve handling of the STATUS_UNHANDLED_EXCEPTION error. Start
implementing the display of the dialog button descriptions ("OK" to
terminate the application; "Cancel" to debug the application).
- Add support for the "ErrorMode" and "ShellErrorMode" registry values
under HKLM\System\CurrentControlSet\Control\Windows.
- Use MessageBoxTimeoutW() in UserpMessageBox() to support different
message box timeouts.
- Log hard errors into the System event log.
- Fix a copypasta.
- Remove dead code.
Thanks to mudhead, who spotted most of these.
NB:
This EXPERIMENTAL_MOUSE_CURSOR_SUPPORT code isn't compiled by default since r7865.
CORE-14511
SendNotifyMessageW: It doesn't support messages with pointers so there is no need to call MsgiUMToKMMessage
SendMessageTimeoutW, SendMessageTimeoutA: These two do support marshaling pointers so they need to use MsgiUMToKMMessage.
This is actually a bug that happens only in the rare case where we send a WM_COPYDATA with a timeout.
PDBs reveal that these functions are also used in winspool.drv, but not imported from spoolss.dll to retain the client/server architecture.
As winspool.drv highly benefits from the MarshallUp* functions, I put them in a source file shared between spoolss.dll and winspool.drv.
The added API Tests cover my testing and all implemented features.
One more item done from https://reactos.org/wiki/Printing !
This reverts ea4daf8b68 committed 2017-12-09 to master, the commit was named
"[WIN32K] Fix NtGdiGetTextFaceW to report face name correctly (#173)",
reverting got ack of khmz,
reopening less severe CORE-14071 accordingly
Yes, it checks the input handle and doesn't fail if an invalid level is given, because someone may still send a Command.
This also fixes CORE-12794. Thanks for reporting!
We applied this patch also last second in 0.4.7rls, now in master.
IntTrackPopupMenuEx() caused the BSOD when called while window is in the process of being destroyed.
* Pass the correct handle to _RpcGetPrinter in GetPrinterW.
* Pass an empty string instead of a NULL pointer as wszComputerName to the GetPrinterLevel* functions, because this variable is later used as source for StringCbCopyExW.
* Don't check for GetLastError() == ERROR_SUCCESS in tests. Windows apparently only sets the last error in case of failure.
The Printing code should probably be changed similarly in a future commit.
Should fix CORE-14072
This may get more applications to work which previously called into the WINE-generated stubs (that throw an exception).
It also improves debug logs when the "winspool" debug channel is enabled. With such detailed debug logs, we may get an idea which winspool APIs need to be implemented sooner than others.
