Timo originally proposed this but I'd like to actually see the
proposal implemented. When working on ReactOS, I'd like developers to
create tickets in jira that their commits can then reference. For
example, Amine's wine syncs could have a ticket with the title "Wine
sync with version 1.x.y" or Alex's NPFS rewrite could have a ticket
with the title "New NPFS driver" and the relevant commits can have the
ticket number in them. This way when time comes for the changelog, all
that needs to be done is gather a list of all tickets closed before
the branch, no more of the digging through thousands of commit
messages crap.
Hello,
I am new to the reactos project.
I think I found a task where I can contribute :
http://www.reactos.org/wiki/Printing
But I don't know if someone else work on this task ?
Thank you
Loïc Maury
Hi All!!!
I'm not in the position to handle anymore bug reports other than the
only ones I'm working on now. Please do not assign new bugs to me!
Thanks,
James
Hi,
two major improvements have been done to testbots today, linked with
commit r59985:
http://svn.reactos.org/svn/reactos?view=revision&revision=59985
Thanks to Olaf, the Patch testbot has been extended that way: if you
specify parameter name windll with value yes, then ntdll from win2k3
will be used for the tests of your patch.
If you specify patch ID: 0, then unpatched revision will be tested.
In parallel, I've been working on Linux VMware testbot, that now has a
second testbot. This one is triggered on each commit and will test
ReactOS trunk with ntdll from win2k3. The results are uploaded to
testman. You can see the results with first attempt:
http://reactos.org/sites/all/modules/reactos/testman/compare.php?ids=19420,…
So far, we didn't include kernel32.dll nor npfs.sys due to the inability
of regtests to work with them. This will come later on.
Thanks to all for your great work permitting this major step for the
ReactOS project.
With my best regards,
--
Pierre Schweitzer<pierre at reactos.org>
System Administrator
ReactOS Foundation
Hey Guys,
I'll be in Montreal on October 2nd (Wednesday) giving a tech talk about
ReactOS, for about 2 hours. I intend to go over everything from development
to infrastructure (translation, testing, etc).
Are there any materials and/or suggestions from previous talks available
anywhere? Any set of tools/games/apps you recommend I try out?
--
Best regards,
Alex Ionescu
Me too have same opinion...
Sent from my windows Phone
From: Aleksey Bragin
Sent: 06-09-2013 AM 01:09
To: ReactOS Development List
Subject: Re: [ros-dev] Google Montreal Tech Talk
On 05.09.2013 23:00, Sven Barth wrote:
> On 05.09.2013 16:36, Александр wrote:
>> Tell them about http://www.youtube.com/watch?v=BzJTZY54r0I training
>> course called "operating systems" based on Reactos in Moscow State
>> Technical University by Aleksey Bragin. Also tell them about 2000 pages
>> of Chinese textbook devoted to Reactos 1)
>> http://yadi.sk/d/yRbwE6-23NqQu 2) http://yadi.sk/d/CxgVpVzS3G-GQ
>
> Pity that I understand neither Russian nor Chinese...
>
> @Aleksey: If you allow I have two small suggestions regarding your
> style of lecture based on the linked video (I don't know whether this
> already changed since the time of recording though):
> - try to look towards your students
> - please keep your hands out of your pockets
> As a student I definitely prefer presenters that respect these two
> points (and yes, I'm aware that this can be hard)
>
> Regards,
> Sven
Thanks Sven, I improved after watching the first recorded video of the
lecture myself, and tried to "fix" those issues in the next lectures.
Next time to practice would be 2014 spring when I am reading the same
course to the new 2nd year students.
Regards,
Aleksey Bragin
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev
I just wanted to say that this is just amazing. Being able to debug
ReactOS with "reference" low-level DLLs is great, but being able to
debug ReactOS ntdll and kernel32 when running them in reference
environment (that is, Windows 2003) is even better!
Indeed, I think, having a special testbot for this would be very beneficial.
Regards,
Aleksey
On 04.09.2013 11:28, ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Wed Sep 4 07:28:15 2013
> New Revision: 59985
>
> URL: http://svn.reactos.org/svn/reactos?rev=59985&view=rev
> Log:
> This commit, in my opinion, marks an important milestone in ReactOS development. One is now able to boot to desktop, launch applications, download through the application manager, play solitaire, minesweeper, launch Task Manager, etc... by using an unmodified Windows 2003 kernel32.dll binary (and, until our NPFS driver is fixed, the unmodified Windows 2003 NPFS driver). Additionally, one is able to achieve the same by booting with an unmodified Windows 2003 ntdll.dll, including a combination of both. The capability to mix-and-match components such as kernel32 and ntdll, at the heart of the system, will allow to better understand apitest failures (just as Wine has long had the capability to use Windows DLLs instead). With these two building blocks, additional Windows 2003 DLLs can be dropped in/tested, etc, and where failures are seen, a likely component can now be blamed. Furthermore, debugging with public symbols for these DLLs is now possible with WinDBG (in fact, this is how many bugs were fixed in this attempt). Many issues already exist when running with this combination FYI, for example, I was not able to launch any installers (tested Firefox and MIRC). This already demonstrates either missing functionality or ReactOS-specific functionality in components which depend on kernel32. I suspect the next step is infrastructure work to get special patchbot/builders to try and report back winetest results, and for additional DLLs to be "ported"/made to work. On a final note, this mixing and matching has benefits on both ends -- it's now likely that ReactOS' ntdll can run on Server 2003, at least far enough to get to Explorer or Task Manager. Running apitests on Server 2003 with and without reactos DLLs should also easily identify if certain DLLs are directly to blame for certain regressions/failures. </end excited rant>
> [BASESRV]: Allocate the INI mappings from the right heap.
>
> Modified:
> trunk/reactos/subsystems/win/basesrv/init.c
>
> Modified: trunk/reactos/subsystems/win/basesrv/init.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win/basesrv/ini…
> ==============================================================================
> --- trunk/reactos/subsystems/win/basesrv/init.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win/basesrv/init.c [iso-8859-1] Wed Sep 4 07:28:15 2013
> @@ -139,7 +139,7 @@
> BaseSrvInitializeIniFileMappings(IN PBASE_STATIC_SERVER_DATA StaticServerData)
> {
> /* Allocate the mapping blob */
> - BaseSrvIniFileMapping = RtlAllocateHeap(BaseSrvHeap,
> + BaseSrvIniFileMapping = RtlAllocateHeap(BaseSrvSharedHeap,
> HEAP_ZERO_MEMORY,
> sizeof(*BaseSrvIniFileMapping));
> if (BaseSrvIniFileMapping == NULL)
>
>
Hi Alex!
The stack guards prevent excessive recursions without throwing exceptions
and just kills the message loop by returning false. Removing them could
regress some misbehaving applications. Only one comes to mind, java
installer.
Thanks,
James
