Fix buffer overruns in LanaFlagIsSet() and SetLanaFlag().
Normally, i shouldn't be > 7, MAX_LANA is set to 254.
CID #1102306
CID #1102305
svn path=/trunk/; revision=62633
Make sure _abnormal_termination() returns the correct result and make sure the compiler does not rely on register values in the finally and filter function.
The C++ PSEH tests now all pass.
=> We now have PSEH support for C++.
svn path=/trunk/; revision=62630
Some fixes for RtlGetFullPathName_U(str):
- Start to polish RtlpCollapsePath (Work in progress)
- Correctly zero-out the path destination buffer
They fix the following tests:
* ntdll:RtlGetFullPathName_U (2 failures to full success)
* ntdll:RtlGetFullPathName_UstrEx (2 failures to full success)
svn path=/trunk/; revision=62623
Properly check for total length in LdrpGetProcedureAddress().
It contains more than just a name.
Fixes a buffer overrun.
CID #716122
svn path=/trunk/; revision=62618
- Patch by Piotr Caban : Make it possible to activate a window with parent and no WS_CHILD flag in WS_NCLBUTTONDOWN function.
- Sync port from wine with modifications and addons.
svn path=/trunk/; revision=62610
Finally...
- Specify that we use MUTEXes instead of binary semaphores,
- Change two interface names in our code: ACPI_DEVICE_ID_LIST --> ACPI_PNP_DEVICE_ID_LIST and acpi_device_id --> acpi_pnp_device_id (only those names were changed in ACPICA).
- Implement AcpiOsPhysicalTableOverride which doesn't any table override (same behaviour as AcpiOsTableOverride).
- Latest ACPICA versions introduce the AcpiOsWaitEventsComplete API, which is used to wait for all asynchronous events to complete. But we do nothing at the moment ("inspired" from the behaviour from http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/dev/acpi/acpica/OsdSchedule.c , but I'm sure ReactOS ACPI specialists know better than me whether or not it is judicious to do so !!!)
- Extend AcpiOsRead/WriteMemory to be able to read/write 64-bit values, as required by the ACPICA implementation.
Fix the build. Now, only warnings from our code (not ACPICA) need to be fixed.
Real HW testers, please retest your real HW with this revision (or above) !!
CORE-8044 #comment Everything updated in revisions 62604 to 62608.
svn path=/trunk/; revision=62608
Addendum to revision 62606 : because of typedefs redefinitions (we, after, include acpi.h and co. together with DDK in other acpi bus drivers), we hackishly needed to disable them in actypes.h, and now we need to include ntddk *inside* acpi.h ...
Everything would be nice only if ACPICA would not have the "clever" (read: dumb) idea to define a ACPI_BIOS_ERROR macro, which is (you guessed it) already defined.... in the DDK via the standard bugcheck code macros.
So we introduce two hacks: the firs one right after the inclusion of ntddk.h *in* acpi.h to first undefine the macro (coming from bugcheck.h), *then*, we re-undefine it *after* the inclusion of acpi.h (in the precompiled header) so that drivers that need to use acpi (via the header) can after, include the ntddk.h ...
What a hack :DD
Part 2bis of our modifications to ACPICA code.
CORE-8044
svn path=/trunk/; revision=62607
Disable redundant typedefs that we already got from the inclusion of ntddk.h from elsewhere (and it was done like that in our old modifications of ACPICA).
Personally I don't like this way to go, but for the moment just apply something that (seemed to) worked before...
Part 2 of our modifications to ACPICA code.
CORE-8044
svn path=/trunk/; revision=62606
Do not assume that, when compiling from Windows, we cannot use GCC. In fact we can, and this is what we did before...
Move asm-specific code to where it should belong.
I've checked that: MSVC_asm_code(old_acpica_version) == MSVC_asm_code(new_acpica_version), so that I took its GCC equivalent from our old version of ACPICA and placed it there.
Part 1 of our modifications to ACPICA code.
CORE-8044
svn path=/trunk/; revision=62605
- Add an error message for Proprietary Software Execution Prevention
feature supported by recent CPUs.
- TODO: Implement this feature in the kernel.
svn path=/trunk/; revision=62598
ACHTUNG! ACHTUNG! Even if you can build ROS with MSVC 2008, you cannot boot it (see the below-mentioned JIRA report) ACHTUNG! ACHTUNG!
CORE-8023 #comment MSVC 2008 build resurrected in revision 62595.
svn path=/trunk/; revision=62595
For host-tools, including stdint.h when using MSVC is not reliable, so use a tried-&-tested solution (see mkshelllink & geninf tools): include stdint.h if we don't use MSVC, otherwise define just what's needed.
Another solution would be to create a include/host/stdint.h which does this same job, and in the host-tools, include this file.
CORE-8023
svn path=/trunk/; revision=62594
Move some defines where they belong (they are used in mkhive because they are employed in cmlib functions, and cmlib itself uses them too).
svn path=/trunk/; revision=62592
- Verify valid IRQL in KeDelayExecutionThread, just like in KeWait*
- Return from KeDelayExecutionThread after yielding execution
svn path=/trunk/; revision=62590
Reshuffle the test a bit so that it clearly fails on ReactOS:
- Gather creation timestamp right after the first creation and always compare to it. This is to workaround the move = copy + delete hack from ReactOS which is resetting the timestamps (and thus making the test pass ;-)).
- Wait more than 20ms (1s). If Microsoft FastFAT has a creation resolution of 10ms, we don't. So it would hide the thing as well.
With such changes, the test still works on Windows, whereas it fails on ReactOS
CORE-7272
svn path=/trunk/; revision=62589
