Ros-dev May 2018

ros-dev@reactos.org

18 participants
9 discussions

Document regarding the rules for managing pull requests

by David Quintana (gigaherz)

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

6 years, 3 months

Status Meeting (May 2018)

by Colin Finck

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

6 years, 3 months

Re: [ros-dev] Status Meeting (May 2018)

by hermes.belusca＠sfr.fr

Hi! To that I see one solution, that has actually already been proposed in the PR: we make an external package (a la Wine gecko) that one can download during installation, or later through RAPPS. Then this package (possibly together with other heavy core ones?) could be hosted in some GitHub sub-repo or elsewhere... Closing the PR now would definitely not be the right solution. Best, H.‌ <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : "Colin Finck" A : ros-dev(a)reactos.org Envoyé: mercredi 30 mai 2018 18:21 Objet : Re: [ros-dev] Status Meeting (May 2018)   <div class="gl_quoted">Am 30.05.2018 um 13:26 schrieb Ged Murphy: > Potential problems are: > 4) something else? I've been struggling with e.g. https://github.com/reactos/reactos/pull/276 On the one hand, we definitely need official support for Chinese, Korean, and Japanese character sets. On the other hand, this must not bloat up ReactOS by default, and just dropping a 12 MB font into the repository definitely does. So what is the ideal solution? I don't even know myself. - I could leave the PR open and hope that the submitter addresses my comments and comes up with a better solution. That hasn't happened in the last months. - I could close the PR right away. That would give the submitter no chance to address my comments and may even look disrespectful. And the original problem tends to be forgotten. - I could close the PR and open a JIRA issue describing the problem. If we decide on that as a general rule, we would put another burden on every reviewer. Additionally, such general JIRA issues tend to rot in our database as well. I think we often have this situation where the submitted PR is wrong, but we don't know the right solution either, and therefore keep the PR open. If we can better deal with these cases, the number of open PRs may decrease significantly. - Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

6 years, 3 months

Re: [ros-dev] Phoronix

by Can Tasan

Well, the problem is that current CC is missing HALF of the improvements made.

6 years, 3 months

Phoronix

by Can Tasan

Phoronix has published an article regarding 0.4.9, but Community Changelog is a month behind! They gave links despite warnings! Please get the news deleted until I make an update!!!

6 years, 3 months

Re: [ros-dev] [ros-diffs] 04/05: [USETUP] Enhancements for filesystem utility functions.

by Pierre Schweitzer

Obviously, as long as you have the IopParseDevice hack in action in usetup, you cannot expect FS to given you reliable information when you open the device since you directly talk to scsiport driver. Le 26/05/2018 à 19:18, Hermès Bélusca-Maïto a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=56ea51bbe498d126a61ba… > > commit 56ea51bbe498d126a61bab93c7ae95860bd290f2 > Author: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > AuthorDate: Sat May 13 16:20:10 2017 +0000 > Commit: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > CommitDate: Sat May 26 19:09:38 2018 +0200 > > [USETUP] Enhancements for filesystem utility functions. > > - Introduce code that detects the filesystem of a (mounted?) partition, using NtQueryVolumeInformationFile() with FileFsAttributeInformation class, > aka. rely on ReactOS itself (kernel, storage stack, filesystem drivers...) to recognize the FS on a partition that should normally be seen by the system. > This currently half-works for whatever reason (to be insvestigated), while it works on Windows. > - Fix few comments & a function parameter name. > - Use NT string pointer types. > > svn path=/branches/setup_improvements/; revision=74529 > --- > base/setup/usetup/fslist.c | 131 ++++++++++++++++++++++++++++++++++++++++----- > base/setup/usetup/fslist.h | 10 ++-- > 2 files changed, 122 insertions(+), 19 deletions(-) > > diff --git a/base/setup/usetup/fslist.c b/base/setup/usetup/fslist.c > index 0b190d4a8b..1eb158b777 100644 > --- a/base/setup/usetup/fslist.c > +++ b/base/setup/usetup/fslist.c > @@ -35,7 +35,7 @@ > VOID > AddProvider( > IN OUT PFILE_SYSTEM_LIST List, > - IN LPCWSTR FileSystemName, > + IN PCWSTR FileSystemName, > IN FORMATEX FormatFunc, > IN CHKDSKEX ChkdskFunc) > { > @@ -69,7 +69,7 @@ AddProvider( > PFILE_SYSTEM_ITEM > GetFileSystemByName( > IN PFILE_SYSTEM_LIST List, > - IN LPWSTR FileSystemName) > + IN PWSTR FileSystemName) > { > PLIST_ENTRY ListEntry; > PFILE_SYSTEM_ITEM Item; > @@ -87,6 +87,80 @@ GetFileSystemByName( > return NULL; > } > > +#if 0 // FIXME: To be fully enabled when our storage stack & al. will work better! > + > +/* NOTE: Ripped & adapted from base/system/autochk/autochk.c */ > +static NTSTATUS > +_MyGetFileSystem( > + IN struct _PARTENTRY* PartEntry, > + IN OUT PWSTR FileSystemName, > + IN SIZE_T FileSystemNameSize) > +{ > + NTSTATUS Status; > + HANDLE FileHandle; > + IO_STATUS_BLOCK IoStatusBlock; > + PFILE_FS_ATTRIBUTE_INFORMATION FileFsAttribute; > + UCHAR Buffer[sizeof(FILE_FS_ATTRIBUTE_INFORMATION) + MAX_PATH * sizeof(WCHAR)]; > + > + OBJECT_ATTRIBUTES ObjectAttributes; > + UNICODE_STRING PartitionRootPath; > + WCHAR PathBuffer[MAX_PATH]; > + > + FileFsAttribute = (PFILE_FS_ATTRIBUTE_INFORMATION)Buffer; > + > + /* Set PartitionRootPath */ > + swprintf(PathBuffer, > + // L"\\Device\\Harddisk%lu\\Partition%lu", // Should work! But because ReactOS sucks atm. it actually doesn't work!! > + L"\\Device\\Harddisk%lu\\Partition%lu\\", // HACK: Use this as a temporary hack! > + PartEntry->DiskEntry->DiskNumber, > + PartEntry->PartitionNumber); > + RtlInitUnicodeString(&PartitionRootPath, PathBuffer); > + DPRINT("PartitionRootPath: %wZ\n", &PartitionRootPath); > + > + /* Open the partition */ > + InitializeObjectAttributes(&ObjectAttributes, > + &PartitionRootPath, > + OBJ_CASE_INSENSITIVE, > + NULL, > + NULL); > + Status = NtOpenFile(&FileHandle, // PartitionHandle, > + FILE_GENERIC_READ /* | SYNCHRONIZE */, > + &ObjectAttributes, > + &IoStatusBlock, > + FILE_SHARE_READ, > + 0 /* FILE_SYNCHRONOUS_IO_NONALERT */); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to open partition %wZ, Status 0x%08lx\n", &PartitionRootPath, Status); > + return Status; > + } > + > + /* Retrieve the FS attributes */ > + Status = NtQueryVolumeInformationFile(FileHandle, > + &IoStatusBlock, > + FileFsAttribute, > + sizeof(Buffer), > + FileFsAttributeInformation); > + NtClose(FileHandle); > + > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("NtQueryVolumeInformationFile failed for partition %wZ, Status 0x%08lx\n", &PartitionRootPath, Status); > + return Status; > + } > + > + if (FileSystemNameSize * sizeof(WCHAR) < FileFsAttribute->FileSystemNameLength + sizeof(WCHAR)) > + return STATUS_BUFFER_TOO_SMALL; > + > + RtlCopyMemory(FileSystemName, > + FileFsAttribute->FileSystemName, > + FileFsAttribute->FileSystemNameLength); > + FileSystemName[FileFsAttribute->FileSystemNameLength / sizeof(WCHAR)] = UNICODE_NULL; > + > + return STATUS_SUCCESS; > +} > + > +#endif > > PFILE_SYSTEM_ITEM > GetFileSystem( > @@ -94,7 +168,11 @@ GetFileSystem( > IN struct _PARTENTRY* PartEntry) > { > PFILE_SYSTEM_ITEM CurrentFileSystem; > - LPWSTR FileSystemName = NULL; > + PWSTR FileSystemName = NULL; > +#if 0 // For code temporarily disabled below > + NTSTATUS Status; > + WCHAR FsRecFileSystemName[MAX_PATH]; > +#endif > > CurrentFileSystem = PartEntry->FileSystem; > > @@ -106,6 +184,26 @@ GetFileSystem( > > CurrentFileSystem = NULL; > > +#if 0 // FIXME: To be fully enabled when our storage stack & al. will work better! > + > + /* > + * We don't have one... > + * > + * Try to infer one using NT file system recognition. > + */ > + Status = _MyGetFileSystem(PartEntry, FsRecFileSystemName, ARRAYSIZE(FsRecFileSystemName)); > + if (NT_SUCCESS(Status) && *FsRecFileSystemName) > + { > + /* Temporary HACK: map FAT32 back to FAT */ > + if (wcscmp(FsRecFileSystemName, L"FAT32") == 0) > + wcscpy(FsRecFileSystemName, L"FAT"); > + > + FileSystemName = FsRecFileSystemName; > + goto Quit; > + } > + > +#endif > + > /* > * We don't have one... > * > @@ -141,12 +239,19 @@ GetFileSystem( > FileSystemName = L"NTFS"; /* FIXME: Not quite correct! */ > } > > +#if 0 > +Quit: // For code temporarily disabled above > +#endif > + > // HACK: WARNING: We cannot write on this FS yet! > - if (PartEntry->PartitionType == PARTITION_EXT2 || PartEntry->PartitionType == PARTITION_IFS) > - DPRINT1("Recognized file system %S that doesn't support write support yet!\n", FileSystemName); > + if (FileSystemName) > + { > + if (PartEntry->PartitionType == PARTITION_EXT2 || PartEntry->PartitionType == PARTITION_IFS) > + DPRINT1("Recognized file system %S that doesn't support write support yet!\n", FileSystemName); > + } > > DPRINT1("GetFileSystem -- PartitionType: 0x%02X ; FileSystemName (guessed): %S\n", > - PartEntry->PartitionType, FileSystemName); > + PartEntry->PartitionType, FileSystemName ? FileSystemName : L"None"); > > if (FileSystemName != NULL) > CurrentFileSystem = GetFileSystemByName(FileSystemList, FileSystemName); > @@ -160,7 +265,7 @@ CreateFileSystemList( > IN SHORT Left, > IN SHORT Top, > IN BOOLEAN ForceFormat, > - IN LPCWSTR ForceFileSystem) > + IN PCWSTR SelectFileSystem) > { > PFILE_SYSTEM_LIST List; > PFILE_SYSTEM_ITEM Item; > @@ -183,16 +288,16 @@ CreateFileSystemList( > > if (!ForceFormat) > { > - /* Add 'Keep' provider */ > + /* Add the 'Keep existing filesystem' dummy provider */ > AddProvider(List, NULL, NULL, NULL); > } > > - /* Search for ForceFileSystem in list */ > + /* Search for SelectFileSystem in list */ > ListEntry = List->ListHead.Flink; > while (ListEntry != &List->ListHead) > { > Item = CONTAINING_RECORD(ListEntry, FILE_SYSTEM_ITEM, ListEntry); > - if (Item->FileSystemName && wcscmp(ForceFileSystem, Item->FileSystemName) == 0) > + if (Item->FileSystemName && wcscmp(SelectFileSystem, Item->FileSystemName) == 0) > { > List->Selected = Item; > break; > @@ -205,7 +310,6 @@ CreateFileSystemList( > return List; > } > > - > VOID > DestroyFileSystemList( > IN PFILE_SYSTEM_LIST List) > @@ -226,7 +330,6 @@ DestroyFileSystemList( > RtlFreeHeap(ProcessHeap, 0, List); > } > > - > VOID > DrawFileSystemList( > IN PFILE_SYSTEM_LIST List) > @@ -264,7 +367,9 @@ DrawFileSystemList( > snprintf(Buffer, sizeof(Buffer), MUIGetString(STRING_FORMATDISK2), Item->FileSystemName); > } > else > + { > snprintf(Buffer, sizeof(Buffer), MUIGetString(STRING_KEEPFORMAT)); > + } > > if (ListEntry == &List->Selected->ListEntry) > CONSOLE_SetInvertedTextXY(List->Left, > @@ -279,7 +384,6 @@ DrawFileSystemList( > } > } > > - > VOID > ScrollDownFileSystemList( > IN PFILE_SYSTEM_LIST List) > @@ -291,7 +395,6 @@ ScrollDownFileSystemList( > } > } > > - > VOID > ScrollUpFileSystemList( > IN PFILE_SYSTEM_LIST List) > diff --git a/base/setup/usetup/fslist.h b/base/setup/usetup/fslist.h > index 685a2cfe2e..4433d381ba 100644 > --- a/base/setup/usetup/fslist.h > +++ b/base/setup/usetup/fslist.h > @@ -31,7 +31,7 @@ > typedef struct _FILE_SYSTEM_ITEM > { > LIST_ENTRY ListEntry; > - LPCWSTR FileSystemName; /* Not owned by the item */ > + PCWSTR FileSystemName; /* Not owned by the item */ > FORMATEX FormatFunc; > CHKDSKEX ChkdskFunc; > BOOLEAN QuickFormat; > @@ -46,16 +46,16 @@ typedef struct _FILE_SYSTEM_LIST > } FILE_SYSTEM_LIST, *PFILE_SYSTEM_LIST; > > VOID > -FS_AddProvider( > +AddProvider( > IN OUT PFILE_SYSTEM_LIST List, > - IN LPCWSTR FileSystemName, > + IN PCWSTR FileSystemName, > IN FORMATEX FormatFunc, > IN CHKDSKEX ChkdskFunc); > > PFILE_SYSTEM_ITEM > GetFileSystemByName( > IN PFILE_SYSTEM_LIST List, > - IN LPWSTR FileSystemName); > + IN PWSTR FileSystemName); > > struct _PARTENTRY; // Defined in partlist.h > PFILE_SYSTEM_ITEM > @@ -68,7 +68,7 @@ CreateFileSystemList( > IN SHORT Left, > IN SHORT Top, > IN BOOLEAN ForceFormat, > - IN LPCWSTR ForceFileSystem); > + IN PCWSTR SelectFileSystem); > > VOID > DestroyFileSystemList( > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

6 years, 3 months

Testman

by Edijs van Kole de McSnikovics

Hello. I am wondering if testman source code is available to download. ----------------------------------------------SIGNATURE------------------------------------------------------ Draudžiama tiesiogiai teikti reklama konkreciam asmeniui, jeigu yra aiškiai išreikštas šio asmens nesutikimas. Už reklamos naudojimo reikalavimu nesilaikyma istatymas numato bauda nuo 300 iki 10 tukst. EUR. Nesutinku gauti reklamos ar reklaminio pobudžio žinuciu! Nesutinku, jog mano duomenys butu naudojami rinkodaros tikslais! Nesutinku, jog mano duomenys butu perduodami treciosioms salims be mano sutikimo!

6 years, 3 months

Re: [ros-dev] Ros-dev Digest, Vol 165, Issue 3

by John Duncan

unsubscribe On Sun, May 6, 2018 at 8:00 AM, <ros-dev-request(a)reactos.org> wrote: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: "Note: LibreOffice 5.4 will be the last codeline > tosupport Windows XP or Vista" (Javier Agustìn Fernàndez Arroyo) > 2. Re: "Note: LibreOffice 5.4 will be the last codeline > tosupport Windows XP or Vista" (Erkin Alp Güney) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 6 May 2018 01:02:53 +0200 > From: Javier Agustìn Fernàndez Arroyo <elhoir(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last > codeline tosupport Windows XP or Vista" > Message-ID: > <CAAHf8rcC_PhT6OHmf-frhuB6tarj6SAj3un8AipR48hChEDM > gQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > as an alternative, Apache OpenOffice still supports NT5 > > On Sun, May 6, 2018 at 12:38 AM, David Quintana (gigaherz) < > gigaherz(a)gmail.com> wrote: > > > No need to panick, they themselves link to this as an archive of old > > versions: https://downloadarchive.documentfoundation.org/ > libreoffice/old/ > > So even if it's gone from their own site, it should remain there. > > > > On 6 May 2018 at 00:30, Javier Agustìn Fernàndez Arroyo < > elhoir(a)gmail.com> > > wrote: > > > >> hello again guys, > >> > >> What if we get latest NT5 libreoffice version (5.4.6 as of now, and > >> 5.4.7-rc1 is out) just for testing purposes? i guess it will be dropped > >> from official website, andi don´t know if it will be still available in > any > >> way...... > >> > >> On Sat, Jul 1, 2017 at 9:29 AM, Michael Fritscher < > michael(a)fritscher.net> > >> wrote: > >> > >>> Hi, > >>> > >>> is there a list which need to be done to get the basic NT6 architecture > >>> just to get feeling how much work it is? Sadly, I'm afraid that we'll > >>> need a proper NT6 architecture to get modern drivers running, won't we? > >>> > >>> Best regards, > >>> Michael Fritscher > >>> > >>> On 30.06.2017 11:46, Ged Murphy wrote: > >>> > That’s what’s currently being worked on. > >>> > > >>> > The kernel still closely follows the NT5.2 architecture, but user > mode > >>> will have NT6+ compatibility shims to allow modern applications to run > >>> correctly. > >>> > > >>> > > >>> > > >>> > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of > >>> ajaczgz(a)yahoo.es > >>> > Sent: 30 June 2017 05:47 > >>> > To: ReactOS Development List <ros-dev(a)reactos.org> > >>> > Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last > >>> codeline tosupport Windows XP or Vista" > >>> > > >>> > > >>> > > >>> > I think it’s no neccesary to implement NT6, only to avoid the > >>> compatibility tests to NT6 and implement only the characteristics that > the > >>> most of the programs uses. > >>> > > >>> > > >>> > > >>> > Best regards > >>> > > >>> > Antonio J. Arrieta Cuartero > >>> > > >>> > > >>> > > >>> > Enviado desde mi Lumia 635 con Windows 10 Mobile > >>> > > >>> > > >>> > > >>> > De: Riccardo Paolo Bestetti <mailto:riccardo.kyogre@live.it> > >>> > Enviado: jueves, 29 de junio de 2017 22:11 > >>> > Para: ReactOS Development List <mailto:ros-dev@reactos.org> > >>> > Asunto: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last > codeline > >>> tosupport Windows XP or Vista" > >>> > > >>> > > >>> > > >>> > Hello Colin, > >>> > > >>> > As this definitely wasn't the predominant thinking the last time this > >>> same discussion took place, Hermès' email scared me a bit. Thank you so > >>> much for clarifying. > >>> > > >>> > > >>> > > >>> > Best regards, > >>> > > >>> > Riccardo Paolo Bestetti > >>> > > >>> > > >>> > > >>> > -----Original Message----- > >>> > > >>> > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of > Colin > >>> Finck > >>> > > >>> > Sent: giovedì 29 giugno 2017 20:00 > >>> > > >>> > To: ros-dev(a)reactos.org <mailto:ros-dev@reactos.org> > >>> > > >>> > Subject: Re: [ros-dev] "Note: LibreOffice 5.4 will be the last > >>> codeline to support Windows XP or Vista" > >>> > > >>> > > >>> > > >>> > Rest assured, we know that ReactOS won't be of much use if we stay > >>> NT5-only. Work is underway to provide a seamless support of NT6 > >>> applications on top of the existing codebase. > >>> > > >>> > Also the majority of developers should be using an NT6 platform > >>> themselves, so they certainly aim for support for NT6 applications. > >>> > > >>> > Finally, applications compiled by modern versions of Visual Studio > are > >>> NT6-only by default, so supporting this platform is unavoidable. > >>> > > >>> > > >>> > > >>> > Just my two cents, as the previous replies could lead you to believe > >>> we're failing the reality check. > >>> > > >>> > > >>> > > >>> > Cheers, > >>> > > >>> > > >>> > > >>> > Colin > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > Am 29.06.2017 um 18:54 schrieb Riccardo Paolo Bestetti: > >>> > > >>> >> I’m just gonna snap in for my yearly IT guy NT6 rant: this mindset > is > >>> > > >>> >> going to kill the project by making it useless whenever it reaches a > >>> > > >>> >> usable state. > >>> > > >>> >> > >>> > > >>> >> Windows XP/Server 2003 use is **already** marginal as of today, and > >>> > > >>> >> it’s only gonna get “worse” as more and more networks get infected > by > >>> > > >>> >> ransomware and institutions all over the world wake up and update > >>> (and > >>> > > >>> >> as time passes of course). It’s not a matter of “fancy”, it is a > >>> > > >>> >> matter of what people use on their computers. With that argument you > >>> > > >>> >> may as well advocate for DOS. > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> Please don’t be offended, as always this is only intended as a > >>> reality > >>> > > >>> >> check. > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> Best regards, > >>> > > >>> >> > >>> > > >>> >> Riccardo Paolo Bestetti > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> *From:*Ros-dev [mailto:ros-dev-bounces@reactos.org] *On Behalf Of > >>> > > >>> >> *Hermès BÉLUSCA-MAÏTO > >>> > > >>> >> *Sent:* giovedì 29 giugno 2017 16:09 > >>> > > >>> >> *To:* 'ReactOS Development List' <ros-dev(a)reactos.org <mailto: > >>> ros-dev(a)reactos.org> > > >>> > > >>> >> *Subject:* Re: [ros-dev] "Note: LibreOffice 5.4 will be the last > >>> > > >>> >> codeline to support Windows XP or Vista" > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> I’m wondering for which useless / fancy features they need Windows > 7+ > >>> > > >>> >> support only…. > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> H. > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> *De :*Ros-dev [mailto:ros-dev-bounces@reactos.org] *De la part de* > >>> > > >>> >> Javier Agustìn Fernàndez Arroyo *Envoyé :* jeudi 29 juin 2017 15:48 > >>> *À > >>> > > >>> >> :* ReactOS Development List *Objet :* [ros-dev] "Note: LibreOffice > >>> 5.4 > >>> > > >>> >> will be the last codeline to support Windows XP or Vista" > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> https://wiki.documentfoundation.org/Releases/5.4.0/RC1 > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> FYI > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> > >>> > > >>> >> _______________________________________________ > >>> > > >>> >> 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 <mailto:Ros-dev@reactos.org> > >>> > > >>> > http://www.reactos.org/mailman/listinfo/ros-dev > >>> > > >>> > _______________________________________________ > >>> > > >>> > Ros-dev mailing list > >>> > > >>> > Ros-dev(a)reactos.org <mailto:Ros-dev@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 > >>> > >> > >> > >> _______________________________________________ > >> 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 > > >

6 years, 4 months

"Note: LibreOffice 5.4 will be the last codeline to support Windows XP or Vista"

by Javier Agustìn Fernàndez Arroyo

https://wiki.documentfoundation.org/Releases/5.4.0/RC1 FYI

6 years, 4 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev May 2018