This option is only useful for the i386 architecture and breaks ARM builds.
Reviewed-by: Victor Perevertkin <victor.perevertkin@reactos.org>
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Some compilers call it 'arm64', while others prefer 'aarch64'. It's a big mess,
thanks Arm Ltd...
Reviewed-by: Stanislav Motylkov <x86corez@gmail.com>
Reviewed-by: Serge Gautherie <reactos-git_serge_171003@gautherie.fr>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Not defining the type breaks the compilation on (at least arm) Linux. Add a check for Linux-as-build-host to make it pass.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Only resources of HAL were checked against conflicts, not those of PnP Manager
Let IoReportResourceForDetection() make a silent conflict check.
Otherwise IopCheckResourceDescriptor() will always return 'no conflict'.
CORE-17789
As we are a non PNP driver, the call chain will be
DriverEntry -> VidePortInitialize -> VideoPortFindAdapter -> HwFindAdapter.
If legacy resources are available, we will fail VGAFindAdapter,
so DriverEntry will fail, so vgamp.sys driver won't be used.
CORE-17789
Logspam started during 0.4.9-dev'ing when zipfldr got committed, logspam became much worse by
0.4.10-dev-599-g 932df378bf
But the actual bug of 'calling those functions when not needed' is much older than that.
I do intend to port this improvement back into older rls-branches.
Previous code did not detect equal resource ranges as conflicting.
Thanks Hervé Poussineau for pointing this out!
Meanwhile, simplify the code to make it more readable.
In 0.4.14-dev-1321-g d6e0fe78e7
we introduced the following compiler warning for MSVC2010 release build:
reactos/base/applications/notepad/lang/es-ES.rc(12) : warning RC4204 : ASCII character not equivalent to virtual key code
That warning was muted without investing too much love by
0.4.15-dev-2469-g d0bb775774
Today we apply the proper fix that brings us back in sync with other languages.
I do intend to port the proper fix back to 0.4.14RC as well.
Revert my last dsound fix, because it does not fix the actual problem with audio formats support. It only makes the situation worse. It prevents the error when creating an audio stream, but the sound is not playing correctly, both in ReactOS and Windows (with our dsound.dll). Without this fix, it works perfectly on Windows, but does not in ROS.
In particular, the sound is not playing properly in AIMP 4.71 with other audio formats besides default (44100 Hz, 16 bit, stereo). And any other apps which request these audio formats may be also affected as well.
Force the status back to failure, because otherwise the badly required code is not executed at all.
I've made a more correct fix(es) in other audio component(s) instead and will submit them if further PRs.
This reverts commit 183566ee58.
CORE-10907
