Ros-dev

ros-dev@reactos.org

5788 discussions

Re: [ros-dev] [ros-diffs] [janderwald] 73016: [USBAUDIO] - implement retrieving string descriptor of product and store it in registry.

by Thomas Faber

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

7 years, 11 months

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

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) > { > > >

7 years, 11 months

Re: [ros-dev] [ros-diffs] [hbelusca] 72992: [CONSRV]: Code style changes only.

by Thomas Faber

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)

7 years, 11 months

MSVC and GCC Windows Buildslaves are back - old ISOs are not

by Colin Finck

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

7 years, 11 months

ReactOS Service Login problems fixed

by Colin Finck

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

7 years, 11 months

Retrieving the computer name of a named pipe client

by Colin Finck

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

7 years, 11 months

Re: [ros-dev] Retrieving the computer name of a named pipe client

by Alex Ionescu

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

7 years, 11 months

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

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 >

7 years, 11 months

Re: [ros-dev] [ros-diffs] [hbelusca] 72943: [PING] - Use a dynamic-allocated buffer with FormatMessageW, fixes messages disappearance (eg. ping help in russian). CORE-12108 #comment Fixed in r72943. - Remove the unneeded 1-...

by Colin Finck

hbelusca(a)svn.reactos.org wrote: > +#define RC_STRING_MAX_SIZE 4096 > + > + WCHAR Format[RC_STRING_MAX_SIZE]; > + LPWSTR lpMsgBuf = NULL; > + DWORD Len; > va_list args; > > if (!LoadStringW(GetModuleHandleW(NULL), id, Format, > _countof(Format))) Now instead of #define RC_STRING_MAX_SIZE 4096 WCHAR Format[RC_STRING_MAX_SIZE]; LoadStringW(GetModuleHandleW(NULL), id, Format, _countof(Format)); just do a LPWSTR lpFormatBuf; LoadStringW(GetModuleHandleW(NULL), id, (LPWSTR)&lpFormatBuf, 0); and you have a perfect universal solution for any resource string length without caring about buffer sizes at all. It doesn't even need any extra memory :) This should actually be changed in a lot of places! - Colin

7 years, 11 months

[ros-diffs] [spetreolle] 72905: [NtUser] Turn an ERR into a TRACE.

by James Tabor

Now we will never know what happen to the lost application!

7 years, 11 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev