Alex Ionescu | 20 Oct 20:50 2014
Picon

Re: [ros-diffs] [hbelusca] 64773: [FAST486]: Do not call RtlCopyMemory for copying few bytes (2 and 4).

memcpy already has logic to handle, 1, 2, 4, 8, etc.. sizes.

Best regards,
Alex Ionescu

On Thu, Oct 16, 2014 at 2:48 PM, <hbelusca-FK+hrUIho1S2+TBAgxGDFw@public.gmane.org> wrote:
Author: hbelusca
Date: Thu Oct 16 21:48:18 2014
New Revision: 64773

URL: http://svn.reactos.org/svn/reactos?rev=64773&view=rev
Log:
[FAST486]: Do not call RtlCopyMemory for copying few bytes (2 and 4).

Modified:
    trunk/reactos/lib/fast486/fast486.c
    trunk/reactos/lib/fast486/opgroups.c

Modified: trunk/reactos/lib/fast486/fast486.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fast486/fast486.c?rev=64773&r1=64772&r2=64773&view=diff
==============================================================================
--- trunk/reactos/lib/fast486/fast486.c [iso-8859-1] (original)
+++ trunk/reactos/lib/fast486/fast486.c [iso-8859-1] Thu Oct 16 21:48:18 2014
<at> <at> -117,7 +117,6 <at> <at>
 Fast486MemReadCallback(PFAST486_STATE State, ULONG Address, PVOID Buffer, ULONG Size)
 {
     UNREFERENCED_PARAMETER(State);
-
     RtlMoveMemory(Buffer, (PVOID)Address, Size);
 }

<at> <at> -126,7 +125,6 <at> <at>
 Fast486MemWriteCallback(PFAST486_STATE State, ULONG Address, PVOID Buffer, ULONG Size)
 {
     UNREFERENCED_PARAMETER(State);
-
     RtlMoveMemory((PVOID)Address, Buffer, Size);
 }


Modified: trunk/reactos/lib/fast486/opgroups.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/fast486/opgroups.c?rev=64773&r1=64772&r2=64773&view=diff
==============================================================================
--- trunk/reactos/lib/fast486/opgroups.c        [iso-8859-1] (original)
+++ trunk/reactos/lib/fast486/opgroups.c        [iso-8859-1] Thu Oct 16 21:48:18 2014
<at> <at> -2016,6 +2016,7 <at> <at>

 FAST486_OPCODE_HANDLER(Fast486OpcodeGroup0F01)
 {
+    // FAST486_TABLE_REG TableReg;
     UCHAR TableReg[6];
     FAST486_MOD_REG_RM ModRegRm;
     BOOLEAN OperandSize, AddressSize;
<at> <at> -2054,8 +2055,9 <at> <at>
             }

             /* Fill the 6-byte table register */
-            RtlCopyMemory(TableReg, &State->Gdtr.Size, sizeof(USHORT));
-            RtlCopyMemory(&TableReg[sizeof(USHORT)], &State->Gdtr.Address, sizeof(ULONG));
+            // TableReg = State->Gdtr;
+            *((PUSHORT)&TableReg) = State->Gdtr.Size;
+            *((PULONG)&TableReg[sizeof(USHORT)]) = State->Gdtr.Address;

             /* Store the GDTR */
             return Fast486WriteMemory(State,
<at> <at> -2076,8 +2078,9 <at> <at>
             }

             /* Fill the 6-byte table register */
-            RtlCopyMemory(TableReg, &State->Idtr.Size, sizeof(USHORT));
-            RtlCopyMemory(&TableReg[sizeof(USHORT)], &State->Idtr.Address, sizeof(ULONG));
+            // TableReg = State->Idtr;
+            *((PUSHORT)&TableReg) = State->Idtr.Size;
+            *((PULONG)&TableReg[sizeof(USHORT)]) = State->Idtr.Address;

             /* Store the IDTR */
             return Fast486WriteMemory(State,
<at> <at> -2117,7 +2120,8 <at> <at>
             }

             /* Load the new GDT */
-            State->Gdtr.Size = *((PUSHORT)TableReg);
+            // State->Gdtr = TableReg;
+            State->Gdtr.Size = *((PUSHORT)&TableReg);
             State->Gdtr.Address = *((PULONG)&TableReg[sizeof(USHORT)]);

             /* In 16-bit mode the highest byte is masked out */
