- Ros-dev - ReactOS.org

Installing driver without reboot
by Maxime Daniel 28 Mar '14

28 Mar '14

Hi, Is it possible to install a driver (virtual network interface) witout reboot the system ? I tried TAP interface (installation with devcon: devcon install inf-file tap0901) but the interface is only loaded during the next reboot (same for a ndis sample from DDK) Is there a way to load a driver interface with a true plug'n'play mechanism ? -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 16:33:29 up 24 days, 8 min, 1 user, load average: 0.31, 0.68, 0.72

1 0

Re: [ros-dev] Installing and running ReactOS on modern hardware
by Thomas Mueller 28 Mar '14

28 Mar '14

from "David Quintana (gigaherz)" <gigaherz(a)gmail.com>: > [-- Type: multipart/alternative, Encoding: 7bit, Size: 5.8K --] > Content-Type: multipart/alternative; boundary=001a1135f7ac55c1ca04f557713d > Content-Type: text/plain; charset=UTF-8 > First of all, I'm not an expert when it comes to what ReactOS supports in > terms of real hardware. > I believe (someone will correct me if I'm wrong), that ReactOS is not > currently able to boot from USB, and in fact, will fail to boot at all if > an incompatible USB controller (which is most of them, I think?) is > present. Burning a CD-ROM with the setup or livecd images, and possibly > disabling the USB controllers from your bios config, may give you better > results. > I'm assuming that your intention is to try ReactOS in real hardware, > otherwise it would be better advised to just use VMware, VirtualBox, or > QEMU, as those work mostly out of the box. > Ideally, your real-hardware testing platform should have a serial port, and > this serial port should be connected to another computer with a serial > port, by using a null-modem cable. This way you could see debug messages > through the serial port, and interact with the remote debugger driver when > (more than if) it crashes. > ReactOS currently only supports FAT32, because it's a simple driver that > does not need advanced features of the storage system. As the storage stack > improves, it will be possible to attempt using more complex drivers. We > already have an EXT2 driver, but last I heard it was not stable enough to > be able to boot from it. > That's all I know. If it's not enough, maybe someone with more experience > can add to it. Thanks for response, but surely one-part plain text would be better than multipart/alternative? I could try commands such as drivemap in GRUB 2, but then ReactOS would be lost when trying to boot. Would MS-Windows drivers work in ReactOS when running from within VirtualBox or QEMU? I don't really want to try ReactOS on the same disk with FreeBSD and Linux installations that I want to keep intact, might be too hazardous. I don't have any serial ports but have serial headers on motherboard, could conceivably make a serial port. FreeDOS can boot from USB stick thanks to recognition by the BIOS/UEFI. I really would want to install ReactOS to something rewritable; having to burn a new CD for every little change is too much. With ReactOS being far from ready for production use, I figure I would have to make frequent changes/adjustments. I downloaded the installation iso for ReactOS 0.3.15, burned to CD, but that failed to boot. I believe Linux and *BSD are far more flexible in where they can install to than MS-Windows or OS/2. I hope ReactOS could rise above such Windows booting limitations. I ran OS/2 from 16-bit 1.3 in 1990 or 1991 to OS/2 Warp 4 in the single-digit days of April 2001. Then following a crash, on the next boot, CHKDSK, which ran automatically on the uncleanly-dismounted file system, ran amok and trashed everything on the hard drive. I was never again able to boot OS/2 after that. Now Linux and FreeBSD capabilities seem to far surpass OS/2 and its successor eComStation. Tom

2 4

Status Meeting (March 2014)
by Aleksey Bragin 27 Mar '14

27 Mar '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 27th of March, 19:00 UTC. Put that into your calendars so you don't forget. 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. Regards, Aleksey Bragin

2 1

ndis netvmini adapter
by Maxime Daniel 27 Mar '14

27 Mar '14

Hi, I'm trying to compile and test the netvmini ndis 5 adapter code from WDK, at first to understand how it works, then to modify it for another purpose. At this time I: - put the code on driver/network/dd/netvmini and adapted CMakeLists - put the inf on media/inf and adapted CMakeLists - fixed the code, it builds - add an entry to hivesys.inf to load the driver at boot The driver is well displayed during boot, debug message appears (the DriverEntry), on NtObj, the driver is visible and it appears on "Non Plug and Play" on device manager. Now, I don't know exactly what to do with it. How can I call the driver and add an adapter ? The userland tool given with the code works (I needed to comment some functions and add _DEV_BROADCAST_HANDLE struct by hand, it seems to not be implemented on dbt.h). When I run the userland tools, it fails with EnumDevices. Some help ? Thanks

2 1

Resuscitating MSVC 2008 builds (at least) for testing purposes only :P
by Hermès BÉLUSCA - MAÏTO 26 Mar '14

26 Mar '14

Because I was recently shocked (if I may say :D) that, for building a 2003-class operating system, we need 2010+ tools, I was wondering whether it was still possible to build ReactOS with MSVC 2008 and 2005. Ive created a task for that in Jira: http://jira.reactos.org/browse/CORE-8023 . After application of the configure.cmd patch that I give in the report, plus few tweaks in two headers (and adding some stdint.h in the correct directory for MSVC, needed for compiling host-tools, because this file is not included in default MSVC installation until MSVC 2010+), I was able to build a full bootcd and livecd (see the details in the abovementioned report, basically it currently builds with MSVC 2008 but not 2005). However there happens an interesting thing: the [boot|live]cd boots (freeldr seems to work and load the kernel and drivers), but after that, the kernel (debugged in WinDbg) hangs indefinitely here: Windows Server 2003 Kernel Version 3790 UP Checked x86 compatible Built by: 20140326-r62565 Machine Name: Kernel base = 0x80400000 PsLoadedModuleList = 0x005fcf88 System Uptime: not available (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:494) Supported CPU features : KF_V86_VIS KF_RDTSC KF_CR4 KF_CMOV KF_GLOBAL_PAGE KF_LARGE_PAGE KF_MTRR KF_CMPXCHG8B KF_MMX KF_WORKING_PTE KF_PAT KF_FXSR KF_FAST_SYSCALL KF_XMMI KF_XMMI64 KF_NX_BIT (f:\ros_vs_test\ntoskrnl\ke\i386\cpu.c:801) Prefetch Cache: 64 bytes L2 Cache: 0 bytes L2 Cache Line: 64 bytes L2 Cache Associativity: 0 <_hangs_forever_here_> If some of you have an idea what *might* happen there, Im all ears! Cheers, Hermès.

2 1

Need assistance on bug 7965
by Alexander Varnin 26 Mar '14

26 Mar '14

Hello, dear developers! Sorry if I am doing something wrong, but I am not sure, if everyone who may help would be notified by JIRA. I made some bug hunting on CORE-7965 and now need some assistance in finding way to fix it. I have posted the results in my last comment on JIRA: http://jira.reactos.org/browse/CORE-7965?focusedCommentId=57456&page=com.at… In short: a bug is related to some interprocess virtual address transmission that is leading to access attempt on unallocated virtual memory, that finally crashes ReactOS.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 62562: [EXT2] try_return() == try_return(S) with nothing in S . The code sometimes use it. Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'.
by Thomas Faber 26 Mar '14

26 Mar '14

That's illegal, macros can't be overloaded. drivers/filesystems/ext2/inc/ext2fsd.h:64:0: warning: "try_return" redefined [enabled by default] You could try #define try_return(...) { __VA_ARGS__; goto try_exit; } If that doesn't do it, it might simply need a separate macro (I'm not sure to what extent this is third party code though) (also if these were the last instances of that -- and I think so --, we might want to make 4003 an error) On 2014-03-24 23:20, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon Mar 24 22:20:52 2014 > New Revision: 62562 > > URL: http://svn.reactos.org/svn/reactos?rev=62562&view=rev > Log: > [EXT2] > try_return() == try_return(S) with nothing in S . The code sometimes use it. > Shut up MSVC warning C4003: not enough actual parameters for macro 'try_return'. > > Modified: > trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > > Modified: trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/ext2/i… > ============================================================================== > --- trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/ext2/inc/ext2fsd.h [iso-8859-1] Mon Mar 24 22:20:52 2014 > @@ -60,6 +60,7 @@ > extern Ext2Data Ext2GlobalData; > > // try-finally simulation > +#define try_return() { goto try_exit; } > #define try_return(S) { S; goto try_exit; } > #define try_return1(S) { S; goto try_exit1; } > #define try_return2(S) { S; goto try_exit2; } > >

