This reverts commit 0.4.15-dev-791-g
6d7ebc2048
It was a workaround just. To bypass sysaudio. It had a very positive effect on
our playback performance, but using the different codepaths did also lead to
regressions, that I have no idea how to address, therefore I think it's my
personal responsibility to revert it. I guess it's better to improve on the
code-paths that we intend to use finally, instead of fixing what will
be dead paths in the future.
The revert will fix:
- CORE-17277 crash of dsound:duplex on "GCCLin_x86 on Test VBox"
- CORE-17278 crash of dsound:capture on "GCCLin_x86 on Test VBox"
- CORE-17285 Realtek HD Audio does no longer work in ReactOS
But ofc now we will suffer again from very severe things that the hack could workaround:
- CORE-13202 Unhandled exception from wdmaud.drv when recording sound in Scratch 1.4 leads to app-crash
- CORE-13488 A deadlock in "DiabloII" character selection screen and "The Lion King II"
- CORE-8726/CORE-9986/CORE-16564 AC97 driver from rapps will need reboot-orgies again, does not longer
work in the same session that we installed the driver
- CORE-9981 "DosBox + Commander Keen6" totally garbled sound output instead of music
"ScummVM 2.0 with Monkey Island 2" totally garbled sound output instead of music
- the test execution times of "GCCLin_x86 on Test VBox" will almost double
Press'n'Hold of a button, then leaving the button rect
should redraw the button in unpressed state
Thanks to JIRA user 'I_kill_Bugs' for perfecting
my initial experiments to fix that.
It regressed by 0.4.9-dev-719-g
b3fb8555bf
No need to sync anything with Wine, their code is
correct on Wine head. The bug was in ros specific diff.
Otherwise we'd call ZwQuerySection on an invalid handle and get:
(ntoskrnl/mm/section.c:4320) Failed to reference section: 0xc0000008
Also correctly check DllCharacteristics: If the argument is missing, the
file is _not_ a system file, i.e. we should check for restrictions.
Related to #3249. IACLCustomMRU has a special case of TypedURLs. The TypedURLs key consists of the registry values of "url1", "url2", "url3" etc instead of "MRUList", "a", "b" etc. CORE-9281
CORE-17312
Hide everything under the same foreground & background colors, so that
the actual color and text blanking reset does not create a visual "blinking".
Then, blank the text and finally reset the actual foreground &
background colors.
We do this because we cannot do the screen scrolling trick that would
allow to change both the text and the colors at the same time (the
function is currently not available in our console "emulation" layer).
Dedicated to the hard work of Joachim Henze! xD
This reverts part of commit 043a98dd (see also commit b2aeafca).
Contrary to what I assumed in commit 043a98dd (and was also assumed in
the older commit b2aeafca), we cannot use the singled-linked lists to
queue and dequeue the PnP device-install events, because:
- the events must be treated from the oldest to the newest ones, for
consistency, otherwise this creates problems, as shown by e.g. CORE-16103;
- the system singled-linked lists only offer access to the top of the
list (like a stack) instead of to both the top and the bottom of the
list, as would be required for a queue. Using the SLISTs would mean
that only the newest-received events would be treated first, while the
oldest (which were the first received) events would be treated last,
and this is wrong.
Therefore one must use e.g. the standard doubly-linked list. Also, using
locked operations (insertion & removal) on the list of device-install
events is necessary, because these operations are done concurrently by
two different threads: PnpEventThread() and DeviceInstallThread().
Since the interlocked linked list functions are not available in user-mode,
we need to use instead locking access through e.g. a mutex.
Add some tests for "TypedURLs" of a special case. The TypedURLs registry key consists of the registry values of "url1", "url2", "url3" etc instead of "MRUList", "a", "b" etc. CORE-9281
A ros specific addition that does not exist on Windows.
Default for Server is still the classic shutdown dlg,
no change on that.
But interested users can manually now create the registry setting
"EnforceFriendlyShutdown" REG_DWORD to "1"
within "SYSTEM\\CurrentControlSet\\Control\\Windows"
to allow overriding the Windows default behavior
without relying on changing the product version number, because
that would not be side-effect-free.
Addendum to 0.4.15-dev-650-g
2edcb58e65
- Move initialization of bc->raw_params also in BatchParams().
- The bc->raw_params, i.e. the unparsed batch/CALL parameters obtained
with %*, has any leading and trailing whitespace trimmed
(since Windows 2000+).
- Fail if no parameter is provided.
- The "CALL :label args..." syntax is available only when command extensions
are enabled. Fail if this syntax is used outside of a batch context.
- Reparse the CALL command parameter with the command parser, in order
to accurately parse and interpret it as a possible command (including
escape carets, etc...) and not duplicate the logic.
** CURRENT Windows' CMD-compatibility LIMITATION ** (may be lifted in
a "ROS-specific" running mode of CMD): only allow standard commands to
be specified as parameter of the CALL command.
This reparsing behaviour can be observed in Windows' CMD, by dumping
the interpreted commands after enabling the cmd!fDumpParse flag from
a debugger (using public symbols).
- When reparsing, we should tell the parser to NOT ignore lines that
start with a colon, because in this situation these are to be
considered as valid "commands" (for parsing "CALL :label").
* For Windows' CMD-compatibility, the remaining escape carets need to
be doubled again so that, after the new parser step, they are escaped
back to their original form. But then we also need to do it the "buggy"
way à la Windows, where carets in quotes are doubled either! However
when being re-parsed, since they are in quotes they remain doubled!!
(see "Phase 6" in https://stackoverflow.com/a/4095133/13530036 ).
* A MSCMD_CALL_QUIRKS define allows to disable this buggy behaviour,
and instead tell the parser to not not interpret the escape carets.
- When initializing a new batch context when the "CALL :label" syntax is
used, ensure that we reuse the same batch file position pointer as its
parent, so as to have correct call label ordering behaviour.
That is,
:label
ECHO hi
CALL :label
:label
ECHO bye
should display:
hi
bye
bye
i.e., the CALL calls the second label instead of the first one (and
thus entering into an infinite loop).
Finally, the "CALL :label" syntax strips the first ':' away, so, as a
side-effect, the command "CALL :EOF" fails (otherwise it would perform
a "GOTO :EOF" and succeeds), while "CALL ::EOF" succeeds.
Fixes some cmd_winetests.
Tests adapted from https://stackoverflow.com/q/31987023/13530036
and from https://stackoverflow.com/a/38938416/13530036 .
- Test when CALL with a label containing /? actually calls GOTO's help,
and test when CALL's help is displayed instead.
- Test when CALL with a label containing /?, but specified by variables,
do NOT trigger GOTO's or CALL's help.
- Test the effect of the presence of escape carets in CALL label string.
- Test that CALL indeed supports double delayed expansion. Adapted from
https://stackoverflow.com/a/31990563/13530036 .
All these modifications have been verified with Windows' CMD, either
by using written cmd_rostests and the existing cmd_winetests, or
manually by enabling the flags cmd!fDumpTokens and cmd!fDumpParse
(available in the public symbols) and analyzing how the tokens are
being parsed, as well as the generated command tree.
See also the following links for more details (but remember that these
observations have to be double-checked in Windows' CMD!):
* Parser rules: https://stackoverflow.com/a/4095133/13530036
* Discussion: https://www.dostips.com/forum/viewtopic.php?f=3&t=8355
* Numbers parsing: https://www.dostips.com/forum/viewtopic.php?t=3758
* Label names vs. GOTO and CALL: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803
and: https://www.dostips.com/forum/viewtopic.php?f=3&t=3803&p=55405#p55405
- Fix REM command parsing. A C_COMMAND-like structure should still
be built, so that it can show up during batch command echo. However
some specific handling needs to be done, so use instead a new C_REM
command type.
Escape carets are parsed differently than usual: they are explicitly
kept in the command line and don't participate in line continuations.
Also, the Windows' CMD behaviour is to discards everything before the
last line continuation.
- Prefix operator '@' (the "silent" operator) is parsed as a separate
command. Thus, the command @@foo@bar is parsed as: '@', '@', 'foo@bar'.
- Improve the checks for numbered redirection.
For this purpose, we check whether this is a number, that is in first
position in the current parsing buffer or is preceded by a whitespace-
like separator, including standard command operators (excepting '@' !)
and double-quotes.
- Empty command blocks, i.e. "( )", standing by themselves, or present
in IF or FOR commands, are considered invalid. (The closing parenthesis
is considered "unexpected".)
- Ignore single closing parenthesis when being outside of command blocks,
thus interpreting it as a command, and ignore explicitly everything
following on the same line, including line continuations.
This very specific situation can happen e.g. while running in batch mode,
when jumping to a label present inside a command block.
See the code for a thorough explanation.
- Detect whether a parenthesized block is not terminated at the end
of a command stream (getting a NUL character instead of a newline),
and if so, bail out early instead of entering into an infinite loop.
- Perform a similar check for the parenthesized list in FOR commands.
- Initialize the static 'InsideBlock' value to a known value.
- The '&' operator (multi-commmand) is allowed to have an empty RHS.
When such situation occurs, turn the CurrentTokenType to TOK_END
so as to avoid a parse error later on.
- The main body of a IF statement, or its 'else' clause, as well as
the main body of a FOR statement, must not be empty, otherwise this
is considered a syntax error. If so, call ParseError() that sets
the 'bParseError' flag, and forcing all batch execution to stop.
