Ros-dev

ros-dev@reactos.org

5789 discussions

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>

7 years, 1 month

Re: [ros-dev] Phoronix

by Can Tasan

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

7 years, 1 month

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!!!

7 years, 1 month

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.

7 years, 1 month

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!

7 years, 1 month

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 > > >

7 years, 1 month

"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

7 years, 1 month

logon sound remaked

by Javier Agustìn Fernàndez Arroyo

did you guys hear this? :) https://www.youtube.com/watch?v=xO5T5d4AmYo

7 years, 2 months

Tr : ReactOS, AHK: offline!

by Sylvain Petreolle

Due to my family presence, I need to stop the Test KVM AHK bot during this week end.I have good news regarding CORE-14536 and sound in general. "I'll be back." Kind regards, Sylvain Petreolle Le Vendredi 27 avril 2018 14h46, Serge Gautherie <reactos_serge_161107(a)gautherie.fr> a écrit : Hello Sylvain, Test KVM AHK is offline since "about 1 day ago (2018-Apr-25 18:27:36)". Thanks. --

7 years, 2 months

Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null driver.

by Alex Ionescu

1) I thought certain MDL fast I/O routines can get called at DISPATCH_LEVEL 2) For perf reasons, causing a page-fault in the middle of a "fast I/O" is probably a bad idea. That being said -- these concerns seem silly since we are talking about the "Null" driver which... is entirely PAGED_CODE and clearly neither #1 or #2 are actual issues. In Windows, the fast I/o table is part of the DEVICE_OBJECT itself. Not sure why our driver allocates a separate pool allocation to begin with. Best regards, Alex Ionescu On Mon, Apr 23, 2018 at 1:30 AM, Ged Murphy <gedmurphy.maillists(a)gmail.com> wrote: > They're pagable in NT6, I don't know whether that's the case in NT5. > > Change looks good to me, I'm not really sure why Alex used NNP? > Perhaps our kernel does/did things slightly differently back when he wrote > the Null driver? > > Ged. > > -----Original Message----- > From: Ros-dev <ros-dev-bounces(a)reactos.org> On Behalf Of Thomas Faber > Sent: Monday, 23 April 2018 07:49 > To: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > Cc: ros-dev(a)reactos.org > Subject: Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null > driver. > > On 2018-04-22 22:23, Hermès Bélusca-Maïto wrote: > > diff --git a/drivers/base/null/null.c b/drivers/base/null/null.c index > > 610e886ddd..0d4ed541de 100644 > > --- a/drivers/base/null/null.c > > +++ b/drivers/base/null/null.c > > @@ -181,26 +199,16 @@ DriverEntry(IN PDRIVER_OBJECT DriverObject, > > DriverObject->MajorFunction[IRP_MJ_READ] = NullDispatch; > > DriverObject->MajorFunction[IRP_MJ_LOCK_CONTROL] = NullDispatch; > > DriverObject->MajorFunction[IRP_MJ_QUERY_INFORMATION] = > > NullDispatch; > > + DriverObject->DriverUnload = NullUnload; > > > > - /* Allocate the fast I/O dispatch table */ > > - FastIoDispatch = ExAllocatePoolWithTag(NonPagedPool, > > - sizeof(FAST_IO_DISPATCH), > > - 'llun'); > > - if (!FastIoDispatch) > > - { > > - /* Failed, cleanup */ > > - IoDeleteDevice(DeviceObject); > > - return STATUS_INSUFFICIENT_RESOURCES; > > - } > > - > > - /* Initialize it */ > > - RtlZeroMemory(FastIoDispatch, sizeof(FAST_IO_DISPATCH)); > > - FastIoDispatch->SizeOfFastIoDispatch = sizeof(FAST_IO_DISPATCH); > > + /* Initialize the fast I/O dispatch table */ > > + RtlZeroMemory(&FastIoDispatch, sizeof(FastIoDispatch)); > > + FastIoDispatch.SizeOfFastIoDispatch = sizeof(FastIoDispatch); > > > > /* Setup our pointers */ > > - FastIoDispatch->FastIoRead = NullRead; > > - FastIoDispatch->FastIoWrite = NullWrite; > > - DriverObject->FastIoDispatch = FastIoDispatch; > > + FastIoDispatch.FastIoRead = NullRead; > > + FastIoDispatch.FastIoWrite = NullWrite; > > + DriverObject->FastIoDispatch = &FastIoDispatch; > > > Are you sure FAST_IO_DISPATCH is allowed to be pageable? It seems to only > be used at low IRQLs, so it seems logical. However I see it allocated > nonpaged everywhere else and can't seem to find definitive documentation on > the subject. > (And yes, most filesystem drivers use a static structure, but those > drivers don't use MmPageEntireDriver) > > Thanks, > Thomas > > _______________________________________________ > 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 >

7 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev