- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [tkreuzer] 65255: Merged revision(s) 62353, 62531-62532, 62853, 64152, 64173-64174 from branches/kernel-fun/reactos: [NTOSKRNL] Implement SystemPrioritySeperation case in NtSetSystemInformation ......

by Thomas Faber

On 2014-11-04 21:47, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Tue Nov 4 20:47:18 2014 > @@ -1580,6 +1580,8 @@ > if (OpenPacket.ParseCheck != TRUE) > { > /* Parse failed */ > + DPRINT1("IopQueryAttributesFile failed for '%wZ' with 0x%lx\n", > + ObjectAttributes->ObjectName, Status); > return Status; > } > else This one seems to be super noisy on testbot.

10 years, 12 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 65210: [NTOS/PS] - Do not leak a reference to the process object when setting quotas.

by Timo Kreuzer

Doesn't this change Windows behaviour? No, luckily it does not change *Windows* behaviour. It does not even change ReactOS behaviour, but only, because it was already broken before. Since MS implemented this function in an arbitrary and hard to comprehend way, we need to follow this pattern. This means, the function must not fail on process reference failure, unless certain conditions are met, otherwise we will fail with the wrong Status code. To fix the situation, we could remember the fact that the process couldn't be referenced (possibly by setting Process to NULL) and later check that after other checks were done. The alternative is referencing the process individually in each and every case, which will make the function even more huge and does not really help with it's readability. Or we can factor our each case and implement it as a separate function. It would add a lot of code duplication, but might help a bit with readability and maintainability. Am 03.11.2014 10:52, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Nov 3 09:52:08 2014 > New Revision: 65210 > > URL: http://svn.reactos.org/svn/reactos?rev=65210&view=rev > Log: > [NTOS/PS] > - Do not leak a reference to the process object when setting quotas. > > Modified: > trunk/reactos/ntoskrnl/include/internal/ps.h > trunk/reactos/ntoskrnl/ps/query.c > trunk/reactos/ntoskrnl/ps/quota.c > > Modified: trunk/reactos/ntoskrnl/include/internal/ps.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -303,7 +303,7 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > > Modified: trunk/reactos/ntoskrnl/ps/query.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/query.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -1528,6 +1528,7 @@ > /* Validate the number */ > if ((BasePriority > HIGH_PRIORITY) || (BasePriority <= LOW_PRIORITY)) > { > + ObDereferenceObject(Process); > return STATUS_INVALID_PARAMETER; > } > > @@ -1918,11 +1919,12 @@ > > case ProcessQuotaLimits: > > - return PspSetQuotaLimits(ProcessHandle, > + Status = PspSetQuotaLimits(Process, > 1, > ProcessInformation, > ProcessInformationLength, > PreviousMode); > + break; > > case ProcessWorkingSetWatch: > DPRINT1("WS watch not implemented\n"); > > Modified: trunk/reactos/ntoskrnl/ps/quota.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/quota.c?rev=65… > ============================================================================== > --- trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] Mon Nov 3 09:52:08 2014 > @@ -292,14 +292,13 @@ > NTSTATUS > NTAPI > PspSetQuotaLimits( > - _In_ HANDLE ProcessHandle, > + _In_ PEPROCESS Process, > _In_ ULONG Unused, > _In_ PVOID QuotaLimits, > _In_ ULONG QuotaLimitsLength, > _In_ KPROCESSOR_MODE PreviousMode) > { > QUOTA_LIMITS_EX CapturedQuotaLimits; > - PEPROCESS Process; > PEPROCESS_QUOTA_BLOCK QuotaBlock, OldQuotaBlock; > BOOLEAN IncreaseOkay; > KAPC_STATE SavedApcState; > @@ -368,19 +367,6 @@ > } > _SEH2_END; > > - /* Reference the process */ > - Status = ObReferenceObjectByHandle(ProcessHandle, > - PROCESS_SET_QUOTA, > - PsProcessType, > - PreviousMode, > - (PVOID*)&Process, > - NULL); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Failed to reference process handle: 0x%lx\n", Status); > - return Status; > - } > - > /* Check the caller changes the working set size limits */ > if ((CapturedQuotaLimits.MinimumWorkingSetSize != 0) && > (CapturedQuotaLimits.MaximumWorkingSetSize != 0)) > @@ -418,7 +404,6 @@ > /* Check if the caller has the required privilege */ > if (!SeSinglePrivilegeCheck(SeIncreaseQuotaPrivilege, PreviousMode)) > { > - ObDereferenceObject(Process); > return STATUS_PRIVILEGE_NOT_HELD; > } > > @@ -460,8 +445,6 @@ > Status = STATUS_SUCCESS; > } > > - /* Dereference the process and return the status */ > - ObDereferenceObject(Process); > return Status; > } > > > >

