Thomas Faber | 23 Oct 14:22 2014

Re: [ros-diffs] [jgardou] 64911: [USER32] - Fix LookupIconIdFromDirectoryEx, returning 0 when no matching entry is found. - Fix error handling when opening a cursor file. - Various code beautification here and the...

On 2014-10-23 11:32, jgardou@... wrote:
> -    if ( dwFileSize < (sizeof(*dir) + sizeof(dir->idEntries[0])*(dir->idCount-1)) )
> +    if (dwFileSize < (sizeof(*dir) + FIELD_OFFSET(CURSORICONFILEDIR, idEntries[dir->idCount])))

Did you mean to remove the sizeof(*dir)?
Alexander Rechitskiy | 23 Oct 11:19 2014
Picon

Tuesday is a best day for software\pr releases

Tuesday is a best day for software\pr releases. 
 
This conclusion is based on the analysis of the number of downloads and visits to the site ReactOS.org
In normal times Tuesday - a day of peak attendance or the day before the day of peak attendance.
 
This will help to improve the promotion of information in the media
 
--
Best regards,
Alexander Rechitskiy
_______________________________________________
Ros-dev mailing list
Ros-dev@...
http://www.reactos.org/mailman/listinfo/ros-dev
Timo Kreuzer | 22 Oct 21:19 2014
Picon

Re: [ros-diffs] [tfaber] 64889: [NTOS:MM] - Add a way to generate a pool tag from the calling driver name if none is specified. Disabled by default.


Simpler:

+    if (LdrEntry)
+    {
+        ULONG i;
+        Tag = '____'; // IMO better than '    '
+        for (i = 0; i < min(4, LdrEntry->BaseDllName.Length / sizeof(WCHAR)); i++)
+            ((PCHAR)&Tag)[i] = (LdrEntry->BaseDllName.Buffer[i] & 0xff);
+    }

Maybe we can also add support for tracking backtraces of pool allocations.

Am 22.10.2014 15:26, schrieb tfaber@...:
> Author: tfaber
> Date: Wed Oct 22 13:26:50 2014
> New Revision: 64889
>
> URL: http://svn.reactos.org/svn/reactos?rev=64889&view=rev
> Log:
> [NTOS:MM]
> - Add a way to generate a pool tag from the calling driver name if none is specified. Disabled by default.
>
> Modified:
>      trunk/reactos/ntoskrnl/mm/ARM3/expool.c
>
> Modified: trunk/reactos/ntoskrnl/mm/ARM3/expool.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/expool.c?rev=64889&r1=64888&r2=64889&view=diff
> ==============================================================================
> --- trunk/reactos/ntoskrnl/mm/ARM3/expool.c	[iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/mm/ARM3/expool.c	[iso-8859-1] Wed Oct 22 13:26:50 2014
>  <at>  <at>  -2046,10 +2046,25  <at>  <at> 
>   ExAllocatePool(POOL_TYPE PoolType,
>                  SIZE_T NumberOfBytes)
>   {
> -    //
> -    // Use a default tag of "None"
> -    //
> -    return ExAllocatePoolWithTag(PoolType, NumberOfBytes, TAG_NONE);
> +    ULONG Tag = TAG_NONE;
> +#if 0 && DBG
> +    PLDR_DATA_TABLE_ENTRY LdrEntry;
> +
> +    /* Use the first four letters of the driver name, or "None" if unavailable */
> +    LdrEntry = KeGetCurrentIrql() <= APC_LEVEL
> +                ? MiLookupDataTableEntry(_ReturnAddress())
> +                : NULL;
> +    if (LdrEntry)
> +    {
> +        ULONG i;
> +        Tag = 0;
> +        for (i = 0; i < min(4, LdrEntry->BaseDllName.Length / sizeof(WCHAR)); i++)
> +            Tag = Tag >> 8 | (LdrEntry->BaseDllName.Buffer[i] & 0xff) << 24;
> +        for (; i < 4; i++)
> +            Tag = Tag >> 8 | ' ' << 24;
> +    }
> +#endif
> +    return ExAllocatePoolWithTag(PoolType, NumberOfBytes, Tag);
>   }
>   
>   /*
>  <at>  <at>  -2513,7 +2528,7  <at>  <at> 
>       //
>       // Allocate the pool
>       //
> -    return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, 'enoN');
> +    return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, TAG_NONE);
>   }
>   
>   /*
>
>
>
Timo Kreuzer | 22 Oct 20:56 2014
Picon

Re: [ros-diffs] [khornicek] 64882: [SERVMAN] - fix resource leaks CID 716292, 716293, 716294 - fix CID 716772 (double free), 513719 (wrong NULL check), 1206739 (cosmetic) - make line endings CR LF when exporting t...

Am 22.10.2014 00:58, schrieb khornicek@...:

> -                if (LVText != NULL)
> +                if (_tcslen(LVText))
>                   {
>                       WriteFile(hFile,
>                                 LVText,

I think LVText might not be zero terminated, when the SendMessage call 
fails.
What about if (dwTextLength != 0)?
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

Gmane