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
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
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
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.
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;
+ }
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
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.
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
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?
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
>
>
>
>
>
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
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?
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
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
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
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
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