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
