Ros-dev December 2020

ros-dev@reactos.org

12 participants
8 discussions

Re: [ros-dev] Status Meeting (November 2020)

by Hermès BÉLUSCA-MAÏTO

What about that discussion about why we have ditched out MSVC 2010 support (starting to depend on that fact, and thus, breaking any possibility of self-hosting ROS building on ROS using MSVC compiler (without the IDE), since later versions of MSVC only work on Vista+, and as an indirect consequence, too, opening the can of worms, that is, being able to "pollute", involuntarily or not, the ReactOS core code (kernel + drivers) with C99+ non-standard portable code -- ), and without having first warned heavily through all the mailing lists etc. , thus allowing the developers to voice their concerns publicly in the MLs ? This was done around in mattermost only, after we decided for some reason that we wouldn't need the VC2010 buildbots anymore. Hermes. -----Original Message----- From: Ros-dev <ros-dev-bounces(a)reactos.org> On Behalf Of Colin Finck Sent: Sun Nov 15 17:24:22 UTC 2020 To: ReactOS Development List <ros-dev(a)reactos.org> Subject: [ros-dev] Status Meeting (November 2020) Hi all, With several people asking for a status meeting, let's have another one before the year is over. Let me invite you to the meeting on Thursday, 26th November 2020 19:00 UTC Mattermost private channel "Meeting" So far, there is only one point on the agenda: * Achievements and Future Outlook (everyone) What have you been working on and what are your plans? Please submit further agenda proposals by answering to this mail. Looking forward to see you! Colin

3 years, 8 months

FOSDEM online

by Mark Jansen

Hello, This year FOSDEM is going to be an online event: https://fosdem.org/2021/news/2020-12-11-stands-cfp/ Are there volunteers for an online ReactOS stand? We would need some short video's for introduction and demonstration purposes, as well as some people active in a chat room answering questions. Regards, Mark

3 years, 8 months

Re: [ros-dev] [ros-diffs] [reactos] 01/01: Implement IRP_MN_QUERY_DEVICE_TEXT.DeviceTextLocationInformation

by jerome.gardou＠reactos.org