10 years, 12 months

1
0
0 0

Fezile server downtime this evening

by Colin Finck

Hi all, Jan and I will finally install the remote management card in Fezile this evening and verify the cabling of our UPS systems. This will cause a short downtime of the Fezile server along with its testslaves, cppcheck, Doxygen, Git and iso.reactos.org. In case we notice a fault in UPS cabling, we may also be required to temporarily shut down other servers, replug their power cables and boot them up again. This may cause very short downtimes as well. After this measure, we will be able to totally manage this important server remotely, even if its OS has failed at some point. Proper UPS cabling also ensures smooth operations in case of sudden power outages. Thanks for your understanding! Cheers, Colin

10 years, 12 months

1
0
0 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 65166: [NTFS] Simplify buffer size management in GetNtfsFileRecord(). As tests shown, Windows doesn't care about the real size of the file record and expects the caller to pass the co...

by Thomas Faber

On 2014-11-01 11:02, pschweitzer(a)svn.reactos.org wrote: > - OutputBuffer->FileRecordLength = FileRecord->BytesInUse; > - RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, FileRecord->BytesInUse); > + OutputBuffer->FileRecordLength = DeviceExt->NtfsInfo.BytesPerFileRecord; > + RtlCopyMemory(OutputBuffer->FileRecordBuffer, FileRecord, DeviceExt->NtfsInfo.BytesPerFileRecord); Wait, now there's no check against OutputBufferLength at all? It should at least be min(DeviceExt->NtfsInfo.BytesPerFileRecord, Stack->Parameters.FileSystemControl.OutputBufferLength) in the memcpy size. Or am I missing something?

11 years

2
3
0 0

Re: [ros-dev] [ros-diffs] [jgardou] 65140: [FASTFAT] - Fix renaming files in case the target file already exists. - Plug a few reference count leaks on FCBs. CORE-8660 #comment fixed in r65140 #resolve CORE-8633 #comment fi...

by Pierre Schweitzer