<at> <at> -2156,7 +2160,8 <at> <at>
             }

             /* Load the new IDT */
-            State->Idtr.Size = *((PUSHORT)TableReg);
+            // State->Idtr = TableReg;
+            State->Idtr.Size = *((PUSHORT)&TableReg);
             State->Idtr.Address = *((PULONG)&TableReg[sizeof(USHORT)]);

             /* In 16-bit mode the highest byte is masked out */



_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Love Nystrom | 20 Oct 19:15 2014
Picon

Re: RtlUlonglongByteSwap (Thomas Faber)


Fastcall passes 64 bit arguments on the stack.

Aaagh.. I didn't know that.. Thanks for pointing it out.
IMO that's incredibly stupid, as a 32-bit CPU (or x64 running 32bit)
uses the register combination EAX:EDX for 64 bit integers, and
EAX:EDX is used for 64 bit return values (again in 32bit mode).
The compiler designers need to smarten up!

Best Regards
  Love
And yes, this is about an ntdll/ntoskrnl export, so we must be binary compatible with what Windows does. But the implementation that is normally used is an inline/intrinsic function anyway. This is just about the export (or rather, importing it). On 2014-10-17 00:24, Love Nystrom wrote:
> <at> Timo, <at> Thomas, <at> Ged > > Byte order swappers should always be fastcall for perfomance reasons. > They have no need for the benefits of the cdecl call convention. > Using cdecl in this case would make the binary code pitifully slow. > > Think about it for a bit.. Some pseudocode show what I mean: > > ..CDECL... > > push hi > push lo > call Swapper > mov dsthi, edx > mov dstlo, eax > add esp, 4 > ... > > // UINT64 __cdecl > Swapper: > push ebp > mov ebp, esp > mov eax, ebp+8 // lo > mov eax, ebp+12 // hi > bswap > xchg eax, edx > bswap > pop ebp > ret > > ..FASTCALL... > > mov edx, hi > mov eax, lo > call Swapper > mov dsthi, edx > mov dstlo, eax > ... > > // UINT64 __declspec(naked) __fastcall > Swapper: > bswap > xchg eax, edx > bswap > ret > > Sadly the compiler designers were not (yet) clever enough > to make the fastcall regs EAX, EDX, ECX, in that exact order, > but even as it stands today.. > > Swapper: > mov eax, ecx > bswap > xchg eax, edx > bswap > ret > > > (If you actually link against a binary swapper compiled out of your > control with > cdecl convention, the argument falls of course, as you must comply with > the binary.) > > Keep up the good work.. > Best Regards > // Love

_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Alexander Rechitskiy | 18 Oct 23:51 2014
Picon

Re: Claim your commits

it works now!
 
07.10.2014, 19:19, "David Quintana (gigaherz)" <gigaherz <at> gmail.com>:
"This website is under heavy load" -- Maybe later, if the site survives ;P

On 7 October 2014 14:19, Alexander Rechitskiy <art1st-tm <at> yandex.ru> wrote:
Dear ReactOS Developers 
 
Please join Black Duck Open Hub (ex ohloh) and claim your commits for ReactOS and other opensource projects.
 
 
 
This is a simple way to prove the importance of ReaсtOS for the whole opensource  community by power of numbers.
 
 
 
--
Best regards,
Alexander Rechitskiy

_______________________________________________
Ros-dev mailing list
Ros-dev <at> reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
,

_______________________________________________
Ros-dev mailing list
Ros-dev <at> reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev

 
 
--
Best regards,
Alexander Rechitskiy
_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Thomas Faber | 18 Oct 12:44 2014

Re: [ros-diffs] [akhaldi] 64795: [CMAKE] * Make the minimum required version 2.8. * Remove redundant psdk dependencies. * Tidy up CMake files.

On 2014-10-18 01:28, akhaldi <at> svn.reactos.org wrote:
> [CMAKE]
> * Make the minimum required version 2.8.

As Víctor just found out the hard way, using target_include_directories
makes our minimum version 2.8.11. Should we set that as the minimum to
create a more obvious error message?

Current error:
CMake Error at dll/keyboard/CMakeLists.txt:92 (target_include_directories):
  Unknown CMake command "target_include_directories".

_______________________________________________
Ros-dev mailing list
Ros-dev <at> reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Love Nystrom | 17 Oct 00:24 2014
Picon

Re: RtlUlonglongByteSwap

 <at> Timo,  <at> Thomas,  <at> Ged

Byte order swappers should always be fastcall for perfomance reasons.
They have no need for the benefits of the cdecl call convention.
Using cdecl in this case would make the binary code pitifully slow.

Think about it for a bit.. Some pseudocode show what I mean:

..CDECL...

     push hi
     push lo
     call Swapper
     mov  dsthi, edx
     mov  dstlo, eax
     add  esp, 4
     ...

// UINT64 __cdecl
Swapper:
     push  ebp
     mov   ebp, esp
     mov   eax, ebp+8  // lo
     mov   eax, ebp+12 // hi
     bswap
     xchg  eax, edx
     bswap
     pop   ebp
     ret

..FASTCALL...

     mov  edx, hi
     mov  eax, lo
     call Swapper
     mov  dsthi, edx
     mov  dstlo, eax
     ...

// UINT64 __declspec(naked) __fastcall
Swapper:
     bswap
     xchg eax, edx
     bswap
     ret

Sadly the compiler designers were not (yet) clever enough
to make the fastcall regs EAX, EDX, ECX, in that exact order,
but even as it stands today..

Swapper:
     mov   eax, ecx
     bswap
     xchg  eax, edx
     bswap
     ret

(If you actually link against a binary swapper compiled out of your 
control with
cdecl convention, the argument falls of course, as you must comply with 
the binary.)

Keep up the good work..
Best Regards
// Love
Alex Ionescu | 16 Oct 07:59 2014
Picon

Re: [ros-diffs] [tkreuzer] 64757: [NTOSKRNL] Don't use an uninitialized variable in MmArmAccessFault (Alex, please review). Brought to you by MSVC runtime checks.

Wow, does static analyzer really not catch this?

Best regards,
Alex Ionescu

On Wed, Oct 15, 2014 at 3:03 PM, <tkreuzer-FK+hrUIho1S2+TBAgxGDFw@public.gmane.org> wrote:
Author: tkreuzer
Date: Wed Oct 15 22:03:50 2014
New Revision: 64757

URL: http://svn.reactos.org/svn/reactos?rev=64757&view=rev
Log:
[NTOSKRNL]
Don't use an uninitialized variable in MmArmAccessFault (Alex, please review). Brought to you by MSVC runtime checks.

Modified:
    trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c

Modified: trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c?rev=64757&r1=64756&r2=64757&view=diff
==============================================================================
--- trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c   [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/mm/ARM3/pagfault.c   [iso-8859-1] Wed Oct 15 22:03:50 2014
<at> <at> -1511,7 +1511,7 <at> <at>
     NTSTATUS Status;
     PMMSUPPORT WorkingSet;
     ULONG ProtectionCode;
-    PMMVAD Vad;
+    PMMVAD Vad = NULL;
     PFN_NUMBER PageFrameIndex;
     ULONG Color;
     BOOLEAN IsSessionAddress;



_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Thomas Faber | 15 Oct 22:46 2014

Re: [ros-diffs] [pschweitzer] 64752: [NTFS] Implement NtfsDateTimeToFileTime() which convert epoch time (1970) to Windows time (1601)

On 2014-10-15 22:23, pschweitzer <at> svn.reactos.org wrote:
> +/* See:
> + -> http://msdn.microsoft.com/en-us/library/ms724228
> + -> http://bos.asmhackers.net/docs/filesystems/ntfs/standard.html#layout
> + */
> +VOID
> +NtfsDateTimeToFileTime(ULONGLONG NtfsTime,
> +                       PLARGE_INTEGER SystemTime)
> +{
> +
> +    SystemTime->QuadPart = NtfsTime + 116444736000000000;
> +}

Doesn't NTFS use FILETIME directly? I thought that's the reason it's
called "file time" in the first place. ;)
Wikipedia says
"Date range: 1 January 1601 – 28 May 60056 (File times are 64-bit
 numbers counting 100-nanosecond intervals (ten million per second)
 since 1601, which is 58,000+ years)"
and your link doesn't seem to disagree.

_______________________________________________
Ros-dev mailing list
Ros-dev <at> reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
Timo Kreuzer | 15 Oct 21:11 2014
Picon

Re: [ros-diffs] [hbelusca] 64747: [NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT mode), and use sizeof(object) instead of sizeof(type_of_object).


Looks like bugs

Am 15.10.2014 00:46, schrieb hbelusca@...:
> Author: hbelusca
> Date: Tue Oct 14 22:46:40 2014
> New Revision: 64747
>
> URL: http://svn.reactos.org/svn/reactos?rev=64747&view=rev
> Log:
> [NTVDM]: Zero-fill memory with RtlZeroMemory (that exists also in NT mode), and use sizeof(object)
instead of sizeof(type_of_object).

>       /* Clear the current directory buffer */
> -    ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
> +    RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));

>  <at>  <at>  -2901,7 +2901,7  <at>  <at> 
>       WCHAR Buffer[256];
>   
>       /* Clear the current directory buffer */
> -    ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));
> +    RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories));

>  <at>  <at>  -1901,7 +1901,7  <at>  <at> 
>   
>   VOID VgaClearMemory(VOID)
>   {
> -    ZeroMemory(VgaMemory, sizeof(VgaMemory));
> +    RtlZeroMemory(VgaMemory, sizeof(VgaMemory));
>   }
>   
>   
Ged Murphy | 15 Oct 19:08 2014
Picon

Re: [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes stack corruption CORE-8632 #resolve

There shouldn't really be anything using this header

-----Original Message-----
From: Ros-diffs [mailto:ros-diffs-bounces@...] On Behalf Of tfaber@...
Sent: 15 October 2014 17:38
To: ros-diffs@...
Subject: [ros-diffs] [tfaber] 64749: [PSDK] - Use macro version of RtlUlonglongByteSwap in winternl.h
because using the fastcall version causes stack corruption CORE-8632 #resolve

Author: tfaber
Date: Wed Oct 15 16:38:13 2014
New Revision: 64749

URL: http://svn.reactos.org/svn/reactos?rev=64749&view=rev
Log:
[PSDK]
- Use macro version of RtlUlonglongByteSwap in winternl.h because using the fastcall version causes
stack corruption
CORE-8632 #resolve

Modified:
    trunk/reactos/include/psdk/winternl.h

Modified: trunk/reactos/include/psdk/winternl.h
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?rev=64749&r1=64748&r2=64749&view=diff
==============================================================================
--- trunk/reactos/include/psdk/winternl.h	[iso-8859-1] (original)
+++ trunk/reactos/include/psdk/winternl.h	[iso-8859-1] Wed Oct 15 16:38:13 2014
 <at>  <at>  -2310,7 +2310,12  <at>  <at> 
 BOOLEAN   WINAPI RtlTimeToSecondsSince1980(const LARGE_INTEGER *,LPDWORD);
 BOOL      WINAPI RtlTryEnterCriticalSection(RTL_CRITICAL_SECTION *);

+#ifdef __REACTOS__
 ULONGLONG __fastcall RtlUlonglongByteSwap(ULONGLONG);
+#define RtlUlonglongByteSwap(_x) _byteswap_uint64((_x)) #else ULONGLONG 
+__cdecl RtlUlonglongByteSwap(ULONGLONG); #endif
 DWORD     WINAPI RtlUnicodeStringToAnsiSize(const UNICODE_STRING*);
 NTSTATUS  WINAPI RtlUnicodeStringToAnsiString(PANSI_STRING,PCUNICODE_STRING,BOOLEAN);
 NTSTATUS  WINAPI RtlUnicodeStringToInteger(const UNICODE_STRING *,ULONG,ULONG *);
Alex Ionescu | 11 Oct 18:46 2014
Picon

Re: [ros-diffs] [tfaber] 64665: [NTOS:KE] - Implement KiRaiseSecurityCheckFailure[Handler] to handle int 0x29 (__fastfail). Based on patch by Timo Kreuzer. (Yes, this is a Windows 8 feature. However all it does is...

Now improve the LIST_ENTRY Macros to use it :)

Best regards,
Alex Ionescu

On Sat, Oct 11, 2014 at 6:15 AM, <tfaber-FK+hrUIho1S2+TBAgxGDFw@public.gmane.org> wrote:
Author: tfaber
Date: Sat Oct 11 13:15:10 2014
New Revision: 64665

URL: http://svn.reactos.org/svn/reactos?rev=64665&view=rev
Log:
[NTOS:KE]
- Implement KiRaiseSecurityCheckFailure[Handler] to handle int 0x29 (__fastfail). Based on patch by Timo Kreuzer.
(Yes, this is a Windows 8 feature. However all it does is improve the debugging experience, and we have a need for that)
CORE-8419

Modified:
    trunk/reactos/include/reactos/mc/bugcodes.mc
    trunk/reactos/ntoskrnl/ke/i386/trap.s
    trunk/reactos/ntoskrnl/ke/i386/traphdlr.c

Modified: trunk/reactos/include/reactos/mc/bugcodes.mc
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/mc/bugcodes.mc?rev=64665&r1=64664&r2=64665&view=diff
==============================================================================
--- trunk/reactos/include/reactos/mc/bugcodes.mc        [iso-8859-1] (original)
+++ trunk/reactos/include/reactos/mc/bugcodes.mc        [iso-8859-1] Sat Oct 11 13:15:10 2014
<at> <at> -1128,7 +1128,7 <at> <at>
 Run a system diagnostic utility supplied by your hardware manufacturer.
 In particular, run a memory check, and check for faulty or mismatched
 memory. Try changing video adapters.
-
+
 Disable or remove any newly installed hardware and drivers. Disable or
 remove any newly installed software. If you need to use Safe Mode to
 remove or disable components, restart your computer, press F8 to select
<at> <at> -1322,7 +1322,7 <at> <at>
 SymbolicName=DRIVER_CORRUPTED_EXPOOL
 Language=English
 A device driver has pool.
-
+
 Check to make sure any new hardware or software is properly installed.
 If this is a new installation, ask your hardware or software manufacturer
 for any ReactOS updates you might need.
<at> <at> -1478,7 +1478,7 <at> <at>
 must not contain such items.  Usually this is memory being freed.  This
 is usually caused by a device driver that has not cleaned up properly
 before freeing memory.
-
+
 If Parameter1 == 1, an attempt was made to queue an executive worker item
 with a usermode execution routine.
 .
<at> <at> -1570,3 +1570,11 <at> <at>
 Language=English
 An attempt was made to execute to non-executable memory.
 .
+
+MessageId=0x139
+Severity=Success
+Facility=System
+SymbolicName=KERNEL_SECURITY_CHECK_FAILURE
+Language=English
+A critical kernel security check failed.
+.

Modified: trunk/reactos/ntoskrnl/ke/i386/trap.s
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/trap.s?rev=64665&r1=64664&r2=64665&view=diff
==============================================================================
--- trunk/reactos/ntoskrnl/ke/i386/trap.s       [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/trap.s       [iso-8859-1] Sat Oct 11 13:15:10 2014
<at> <at> -59,9 +59,11 <at> <at>
 idt _KiTrap11,         INT_32_DPL0  /* INT 11: Align Check Exception (#AC)  */
 idt _KiTrap0F,         INT_32_DPL0  /* INT 12: Machine Check Exception (#MC)*/
 idt _KiTrap0F,         INT_32_DPL0  /* INT 13: SIMD FPU Exception (#XF)     */
-REPEAT 22
-idt _KiTrap0F,         INT_32_DPL0  /* INT 14-29: UNDEFINED INTERRUPTS      */
+REPEAT 21
+idt _KiTrap0F,         INT_32_DPL0  /* INT 14-28: UNDEFINED INTERRUPTS      */
 ENDR
+idt _KiRaiseSecurityCheckFailure, INT_32_DPL3
+                                    /* INT 29: Handler for __fastfail       */
 idt _KiGetTickCount,   INT_32_DPL3  /* INT 2A: Get Tick Count Handler       */
 idt _KiCallbackReturn, INT_32_DPL3  /* INT 2B: User-Mode Callback Return    */
 idt _KiRaiseAssertion, INT_32_DPL3  /* INT 2C: Debug Assertion Handler      */
<at> <at> -113,6 +115,7 <at> <at>
 TRAP_ENTRY KiTrap10, KI_PUSH_FAKE_ERROR_CODE
 TRAP_ENTRY KiTrap11, KI_PUSH_FAKE_ERROR_CODE
 TRAP_ENTRY KiTrap13, KI_PUSH_FAKE_ERROR_CODE
+TRAP_ENTRY KiRaiseSecurityCheckFailure, KI_PUSH_FAKE_ERROR_CODE
 TRAP_ENTRY KiGetTickCount, KI_PUSH_FAKE_ERROR_CODE
 TRAP_ENTRY KiCallbackReturn, KI_PUSH_FAKE_ERROR_CODE
 TRAP_ENTRY KiRaiseAssertion, KI_PUSH_FAKE_ERROR_CODE

Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/traphdlr.c?rev=64665&r1=64664&r2=64665&view=diff
==============================================================================
--- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c   [iso-8859-1] (original)
+++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c   [iso-8859-1] Sat Oct 11 13:15:10 2014
<at> <at> -1462,6 +1462,46 <at> <at>

 VOID
 FASTCALL
+KiRaiseSecurityCheckFailureHandler(IN PKTRAP_FRAME TrapFrame)
+{
+    /* Save trap frame */
+    KiEnterTrap(TrapFrame);
+
+    /* Decrement EIP to point to the INT29 instruction (2 bytes, not 1 like INT3) */
+    TrapFrame->Eip -= 2;
+
+    /* Check if this is a user trap */
+    if (KiUserTrap(TrapFrame))
+    {
+        /* Dispatch exception to user mode */
+        KiDispatchException1Args(STATUS_STACK_BUFFER_OVERRUN,
+                                 TrapFrame->Eip,
+                                 TrapFrame->Ecx,
+                                 TrapFrame);
+    }
+    else
+    {
+        EXCEPTION_RECORD ExceptionRecord;
+
+        /* Bugcheck the system */
+        ExceptionRecord.ExceptionCode = STATUS_STACK_BUFFER_OVERRUN;
+        ExceptionRecord.ExceptionFlags = EXCEPTION_NONCONTINUABLE;
+        ExceptionRecord.ExceptionRecord = NULL;
+        ExceptionRecord.ExceptionAddress = (PVOID)TrapFrame->Eip;
+        ExceptionRecord.NumberParameters = 1;
+        ExceptionRecord.ExceptionInformation[0] = TrapFrame->Ecx;
+
+        KeBugCheckWithTf(KERNEL_SECURITY_CHECK_FAILURE,
+                         TrapFrame->Ecx,
+                         (ULONG_PTR)TrapFrame,
+                         (ULONG_PTR)&ExceptionRecord,
+                         0,
+                         TrapFrame);
+    }
+}
+
+VOID
+FASTCALL
 KiGetTickCountHandler(IN PKTRAP_FRAME TrapFrame)
 {
     UNIMPLEMENTED_DBGBREAK();



_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Alex Ionescu | 11 Oct 18:45 2014
Picon

Re: [ros-diffs] [tkreuzer] 64658: [NTDLL] Don't assert that the caller of exported APIs passes correct parameters.

Windows does. Why shouldn't we? It's a non-documented API.

Best regards,
Alex Ionescu

On Sat, Oct 11, 2014 at 1:52 AM, <tkreuzer-FK+hrUIho1S2+TBAgxGDFw@public.gmane.org> wrote:
Author: tkreuzer
Date: Sat Oct 11 08:52:33 2014
New Revision: 64658

URL: http://svn.reactos.org/svn/reactos?rev=64658&view=rev
Log:
[NTDLL]
Don't assert that the caller of exported APIs passes correct parameters.

Modified:
    trunk/reactos/dll/ntdll/ldr/ldrapi.c

Modified: trunk/reactos/dll/ntdll/ldr/ldrapi.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/ntdll/ldr/ldrapi.c?rev=64658&r1=64657&r2=64658&view=diff
==============================================================================
--- trunk/reactos/dll/ntdll/ldr/ldrapi.c        [iso-8859-1] (original)
+++ trunk/reactos/dll/ntdll/ldr/ldrapi.c        [iso-8859-1] Sat Oct 11 08:52:33 2014
<at> <at> -209,9 +209,6 <at> <at>
         /* A normal failure */
         return STATUS_INVALID_PARAMETER_3;
     }
-
-    /* Do or Do Not. There is no Try */
-    ASSERT((Disposition != NULL) || !(Flags & LDR_LOCK_LOADER_LOCK_FLAG_TRY_ONLY));

     /* If the flag is set, make sure we have a valid pointer to use */
     if ((Flags & LDR_LOCK_LOADER_LOCK_FLAG_TRY_ONLY) && !(Disposition))



_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev

Gmane