Hi all!
Let me invite you to the August 2018 meeting, taking place this
Thursday, August 30, 2018 at 19:00 UTC.
Invited members will again receive their credentials shortly before the
meeting.
The current agenda is:
1. Status Reports (extended)
Note that this is the first meeting after both GSoC and the
Hackfest.
Participants in either effort are encouraged to also report
their related work, what they liked and didn't like about GSoC/
Hackfest, and what we could do better next time.
As always, I'm open for additional proposals.
I also have to announce that I will definitely be unavailable during the
entire September, so someone else has to invite for and lead the
September meeting.
Best regards,
Colin
Hi all,
I took some time during Hackfest to upgrade our Test_VBox Testbot to
Ubuntu 18.04, which finally brings us VirtualBox 5.2.x support for
sysreg2. Pierre also worked on the relevant BuildBot scripts to improve
their reliability.
This has resulted in
https://github.com/reactos/buildbot_config/commit/388a831eb5ccf67535d8cbd6d…
and since using that script, the infamous "IVirtualBox object is null"
bug hasn't occurred again :)
The upgrade from VirtualBox 4.3.40 to 5.2.10 also resulted in unbearably
slow serial port output at first, but this could be fixed by
https://github.com/reactos/sysreg2/commit/a4eb4a4551618b4af4dc1985ad8c55fe0….
Have a look at this commit if you encounter a slow serial port output in
one of the latest VirtualBox versions with either operating system.
This only leaves a funnily flawed WINE test left, which currently causes
the entire regression testing process to come to a standstill:
https://jira.reactos.org/browse/CORE-14975
Cheers,
Colin
|My proposed architecture diagram for ENIW: Linux app systemd <>
systemd2svchost Windows userland ------ User-mode Linux kernel -------
SVCHOST Windows services ENIW.SYS Windows personalities Kernel-mode
drivers for everything -------------------------- NTOSKRNL.EXE
----------------------------------- ENIW is a component to implement
WSL-like functionality named after WINE and its bacronym is ENIW never
imitated WSL. systemd2svchost is a service translator to run systemd
units as svchost services. Forum thread:
<https://www.reactos.org/forum/viewtopic.php?f=9&t=17434> JIRA ticket:
<https://jira.reactos.org/browse/CORE-13613> Yours, faihfully Erkin Alp |
Hi Timo et al.,
To make the issue wider known than just me comment on GitHub. That
commit introduced a regression.
Le 20/08/2018 à 18:07, Timo Kreuzer a écrit :
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=c219be9409af429909b14…
>
> commit c219be9409af429909b1433da536516b3c3ab823
> Author: Timo Kreuzer <timo.kreuzer(a)reactos.org>
> AuthorDate: Sun Feb 4 19:20:56 2018 +0100
> Commit: Timo Kreuzer <timo.kreuzer(a)reactos.org>
> CommitDate: Mon Aug 20 18:07:35 2018 +0200
>
> [NTOS:MM] Fix paged pool expansion
> ---
> ntoskrnl/mm/ARM3/pool.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/ntoskrnl/mm/ARM3/pool.c b/ntoskrnl/mm/ARM3/pool.c
> index 7cebabe818..113a7aa981 100644
> --- a/ntoskrnl/mm/ARM3/pool.c
> +++ b/ntoskrnl/mm/ARM3/pool.c
> @@ -561,10 +565,11 @@ MiAllocatePoolPages(IN POOL_TYPE PoolType,
> MiInitializePfnForOtherProcess(PageFrameNumber,
> (PMMPTE)PointerPde,
> MmSystemPageDirectory[(PointerPde - MiAddressToPde(NULL)) / PDE_COUNT]);
> +#endif
>
> /* Write the actual PDE now */
> -// MI_WRITE_VALID_PDE(PointerPde, TempPde);
> -#endif
> + MI_WRITE_VALID_PDE(PointerPde, TempPde);
> +
That little change for x86 actually breaks VBox support. It hits an
ASSERT during 3rd stage:
*** Assertion failed: PointerPde->u.Hard.Valid == 0
*** Source File:
/srv/buildbot/Build_GCCLin_x86/build/ntoskrnl/mm/ARM3/miarm.h, line 975
See testbots for instance:
https://build.reactos.org/builders/Test%20VBox/builds/8625/steps/test/logs/…
Cheers,
Pierre
--
Pierre Schweitzer <pierre at reactos.org>
System & Network Administrator
Senior Kernel Developer
ReactOS Deutschland e.V.
Why are these misleading? These are checks that Windows does that we are
missing.
Guys, open PRs for changes like these ffs.
Best regards,
Alex Ionescu
On Wed, Aug 8, 2018 at 7:14 PM Thomas Faber <thomas.faber(a)reactos.org>
wrote:
>
> https://git.reactos.org/?p=reactos.git;a=commitdiff;h=1ed0f9ab576f094b27e11…
>
> commit 1ed0f9ab576f094b27e11ba374738ecabc00e2e6
> Author: Thomas Faber <thomas.faber(a)reactos.org>
> AuthorDate: Wed Aug 8 19:58:56 2018 +0200
> Commit: Thomas Faber <thomas.faber(a)reactos.org>
> CommitDate: Wed Aug 8 20:08:38 2018 +0200
>
> [HAL] Remove misleading debug prints about USB controllers.
> ---
> hal/halx86/legacy/bussupp.c | 26 --------------------------
> 1 file changed, 26 deletions(-)
>
> diff --git a/hal/halx86/legacy/bussupp.c b/hal/halx86/legacy/bussupp.c
> index a37d875ede..4d20396560 100644
> --- a/hal/halx86/legacy/bussupp.c
> +++ b/hal/halx86/legacy/bussupp.c
> @@ -1128,32 +1128,6 @@ HalpInitializePciBus(VOID)
> }
> }
>
> - /* Check if this is a USB controller */
> - if ((PciData->BaseClass == PCI_CLASS_SERIAL_BUS_CTLR) &&
> - (PciData->SubClass == PCI_SUBCLASS_SB_USB))
> - {
> - /* Check if this is an OHCI controller */
> - if (PciData->ProgIf == 0x10)
> - {
> - DbgPrint("\tDevice is an OHCI (USB) PCI Expansion
> Card. Turn off Legacy USB in your BIOS!\n\n");
> - continue;
> - }
> -
> - /* Check for Intel UHCI controller */
> - if (PciData->VendorID == 0x8086)
> - {
> - DbgPrint("\tDevice is an Intel UHCI (USB)
> Controller. Turn off Legacy USB in your BIOS!\n\n");
> - continue;
> - }
> -
> - /* Check for VIA UHCI controller */
> - if (PciData->VendorID == 0x1106)
> - {
> - DbgPrint("\tDevice is a VIA UHCI (USB)
> Controller. Turn off Legacy USB in your BIOS!\n\n");
> - continue;
> - }
> - }
> -
> /* Now check the registry for chipset hacks */
> Status = HalpGetChipHacks(PciData->VendorID,
> PciData->DeviceID,
>
>
Hi all!
Looking at the calendar, it would be time for the July Meeting today.
However, I didn't receive any agenda proposals and also forgot to
announce it in the course of releasing 0.4.9.
So I suggest we postpone the meeting to next week's Thursday, August 2.
Please send agenda proposals by then.
That meeting also allows us to handle last-minute planning regarding the
Hackfest.
Best regards,
Colin
Hi,
I really like this idea. Actually i was thinking something similar about user mode apps like paint or even the file browser of the shell which can be used from windows xp to windows 10. (You need just these three files from us: filebrowser.exe, rshell.dll and browseui.dll).
Ged Murphy <gedmurphy.maillists(a)gmail.com> wrote on Wed, August 1st, 2018, 11:30 PM:
> We could keep components in the reactos git project and just create a new repo for them, however it might still get lost/overshadowed slightly by the main reactos codebase. Another option would be to create a new separate project with one\multiple repos. This would allow us to truly separate components from the reactos project and try to generate interest on their own merit.
>
> We'd need to maximize their visibility by adding a good README.rd files with plenty of buzzwords for the google crawler bot to pick up.
>
> If it was successful and we decide to do more, then we'd need to come up with a format as to how to best manage multiple components.
> Do we have individual repos for each component, which allows dedicated README.rd files? This would give maximum flexibility and allow us to have a separate README.rd for each component.
> Do we bundle everything into one repo similar to how the WDK samples are setup? This is easier to manage, but less convenient for end users, and won't be as visible for people to find in google searches.
>
> Ged.
>
>
> -----Original Message-----
> From: Ros-dev <ros-dev-bounces(a)reactos.org> On Behalf Of Hermès BÉLUSCA-MAÏTO
> Sent: Wednesday, 01 August 2018 20:20
> To: 'ReactOS Development List' <ros-dev(a)reactos.org>
> Subject: Re: [ros-dev] Postponing the July Meeting
>
> Hi,
>
> This sounds interesting, for potential developers wanting just to work on some module, but not wanting to deal with the whole OS thing.
> Would this mean that we also have to think about git submodules? Because (in the case of the NTFS driver for example) it would be in a different git repo, and then it would have to be automatically downloaded and updated whenever one of the core ROS dev updates his own ROS git repo.
>
> Cheers,
> Hermes
>
> > -----Message d'origine-----
> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Ged
> > Murphy Envoyé : mercredi 1 août 2018 20:16 À : 'ReactOS Development
> > List'
> > Objet : Re: [ros-dev] Postponing the July Meeting
> >
> > I have an item for the agenda. I'd like to discuss the possibility of
> > moving some of our drivers out of the main repo and into something more convenient.
> >
> > In case I don't make the meeting, I'll put forward some of my reasons here:
> >
> > This thought has come about due to the btrfs driver which we use from
> > Mark Harmstone. Mark's project receives quite a bit of interest on
> > github, and I'm assuming one of the reasons is that it's so easy to
> > find and build. Searching for 'btrfs windows' lists his project as the
> > top hit in google, and building is as simple as cloning, opening the
> > project in VS and clicking build (assuming you have the
> > WDK)
> >
> > I'm wondering if we did the same thing to some of our drivers, we
> > might generate more interest in them. A good example would be our NTFS driver.
> > When searching for open source NTFS solutions you're only really given
> > Linux and Max options. The reactos driver is buried deep in the search
> > list, and you only see it if you know what you're looking for. Next if
> > you want to build it, you need to clone the main reactos repo, install
> > the build tools, setup and build the environment, build the tool
> > chain, build the linkers libs, etc, etc. There are so many barriers
> > for people who aren't part of the reactos development team that the chance of getting anyone interested in it are practically zero.
> >
> > This process would be much simpler if the code was available to clone
> > as a separate project, and could simply build with the WDK and VS.
> > There's then a chance that it might start to generate interest, and
> > people may start working on it instead of it just bit-rotting deep in our main repo.
> >
> > If we're going to do that, why not consider others too. Network cards,
> > sound stack, USB, boot loaders, printer drivers, directx, etc, There's
> > lots of things that people might be interested in working on and using
> > if they weren't tied to the reactos code base. We obviously benefit
> > from any external interest, and simply pull/import it back into the reactos project.
> >
> > Ged.
> >
> >
> >
> > -----Original Message-----
> > From: Ros-dev <ros-dev-bounces(a)reactos.org> On Behalf Of Colin Finck
> > Sent: Thursday, 26 July 2018 17:58
> > To: 'ReactOS Development List' <ros-dev(a)reactos.org>
> > Subject: [ros-dev] Postponing the July Meeting
> >
> > Hi all!
> >
> > Looking at the calendar, it would be time for the July Meeting today.
> > However, I didn't receive any agenda proposals and also forgot to
> > announce it in the course of releasing 0.4.9.
> > So I suggest we postpone the meeting to next week's Thursday, August 2.
> >
> > Please send agenda proposals by then.
> > That meeting also allows us to handle last-minute planning regarding
> > the Hackfest.
> >
> > Best regards,
> >
> > Colin
> >
> >
> >
> > _______________________________________________
> > Ros-dev mailing list
> > Ros-dev(a)reactos.org
> > http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev
>
>
> _______________________________________________
> Ros-dev mailing list
> Ros-dev(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-dev