Warm thanks for debugging this issue Jérôme. I do value your help. This should unlock many autoupdating apps in ReactOS. Thanks again. On 31/10/2014 12:04, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Fri Oct 31 11:04:12 2014 > New Revision: 65140 > > URL: http://svn.reactos.org/svn/reactos?rev=65140&view=rev > Log: > [FASTFAT] > - Fix renaming files in case the target file already exists. > - Plug a few reference count leaks on FCBs. > CORE-8660 #comment fixed in r65140 #resolve > CORE-8633 #comment fixed in r65140 #resolve > CORE-4758 #comment fixed in r65140 #resolve > > Modified: > trunk/reactos/drivers/filesystems/fastfat/cleanup.c > trunk/reactos/drivers/filesystems/fastfat/create.c > trunk/reactos/drivers/filesystems/fastfat/finfo.c > > Modified: trunk/reactos/drivers/filesystems/fastfat/cleanup.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -92,6 +92,7 @@ > pFcb->FileObject = NULL; > CcUninitializeCacheMap(tmpFileObject, NULL, NULL); > ObDereferenceObject(tmpFileObject); > + vfatReleaseFCB(IrpContext->DeviceExt, pFcb); > } > > CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE); > > Modified: trunk/reactos/drivers/filesystems/fastfat/create.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/create.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -365,7 +365,6 @@ > DPRINT("'%wZ'\n", &FileObject->RelatedFileObject->FileName); > > *ParentFcb = FileObject->RelatedFileObject->FsContext; > - vfatGrabFCB(DeviceExt, *ParentFcb); > } > else > { > > Modified: trunk/reactos/drivers/filesystems/fastfat/finfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fastfa… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/finfo.c [iso-8859-1] Fri Oct 31 11:04:12 2014 > @@ -396,41 +396,53 @@ > /* If it exists */ > if (NT_SUCCESS(Status)) > { > + DPRINT("Target file %wZ exists. FCB Flags %08x\n", NewName, TargetFcb->Flags); > /* Check whether we are allowed to replace */ > if (ReplaceIfExists) > { > /* If that's a directory or a read-only file, we're not allowed */ > - if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)); > - { > + if (vfatFCBIsDirectory(TargetFcb) || ((*TargetFcb->Attributes & FILE_ATTRIBUTE_READONLY) == FILE_ATTRIBUTE_READONLY)) > + { > + DPRINT("And this is a readonly file!\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_OBJECT_NAME_COLLISION; > } > > - /* Attempt to flush (might close the file) */ > - if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > - { > + > + /* If we still have a file object, close it. */ > + if (TargetFcb->FileObject) > + { > + if (!MmFlushImageSection(TargetFcb->FileObject->SectionObjectPointer, MmFlushForDelete)) > + { > + DPRINT("MmFlushImageSection failed.\n"); > + vfatReleaseFCB(DeviceExt, *ParentFCB); > + *ParentFCB = NULL; > + vfatReleaseFCB(DeviceExt, TargetFcb); > + return STATUS_ACCESS_DENIED; > + } > + > + TargetFcb->FileObject->DeletePending = TRUE; > + VfatCloseFile(DeviceExt, TargetFcb->FileObject); > + } > + > + /* If we are here, ensure the file isn't open by anyone! */ > + if (TargetFcb->OpenHandleCount != 0) > + { > + DPRINT("There are still open handles for this file.\n"); > vfatReleaseFCB(DeviceExt, *ParentFCB); > *ParentFCB = NULL; > vfatReleaseFCB(DeviceExt, TargetFcb); > return STATUS_ACCESS_DENIED; > } > > - /* If we are, ensure the file isn't open by anyone! */ > - if (TargetFcb->OpenHandleCount != 0) > - { > - vfatReleaseFCB(DeviceExt, *ParentFCB); > - *ParentFCB = NULL; > - vfatReleaseFCB(DeviceExt, TargetFcb); > - return STATUS_ACCESS_DENIED; > - } > - > /* Effectively delete old file to allow renaming */ > + DPRINT("Effectively deleting the file.\n"); > VfatDelEntry(DeviceExt, TargetFcb, NULL); > - vfatGrabFCB(DeviceExt, *ParentFCB); > vfatReleaseFCB(DeviceExt, TargetFcb); > *Deleted = TRUE; > + return STATUS_SUCCESS; > } > else > { > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

11 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 65133: [LOGOFF] * Plug some leaks. CIDs 716284 and 716285. CORE-7975

by Thomas Faber

Hey, On 2014-10-31 10:22, akhaldi(a)svn.reactos.org wrote: > @@ -90,6 +91,7 @@ > //Invalid parameter detected > if (AllocAndLoadString(&lpIllegalMsg, GetModuleHandle(NULL), IDS_ILLEGAL_PARAM)) > _putts(lpIllegalMsg); > + LocalFree(lpIllegalMsg); > return FALSE; > } > } > This needs braces. Both puts and LocalFree should only be executed if AllocAndLoadString succeeds (but return FALSE in either case). Thanks!

11 years

1
0
0 0

BuildBot changes

by Colin Finck

Hi all, As you can see in project-tools SVN, I've improved our Bash scripts for Buildslaves. They're now also usable under Windows (in a Cygwin environment) and I'm already doing this on our new Windows Buildslave Carrier-Win7. Bash on Windows may look hacky at first, but it's definitely more comfortable than Batch! Moreover, we now only have a single version of build scripts to maintain for all our Buildslaves! This also involved some naming changes on the existing slaves to maintain a consistent scheme. Tell me if anything broke. Bringing all desired Windows builders back will still take some time. I've only started with a RosBE-Windows based one right now and I need your help here: For some reason, VirtualBox 4.3.18 (used for reg-testing) doesn't want to run headless. I can do a 'runas /user:buildbot VBoxManage controlvm "ReactOS Testbot" poweroff' in a CMD and it will work well. The very same command executed through BuildBot ends with: ==================================================================== VBoxManage.exe: error: Failed to create the VirtualBox object! VBoxManage.exe: error: Code E_ACCESSDENIED (0x80070005) - General access denied error (extended info not available) VBoxManage.exe: error: Most likely, the VirtualBox COM server is not running or failed to start. ==================================================================== See http://build.reactos.org/builders/Carrier-Win7%20VBox-Testbot/builds/6/step… VBoxSVC.log isn't touched when BuildBot tries this command, so I have no additional information. Haven't found a solution yet, so I'm asking here if any of the VBox experts know what could be going wrong. Cheers, Colin

11 years

5
10
0 0

Do not waste 65432 and 65536 GET!

by Alexander Rechitskiy

11 years

1
0
0 0

Status Meeting (October 2014)

by Aleksey Bragin