Eric, Can we please refrain from using sprintf, strlen and the like in kernel-mode drivers ? Expecially on buffers which are obviously too small for their purpose ? Please use functions from ntstrsafe.h and work directly on W-buffers, thanks. Thanks Jérôme Le dimanche 6 décembre 2020, 12:45:55 CET Eric Kohl a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=cac7b003c04c1f42f45221 > 56c2d2f77996b271c2 > > commit cac7b003c04c1f42f4522156c2d2f77996b271c2 > Author: Eric Kohl <eric.kohl(a)reactos.org> > AuthorDate: Sun Dec 6 12:42:50 2020 +0100 > Commit: Eric Kohl <eric.kohl(a)reactos.org> > CommitDate: Sun Dec 6 12:42:50 2020 +0100 > > Implement IRP_MN_QUERY_DEVICE_TEXT.DeviceTextLocationInformation > --- > drivers/storage/port/scsiport/pdo.c | 34 +++++++++++++++++++++++++++++++--- > 1 file changed, 31 insertions(+), 3 deletions(-) > > diff --git a/drivers/storage/port/scsiport/pdo.c > b/drivers/storage/port/scsiport/pdo.c index 182f2b029ec..5ddbd7e2b34 100644 > --- a/drivers/storage/port/scsiport/pdo.c > +++ b/drivers/storage/port/scsiport/pdo.c > @@ -185,10 +185,12 @@ PdoHandleQueryDeviceText( > PIO_STACK_LOCATION IoStack; > UINT32 Offset = 0; > PINQUIRYDATA InquiryData; > - CHAR LocalBuffer[sizeof(InquiryData->VendorId) + > sizeof(InquiryData->ProductId) + 2]; + CHAR LocalBuffer[40]; > ANSI_STRING AnsiString; > UNICODE_STRING DeviceDescription; > > + DPRINT("PdoHandleQueryDeviceText\n"); > + > IoStack = IoGetCurrentIrpStackLocation(Irp); > > InquiryData = &DeviceExtension->InquiryData; > @@ -196,9 +198,8 @@ PdoHandleQueryDeviceText( > switch (IoStack->Parameters.QueryDeviceText.DeviceTextType) > { > case DeviceTextDescription: > - case DeviceTextLocationInformation: > { > - DPRINT("PdoHandleQueryDeviceText\n"); > + DPRINT("DeviceTextDescription\n"); > > Offset += CopyFieldTruncate(InquiryData->VendorId, > &LocalBuffer[Offset], > @@ -227,6 +228,33 @@ PdoHandleQueryDeviceText( > Irp->IoStatus.Information = > (ULONG_PTR)DeviceDescription.Buffer; return STATUS_SUCCESS; > } > + > + case DeviceTextLocationInformation: > + { > + DPRINT("DeviceTextLocationInformation\n"); > + > + sprintf(LocalBuffer, "Bus Number %d, Target ID %d, LUN %d", > + DeviceExtension->PathId, DeviceExtension->TargetId, > DeviceExtension->Lun); + > + RtlInitAnsiString(&AnsiString, (PCSZ)&LocalBuffer); > + > + DeviceDescription.Length = 0; > + DeviceDescription.MaximumLength = (USHORT)((strlen(LocalBuffer) > + 1) * sizeof(WCHAR)); + DeviceDescription.Buffer = > ExAllocatePoolWithTag(PagedPool, + > DeviceDescription.MaximumLength, + > TAG_SCSIPORT); + if > (!DeviceDescription.Buffer) > + { > + Irp->IoStatus.Information = 0; > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + RtlAnsiStringToUnicodeString(&DeviceDescription, &AnsiString, > FALSE); + > + Irp->IoStatus.Information = > (ULONG_PTR)DeviceDescription.Buffer; + return STATUS_SUCCESS; > + } > + > default: > { > Irp->IoStatus.Information = 0;

3 years, 9 months

Status Meeting (November 2020)

by Do Ho

Hello, as Colin already mentioned, I have tried to compile libc++ for ReactOS. I stopped the project for two reasons: 1. The current state of the CRT in ReactOS. 2. The ongoing discussion about MSVC 2010. With MSVC 2010 it is of course impossible to compile a current version of libc++. So why should I waste my time? Without a clear commitment to using current C++ compilers, it simply makes no sense. As Colin described in detail, current technologies would increase the pace of development and attract more interested developers. Developers like me, who simply do something else without the project ever knowing about them. But don't get me wrong, this is not about me or libc++. Maybe libc++ cannot be used for other reasons after all! But with MSVC 2010 you don't even have to start. All the best, Dominik

3 years, 9 months

Status Meeting (November 2020)

by Олег Дубінський

3 years, 9 months

Status Meeting (November 2020)

by Joachim Henze

I totally and vehemently agree with Hermes here: We should NOT ditch VS2010. Arguments that were raised by others against VS2010 and my reply: -"ditching it brings in new developers to ros magically" <- I do ask then, where are they? I don't see any. -"we should not be limited to strict C89" <- No one did request for that. All we want is to remain compatible to VS2010. A subset. -"syncing BTRFS is a bit harder" <- So what? Then let others do the job. Actually BTRFS is not even a mandatory feature of ros. Having it in the tree is just luxury. -"libc++" <- I see no urgent need and nothing it would give in return that would outweight what we would sacrifice. My arguments again for keeping VS2010: -VS2010 creates the smallest binaries of all compilers we do support -VS2010 CAN be installed in ros, when ros is installed as Server during 2nd stage, (yes this was not the case for a very short moment, unfortunately exactly when we discussed in https://github.com/reactos/reactos/pull/2658 but now it works again, even in 0.4.14-RC51) -VS2010 can now even open the VS2010 cmd prompt see https://jira.reactos.org/secure/attachment/57140/57140_0.4.15-dev-203-g711f… -no other VS>2010 can even complete its setup in ros, and that will remain like that for many years to come -VS2010 is the last version that runs on XPSP3 (which is important for some of our devs including myself) -VS2010 is the last version that runs on 2k3SP2 which is our current target -VS2010 is reliable with industry-proven stability, and itself no moving target (unlike VS2019 which breaks our builds every few weeks when MS upgrades it) -VS2010 DOES provide std::unique_ptr. Stating anything else is just a lie. It covers > 95% of CPP2011-standard. It is absolutely possible and not complicated to write leak-free-code with it.

3 years, 9 months

Status Meeting (November 2020)

by Олег Дубінський

3 years, 9 months

Status Meeting (November 2020)

by Doug Lyons

Hello, Please note that I would like to cast a vote in favor of restoring compatibility for VS2010. Thanks very much, Doug Lyons -- This email has been checked for viruses by AVG. https://www.avg.com

3 years, 9 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2020