This change (on my own code snippet btw, see commit 5a1a35ca5a6) was necessary because otherwise, the StringPrintf call that is done below (which would then use a WindowTitleU.Buffer == NULL) would generate the harderror dialog title: "(null)" (in addition to other strings being appended), instead of just an empty string.
And so the bug is that I forgot to adjust the condition that needs to be checked before freeing the window title string (if it has been allocated).
Hermès
> -----Message d'origine-----
> De : Thomas Faber [mailto:thomas.faber@reactos.org]
> Envoyé : samedi 9 juin 2018 09:21
> À : ros-dev(a)reactos.org; Hermès Bélusca-Maïto
> Objet : Re: [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning;
> fix few comments; fix the default empty window title string.
>
> On 2018-04-08 16:17, Hermès Bélusca-Maïto wrote:
> > /* Retrieve the window title of the client, if it has one */
> > - RtlInitEmptyUnicodeString(&WindowTitleU, NULL, 0);
> > + RtlInitEmptyUnicodeString(&WindowTitleU, L"", 0);
>
> This looks like a bug. Can you explain why you think it's necessary please?
>
> In particular, it will break this:
>
> if (WindowTitleU.Buffer) RtlFreeUnicodeString(&WindowTitleU);
>
>
> Thanks,
> Thomas
I've found this mirror repo on GitLab, it was created today:
https://gitlab.com/reactos/reactos
Does it belong to the ReactOS team? If not, we may have problems.
----
Regards,
Stas'M
On 2018-04-08 16:17, Hermès Bélusca-Maïto wrote:
> /* Retrieve the window title of the client, if it has one */
> - RtlInitEmptyUnicodeString(&WindowTitleU, NULL, 0);
> + RtlInitEmptyUnicodeString(&WindowTitleU, L"", 0);
This looks like a bug. Can you explain why you think it's necessary please?
In particular, it will break this:
if (WindowTitleU.Buffer) RtlFreeUnicodeString(&WindowTitleU);
Thanks,
Thomas
Hey there !
Went through the reactOS GSOC’18 page. I am interested in making web interface for reactos which can show all GitHub reactos repos, commits, etc using the GitHub API. (https://www.reactos.org/wiki/Google_Summer_of_Code_2018_Ideas#Developer_Web…)
Looking forward to work on the same idea for GSOC’19 under your mentorship. Need to know more about layout of the web interface. Kindly help!
thanks
Hi all!
It's official now! The ReactOS Hackfest 2018 will take place from
Thursday, 16th August 2018 to Tuesday, 21st August 2018 in Berlin, Germany.
Thanks to Thomas, the event location is already checked out ("definitely
more space than in Cologne") and he has found a hostel nearby.
All information can be found at
https://reactos.org/wiki/ReactOS_Hackfest_2018, with the lists for
registering yourself and collecting ideas at
https://reactos.org/wiki/ReactOS_Hackfest_2018/Lists
Hope to see you in August!
Cheers,
Colin
Team members and other interested parties,
At this month's meeting, we decided we had to have a talk about the growing
number of open pull requests. From such a discussion, we game up with a set
of rules that the team members should follow, when reviewing or managing
PRs.
If you are such a person, please take a moment to make sure you can agree
with those rules. There's a PR waiting for your input:
https://github.com/reactos/reactos/pull/585
Hi all!
Let me invite you to the May 2018 meeting, taking place this Thursday,
May 31, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.
Based on requests and current topics, the agenda looks like this:
1. Status Reports
==============
Like last time, participants are requested to just post their
prepared reports again to not waste any minute.
2. Improving our handling of PRs and JIRA reports
==============================================
The global JIRA permissions have been changed this month and there
has been a lot of bad blood regarding issues marked as "trivial".
On the one hand, trivial PRs waste a lot of time of our core
developers as long as they are the only ones able to commit them.
On the other hand, trivial PRs still add minor improvements to the
code, so it would be wrong to just close them as invalid.
Let's have an open discussion on this topic and try to establish
rules we can all work with without taking this problem to a personal
level.
3. Google Summer of Code
=====================
This will be the first meeting, which could be joined by our GSoC
student Victor Perevertkin. If he or the mentors have questions that
are better discussed with all developers in the monthly meeting,
let's do this here.
4. Changes affecting base addresses
================================
Robert Naumann has requested adding this topic to the agenda.
He couldn't merge several PRs translating .mc files, because that
would blow up the kernel and require a regeneration of all base
addresses. He requested a brainstorming session in this meeting
to get to a conclusion how to deal with this problem.
I know that Joachim Henze has also attempted to change base addresses
lately to fix Photoshop CS2, so this is probably the right time to
deal with this problem.
Further topics can be requested by replying to this mail.
See you all on Thursday!
Best regards,
Colin
Hi!<br>
<br>
To that I see one solution, that has actually already been proposed in the PR:<br>
we make an external package (a la Wine gecko) that one can download during installation, or later through RAPPS.<br>
Then this package (possibly together with other heavy core ones?) could be hosted in some GitHub sub-repo or elsewhere...<br>
Closing the PR now would definitely not be the right solution.<br>
<br>
Best,<br>
H.<span style="font-family:arial,helvetica,sans-serif; font-size:12px"></span>
<div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : "Colin Finck"<br>
A : ros-dev(a)reactos.org<br>
Envoyé: mercredi 30 mai 2018 18:21<br>
Objet : Re: [ros-dev] Status Meeting (May 2018)<br>
<div class="gl_quoted">Am 30.05.2018 um 13:26 schrieb Ged Murphy:<br>
> Potential problems are:<br>
> 4) something else?<br>
<br>
I've been struggling with e.g. https://github.com/reactos/reactos/pull/276<br>
<br>
On the one hand, we definitely need official support for Chinese,<br>
Korean, and Japanese character sets.<br>
On the other hand, this must not bloat up ReactOS by default, and just<br>
dropping a 12 MB font into the repository definitely does.<br>
So what is the ideal solution? I don't even know myself.<br>
<br>
- I could leave the PR open and hope that the submitter addresses my<br>
comments and comes up with a better solution. That hasn't happened in<br>
the last months.<br>
<br>
- I could close the PR right away. That would give the submitter no<br>
chance to address my comments and may even look disrespectful. And the<br>
original problem tends to be forgotten.<br>
<br>
- I could close the PR and open a JIRA issue describing the problem.<br>
If we decide on that as a general rule, we would put another burden on<br>
every reviewer. Additionally, such general JIRA issues tend to rot in<br>
our database as well.<br>
<br>
I think we often have this situation where the submitted PR is wrong,<br>
but we don't know the right solution either, and therefore keep the PR<br>
open. If we can better deal with these cases, the number of open PRs may<br>
decrease significantly.<br>
<br>
<br>
- Colin<br>
<br>
_______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev</div>
<div class="gl_quoted"> </div>
</div>