Hello, Let me invite you to the monthly status meeting taking place 30th of October, 19:00 UTC (that's tomorrow!). IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. Regards, Aleksey Bragin

11 years

1
0
0 0

Monthly Meeting?

by Hermès BÉLUSCA - MAÏTO

Hi ! Is there our monthly meeting tomorrow ? Cheers, Hermès.

11 years

1
0
0 0

Re: [ros-dev] [ros-diffs] [akhaldi] 64994: [ADVAPI32] * Update ImpersonateNamedPipeClient(). CORE-8540

by Ged Murphy

Eeww, these are a bit ugly :( On 25/10/2014 19:30, "akhaldi(a)svn.reactos.org" <akhaldi(a)svn.reactos.org> wrote: >Author: akhaldi >Date: Sat Oct 25 18:30:05 2014 >New Revision: 64994 > >URL: http://svn.reactos.org/svn/reactos?rev=64994&view=rev >Log: >[ADVAPI32] >* Update ImpersonateNamedPipeClient(). >CORE-8540 > >Modified: > trunk/reactos/dll/win32/advapi32/wine/security.c > >Modified: trunk/reactos/dll/win32/advapi32/wine/security.c >URL: >http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/wine/s >ecurity.c?rev=64994&r1=64993&r2=64994&view=diff >========================================================================== >==== >--- trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1] >(original) >+++ trunk/reactos/dll/win32/advapi32/wine/security.c [iso-8859-1] Sat Oct >25 18:30:05 2014 >@@ -954,37 +954,14 @@ > return TRUE; > } > >-/********************************************************************** >- * ImpersonateNamedPipeClient EXPORTED >- * >- * @implemented >- */ >-BOOL >-WINAPI >-ImpersonateNamedPipeClient(HANDLE hNamedPipe) >-{ >- IO_STATUS_BLOCK StatusBlock; >- NTSTATUS Status; >- >- TRACE("ImpersonateNamedPipeClient() called\n"); >- >- Status = NtFsControlFile(hNamedPipe, >- NULL, >- NULL, >- NULL, >- &StatusBlock, >- FSCTL_PIPE_IMPERSONATE, >- NULL, >- 0, >- NULL, >- 0); >- if (!NT_SUCCESS(Status)) >- { >- SetLastError(RtlNtStatusToDosError(Status)); >- return FALSE; >- } >- >- return TRUE; >+BOOL WINAPI ImpersonateNamedPipeClient( HANDLE hNamedPipe ) >+{ >+ IO_STATUS_BLOCK io_block; >+ >+ TRACE("(%p)\n", hNamedPipe); >+ >+ return set_ntstatus( NtFsControlFile(hNamedPipe, NULL, NULL, NULL, >+ &io_block, FSCTL_PIPE_IMPERSONATE, NULL, 0, >NULL, 0) ); > } > > /* > >

11 years

3
4
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 64974: [CRT] - Add frame pointer omission information to assembly string functions to fix debugging annoyances. Reviews appreciated

by Timo Kreuzer

Am 25.10.2014 02:08, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Sat Oct 25 00:08:23 2014 > New Revision: 64974 > > URL: http://svn.reactos.org/svn/reactos?rev=64974&view=rev > Log: > [CRT] > - Add frame pointer omission information to assembly string functions to fix debugging annoyances. Reviews appreciated > > > > Modified: trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/i386/tc… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/string/i386/tcsnlen.inc [iso-8859-1] Sat Oct 25 00:08:23 2014 > @@ -5,7 +5,8 @@ > PUBLIC _tcsnlen > .code > > -_tcsnlen: > +FUNC _tcsnlen > + FPO 0, 1, 1, 1, 0, FRAME_FPO This one has 2 parameters

11 years

1
0
0 0

Tuesday is a best day for software\pr releases

by Alexander Rechitskiy

11 years

3
2
0 0

Re: [ros-dev] [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...

by Thomas Faber

On 2014-10-23 11:32, jgardou(a)svn.reactos.org 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)?

11 years

2
1
0 0

Re: [ros-dev] [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.

by Timo Kreuzer

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(a)svn.reactos.org: > 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?… > ============================================================================== > --- 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 > @@ -2046,10 +2046,25 @@ > 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); > } > > /* > @@ -2513,7 +2528,7 @@ > // > // Allocate the pool > // > - return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, 'enoN'); > + return ExAllocatePoolWithQuotaTag(PoolType, NumberOfBytes, TAG_NONE); > } > > /* > > >

11 years

1
0
0 0

Re: [ros-dev] [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...

by Timo Kreuzer

Am 22.10.2014 00:58, schrieb khornicek(a)svn.reactos.org: > - 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)?

11 years

1
0
0 0

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

by Alex Ionescu

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(a)svn.reactos.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=… > > ============================================================================== > --- 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 > @@ -117,7 +117,6 @@ > Fast486MemReadCallback(PFAST486_STATE State, ULONG Address, PVOID Buffer, > ULONG Size) > { > UNREFERENCED_PARAMETER(State); > - > RtlMoveMemory(Buffer, (PVOID)Address, Size); > } > > @@ -126,7 +125,6 @@ > 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… > > ============================================================================== > --- 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 > @@ -2016,6 +2016,7 @@ > > FAST486_OPCODE_HANDLER(Fast486OpcodeGroup0F01) > { > + // FAST486_TABLE_REG TableReg; > UCHAR TableReg[6]; > FAST486_MOD_REG_RM ModRegRm; > BOOLEAN OperandSize, AddressSize; > @@ -2054,8 +2055,9 @@ > } > > /* 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, > @@ -2076,8 +2078,9 @@ > } > > /* 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, > @@ -2117,7 +2120,8 @@ > } > > /* 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 */ > @@ -2156,7 +2160,8 @@ > } > > /* 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 */ > > >

11 years

2
1
0 0

Re: [ros-dev] [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).

by Timo Kreuzer

Looks like bugs Am 15.10.2014 00:46, schrieb hbelusca(a)svn.reactos.org: > 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)); > @@ -2901,7 +2901,7 @@ > WCHAR Buffer[256]; > > /* Clear the current directory buffer */ > - ZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > + RtlZeroMemory(CurrentDirectories, sizeof(CurrentDirectories)); > @@ -1901,7 +1901,7 @@ > > VOID VgaClearMemory(VOID) > { > - ZeroMemory(VgaMemory, sizeof(VgaMemory)); > + RtlZeroMemory(VgaMemory, sizeof(VgaMemory)); > } > >

11 years

4
4
0 0

Re: [ros-dev] RtlUlonglongByteSwap (Thomas Faber)

by Love Nystrom

On 2014-10-17 19.00, ros-dev-request(a)reactos.org wrote: > 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: >> >@Timo, @Thomas, @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 >

11 years

1
0
0 0

Video of our ReactOS presentation online

by Colin Finck