3 5

Installing and running ReactOS on modern hardware
by Thomas Mueller 24 Mar '14

24 Mar '14

I would like to build and install ReactOS from source but may be strapped for where to install it. I have USB sticks, 3 TB SATA hard drives, and 3 TB USB 3.0 hard drive. Hard drives are GPT-partitioned, which ReactOS apparently doesn't support. I have some old IDE hard drives which I access with USB 2.0 enclosure: 1271 MB and 40 GB. I also have an old 341 MB IDE hard drive that I can't read through USB 2.0 enclosure. I could compile from Linux or FreeBSD with ROSBE, could do further builds that way or with Wine and MinGW under Linux or FreeBSD. I don't want to do heavy compiling on USB stick if I can avoid it. I believe the only file system ReactOS currently supports is FAT16 or FAT32, which limits possible partition size compared to NTFS or Linux or BSD file systems. Can I install to USB stick, 4GB or 8 GB, and are there any other possibilities with my hardware? Tom

2 1

What's happening to the build bots??
by Hermès BÉLUSCA - MAÏTO 21 Mar '14

21 Mar '14

Hi all! Since some time now, most of our build bots are unavailable (see http://build.reactos.org/builders , the ones maintained by Olaf). What is happening to them? I sent him a mail but no answer so far I have received. We *need* those bots! , and especially the patch-bot that I am waiting for, because I have two big patches in my local wc that need to be tested and I cannot proceed further for now (and surely other have too, according to some recent Jira reports). Please fix them asap. if possible :D Cheers, Hermès

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 62480: [PSDK] winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure)
by Thomas Faber 20 Mar '14

20 Mar '14

This is intentional, their RTL_ATOM_TABLE is already a pointer: /* Wine doesn't implement atom table as NT does: * - in NT, atom tables are user space tables, which ntdll directly accesses * - on Wine, (even local) atom tables are wineserver objects, hence a HANDLE */ typedef struct atom_table *RTL_ATOM_TABLE, **PRTL_ATOM_TABLE; So that would need to be changed consistently. (also, winternl.h should be used by Wine code only, so shouldn't affect us -- since we have NDK to use instead) On 2014-03-11 23:48, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Tue Mar 11 22:48:04 2014 > New Revision: 62480 > > URL: http://svn.reactos.org/svn/reactos?rev=62480&view=rev > Log: > [PSDK] > winternl.h: Fix RtlLookupAtomInAtomTable prototype (should be sent to wine? not sure) > > 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] Tue Mar 11 22:48:04 2014 > @@ -632,7 +632,7 @@ > FileFsMaximumInformation > } FS_INFORMATION_CLASS, *PFS_INFORMATION_CLASS; > > -typedef enum _KEY_INFORMATION_CLASS { > +typedef enum _KEY_INFORMATION_CLASS { > KeyBasicInformation = 0, > KeyNodeInformation = 1, > KeyFullInformation = 2, > @@ -2244,7 +2244,7 @@ > DWORD WINAPI RtlLengthSid(PSID); > NTSTATUS WINAPI RtlLocalTimeToSystemTime(const LARGE_INTEGER*,PLARGE_INTEGER); > BOOLEAN WINAPI RtlLockHeap(HANDLE); > -NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE,const WCHAR*,RTL_ATOM*); > +NTSTATUS WINAPI RtlLookupAtomInAtomTable(RTL_ATOM_TABLE*,const WCHAR*,RTL_ATOM*); > > NTSTATUS WINAPI RtlMakeSelfRelativeSD(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,LPDWORD); > void WINAPI RtlMapGenericMask(PACCESS_MASK,const GENERIC_MAPPING*); > >

2 1

Thoughts on Kickstarter
by Ólafur Arason 17 Mar '14

17 Mar '14

Hi, I've been following the project for years and I've even used explorer implementation on Windows. I also went to the Montreal event. I'm a linux user so I won't be a full time user any time soon. What I think would make a really good Kickstarter, having watched the Thorium Core progress: Developers Delight: What ReactOS or Thorium D has going for it is fully debugable and fundamental understanding of how Windows works. Microsoft has Visual Studio Online but it's pretty bad, at least at the moment it's a mess to set up. Having a way to run your MinGW-w64 projects, possible compile them. Having support for Clang msvc implementation. And last and not the least is the Visual Studio, which of course is the hardest. Even without that it's going to be really solid. An extra plus is being able to make Windows Embedded development stack running, because Trimble are really tied to that. Also Delphi and what ever other development you can think of. Having git support with CI type workflow is going to be great and with kernel level debug reports what could be better. The MingGW-w64 is going to great for all the open source software developers that need something to develop windows software without touching windows. You should talk with OpenShot they were having problems with that kind of development. This is going to be a double benefit for you guys, not only will it provide you with information about what people are using and what bugs are in your system but also provide a lot of foss software on your platform. Embedded dreams: Now that XP is through people need an embedded version, Windows Embedded isn't it, because it has a really weird api. Vista isn't really there or 7 so, where is your chance. Banks are paying Microsoft to extend XP for their ATMs but not every one can afford it. Enter Thorium E, for all those kiosks and POS. You have greater control so you can build a kit for Embedded user where they decide what's going to be included and what comes up, like not having a screen saver, virus software, IE, only allowing one or two exe files to run and only certain dlls. This would also be perfect to make single use virtual images with only one program running. If you need any help with making the video or with the campaign I would love to help. Regards, Olaf

1 0

[CORE-7969] A week later
by Minas Abrahamyan 15 Mar '14

15 Mar '14

Hi developers, Passed a week after I provided a ready for review and apply patch, a simplest solution for simplest bug. Could anyone review, test, and apply it? https://jira.reactos.org/browse/CORE-7969 Thanks

2 1

ReactOS needs to be self-hostable!
by Hermès BÉLUSCA - MAÏTO 15 Mar '14

15 Mar '14

Hi all ! ReactOS severely needs to be self-hostable for many reasons, one of it because it could allow people who only have Linux to be able to program / debug ReactOS with Windows tools (e.g. we have some people here and there complaining that they cannot use powerful debugging programs for debugging ReactOS (e.g. WinDbg and so on with MSVC builds of ReactOS) and therefore restrain themselves in using the Goode Olde GCC + DPRINT method, because they are running only on Linux). Something more personal is that I really want to program ReactOS on itself (in a VM) when it becomes self-hostable. But there are *only* few steps remaining before ReactOS can really be in such situation !! Ive already tested RosBE on it and I was able to download and configure a build. But there *are still* problems. Here is my setup on a VM: main HDD of letter drive C: with ReactOS, second HDD of letter drive D: with ROS source code in D:\rossrc, third HDD of letter drive E: with build output files in E:\rosbuild . After having successfully configured a build in the usual way (E:\rosbuild> D:\rossrc\configure.cmd), I first tried to compile the host-tools (cd host-tools && ninja). The first thing that Ive noticed is that doing so retriggered a configure, then the compilation as wanted. I retried again, and again it reconfigured the build before actually rebuilding the host-tools. The same phenomenon appears then when trying to build ReactOS proper. After analyzing produced files by the configuration step and comparing with a clean build on windows 2k3, it became clear that few files were missing, because obviously not generated: E:\rosbuild\host-tools\CMakeFiles\2.8.10.2-ReactOS\CMakeCCompiler.cmake and CMakeCXXCompiler.cmake . The other .cmake files that should also be present here (CMakeRCCompiler.cmake and CMakeSystem.cmake) as well as two .bin files and two subdirectories where present (and contain the same things). I was suggesting it might be a problem with the command-line interpreter, so I changed our cmd.exe with the one of windows 2000 (not win2k3, because the latter makes extra calls to some security APIs of advapi32 not implemented on ReactOS before running .bat / .cmd files, and it fails), but nothing changed, the files were not still present. After having enabled extra debug output of cmake (that is called when configuring a build) by adding the flags --debug-output --trace (without quotes) in the cmake calls in configure.cmd (and after redirecting console stdout + stderr to a file when retrigerring a clean configuration), doing that on ReactOS *and* on win2k3 for comparison purposes, I saw that, at some point, some cmake flags concerning compiler recognition (à la: CMAKE_GCC_EXISTS for example) werent set to TRUE or FALSE, but were kept empty. So Im wondering whether it is actually some issue, either concerning our C runtime library (e.g. some called sprintf-like function fails or whatever) is buggy and something fails, OR, something file-system related. Concerning file-system, you know that we have LOTS of kernel32:file winetests failing, about problems for deleting files, recreating (or just creating) them, and so on Maybe for some reason cmake fails to create those CMake(C/CXX)Compiler.cmake files for the same reason one of the kernel32:file tests fail ? I dont know, this previous point being speculative since I didnt test anything regarding that. Therefore it would be very nice *to see you all* trying to uncover where this bug comes from so that you can *finally* declare ReactOS self-hostable before, maybe, the next release !! Cheers, Hermès

2 2

Re: [ros-dev] [ros-diffs] [fireball] 62477: [NTOS] - Remove unneeded macro by David Welch in 2002 and me in 2003.
by Timo Kreuzer 11 Mar '14

11 Mar '14

Good sart, but I'm going to outperform this cleanup approach a bit... ;-) Am 11.03.2014 19:46, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Tue Mar 11 18:46:32 2014 > New Revision: 62477 > > URL: http://svn.reactos.org/svn/reactos?rev=62477&view=rev > Log: > [NTOS] > - Remove unneeded macro by David Welch in 2002 and me in 2003. > > Modified: > trunk/reactos/ntoskrnl/mm/i386/page.c > > Modified: trunk/reactos/ntoskrnl/mm/i386/page.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/i386/page.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/i386/page.c [iso-8859-1] Tue Mar 11 18:46:32 2014 > @@ -40,22 +40,10 @@ > #define PA_ACCESSED (1 << PA_BIT_ACCESSED) > #define PA_GLOBAL (1 << PA_BIT_GLOBAL) > > -#define HYPERSPACE (0xc0400000) > -#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPERSPACE && (ULONG)(v) < HYPERSPACE + 0x400000)) > +#define IS_HYPERSPACE(v) (((ULONG)(v) >= HYPER_SPACE && (ULONG)(v) <= HYPER_SPACE_END)) > > #define PTE_TO_PFN(X) ((X) >> PAGE_SHIFT) > #define PFN_TO_PTE(X) ((X) << PAGE_SHIFT) > - > -#if defined(__GNUC__) > -#define PTE_TO_PAGE(X) ((LARGE_INTEGER)(LONGLONG)(PAGE_MASK(X))) > -#else > -__inline LARGE_INTEGER PTE_TO_PAGE(ULONG npage) > -{ > - LARGE_INTEGER dummy; > - dummy.QuadPart = (LONGLONG)(PAGE_MASK(npage)); > - return dummy; > -} > -#endif > > const > ULONG > > >

1 0

Valve has publushed Direct3D -> OpenGL translation layer
by Alexander Rechitskiy 11 Mar '14

11 Mar '14

Valve has publushed Direct3D -> OpenGL translation layer with BSD like license https://github.com/ValveSoftware/ToGL Taken directly from the DOTA2 source tree; supports: Limited subset of Direct3D 9.0c Bytecode-level HLSL -> GLSL translator Some SM3 support: Multiple Render Targets, no Vertex Texture Fetch This most likely won't build by itself and is provided as-is and completely unsupported. Feel free to use it for your reference, incorporate it into your projects or send us modifications. Be wary that some parts are hardcoded to match Source Engine behavior; see CentroidMaskFromName() and ShadowDepthSamplerMaskFromName() in dxabstract.cpp. Please refer to the LICENSE file for more information. -- Best regards Alexander Rechitskiy

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPartOffset - Fix implementa...
by Timo Kreuzer 08 Mar '14

08 Mar '14

See inline... Am 07.03.2014 20:33, schrieb pschweitzer(a)svn.reactos.org: > [...] > + /* Update user buffer with the change that occured > + * First copy parent name if any > + * Then copy target name, there's always one > + * And finally, copy stream name if any > + * If these names aren't unicode, then convert first > + */ > + _SEH2_TRY > + { > + OutputBuffer->NextEntryOffset = 0; > + OutputBuffer->Action = Action; > + OutputBuffer->FileNameLength = DataLength - sizeof(FILE_NOTIFY_INFORMATION); > + if (IsUnicode) > + { > + if (ParentName->Length) > + { > + RtlCopyMemory(OutputBuffer->FileName, ParentName->Buffer, ParentName->Length); > + OutputBuffer->FileName[ParentName->Length / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ParentName->Length + sizeof(WCHAR); > + } > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten, TargetName->Buffer, TargetName->Length); OutputBuffer->FileName is a WCHAR array, AlreadyWritten is a count of bytes, the pointer arithmetic is wrong here. > + if (StreamName) > + { > + AlreadyWritten += TargetName->Length; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + StreamName->Buffer, StreamName->Length); see above > + } > + } > + else > + { > + if (!ParentName->Length) > + { > + ASSERT(StreamName); > + RtlCopyMemory(OutputBuffer->FileName, StreamName->Buffer, StreamName->Length); > + } > + else > + { > + RtlOemToUnicodeN(OutputBuffer->FileName, OutputBuffer->FileNameLength, > + &ResultSize, ParentName->Buffer, > + ParentName->Length); > + OutputBuffer->FileName[ResultSize / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ResultSize + sizeof(WCHAR); > + > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten, > + OutputBuffer->FileNameLength, &ResultSize, > + TargetName->Buffer, TargetName->Length); see above > + > + if (StreamName) > + { > + AlreadyWritten += ResultSize; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + OutputBuffer->FileNameLength, &ResultSize, > + StreamName->Buffer, StreamName->Length); see above > [...] > + > + /* Look for target name & construct it, if required */ > + if (TargetName.Buffer) > + { > + TargetNameLength = TargetName.Length; The TargetNameLength vatiable is completely redundant > [...] > + > + /* Get the position where we can put our data (aligned!) */ > + AlignedDataLength = ROUND_UP(NotifyChange->DataLength, sizeof(ULONG)); > + /* If it's higher than buffer length, then, bail out without outputing */ > + if (DataLength > NumberOfBytes || AlignedDataLength + DataLength > NumberOfBytes) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + OutputBuffer = 0; > + FileNotifyInfo = 0; Use NULL

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 62442: [NTOSKRNL] - Implement FsRtlNotifyFilterReportChange - Implement FsRtlNotifyUpdateBuffer - Implement FsRtlCancelNotify - Implement FsRtlNotifyGetLastPartOffset - Fix implementa...
by Jérôme Gardou 07 Mar '14

07 Mar '14

Awesomeness, in its purest art. Le 07.03.2014 20:33, pschweitzer(a)svn.reactos.org a écrit : > Author: pschweitzer > Date: Fri Mar 7 19:33:38 2014 > New Revision: 62442 > > URL: http://svn.reactos.org/svn/reactos?rev=62442&view=rev > Log: > [NTOSKRNL] > - Implement FsRtlNotifyFilterReportChange > - Implement FsRtlNotifyUpdateBuffer > - Implement FsRtlCancelNotify > - Implement FsRtlNotifyGetLastPartOffset > - Fix implementation of FsRtlNotifyFilterChangeDirectory > > This finishes the implementation of file system notifications inside the kernel. > Data are properly returned to the caller on changes. > > CORE-2582 > > Modified: > trunk/reactos/ntoskrnl/fsrtl/notify.c > trunk/reactos/ntoskrnl/include/internal/fsrtl.h > > Modified: trunk/reactos/ntoskrnl/fsrtl/notify.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/notify.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] Fri Mar 7 19:33:38 2014 > @@ -12,6 +12,55 @@ > #define NDEBUG > #include <debug.h> > > +/* INLINED FUNCTIONS *********************************************************/ > + > +/* > + * @implemented > + */ > +FORCEINLINE > +VOID > +FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > +{ > + ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread(); > + > + /* Only acquire fast mutex if it's not already acquired by the current thread */ > + if (RealNotifySync->OwningThread != CurrentThread) > + { > + ExAcquireFastMutexUnsafe(&(RealNotifySync->FastMutex)); > + RealNotifySync->OwningThread = CurrentThread; > + } > + /* Whatever the case, keep trace of the attempt to acquire fast mutex */ > + RealNotifySync->OwnerCount++; > +} > + > +/* > + * @implemented > + */ > +FORCEINLINE > +VOID > +FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > +{ > + RealNotifySync->OwnerCount--; > + /* Release the fast mutex only if no other instance needs it */ > + if (!RealNotifySync->OwnerCount) > + { > + ExReleaseFastMutexUnsafe(&(RealNotifySync->FastMutex)); > + RealNotifySync->OwningThread = (ULONG_PTR)0; > + } > +} > + > +#define FsRtlNotifyGetLastPartOffset(FullLen, TargLen, Type, Chr) \ > + for (FullPosition = 0; FullPosition < FullLen; ++FullPosition) \ > + if (((Type)NotifyChange->FullDirectoryName->Buffer)[FullPosition] == Chr) \ > + ++FullNumberOfParts; \ > + for (LastPartOffset = 0; LastPartOffset < TargLen; ++LastPartOffset) { \ > + if ( ((Type)TargetDirectory.Buffer)[LastPartOffset] == Chr) { \ > + ++TargetNumberOfParts; \ > + if (TargetNumberOfParts == FullNumberOfParts) \ > + break; \ > + } \ > + } > + > /* PRIVATE FUNCTIONS *********************************************************/ > > VOID > @@ -22,13 +71,161 @@ > FsRtlNotifySetCancelRoutine(IN PIRP Irp, > IN PNOTIFY_CHANGE NotifyChange OPTIONAL); > > +/* > + * @implemented > + */ > VOID > NTAPI > FsRtlCancelNotify(IN PDEVICE_OBJECT DeviceObject, > IN PIRP Irp) > { > + PVOID Buffer; > + PIRP NotifyIrp; > + ULONG BufferLength; > + PIO_STACK_LOCATION Stack; > + PNOTIFY_CHANGE NotifyChange; > + PREAL_NOTIFY_SYNC RealNotifySync; > + PSECURITY_SUBJECT_CONTEXT SubjectContext = NULL; > + > + /* Get the NOTIFY_CHANGE struct and reset it */ > + NotifyChange = (PNOTIFY_CHANGE)Irp->IoStatus.Information; > + Irp->IoStatus.Information = 0; > + /* Reset the cancel routine */ > + IoSetCancelRoutine(Irp, NULL); > + /* And release lock */ > IoReleaseCancelSpinLock(Irp->CancelIrql); > - UNIMPLEMENTED; > + /* Get REAL_NOTIFY_SYNC struct */ > + RealNotifySync = NotifyChange->NotifySync; > + > + FsRtlNotifyAcquireFastMutex(RealNotifySync); > + > + _SEH2_TRY > + { > + /* Remove the IRP from the notifications list and mark it pending */ > + RemoveEntryList(&(Irp->Tail.Overlay.ListEntry)); > + IoMarkIrpPending(Irp); > + > + /* Now, the tricky part - let's find a buffer big enough to hold the return data */ > + if (NotifyChange->Buffer && NotifyChange->AllocatedBuffer == NULL && > + ((Irp->MdlAddress && MmGetSystemAddressForMdl(Irp->MdlAddress) == NotifyChange->Buffer) || > + NotifyChange->Buffer == Irp->AssociatedIrp.SystemBuffer)) > + { > + /* Assume we didn't find any */ > + Buffer = NULL; > + BufferLength = 0; > + > + /* If we don't have IRPs, check if current buffer is big enough */ > + if (IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + if (NotifyChange->BufferLength >= NotifyChange->DataLength) > + { > + BufferLength = NotifyChange->BufferLength; > + } > + } > + else > + { > + /* Otherwise, try to look at next IRP available */ > + NotifyIrp = CONTAINING_RECORD(NotifyChange->NotifyIrps.Flink, IRP, Tail.Overlay.ListEntry); > + Stack = IoGetCurrentIrpStackLocation(NotifyIrp); > + > + /* If its buffer is big enough, get it */ > + if (Stack->Parameters.NotifyDirectory.Length >= NotifyChange->BufferLength) > + { > + /* Is it MDL? */ > + if (NotifyIrp->AssociatedIrp.SystemBuffer == NULL) > + { > + if (NotifyIrp->MdlAddress != NULL) > + { > + Buffer = MmGetSystemAddressForMdl(NotifyIrp->MdlAddress); > + } > + } > + else > + { > + Buffer = NotifyIrp->AssociatedIrp.MasterIrp; > + } > + > + /* Backup our accepted buffer length */ > + BufferLength = Stack->Parameters.NotifyDirectory.Length; > + if (BufferLength > NotifyChange->BufferLength) > + { > + BufferLength = NotifyChange->BufferLength; > + } > + } > + } > + > + /* At that point, we *may* have a buffer */ > + > + /* If it has null length, then note that we won't use it */ > + if (BufferLength == 0) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + /* If we have a buffer length, but no buffer then allocate one */ > + if (Buffer == NULL) > + { > + PsChargePoolQuota(NotifyChange->OwningProcess, PagedPool, BufferLength); > + Buffer = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, BufferLength, 'NrSF'); > + NotifyChange->AllocatedBuffer = Buffer; > + } > + > + /* Copy data in that buffer */ > + RtlCopyMemory(Buffer, NotifyChange->Buffer, NotifyChange->DataLength); > + NotifyChange->ThisBufferLength = BufferLength; > + NotifyChange->Buffer = Buffer; > + } > + > + /* If we don't have valide buffer, ensure everything is 0-ed out */ > + if (NotifyChange->Flags & NOTIFY_IMMEDIATELY) > + { > + NotifyChange->Buffer = 0; > + NotifyChange->AllocatedBuffer = 0; > + NotifyChange->LastEntry = 0; > + NotifyChange->DataLength = 0; > + NotifyChange->ThisBufferLength = 0; > + } > + } > + > + /* It's now time to complete - data are ready */ > + > + /* Set appropriate status and complete */ > + Irp->IoStatus.Status = STATUS_CANCELLED; > + IofCompleteRequest(Irp, EVENT_INCREMENT); > + > + /* If that notification isn't referenced any longer, drop it */ > + if (!InterlockedDecrement((PLONG)&(NotifyChange->ReferenceCount))) > + { > + /* If it had an allocated buffer, delete */ > + if (NotifyChange->AllocatedBuffer) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NotifyChange->ThisBufferLength); > + ExFreePoolWithTag(NotifyChange->AllocatedBuffer, 'NrSF'); > + } > + > + /* In case of full name, remember subject context for later deletion */ > + if (NotifyChange->FullDirectoryName) > + { > + SubjectContext = NotifyChange->SubjectContext; > + } > + > + /* We mustn't have ANY change left anymore */ > + ASSERT(NotifyChange->NotifyList.Flink == NULL); > + ExFreePoolWithTag(NotifyChange, 0); > + } > + } > + _SEH2_FINALLY > + { > + FsRtlNotifyReleaseFastMutex(RealNotifySync); > + > + /* If the subject security context was captured, release and free it */ > + if (SubjectContext) > + { > + SeReleaseSubjectContext(SubjectContext); > + ExFreePool(SubjectContext); > + } > + } > + _SEH2_END; > } > > /* > @@ -58,6 +255,9 @@ > } > } > > +/* > + *@implemented > + */ > PNOTIFY_CHANGE > FsRtlIsNotifyOnList(IN PLIST_ENTRY NotifyList, > IN PVOID FsContext) > @@ -81,22 +281,6 @@ > } > } > return NULL; > -} > - > -FORCEINLINE > -VOID > -FsRtlNotifyAcquireFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > -{ > - ULONG_PTR CurrentThread = (ULONG_PTR)KeGetCurrentThread(); > - > - /* Only acquire fast mutex if it's not already acquired by the current thread */ > - if (RealNotifySync->OwningThread != CurrentThread) > - { > - ExAcquireFastMutexUnsafe(&(RealNotifySync->FastMutex)); > - RealNotifySync->OwningThread = CurrentThread; > - } > - /* Whatever the case, keep trace of the attempt to acquire fast mutex */ > - RealNotifySync->OwnerCount++; > } > > /* > @@ -216,7 +400,7 @@ > > DataLength = NotifyChange->DataLength; > > - NotifyChange->Flags &= (INVALIDATE_BUFFERS | WATCH_TREE); > + NotifyChange->Flags &= (NOTIFY_IMMEDIATELY | WATCH_TREE); > NotifyChange->DataLength = 0; > NotifyChange->LastEntry = 0; > > @@ -233,19 +417,6 @@ > } > } > > -FORCEINLINE > -VOID > -FsRtlNotifyReleaseFastMutex(IN PREAL_NOTIFY_SYNC RealNotifySync) > -{ > - RealNotifySync->OwnerCount--; > - /* Release the fast mutex only if no other instance needs it */ > - if (!RealNotifySync->OwnerCount) > - { > - ExReleaseFastMutexUnsafe(&(RealNotifySync->FastMutex)); > - RealNotifySync->OwningThread = (ULONG_PTR)0; > - } > -} > - > /* > * @implemented > */ > @@ -293,6 +464,91 @@ > > /* Return that we didn't removed cancel routine */ > return FALSE; > +} > + > +/* > + * @implemented > + */ > +BOOLEAN > +FsRtlNotifyUpdateBuffer(OUT PFILE_NOTIFY_INFORMATION OutputBuffer, > + IN ULONG Action, > + IN PSTRING ParentName, > + IN PSTRING TargetName, > + IN PSTRING StreamName, > + IN BOOLEAN IsUnicode, > + IN ULONG DataLength) > +{ > + /* Unless there's an issue with buffers, there's no reason to fail */ > + BOOLEAN Succeed = TRUE; > + ULONG AlreadyWritten = 0, ResultSize; > + > + PAGED_CODE(); > + > + /* Update user buffer with the change that occured > + * First copy parent name if any > + * Then copy target name, there's always one > + * And finally, copy stream name if any > + * If these names aren't unicode, then convert first > + */ > + _SEH2_TRY > + { > + OutputBuffer->NextEntryOffset = 0; > + OutputBuffer->Action = Action; > + OutputBuffer->FileNameLength = DataLength - sizeof(FILE_NOTIFY_INFORMATION); > + if (IsUnicode) > + { > + if (ParentName->Length) > + { > + RtlCopyMemory(OutputBuffer->FileName, ParentName->Buffer, ParentName->Length); > + OutputBuffer->FileName[ParentName->Length / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ParentName->Length + sizeof(WCHAR); > + } > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten, TargetName->Buffer, TargetName->Length); > + if (StreamName) > + { > + AlreadyWritten += TargetName->Length; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlCopyMemory(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + StreamName->Buffer, StreamName->Length); > + } > + } > + else > + { > + if (!ParentName->Length) > + { > + ASSERT(StreamName); > + RtlCopyMemory(OutputBuffer->FileName, StreamName->Buffer, StreamName->Length); > + } > + else > + { > + RtlOemToUnicodeN(OutputBuffer->FileName, OutputBuffer->FileNameLength, > + &ResultSize, ParentName->Buffer, > + ParentName->Length); > + OutputBuffer->FileName[ResultSize / sizeof(WCHAR)] = L'\\'; > + AlreadyWritten = ResultSize + sizeof(WCHAR); > + > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten, > + OutputBuffer->FileNameLength, &ResultSize, > + TargetName->Buffer, TargetName->Length); > + > + if (StreamName) > + { > + AlreadyWritten += ResultSize; > + OutputBuffer->FileName[AlreadyWritten / sizeof(WCHAR)] = L':'; > + RtlOemToUnicodeN(OutputBuffer->FileName + AlreadyWritten + sizeof(WCHAR), > + OutputBuffer->FileNameLength, &ResultSize, > + StreamName->Buffer, StreamName->Length); > + } > + } > + } > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Succeed = FALSE; > + } > + _SEH2_END; > + > + return Succeed; > } > > /* PUBLIC FUNCTIONS **********************************************************/ > @@ -445,7 +701,7 @@ > > /*++ > * @name FsRtlNotifyFilterChangeDirectory > - * @unimplemented > + * @implemented > * > * FILLME > * > @@ -559,16 +815,16 @@ > NotifyIrp->IoStatus.Status = STATUS_DELETE_PENDING; > IoCompleteRequest(NotifyIrp, EVENT_INCREMENT); > } > - /* Complete if there is directory enumeration and no buffer available any more */ > - if ((NotifyChange->Flags & INVALIDATE_BUFFERS) && (NotifyChange->Flags & ENUMERATE_DIR)) > - { > - NotifyChange->Flags &= ~INVALIDATE_BUFFERS; > + /* Complete now if asked to (and not asked to notify later on) */ > + if ((NotifyChange->Flags & NOTIFY_IMMEDIATELY) && !(NotifyChange->Flags & NOTIFY_LATER)) > + { > + NotifyChange->Flags &= ~NOTIFY_IMMEDIATELY; > IoMarkIrpPending(NotifyIrp); > NotifyIrp->IoStatus.Status = STATUS_NOTIFY_ENUM_DIR; > IoCompleteRequest(NotifyIrp, EVENT_INCREMENT); > } > - /* If no data yet, or directory enumeration, handle */ > - else if (NotifyChange->DataLength == 0 || (NotifyChange->Flags & ENUMERATE_DIR)) > + /* If no data yet, or asked to notify later on, handle */ > + else if (NotifyChange->DataLength == 0 || (NotifyChange->Flags & NOTIFY_LATER)) > { > goto HandleIRP; > } > @@ -612,20 +868,13 @@ > else > { > /* If it can't contain WCHAR, it's ANSI */ > - if (FullDirectoryName->Length < sizeof(WCHAR)) > + if (FullDirectoryName->Length < sizeof(WCHAR) || ((CHAR*)FullDirectoryName->Buffer)[1] != 0) > { > NotifyChange->CharacterSize = sizeof(CHAR); > } > - /* First char is \, so in unicode, right part is 0 > - * whereas in ANSI it contains next char > - */ > - else if (((CHAR*)FullDirectoryName->Buffer)[1] == 0) > + else > { > NotifyChange->CharacterSize = sizeof(WCHAR); > - } > - else > - { > - NotifyChange->CharacterSize = sizeof(CHAR); > } > > /* Now, check is user is willing to watch root */ > @@ -668,7 +917,7 @@ > FsRtlNotifyReleaseFastMutex(RealNotifySync); > > /* If the subject security context was captured and there's no notify */ > - if (SubjectContext && (!NotifyChange || FullDirectoryName)) > + if (SubjectContext && (!NotifyChange || NotifyChange->FullDirectoryName)) > { > SeReleaseSubjectContext(SubjectContext); > ExFreePool(SubjectContext); > @@ -679,7 +928,7 @@ > > /*++ > * @name FsRtlNotifyFilterReportChange > - * @unimplemented > + * @implemented > * > * FILLME > * > @@ -731,7 +980,437 @@ > IN PVOID TargetContext, > IN PVOID FilterContext) > { > - KeBugCheck(FILE_SYSTEM); > + PIRP Irp; > + PVOID OutputBuffer; > + USHORT FullPosition; > + PLIST_ENTRY NextEntry; > + PIO_STACK_LOCATION Stack; > + PNOTIFY_CHANGE NotifyChange; > + PREAL_NOTIFY_SYNC RealNotifySync; > + PFILE_NOTIFY_INFORMATION FileNotifyInfo; > + BOOLEAN IsStream, IsParent, PoolQuotaCharged; > + STRING TargetDirectory, TargetName, ParentName, IntNormalizedParentName; > + ULONG NumberOfBytes, TargetNumberOfParts, FullNumberOfParts, LastPartOffset, ParentNameOffset, ParentNameLength; > + ULONG DataLength, TargetNameLength, AlignedDataLength; > + > + TargetDirectory.Length = 0; > + TargetDirectory.MaximumLength = 0; > + TargetDirectory.Buffer = NULL; > + TargetName.Length = 0; > + TargetName.MaximumLength = 0; > + TargetName.Buffer = NULL; > + ParentName.Length = 0; > + ParentName.MaximumLength = 0; > + ParentName.Buffer = NULL; > + IsStream = FALSE; > + > + PAGED_CODE(); > + > + DPRINT("FsRtlNotifyFilterReportChange(%p, %p, %p, %u, %p, %p, %p, %x, %x, %p, %p)\n", > + NotifySync, NotifyList, FullTargetName, TargetNameOffset, StreamName, NormalizedParentName, > + FilterMatch, Action, TargetContext, FilterContext); > + > + /* We need offset in name */ > + if (!TargetNameOffset && FullTargetName) > + { > + return; > + } > + > + /* Get real structure hidden behind the opaque pointer */ > + RealNotifySync = (PREAL_NOTIFY_SYNC)NotifySync; > + /* Acquire lock - will be released in finally block */ > + FsRtlNotifyAcquireFastMutex(RealNotifySync); > + _SEH2_TRY > + { > + /* Browse all the registered notifications we have */ > + for (NextEntry = NotifyList->Flink; NextEntry != NotifyList; > + NextEntry = NextEntry->Flink) > + { > + /* Try to find an entry matching our change */ > + NotifyChange = CONTAINING_RECORD(NextEntry, NOTIFY_CHANGE, NotifyList); > + if (FullTargetName != NULL) > + { > + ASSERT(NotifyChange->FullDirectoryName != NULL); > + if (!NotifyChange->FullDirectoryName->Length) > + { > + continue; > + } > + > + if (!(FilterMatch & NotifyChange->CompletionFilter)) > + { > + continue; > + } > + > + /* If no normalized name provided, construct it from full target name */ > + if (NormalizedParentName == NULL) > + { > + IntNormalizedParentName.Buffer = FullTargetName->Buffer; > + if (TargetNameOffset != NotifyChange->CharacterSize) > + { > + IntNormalizedParentName.MaximumLength = > + IntNormalizedParentName.Length = TargetNameOffset - NotifyChange->CharacterSize; > + } > + else > + { > + IntNormalizedParentName.MaximumLength = > + IntNormalizedParentName.Length = TargetNameOffset; > + } > + NormalizedParentName = &IntNormalizedParentName; > + } > + > + /* heh? Watched directory bigger than changed file? */ > + if (NormalizedParentName->Length < NotifyChange->FullDirectoryName->Length) > + { > + continue; > + } > + > + /* Same len => parent */ > + if (NormalizedParentName->Length == NotifyChange->FullDirectoryName->Length) > + { > + IsParent = TRUE; > + } > + /* If not, then, we have to be watching the tree, otherwise we don't have to report such changes */ > + else if (!(NotifyChange->Flags & WATCH_TREE)) > + { > + continue; > + } > + /* And finally, we've to check we're properly \-terminated */ > + else > + { > + if (!(NotifyChange->Flags & WATCH_ROOT)) > + { > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + if (((PSTR)NormalizedParentName->Buffer)[NotifyChange->FullDirectoryName->Length] != '\\') > + { > + continue; > + } > + } > + else > + { > + if (((PWSTR)NormalizedParentName->Buffer)[NotifyChange->FullDirectoryName->Length / sizeof (WCHAR)] != L'\\') > + { > + continue; > + } > + } > + } > + > + IsParent = FALSE; > + } > + > + /* If len matches, then check that both name are equal */ > + if (!RtlEqualMemory(NormalizedParentName->Buffer, NotifyChange->FullDirectoryName->Buffer, > + NotifyChange->FullDirectoryName->Length)) > + { > + continue; > + } > + > + /* Call traverse callback (only if we have to traverse ;-)) */ > + if (!IsParent > + && NotifyChange->TraverseCallback != NULL > + && !NotifyChange->TraverseCallback(NotifyChange->FsContext, > + TargetContext, > + NotifyChange->SubjectContext)) > + { > + continue; > + } > + > + /* And then, filter callback if provided */ > + if (NotifyChange->FilterCallback != NULL > + && FilterContext != NULL > + && !NotifyChange->FilterCallback(NotifyChange->FsContext, FilterContext)) > + { > + continue; > + } > + } > + /* We have a stream! */ > + else > + { > + ASSERT(NotifyChange->FullDirectoryName == NULL); > + if (TargetContext != NotifyChange->SubjectContext) > + { > + continue; > + } > + > + ParentName.Buffer = NULL; > + ParentName.Length = 0; > + IsStream = TRUE; > + IsParent = FALSE; > + } > + > + /* If we don't have to notify immediately, prepare for output */ > + if (!(NotifyChange->Flags & NOTIFY_IMMEDIATELY)) > + { > + /* If we have something to output... */ > + if (NotifyChange->BufferLength) > + { > + /* Get size of the output */ > + NumberOfBytes = 0; > + Irp = NULL; > + if (!NotifyChange->ThisBufferLength) > + { > + if (IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + NumberOfBytes = NotifyChange->BufferLength; > + } > + else > + { > + Irp = CONTAINING_RECORD(NotifyChange->NotifyIrps.Flink, IRP, Tail.Overlay.ListEntry); > + Stack = IoGetCurrentIrpStackLocation(Irp); > + NumberOfBytes = Stack->Parameters.NotifyDirectory.Length; > + } > + } > + else > + { > + NumberOfBytes = NotifyChange->ThisBufferLength; > + } > + > + /* If we're matching parent, we don't care about parent (redundant) */ > + if (IsParent) > + { > + ParentName.Length = 0; > + } > + else > + { > + /* If we don't deal with streams, some more work is required */ > + if (!IsStream) > + { > + if (NotifyChange->Flags & WATCH_ROOT || > + (NormalizedParentName->Buffer != FullTargetName->Buffer)) > + { > + /* Construct TargetDirectory if we don't have it yet */ > + if (TargetDirectory.Buffer == NULL) > + { > + TargetDirectory.Buffer = FullTargetName->Buffer; > + TargetDirectory.Length = TargetNameOffset; > + if (TargetNameOffset != NotifyChange->CharacterSize) > + { > + TargetDirectory.Length = TargetNameOffset - NotifyChange->CharacterSize; > + } > + TargetDirectory.MaximumLength = TargetDirectory.Length; > + } > + /* Now, we start looking for matching parts (unless we watch root) */ > + TargetNumberOfParts = 0; > + if (!(NotifyChange->Flags & WATCH_ROOT)) > + { > + FullNumberOfParts = 1; > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + FsRtlNotifyGetLastPartOffset(NotifyChange->FullDirectoryName->Length, > + TargetDirectory.Length, PSTR, '\\'); > + } > + else > + { > + FsRtlNotifyGetLastPartOffset(NotifyChange->FullDirectoryName->Length / sizeof(WCHAR), > + TargetDirectory.Length / sizeof(WCHAR), PWSTR, L'\\'); > + LastPartOffset *= NotifyChange->CharacterSize; > + } > + } > + > + /* Then, we can construct proper parent name */ > + ParentNameOffset = NotifyChange->CharacterSize + LastPartOffset; > + ParentName.Buffer = &TargetDirectory.Buffer[ParentNameOffset]; > + ParentNameLength = TargetDirectory.Length; > + } > + else > + { > + /* Construct parent name even for streams */ > + ParentName.Buffer = &NormalizedParentName->Buffer[NotifyChange->FullDirectoryName->Length] + NotifyChange->CharacterSize; > + ParentNameLength = NormalizedParentName->Length - NotifyChange->FullDirectoryName->Length; > + ParentNameOffset = NotifyChange->CharacterSize; > + } > + ParentNameLength -= ParentNameOffset; > + ParentName.Length = ParentNameLength; > + ParentName.MaximumLength = ParentNameLength; > + } > + } > + > + /* Start to count amount of data to write, we've first the structure itself */ > + DataLength = FIELD_OFFSET(FILE_NOTIFY_INFORMATION, FileName); > + > + /* If stream, we'll just append stream name */ > + if (IsStream) > + { > + ASSERT(StreamName != NULL); > + DataLength += StreamName->Length; > + } > + else > + { > + /* If not parent, we've to append parent name */ > + if (!IsParent) > + { > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + DataLength += RtlOemStringToCountedUnicodeSize(&ParentName); > + } > + else > + { > + DataLength += ParentName.Length; > + } > + DataLength += sizeof(WCHAR); > + } > + > + /* Look for target name & construct it, if required */ > + if (TargetName.Buffer) > + { > + TargetNameLength = TargetName.Length; > + } > + else > + { > + TargetName.Buffer = &FullTargetName->Buffer[TargetNameOffset]; > + TargetNameLength = FullTargetName->Length - TargetNameOffset; > + TargetName.Length = TargetNameLength; > + TargetName.MaximumLength = TargetNameLength; > + } > + > + /* Then, we will append it as well */ > + if (NotifyChange->CharacterSize == sizeof(CHAR)) > + { > + DataLength += RtlOemStringToCountedUnicodeSize(&TargetName); > + } > + else > + { > + DataLength += TargetName.Length; > + } > + > + /* If we also had a stream name, then we can append it as well */ > + if (StreamName != NULL) > + { > + if (NotifyChange->CharacterSize == sizeof(WCHAR)) > + { > + DataLength += StreamName->Length + sizeof(WCHAR); > + } > + else > + { > + DataLength = DataLength + RtlOemStringToCountedUnicodeSize(&TargetName) + sizeof(CHAR); > + } > + } > + } > + > + /* Get the position where we can put our data (aligned!) */ > + AlignedDataLength = ROUND_UP(NotifyChange->DataLength, sizeof(ULONG)); > + /* If it's higher than buffer length, then, bail out without outputing */ > + if (DataLength > NumberOfBytes || AlignedDataLength + DataLength > NumberOfBytes) > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + else > + { > + OutputBuffer = 0; > + FileNotifyInfo = 0; > + /* If we already had a buffer, update last entry position */ > + if (NotifyChange->Buffer != NULL) > + { > + FileNotifyInfo = (PVOID)((ULONG_PTR)NotifyChange->Buffer + NotifyChange->LastEntry); > + FileNotifyInfo->NextEntryOffset = AlignedDataLength - NotifyChange->LastEntry; > + NotifyChange->LastEntry = AlignedDataLength; > + /* And get our output buffer */ > + OutputBuffer = (PVOID)((ULONG_PTR)NotifyChange->Buffer + AlignedDataLength); > + } > + /* If we hadn't buffer, try to find one */ > + else if (Irp != NULL) > + { > + if (Irp->AssociatedIrp.SystemBuffer != NULL) > + { > + OutputBuffer = Irp->AssociatedIrp.SystemBuffer; > + } > + else if (Irp->MdlAddress != NULL) > + { > + OutputBuffer = MmGetSystemAddressForMdl(Irp->MdlAddress); > + } > + > + NotifyChange->Buffer = OutputBuffer; > + NotifyChange->ThisBufferLength = NumberOfBytes; > + } > + > + /* If we couldn't find one, then allocate one */ > + if (NotifyChange->Buffer == NULL) > + { > + PoolQuotaCharged = FALSE; > + _SEH2_TRY > + { > + PsChargePoolQuota(NotifyChange->OwningProcess, PagedPool, NumberOfBytes); > + PoolQuotaCharged = TRUE; > + OutputBuffer = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > + NumberOfBytes, 'NrSF'); > + NotifyChange->Buffer = OutputBuffer; > + NotifyChange->AllocatedBuffer = OutputBuffer; > + } > + /* If something went wrong during allocation, notify immediately instead of outputing */ > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + if (PoolQuotaCharged) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NumberOfBytes); > + } > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + _SEH2_END; > + } > + > + /* Finally, if we have a buffer, fill it in! */ > + if (OutputBuffer != NULL) > + { > + if (FsRtlNotifyUpdateBuffer((FILE_NOTIFY_INFORMATION *)OutputBuffer, > + Action, &ParentName, &TargetName, > + StreamName, NotifyChange->CharacterSize == sizeof(WCHAR), > + DataLength)) > + { > + NotifyChange->DataLength = DataLength + AlignedDataLength; > + } > + /* If it failed, notify immediately */ > + else > + { > + NotifyChange->Flags |= NOTIFY_IMMEDIATELY; > + } > + } > + } > + > + /* If we have to notify right now (something went wrong?) */ > + if (NotifyChange->Flags & NOTIFY_IMMEDIATELY) > + { > + /* Ensure that all our buffers are NULL */ > + if (NotifyChange->Buffer != NULL) > + { > + if (NotifyChange->AllocatedBuffer != NULL) > + { > + PsReturnProcessPagedPoolQuota(NotifyChange->OwningProcess, NotifyChange->ThisBufferLength); > + ExFreePoolWithTag(NotifyChange->AllocatedBuffer, 'NrSF'); > + } > + > + NotifyChange->Buffer = NULL; > + NotifyChange->AllocatedBuffer = NULL; > + NotifyChange->LastEntry = 0; > + NotifyChange->DataLength = 0; > + NotifyChange->ThisBufferLength = 0; > + } > + } > + } > + } > + > + /* If asking for old name in case of a rename, notify later on, > + * so that we can wait for new name. > + * http://msdn.microsoft.com/en-us/library/dn392331.aspx > + */ > + if (Action == FILE_ACTION_RENAMED_OLD_NAME) > + { > + NotifyChange->Flags |= NOTIFY_LATER; > + } > + else > + { > + NotifyChange->Flags &= ~NOTIFY_LATER; > + if (!IsListEmpty(&NotifyChange->NotifyIrps)) > + { > + FsRtlNotifyCompleteIrpList(NotifyChange, STATUS_SUCCESS); > + } > + } > + } > + } > + _SEH2_FINALLY > + { > + FsRtlNotifyReleaseFastMutex(RealNotifySync); > + } > + _SEH2_END; > } > > /*++ > > Modified: trunk/reactos/ntoskrnl/include/internal/fsrtl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/fsrtl.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/fsrtl.h [iso-8859-1] Fri Mar 7 19:33:38 2014 > @@ -53,9 +53,9 @@ > // Notifications flags > // > #define WATCH_TREE 0x01 > -#define INVALIDATE_BUFFERS 0x02 > +#define NOTIFY_IMMEDIATELY 0x02 > #define CLEANUP_IN_PROCESS 0x04 > -#define ENUMERATE_DIR 0x08 > +#define NOTIFY_LATER 0x08 > #define WATCH_ROOT 0x10 > #define DELETE_IN_PROCESS 0x20 > > >

2 1

NDIS NdisIMRegisterLayeredMiniport
by Maxime Daniel 07 Mar '14

07 Mar '14

Hello, I need to use NDIS NdisIMRegisterLayeredMiniport functions to provide a virtual ethernet card. I read the documentation on MSDN and it seems that this functions is required to build an adapter without physical link (eg, with no hardware IRQ). The problem is that this function is not implemented yet on reactos (svn rev. 62083). Is someone can tell me if it's implementable or if there is an alternative to build a virtual ethernet adapter with current implementation of NDIS. Thanks. -- Daniel Maxime Linux version 3.6.9-maxux64 (emy) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #3 SMP PREEMPT Wed Feb 19 16:40:22 CET 2014 14:02:53 up 1 day, 21:38, 1 user, load average: 0.17, 0.26, 0.23

2 2

Re: [ros-dev] [ros-diffs] [hbelusca] 62419: [APITESTS:kernel32] Be more specific about which last error we expect.
by Timo Kreuzer 05 Mar '14

05 Mar '14

IIRC, we have something like ok_lasterror() Am 05.03.2014 02:53, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Mar 5 01:53:46 2014 > New Revision: 62419 > > URL: http://svn.reactos.org/svn/reactos?rev=62419&view=rev > Log: > [APITESTS:kernel32] > Be more specific about which last error we expect. > > Modified: > trunk/rostests/apitests/kernel32/dosdev.c > > Modified: trunk/rostests/apitests/kernel32/dosdev.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/kernel32/dosdev.… > ============================================================================== > --- trunk/rostests/apitests/kernel32/dosdev.c [iso-8859-1] (original) > +++ trunk/rostests/apitests/kernel32/dosdev.c [iso-8859-1] Wed Mar 5 01:53:46 2014 > @@ -137,7 +137,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -168,7 +168,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -203,7 +203,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -266,7 +266,7 @@ > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > hnd = FindFirstFileA(SUBST_DRIVE_SEARCH, &Data); > ok(hnd == INVALID_HANDLE_VALUE, "Opened subst drive when it should fail\n"); > - ok(GetLastError() == ERROR_INVALID_NAME, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INVALID_NAME, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INVALID_NAME), GetLastError()); > if (hnd) FindClose(hnd); > Result = DefineDosDeviceA(DDD_REMOVE_DEFINITION, SUBST_DRIVE, NULL); > ok(Result, "Failed to remove subst drive using NULL Target name\n"); > @@ -313,7 +313,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -333,7 +333,7 @@ > ok(Result, "Failed to subst drive\n"); > DriveType1 = GetDriveTypeA(SUBST_DRIVE_WITH_TRAILING_PATH_SEPERATOR); > ok(DriveType1 != SystemDriveType, "subst drive types match when it shouldn't\n"); > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_FILE_NOT_FOUND), GetLastError()); > dwMaskCur = GetLogicalDrives(); > ok(dwMaskCur != dwMaskPrev, "Drive masks match when it shouldn't\n"); > ok((dwMaskCur & (1 << (SUBST_DRIVE_LETTER - 'A'))), "Drive bit is not set\n"); > @@ -362,7 +362,7 @@ > ok(Result, "Failed to subst drive\n"); > Result = QueryDosDeviceA(SUBST_DRIVE, Buffer, 0); > ok(!Result, "Should fail as the buffer passed is supposed to be small\n"); > - ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INSUFFICIENT_BUFFER), GetLastError()); > Result = QueryDosDeviceA(SUBST_DRIVE, Buffer, MAX_PATH); > ok(Result, "failed to get target path\n"); > ok(_strnicmp(Buffer, "\\??\\", 4) == 0, "The target returned does have correct prefix set\n"); > @@ -374,7 +374,7 @@ > /* This will try to retrieve all existing MS-DOS device names */ > Result = QueryDosDeviceA(NULL, Buffer, 0); > ok(!Result, "Should fail as the buffer passed is supposed to be small\n"); > - ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "GetLastError() reports unexpected error code\n"); > + ok(GetLastError() == ERROR_INSUFFICIENT_BUFFER, "Wrong last error. Expected %lu, got %lu\n", (DWORD)(ERROR_INSUFFICIENT_BUFFER), GetLastError()); > } > > START_TEST(dosdev) > > >

2 1

About hotpatchable dlls on ReactOS
by Hermès BÉLUSCA - MAÏTO 02 Mar '14

02 Mar '14

Hi guys ! It seems to appear that some games need standard APIs hotpatchable, in the sense of MS: few extra bytes present in the prologue of the functions that allow somebody to detour the API. I knew that this feature was useful for windows updates, but what I didnt know is that there are other programs that use it: see this answer from James on the Epic Win! forum thread: http://www.reactos.org/forum/viewtopic.php?f=2 <http://www.reactos.org/forum/viewtopic.php?f=2&t=10972&p=106823#p106814> &t=10972&p=106823#p106814 , and the following post is something that Ive found about this subject, and the fact that Wine already have done something about that. So my question: should we support/create hotpatchable images (of the standard dlls and maybe ?? exes) in ReactOS ? Is it already done ? If not, what needs to be added ? It seems that MSVC and GCC handle that a bit differently. Cheers, Hermès BÉLUSCA - MAÏTO

4 6

jira account
by Alexander Varnin 01 Mar '14

01 Mar '14

Hello! I have registered on main site, because I want to login to JIRA, but JIRA says now that my login is incorrect. Does it need some time to make JIRA accout accessible after registration? Or I need to do some actions? Do I need to request account for JIRA separately?

5 7

Short Testman downtime tomorrow
by Colin Finck 28 Feb '14

28 Feb '14

Hi all, In the process of improving the performance of our website and finally getting rid of old.reactos.org, I'm moving away the Testman database to a new VM tomorrow. This will cause a short downtime, in which you're unable to browse Testman results or submit new ones. Even if something goes wrong during that process, the downtime shouldn't last longer than 2 hours. With best regards, Colin

1 0

Status Meeting (February 2014)
by Aleksey Bragin 27 Feb '14

27 Feb '14

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 27th of February, 19:00 UTC. Put that into your calendars so you don't forget. And that's in two days! 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. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to me shortly before the meeting starts). Regards, Aleksey Bragin

2 1

Fwd: [ReactOS Deutschland e.V.] Your organization application has been rejected.
by Amine Khaldi 24 Feb '14

24 Feb '14

-------- Original Message -------- Subject: [ReactOS Deutschland e.V.] Your organization application has been rejected. Date: Mon, 24 Feb 2014 18:40:28 +0000 From: no-reply(a)google-melange.appspotmail.com To: amine.khaldi(a)reactos.org Thank you for submitting ReactOS Deutschland e.V.'s application to Google Summer of Code 2014. Unfortunately, we were unable to accept your organization's application at this time. Every year we receive many more applications than we are able to accommodate, and we would encourage you to reapply for future instances of the program. If you would like some general feedback on why your organization was not accepted, please consider attending the IRC meeting in #gsoc on Freenode on Friday, 28 February, 2014 at 16:00 UTC. Please note that the feedback meeting will be limited to the first 50 organizations to queue up (queuing in the channel will begin at 15:30 UTC). Best regards,

2 2

VIA Embedded at Embedded World 2014
by Alexander Rechitskiy 24 Feb '14

24 Feb '14

Could somebody visit and represent ReactOS to VIA Embedded at Embedded World 2014? http://www.embedded-world.de/en/ February 25th - 27th in Nuremberg Germany -- Best regards, Alexander Rechitskiy

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev