Ros-dev

ros-dev@reactos.org

5789 discussions

by Thomas Mueller

I saw an article on heise online (German-language website) http://www.heise.de/newsticker/ on ReactOS liest NTFS http://www.heise.de/newsticker/meldung/ReactOS-liest-NTFS-2442615.html Date is 05.11.2014, meaning just yesterday. I subsequently looked on reactos.org and couldn't find any reference to this article. So far, this is only for reading NTFS on ReactOS; writing ability stil has to be worked on. This is the first article I've seen on this subject: looks like progress. Some ReactOS developers must be familiar with this? Tom

10 years, 5 months

Re: [ros-dev] [ros-diffs] [jgardou] 65388: [TCPIP] - Comment out an optimisation which doesn't work. Reviews of why would be most appreciated.

by Timo Kreuzer

tcpip.c:264 /* Keep this list sorted */ InsertHeadList(ListEntry, &OutInstance->ListEntry); This should probably be InsertTailList(), since you want to insert before the current ListEntry Am 12.11.2014 12:39, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Nov 12 11:39:13 2014 > New Revision: 65388 > > URL: http://svn.reactos.org/svn/reactos?rev=65388&view=rev > Log: > [TCPIP] > - Comment out an optimisation which doesn't work. > Reviews of why would be most appreciated. > > Modified: > branches/tcpip_revolution/drivers/network/tcpip/entities.c > > Modified: branches/tcpip_revolution/drivers/network/tcpip/entities.c > URL: http://svn.reactos.org/svn/reactos/branches/tcpip_revolution/drivers/networ… > ============================================================================== > --- branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] (original) > +++ branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] Wed Nov 12 11:39:13 2014 > @@ -309,9 +309,11 @@ > return STATUS_SUCCESS; > } > > +#if 0 > /* The list is sorted, so we can cut the loop a bit */ > if (ID.tei_instance < Instance->InstanceId.tei_instance) > break; > +#endif > > ListEntry = ListEntry->Flink; > } > > >

10 years, 5 months

Re: [ros-dev] [ros-diffs] [spetreolle] 65378: [ADVAPI_WINETEST] Make peace^W tests, not war.☮ Wave a hello to sysreg so that it doesn't kill us. ROSTESTS-56

by Thomas Faber

Hmm, my thought behind disabling this was more that this one test doesn't justify increasing our whole test run time by 10%. On 2014-11-11 11:12, spetreolle(a)svn.reactos.org wrote: > Author: spetreolle > Date: Tue Nov 11 16:12:14 2014 > New Revision: 65378 > > URL: http://svn.reactos.org/svn/reactos?rev=65378&view=rev > Log: > [ADVAPI_WINETEST] > Make peace^W tests, not war.☮ > Wave a hello to sysreg so that it doesn't kill us. > ROSTESTS-56 > > Modified: > trunk/rostests/winetests/advapi32/service.c > > Modified: trunk/rostests/winetests/advapi32/service.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/advapi32/servic… > ============================================================================== > --- trunk/rostests/winetests/advapi32/service.c [iso-8859-1] (original) > +++ trunk/rostests/winetests/advapi32/service.c [iso-8859-1] Tue Nov 11 16:12:14 2014 > @@ -2166,6 +2166,9 @@ > DWORD le1, le2; > SERVICE_STATUS status; > > +#ifdef __REACTOS__ > + fprintf(stdout, "ROSTESTS-56: Hello sysreg, I am awake\n"); > +#endif > ret = StartServiceA(svc_handle, 0, NULL); > le1 = GetLastError(); > ok(!ret, "%s: StartServiceA() should have failed\n", name); > @@ -2260,12 +2263,6 @@ > * insanely long timeout: 120s. So skip the rest of the tests. > */ > win_skip("Skip some service start/stop tests on NT4\n"); > - goto cleanup; > - } > - > - if (!winetest_interactive) > - { > - skip("ROSTESTS-56: Skipping service start timeout tests!\n"); > goto cleanup; > } >

10 years, 5 months

Re: [ros-dev] [ros-diffs] [pschweitzer] 65352: [NTOSKRNL] So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack. But, so far, onl...

by Alex Ionescu

Let me make a simple arrogant comment: Don't try to fix hacks that I spent years trying to fix (and failed). They just can't be fixed :P Best regards, Alex Ionescu On Mon, Nov 10, 2014 at 1:45 AM, <pschweitzer(a)svn.reactos.org> wrote: > Author: pschweitzer > Date: Mon Nov 10 09:45:43 2014 > New Revision: 65352 > > URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev > Log: > [NTOSKRNL] > So... Because actual ReactOS mood is to worship hacks instead of looking > for proper fixes to have decent behavior: reenable the IopParseDevice hack. > > But, so far, only reenable it for the 1st stage: the most intensive > storage stack stage (unless you start playing with partitions & formating > in 3rd stage). > > CORE-8732 #resolve #comment Bug is now properly hidden with r65352 > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 > 09:45:43 2014 > @@ -404,6 +404,27 @@ > /* Check if we can simply use a dummy file */ > UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly)); > > + /* FIXME: Small hack still exists, have to check why... > + * This is triggered multiple times by usetup and then once per boot. > + */ > + if (ExpInTextModeSetup && > + !(DirectOpen) && > + !(RemainingName->Length) && > + !(OpenPacket->RelatedFileObject) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > + !(UseDummyFile)) > + { > + DPRINT1("Using IopParseDevice() hack. Requested invalid > attributes: %lx\n", > + DesiredAccess & ~(SYNCHRONIZE | > + FILE_READ_ATTRIBUTES | > + READ_CONTROL | > + ACCESS_SYSTEM_SECURITY | > + WRITE_OWNER | > + WRITE_DAC)); > + DirectOpen = TRUE; > + } > + > /* Check if this is a direct open */ > if (!(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > > >

10 years, 5 months

Re: [ros-dev] [ros-diffs] [pschweitzer] 65367: [PARTTEST] Add a dummy application that will open first disk and check first sector for MBR and then will open first partition to check for something known (& not MBR)

by Michael Fritscher

Hi, > + if (Sector->BytesPerSector * Sector->SectorsPerCluster > 32 * 1024) > + { > + return FALSE; > + } FAT supports cluster sizes until 64KB ;-) At least the WinNT series can work with them. Best regards, Michael Fritscher

10 years, 5 months

by Aleksey Bragin

Thank you for working on this hack (partial) removal! After all, having it only in the 1st stage is a win over having it enabled all the time. Regards, Aleksey On 10.11.2014 12:45, pschweitzer(a)svn.reactos.org wrote: > Author: pschweitzer > Date: Mon Nov 10 09:45:43 2014 > New Revision: 65352 > > URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev > Log: > [NTOSKRNL] > So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack. > > But, so far, only reenable it for the 1st stage: the most intensive storage stack stage (unless you start playing with partitions & formating in 3rd stage). > > CORE-8732 #resolve #comment Bug is now properly hidden with r65352 > > Modified: > trunk/reactos/ntoskrnl/io/iomgr/file.c > > Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 09:45:43 2014 > @@ -404,6 +404,27 @@ > /* Check if we can simply use a dummy file */ > UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly)); > > + /* FIXME: Small hack still exists, have to check why... > + * This is triggered multiple times by usetup and then once per boot. > + */ > + if (ExpInTextModeSetup && > + !(DirectOpen) && > + !(RemainingName->Length) && > + !(OpenPacket->RelatedFileObject) && > + ((wcsstr(CompleteName->Buffer, L"Harddisk")) || > + (wcsstr(CompleteName->Buffer, L"Floppy"))) && > + !(UseDummyFile)) > + { > + DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n", > + DesiredAccess & ~(SYNCHRONIZE | > + FILE_READ_ATTRIBUTES | > + READ_CONTROL | > + ACCESS_SYSTEM_SECURITY | > + WRITE_OWNER | > + WRITE_DAC)); > + DirectOpen = TRUE; > + } > + > /* Check if this is a direct open */ > if (!(RemainingName->Length) && > !(OpenPacket->RelatedFileObject) && > >

10 years, 5 months

Re: [ros-dev] [ros-diffs] [hbelusca] 65337: [NTOS:PNPMGR] - Remove an unneeded ExFreePool(DeviceInstance.Buffer); call in IopGetInterfaceDeviceList because at this point DeviceInstance is not yet initialized. Fixes MSVC bui...

by Timo Kreuzer

You add parentheses to conform to coding style (our coding style guidelines do not require it) and on the other hand you convert a 2 line if statement into one line, which does not conform to our coding style? Am 09.11.2014 03:26, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Nov 9 02:26:49 2014 > New Revision: 65337 > > URL: http://svn.reactos.org/svn/reactos?rev=65337&view=rev > Log: > [NTOS:PNPMGR] > - Remove an unneeded ExFreePool(DeviceInstance.Buffer); call in IopGetInterfaceDeviceList because at this point DeviceInstance is not yet initialized. Fixes MSVC build. > - No need to check for DeviceInstance.Buffer being NULL or not (in IopDeviceStatus), because in case it was NULL the IopCaptureUnicodeString call already failed. > - Add some brackets to conform to code style. > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/plugpla… > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] Sun Nov 9 02:26:49 2014 > @@ -199,8 +199,7 @@ > } > _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > { > - if (Name.Buffer) > - ExFreePool(Name.Buffer); > + if (Name.Buffer) ExFreePool(Name.Buffer); > Status = _SEH2_GetExceptionCode(); > } > _SEH2_END; >

10 years, 5 months

Re: [ros-dev] [ros-diffs] [hbelusca] 65336: [NTVDM]: Use variable-length buffers in DisplayMessage, in case we display a very long message (uses the _vscwprintf CRT function, not available on Win2k. You need to recompile NT...

by Timo Kreuzer

Am 09.11.2014 02:46, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Nov 9 01:46:31 2014 > New Revision: 65336 > > URL: http://svn.reactos.org/svn/reactos?rev=65336&view=rev > Log: > [NTVDM]: Use variable-length buffers in DisplayMessage, in case we display a very long message (uses the _vscwprintf CRT function, not available on Win2k. You need to recompile NTVDM with WIN2K_COMPLIANT define if you want to be able to run it on win2k. In that case DisplayMessage uses a quite large enough buffer for its needs). If somebody knows an alternative to _vscwprintf that does the very same job, and which exists on Win2k, I would be happy to use it instead. Since _vscwprintf will do the whole work already anyway, you could as well directly print it into the static buffer. You could use _vsnwprintf or StringCbPrintfW, which internally uses the former, and use the result to decide whether the buffer was large enough. This will be more performant, since you only need to print once, when the buffer is large enough.

10 years, 5 months

Re: [ros-dev] [ros-diffs] [tfaber] 65269: [FASTFAT] - VfatCleanupFile: do not dereference the FCB when closing the volume file object. ObDereferenceObject already causes an IRP_MJ_CLOSE request to be sent, which dereference...

by Thomas Faber

Oh... Jérôme, I only just saw that you added this in r65140... And my change does break the msi tests again. :\ Any idea what's going wrong here? I'm relatively certain my change is correct because vfatFCBInitializeCacheFromVolume takes one reference, and VfatCloseFile invoked via ObDereferenceObject will remove that reference again. So apparently we're leaking a directory reference somewhere else? :( Not sure if your previous investigation into this issue can provide any pointers. Otherwise I'll have to start digging for the leak all over again... Thanks. -Thomas On 2014-11-05 19:52, tfaber(a)svn.reactos.org wrote: > --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Wed Nov 5 18:52:11 2014 > @@ -92,7 +92,6 @@ > pFcb->FileObject = NULL; > CcUninitializeCacheMap(tmpFileObject, NULL, NULL); > ObDereferenceObject(tmpFileObject); > - vfatReleaseFCB(IrpContext->DeviceExt, pFcb); > } > > CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE); > >

10 years, 6 months

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, 6 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev