Hello,
Let me invite you to the monthly status meeting taking place 29th of
June, 19:00 UTC.
We do it either in #reactos-meeting on Freenode, or on a very own
standalone IRC server. In that case 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. And everyone is fine with that.
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
Hello all,
Today I noticed that our buildbots couldnt connect to SVN to upload the
commit changes, and therefore failed to build. Also I noticed that the usual
SVN ViewVC address (which was previously https://svn.reactos.org/svn/reactos
, for example) changed to https://svn.reactos.org/viewcvs/reactos/ (granted,
there appear to be an automatic redirection to this new address).
Is it an intentional change, or an unintentional one? We didnt seem to be
warned prior to this on the mailing list!
Cheers,
Hermès
According to The Register, Windows 10 source has been leaked. But reading
that codes is still illegal for ReactOS development, so we might fire you
if you read in the case.
---- Please don't read the leaked source.
Thanks,
Katayama Hirofumi MZ
片山博文MZ
Hi all!
I'm currently planning the ReactOS Hackfest 2017 in the Cologne/Bonn
area in Germany. Currently, the plan is to book a meeting room from
Monday, August 14 to Friday, August 18. We can then use the weekend
before to get to Cologne and explore the city a bit. After the Hackfest,
everybody interested can join us at FrOSCon in Bonn the weekend after.
As booking a room there involves significant costs, I'd like to know who
of you can definitely make it for the Hackfest and who of you is
definitely out.
Please reply now to prevent me from bugging you on IRC all the time! ;)
Cheers,
Colin
hbelusca(a)svn.reactos.org wrote:
> [SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based
> on code by Samuel Serapion & MSDN. What needs to be fixed here, is the
> client/server code to communicate the results back to the main test
> app being running. Work in progress.
I have implemented short and simple WineTest-compatible client/server
code in localspl_apitest. The server is the application that is tested
through rosautotest. For every test, it starts the client, sends the
test name over a pipe and outputs the received testing output. The
client simply has stdout redirected to a pipe and can then use usual
WineTest ok() functions for testing.
Check out rostests/apitests/localspl (server) and
rostests/apitests/localspl/dll (client). Hope that helps!
- Colin
On Sun, Jun 18, 2017 at 1:34 AM, <hbelusca(a)svn.reactos.org> wrote:
> - if (!(CmpProfileLoaded) && !(CmpWasSetupBoot))
> + if (!CmpProfileLoaded && !CmpWasSetupBoot)
>
Why do you keep re-formatting other people's code in unrelated patches?
You've been repeatedly asked to stop doing this.
Best regards,
Alex Ionescu
On 2017-06-19 18:29, hbelusca(a)svn.reactos.org wrote:
> + /*
> + * Free it from the pool.
> + *
> + * We cannot use here ExFreePoolWithTag(..., OB_NAME_TAG); , because
> + * the object name may have been massaged during operation by different
> + * object parse routines. If the latter ones have to resolve a symbolic
> + * link (e.g. as is done by CmpParseKey() and CmpGetSymbolicLink()),
> + * the original object name is freed and re-allocated from the pool,
> + * possibly with a different pool tag. At the end of the day, the new
> + * object name can be reallocated and completely different, but we
> + * should still be able to free it!
> + */
> + ExFreePool(Buffer);
I feel like
ExFreePoolWithTag(Buffer, 0)
conveys that same message without needing a huge comment?
Hi all!
A picture says more than a thousand words:
http://fs5.directupload.net/images/170613/u4d8a59a.png
As promised in the last meeting, I have brought to life a machine for
testing GPU drivers with real GPUs under ReactOS. It combines a QEMU
virtual machine with PCIe GPU Passthrough together with a KVM-over-IP
card for feeding the real video signal back to a window.
What you see in the screenshot is a real NVIDIA GeForce 9300 GPU
attached to a ReactOS VM. We can now test the NVIDIA driver installation
while enjoying the easy debuggability of a VM.
My first report is already out: https://jira.reactos.org/browse/CORE-13423
Every developer interested in working on this can drop me a line and I
will send you credentials for the server.
Soon I will also add an AMD Graphics Card along with another KVM-over-IP
card to let us debug the other big driver package.
Thanks go out to Mr. Kromdijk for the generous server donation,
Christoph for the KVM-over-IP card, and Hervé for the QEMU hints!
Let's all get some flashy 3D acceleration into ReactOS!! :)
Cheers,
Colin