- Ros-dev - ReactOS.org

Re: [ros-dev] USB from GSoC
by mvardan.dev 10 Jan '17

10 Jan '17

Hello Aleksey, About readiness to get merged I think decision should be done by Thomas or Amine. Related to collaboration with ROS, as I have informed on one of the monthly meetings, I have willing to contribute ReactOS. But for now I have probelm with time which is depend on many factors. We can schedule meeting in IRC or wherever you want, to discuss how I can help to our project. Thanks,Vardan. Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Aleksey Bragin <aleksey(a)reactos.org> Date: 12/20/16 03:00 (GMT+04:00) To: ReactOS Development List <ros-dev(a)reactos.org> Subject: [ros-dev] USB from GSoC Hello! What happened to the USB branch made by Vardan during GSoC 2016? Is it ready to be merged, or if not, what's holding it? Any input is appreciated, especially from Vardan himself. Regards, Aleksey Bragin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 1

CLT 2017. Who joins us?
by Daniel Reimer 10 Jan '17

10 Jan '17

Hello and happy new year, soon the deadline for CLT 2017 is here (07.01.) and that time I'd like to add the needed minimum of two ppl there BEFORE that. So... who will join me to https://chemnitzer.linux-tage.de aka 11./12.03.2017 in Chemnitz? The sooner I know it the better it is for planning ^^ (Quite shocking that it's almost a year again since list years CLT...) I am open for anyone asking to take part, BUT I would prefer guys who already were there and know what they will have to expect regarding masses of ppl, strange guys going on your nerves on a 15 min basis and of couse the fun we will have, too. So pleaase answer ASAP. I will join IRC today, too. So if anyone has some nice recent pics of milestones running in ROS, GIMME plz ^^ Greetings Daniel

3 4

Re: [ros-dev] [ros-diffs] [jimtabor] 73475: [Win32SS|RTL] - Fix clipping for Draw Text. Inspired by Katayama Hirofumi MZ patch and ComCtl32/RichEd20/UxThmems. See CORE-2201.
by Thomas Faber 29 Dec '16

29 Dec '16

On 2016-12-22 11:39, jimtabor(a)svn.reactos.org wrote: > +#ifndef _WIN32K_ ///// Fix CORE-2201. > + if (!(flags & DT_NOCLIP) ) > + { > + int hasClip; > + hrgn = CreateRectRgn(0,0,0,0); > + if (hrgn) > + { > + hasClip = GetClipRgn(hdc, hrgn); > + // If the region to be retrieved is NULL, the return value is 0. > + if (hasClip != 1) > + { > + DeleteObject(hrgn); > + hrgn = NULL; > + } > + IntersectClipRect(hdc, rect->left, rect->top, rect->right, rect->bottom); > + } > + } > +#else > + if (!(flags & DT_NOCLIP) ) > + { > + int hasClip; > + hrgn = NtGdiCreateRectRgn(0,0,0,0); > + if (hrgn) > + { > + hasClip = NtGdiGetRandomRgn(hdc, hrgn, CLIPRGN); > + if (hasClip != 1) > + { > + GreDeleteObject(hrgn); > + hrgn = NULL; > + } > + NtGdiIntersectClipRect(hdc, rect->left, rect->top, rect->right, rect->bottom); > + } > + } > +#endif ///// Any particular reason not to simply do the NtGdi call in both user and kernel? Looks like they should be doing the exact same thing.

2 1

The Terminator^W AHK bot needs a vacation
by Sylvain Petreolle 22 Dec '16

22 Dec '16

During Christmas, I have to leave the AHK bot room free of machine noise at my place. The bot is officially on vacation until Dec 27-28th :-) Happy Christmas, Sylvain Petreolle

1 0

USB from GSoC
by Aleksey Bragin 19 Dec '16

19 Dec '16

Hello! What happened to the USB branch made by Vardan during GSoC 2016? Is it ready to be merged, or if not, what's holding it? Any input is appreciated, especially from Vardan himself. Regards, Aleksey Bragin

1 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 73436: [SHELL32] - Initialize the shell icon cache only when needed or when FileIconInit is called (and not in the DllMain of shell32)
by Thomas Faber 07 Dec '16

07 Dec '16

On 2016-12-07 01:10, gadamopoulos(a)svn.reactos.org wrote: > [SHELL32] - Initialize the shell icon cache only when needed or when FileIconInit is called (and not in the DllMain of shell32) > --- trunk/reactos/dll/win32/shell32/iconcache.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/iconcache.cpp [iso-8859-1] Wed Dec 7 00:10:43 2016 > @@ -453,6 +453,9 @@ > sice.dwSourceIndex = dwSourceIndex; > sice.dwFlags = dwFlags; > > + if (!sic_hdpa) > + SIC_Initialize(); > + > EnterCriticalSection(&SHELL32_SicCS); > > if (NULL != DPA_GetPtr (sic_hdpa, 0)) > @@ -687,6 +690,9 @@ > RegCloseKey(hKeyShellIcons); > } > > + if (!sic_hdpa) > + SIC_Initialize(); > + > return SIC_LoadIcon(iconPath, iconIdx, 0); > } > This is great. Unfortunately now you have a race condition if multiple of these functions get called concurrently.

1 0

Re: [ros-dev] [ros-diffs] [ekohl] 73433: [SERVICES] Create a new environment block when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414
by Ged Murphy 06 Dec '16

06 Dec '16

This leaks if ImpersonateLoggedOnUser fails and the environment block is non-null -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ekohl(a)svn.reactos.org Sent: 06 December 2016 17:30 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ekohl] 73433: [SERVICES] Create a new environment block when a service process is started. Patch by Hermès BÉLUSCA - MAÏTO. CORE-12414 + if (Service->lpImage->hToken) + { + /* User token: Run the service under the user account */ + + if (!CreateEnvironmentBlock(&lpEnvironment, Service->lpImage->hToken, FALSE)) + { + /* We failed, run the service with the current environment */ + DPRINT1("CreateEnvironmentBlock() failed with error %d, service '%S' will run with the current environment.\n", + Service->lpServiceName, GetLastError()); + lpEnvironment = NULL; + } + + /* Impersonate the new user */ + if (!ImpersonateLoggedOnUser(Service->lpImage->hToken)) + { + dwError = GetLastError(); + DPRINT1("ImpersonateLoggedOnUser() failed with error %d\n", GetLastError()); + return dwError; + }

1 0

From this moment PVS-Studio is free of charge for opensource projects
by Alexander Rechitskiy 04 Dec '16

04 Dec '16

4 4

Invitation to join ReactOS Deutschland e.V.
by Colin Finck 30 Nov '16

30 Nov '16

Hi all, This invitation is long overdue: Back in 2009 when our German foundation ReactOS Deutschland e.V. was established, it was merely the legal entity to handle the small amount of incoming donations. Today, things have drastically changed: Our fundraising campaign in 2014 as well as the successful website relaunch and 0.4 release brought us many more funds. By establishing scholarships and contracting IT freelancers, ReactOS Deutschland e.V. is actively funding the actual ReactOS development. Apart from that, it is sponsoring and planning the presentation of ReactOS on popular Open-Source exhibitions. Furthermore, we have created an English translation of our Articles of Association/Charter and moved to English reports a while ago. This finally allows non-German members to join. Therefore, I'm inviting all active ReactOS developers to join ReactOS Deutschland e.V. as active members. Needless to say, active members don't pay any membership fees and have full voting rights at our General Assembly. We usually have such a General Assembly every year and this is basically your only duty: Attend the General Assemblies so that decisions are backed by a strong majority. The only exception I have to make is that the members candidating for the Board need to be German speakers to communicate with the authorities. This is necessary from time to time. You find the Articles of Association as well as all annual reports on our website https://ev.reactos.org To become an active member, simply fill out the application at https://ev.reactos.org/files/Membership_Application.pdf and send it to me via mail. You can cross out the "Direct Debit Authorization", this part is only relevant for supporting members. Unfortunately, we're bound to snail mail and can't do applications electronically, because I need a real signature and proof of your application for the authorities. Looking forward to your applications! :) Cheers, Colin

5 5

We can sell ReactOS CD on https://www.osdisc.com/affiliate
by Alexander Rechitskiy 21 Nov '16

21 Nov '16

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 73233: [LSASRV] - No need to hardcode the name of the dll in the GetModuleHandleW call; - Use ARRAYSIZE instead of hardcoding string buffer sizes; - When initializing the "Network Sid", ...
by Thomas Faber 14 Nov '16

14 Nov '16

On 2016-11-14 17:19, hbelusca(a)svn.reactos.org wrote: > - hInstance = GetModuleHandleW(L"lsasrv.dll"); > + hInstance = GetModuleHandleW(NULL); Those are not equivalent at all.

1 0

Re: [ros-dev] [ros-diffs] [mjansen] 73180: [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension completion with the App Paths registry key. Patch by Yaroslav Veremenko. CORE-12049
by Thomas Faber 09 Nov '16

09 Nov '16

APITests should be named after a function. And in particular, they can't be named the same as a Wine test for the same module. This is currently causing result submission on Testbot to fail, so please rename this test. On 2016-11-09 23:13, mjansen(a)svn.reactos.org wrote: > Author: mjansen > Date: Wed Nov 9 22:13:26 2016 > New Revision: 73180 > > URL: http://svn.reactos.org/svn/reactos?rev=73180&view=rev > Log: > [SHELL32_APITEST] Add some tests for ShellExecuteEx showing extension completion with the App Paths registry key. Patch by Yaroslav Veremenko. CORE-12049 > > Added: > trunk/rostests/apitests/shell32/shlexec.cpp (with props) > Modified: > trunk/rostests/apitests/shell32/CMakeLists.txt > trunk/rostests/apitests/shell32/testlist.c

3 2

Re: [ros-dev] [ros-diffs] [phater] 73095: [TCPIP] Copy back unicast IP if broadcast is specified for listen. CORE-12152
by Thomas Faber 03 Nov '16

03 Nov '16

On 2016-11-02 12:24, phater(a)svn.reactos.org wrote: > + /* Check if we had an unspecified address */ > + if (Connection->AddressFile->Address.Address.IPv4Address != bindaddr.addr) > + { > + /* We did, so we need to copy back the address */ > + Connection->AddressFile->Address.Address.IPv4Address = bindaddr.addr; > + } Seems like you could shorten this to just the assignment?

2 1

Re: [ros-dev] [ros-builds] Build GCCLin_x86: build failed
by Jerome Gardou 31 Oct '16

31 Oct '16

Someone's got to help me. I can't figure out how to make this thing patch the rostests directory. Le 31/10/2016 à 11:15, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Build GCCLin_x86 while building ReactOS. > Full details are available at: > https://build.reactos.org/builders/Build%20GCCLin_x86/builds/16201 > > Buildbot URL: https://build.reactos.org/ > > Buildslave for this Build: HotelLux > > Build Reason: A build was forced by 'jgardou <jgardou@localhost>': Test ROSTESTS-155 > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed patching > > sincerely, > -The Buildbot > > > > >

2 2

Re: [ros-dev] [ros-diffs] [hbelusca] 73078: [BTRFS]: Fix compilation with MSVC too, as we don't have the 'FileFsSectorSizeInformation' FS information class in our headers (this is some Win8+ stuff). CORE-12223 #comment MSVC...
by Thomas Faber 30 Oct '16

30 Oct '16

And what's wrong with just adding it to our headers? On 2016-10-30 15:14, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Sun Oct 30 14:14:27 2016 > New Revision: 73078 > > URL: http://svn.reactos.org/svn/reactos?rev=73078&view=rev > Log: > [BTRFS]: Fix compilation with MSVC too, as we don't have the 'FileFsSectorSizeInformation' FS information class in our headers (this is some Win8+ stuff). > CORE-12223 #comment MSVC compilation fixed in r73078 ('FileFsSectorSizeInformation' absent in our headers). > > Modified: > trunk/reactos/drivers/filesystems/btrfs/btrfs.c > > Modified: trunk/reactos/drivers/filesystems/btrfs/btrfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/btrfs/… > ============================================================================== > --- trunk/reactos/drivers/filesystems/btrfs/btrfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/btrfs/btrfs.c [iso-8859-1] Sun Oct 30 14:14:27 2016 > @@ -716,7 +716,8 @@ > Status = overflow ? STATUS_BUFFER_OVERFLOW : STATUS_SUCCESS; > break; > } > - > + > +#ifndef __REACTOS__ > #ifdef _MSC_VER // not in mingw yet > case FileFsSectorSizeInformation: > { > @@ -739,6 +740,7 @@ > break; > } > #endif > +#endif /* __REACTOS__ */ > > default: > Status = STATUS_INVALID_PARAMETER; > >

1 0

Status Meeting (October 2016)
by Aleksey Bragin 27 Oct '16

27 Oct '16

Hello, Let me invite you to the monthly status meeting taking place today, 27th of October, 19:00 UTC. 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. Alternatively we'll do it in #reactos-meeting on Freenode, depending on our admins mood. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 73046: Fix a comment.
by Thomas Faber 26 Oct '16

26 Oct '16

On 2016-10-27 00:06, hbelusca(a)svn.reactos.org wrote: > - /* Sundry checkboxes */ > + /* Other checkboxes */ Not sure how this "fixes" anything? Those are synonyms?

1 0

Re: [ros-dev] [ros-diffs] [janderwald] 73016: [USBAUDIO] - implement retrieving string descriptor of product and store it in registry.
by Thomas Faber 21 Oct '16

21 Oct '16

On 2016-10-21 23:15, janderwald(a)svn.reactos.org wrote: > NTSTATUS > +NTAPI > +USBAudioGetDescriptor( > + IN PDEVICE_OBJECT DeviceObject, > + IN UCHAR DescriptorType, > + IN ULONG DescriptorLength, > + IN UCHAR DescriptorIndex, > + IN LANGID LanguageId, > + OUT PVOID *OutDescriptor) > +{ > + PURB Urb; > + NTSTATUS Status; > + PVOID Descriptor; > + > + /* sanity checks */ > + ASSERT(DeviceObject); > + ASSERT(OutDescriptor); > + ASSERT(DescriptorLength); > + > + // > + // first allocate descriptor buffer > + // > + Descriptor = AllocFunction(DescriptorLength); > + if (!Descriptor) > + { > + /* no memory */ > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + /* allocate urb */ > + Urb = (PURB)AllocFunction(sizeof(URB)); > + if (!Urb) > + { > + /* no memory */ > + FreeFunction(Descriptor); > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + /* initialize urb */ > + UsbBuildGetDescriptorRequest(Urb, > + sizeof(Urb->UrbControlDescriptorRequest), > + DescriptorType, > + DescriptorIndex, > + LanguageId, > + Descriptor, > + NULL, > + DescriptorLength, > + NULL); > + > + /* submit urb */ > + Status = SubmitUrbSync(DeviceObject, Urb); > + > + /* free urb */ > + FreeFunction(Urb); > + > + if (NT_SUCCESS(Status)) > + { > + /* store result */ > + *OutDescriptor = Descriptor; > + } Is Descriptor leaked in the failure case, or does something down the stack take care of that? > + > + /* done */ > + return Status; > +} > +NTSTATUS > +USBAudioRegCreateMediaCategoriesKey( > + IN PUNICODE_STRING Name, > + OUT PHANDLE OutHandle) > +{ > + NTSTATUS Status; > + OBJECT_ATTRIBUTES ObjectAttributes; > + UNICODE_STRING DestinationString; > + HANDLE Handle; > + > + /* initialize root name*/ > + RtlInitUnicodeString(&DestinationString, L"\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Control\\MediaCategories\\"); > + > + /* initialize object attributes */ > + InitializeObjectAttributes(&ObjectAttributes, &DestinationString, OBJ_CASE_INSENSITIVE | OBJ_OPENIF, NULL, NULL); You're missing OBJ_KERNEL_HANDLE. > + > + /* create the key */ > + Status = ZwOpenKey(&Handle, KEY_ALL_ACCESS, &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + /* initialize object attributes */ > + InitializeObjectAttributes(&ObjectAttributes, Name, OBJ_CASE_INSENSITIVE, Handle, NULL); Here too. > + > + Status = ZwCreateKey(OutHandle, KEY_ALL_ACCESS, &ObjectAttributes, 0, NULL, 0, NULL); > + ZwClose(Handle); > + > + } > + return Status; > +} Thanks. -Thomas

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 72997: [KERNEL32]: Mark Get/SetEnvironmentVariableA/W as hotpatchable since it's needed for Clink 0.4.8 (<rant>btw, if GCC was able to set exported stdcall functions as hotpatchable at a...
by Timo Kreuzer 21 Oct '16

21 Oct '16

What about adding it to WINAPI? #ifdef _HOTPATCH_MODULE_ #define WINAPI __stdcall DECLSPEC_HOTPATCH #else #endif #define WINAPI __stdcall Timo Am 20.10.2016 um 00:26 schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Oct 19 22:26:04 2016 > New Revision: 72997 > > URL: http://svn.reactos.org/svn/reactos?rev=72997&view=rev > Log: > [KERNEL32]: Mark Get/SetEnvironmentVariableA/W as hotpatchable since it's needed for Clink 0.4.8 (<rant>btw, if GCC was able to set exported stdcall functions as hotpatchable at a global level, as MSVC does, those "DECLSPEC_HOTPATCH" hacks would not be necessary! </rant>) > > Modified: > trunk/reactos/dll/win32/kernel32/client/environ.c > > Modified: trunk/reactos/dll/win32/kernel32/client/environ.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/environ.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/environ.c [iso-8859-1] Wed Oct 19 22:26:04 2016 > @@ -24,6 +24,7 @@ > */ > DWORD > WINAPI > +DECLSPEC_HOTPATCH > GetEnvironmentVariableA(IN LPCSTR lpName, > IN LPSTR lpBuffer, > IN DWORD nSize) > @@ -158,6 +159,7 @@ > */ > DWORD > WINAPI > +DECLSPEC_HOTPATCH > GetEnvironmentVariableW(IN LPCWSTR lpName, > IN LPWSTR lpBuffer, > IN DWORD nSize) > @@ -212,6 +214,7 @@ > */ > BOOL > WINAPI > +DECLSPEC_HOTPATCH > SetEnvironmentVariableA(IN LPCSTR lpName, > IN LPCSTR lpValue) > { > @@ -252,6 +255,7 @@ > */ > BOOL > WINAPI > +DECLSPEC_HOTPATCH > SetEnvironmentVariableW(IN LPCWSTR lpName, > IN LPCWSTR lpValue) > { > > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 72992: [CONSRV]: Code style changes only.
by Thomas Faber 19 Oct '16

19 Oct '16

On 2016-10-19 01:45, hbelusca(a)svn.reactos.org wrote: > --- trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/winsrv/consrv/frontends/gui/conwnd.c [iso-8859-1] Tue Oct 18 23:45:19 2016 > @@ -137,7 +137,7 @@ > GetSystemMetrics(SM_CXSMICON), > GetSystemMetrics(SM_CYSMICON), > LR_SHARED); > - ghDefaultCursor = LoadCursorW(NULL, IDC_ARROW); > + ghDefaultCursor = LoadCursorW(NULL, MAKEINTRESOURCEW(IDC_ARROW)); > > WndClass.cbSize = sizeof(WNDCLASSEXW); > WndClass.lpszClassName = GUI_CONWND_CLASS; Defining UNICODE or WINE_NO_UNICODE_MACROS seems preferably to this double cast. After all, the definition for IDC_ARROW is: #define IDC_ARROW MAKEINTRESOURCE(32512)

1 0

MSVC and GCC Windows Buildslaves are back - old ISOs are not
by Colin Finck 18 Oct '16

18 Oct '16

Hi all, Thanks to Dmitry Chapyshev's generous donation of rare FB-DIMM memory modules, our Buildserver has enough RAM for the Win7 buildslave VM now. I've fired it up and while builds are much slower than before, they are at least being done again! Note that Doxygen, ISO hosting, and all three buildslaves are on a single HDD-backed server right now, so don't expect any performance miracles. I'm counting on Aleksey here to get us our remaining servers back this month :) Unfortunately, our HDDs were also lacking space, so I had to move the public "bootcd_old" folder from iso.reactos.org to another (private) place. It contained BootCD ISOs from 2009 to 2012, totalling 421GB. Any idea how to deal with them in the long run? I can basically think of 4 possibilities: * We remove ISOs older than 4 years, because nobody would really do regression-testing with them. * We buy additional HDDs every year and continue to host them ourselves just next to the newer ISOs. * We find a free file hosting service for OSS projects that can cope with these amounts of data. Not sure SF.net is the right choice here.. * We choose a paid data storage service like Amazon AWS. As always, comments are very welcome! - Colin

4 6

ReactOS Service Login problems fixed
by Colin Finck 17 Oct '16

17 Oct '16

Hi all! For those of you who experienced Login problems with ReactOS Services such as BuildBot, Mumble or SVN, I have cleaned up and applied some fixes to our LDAP directory today. All known problems should be fixed now! If you still experience such problems, please reply to this mail. - Colin

1 0

Retrieving the computer name of a named pipe client
by Colin Finck 13 Oct '16

13 Oct '16

Hi all, For implementing the RpcBindingServerFromClient rpcrt4.dll API function needed by my Printing Stack, I need to know how to retrieve the computer name of a named pipe client. Vista and later implement GetNamedPipeClientComputerName in kernel32.dll which does exactly this, but this is neither supported under Windows Server 2003 nor implemented in ReactOS and WINE. Determining client information is a basic feature of network communication, so it should be possible under Windows 2003 as well. Additionally, RpcBindingServerFromClient returns the proper computer name of the client, when using named pipes over the ncacn_np transport. It must have got it somehow. Hoping for some ideas from your side! Colin

3 3

Re: [ros-dev] Retrieving the computer name of a named pipe client
by Alex Ionescu 11 Oct '16

11 Oct '16

You literally wrote " but this is neither supported under Windows Server 2003", so yes, there's your answer :) Best regards, Alex Ionescu On Tue, Oct 11, 2016 at 1:18 PM, Colin Finck <colin(a)reactos.org> wrote: > Am 10.10.2016 um 23:22 schrieb Timo Kreuzer: >> #define FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE >> CTL_CODE(FILE_DEVICE_NAMED_PIPE, 12, METHOD_BUFFERED, FILE_ANY_ACCESS) >> >> static const char AttributeName[] = "ClientComputerName"; >> >> Status = NtFsControlFile(NamedPipeHandle, > > Are you sure this is the right way of doing it under Windows 2003? > While 2003's rpcrt4.dll imports NtFsControlFile, running GNU strings on > it doesn't output any "ClientComputerName" string. > > Furthermore, our NPFS driver only implements the FSCTL_PIPE_* control > codes up to FSCTL_PIPE_QUERY_CLIENT_PROCESS (#9). #10 to #16 (with > FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE being #12) are not processed. Same > goes for the free ntifs.h from https://www.acc.umu.se/~bosse/ntifs.h, it > lacks all FSCTL_PIPE_* codes after #9. I'm getting the impression, #10 > to #16 were only introduced with NT 6.0. > If I had the ntifs.h from Windows 2003, I could confirm my theory, but > this file was never public and only part of the commercial IFS Kit. > > So, talking to the NPFS driver probably goes into the right direction, > but I assume we have to find an alternative to > FSCTL_PIPE_GET_CONNECTION_ATTRIBUTE. > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] [ros-diffs] [phater] 72948: [MSAFD] Fix some return codes and better parameter checks based on wine tests CORE-12104
by Thomas Faber 10 Oct '16

10 Oct '16

Hurray! Congrats on your first commit! On 2016-10-10 08:38, phater(a)svn.reactos.org wrote: > Author: phater > Date: Mon Oct 10 06:38:52 2016 > New Revision: 72948 > > URL: http://svn.reactos.org/svn/reactos?rev=72948&view=rev > Log: > [MSAFD] Fix some return codes and better parameter checks based on wine tests CORE-12104 > > Modified: > trunk/reactos/dll/win32/msafd/misc/dllmain.c >

1 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