Hi all, As the question usually arises: The video of Daniel's and my ReactOS presentation at Kieler Linux Tage is online: http://youtu.be/oQsKzW_Rx3k Do whatever you want with it ;) This is probably the first ever ReactOS presentation held using ReactOS itself! And it worked like a charm! We also met an author of German news site heise.de there, who wants to publish an article about the current state ReactOS soon. Cheers, Colin

11 years

4
6
0 0

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

by Thomas Faber

On 2014-10-18 01:28, akhaldi(a)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".

11 years

1
0
0 0

Re: [ros-dev] RtlUlonglongByteSwap

by Love Nystrom

@Timo, @Thomas, @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

11 years

2
1
0 0

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

by Ged Murphy

There shouldn't really be anything using this header -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of tfaber(a)svn.reactos.org Sent: 15 October 2014 17:38 To: ros-diffs(a)reactos.org 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?re… ============================================================================== --- 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 @@ -2310,7 +2310,12 @@ 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 *);

11 years

4
6
0 0

Re: [ros-dev] [ros-diffs] [tfaber] 64762: [NPFS] - Don't call RtlEqualUnicodeString (paged code) while holding a spin lock. Powered by Driver Verifier.

by Hermès BÉLUSCA - MAÏTO

What is the *root* reason for this problem (ok Ive seen in the comment, paged code and holding spin lock, but it doesnt answer my question)? Because Ive looked at our code of RtlEqualUnicodeString and I see that it just calls RtlCompareUnicodeString that in turns just loops over the two memory buffers, checks their contents (and in case we check for char case, calls RtlUpcaseUnicodeChar). And RtlCompareMemory does that, too? What Im missing? Hermès. ------------------------------------------------------------------------- Author: tfaber Date: Thu Oct 16 16:40:13 2014 New Revision: 64762 URL: http://svn.reactos.org/svn/reactos?rev=64762&view=rev Log: [NPFS] - Don't call RtlEqualUnicodeString (paged code) while holding a spin lock. Powered by Driver Verifier. Modified: trunk/reactos/drivers/filesystems/npfs/waitsup.c Modified: trunk/reactos/drivers/filesystems/npfs/waitsup.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/npfs/wa itsup.c?rev=64762&r1=64761&r2=64762&view=diff ============================================================================ == --- trunk/reactos/drivers/filesystems/npfs/waitsup.c [iso-8859-1] (original) +++ trunk/reactos/drivers/filesystems/npfs/waitsup.c [iso-8859-1] Thu Oct 16 16:40:13 2014 @@ -97,6 +97,22 @@ { InitializeListHead(&WaitQueue->WaitList); KeInitializeSpinLock(&WaitQueue->WaitLock); +} + +static +BOOLEAN +NpEqualUnicodeString(IN PCUNICODE_STRING String1, + IN PCUNICODE_STRING String2) +{ + SIZE_T EqualLength; + + if (String1->Length != String2->Length) + return FALSE; + + EqualLength = RtlCompareMemory(String1->Buffer, + String2->Buffer, + String1->Length); + return EqualLength == String1->Length; } NTSTATUS @@ -156,7 +172,8 @@ PipeName.MaximumLength = PipeName.Length; } - if (RtlEqualUnicodeString(&WaitName, &PipeName, FALSE)) + /* Can't use RtlEqualUnicodeString with a spinlock held */ + if (NpEqualUnicodeString(&WaitName, &PipeName)) { /* Found a matching wait. Cancel it */ RemoveEntryList(&WaitIrp->Tail.Overlay.ListEntry);

11 years

2
1
0 0

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

by Alex Ionescu

Wow, does static analyzer really not catch this? Best regards, Alex Ionescu On Wed, Oct 15, 2014 at 3:03 PM, <tkreuzer(a)svn.reactos.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.… > > ============================================================================== > --- 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 > @@ -1511,7 +1511,7 @@ > NTSTATUS Status; > PMMSUPPORT WorkingSet; > ULONG ProtectionCode; > - PMMVAD Vad; > + PMMVAD Vad = NULL; > PFN_NUMBER PageFrameIndex; > ULONG Color; > BOOLEAN IsSessionAddress; > > >

11 years

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev