- Ros-dev - ReactOS.org

ReactOS 0.4.9 to be released tomorrow, July 23, 2018 - Press Kit is online!

by Colin Finck

Hi all! With the great last-minute work on the press release, we can finally release ReactOS 0.4.9 tomorrow, Monday, July 23, 2018! The download will be officially available around noon (CEST). A Press Kit for the ReactOS 0.4.9 release is already available: https://download.reactos.org/reactos/ReactOS/0.4.9/ReactOS-0.4.9-PressKit.z… Feel free to send it to interested parties to let them know about the upcoming release in advance. Best regards, Colin Finck

6 years, 10 months

1
0
0 0

Re: [ros-dev] [ros-diffs] 01/01: [WIN32SS] Fix NtUserGetClipboardData for text paste (#645)

by Pierre Schweitzer

For the record, that commit seems to have broken ReactOS testing (see testman, which records last successful test run for 2170901, ie, previous commit). Starting with that commit, any regression test run never ends. It seems bug reports have been creating regarding regressions (timeouts) in the tests but got ignored so far. It would be great to fix these before pushing any other commits. Cheers, Pierre Le 30/06/2018 à 17:12, Katayama Hirofumi MZ a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6abc9f5b5af6cc7b7c57f… > > commit 6abc9f5b5af6cc7b7c57ff9c6bcc4a919cf85d1e > Author: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > AuthorDate: Sun Jul 1 00:12:23 2018 +0900 > Commit: Hermès BÉLUSCA - MAÏTO <hermes.belusca-maito(a)reactos.org> > CommitDate: Sat Jun 30 17:12:23 2018 +0200 > > [WIN32SS] Fix NtUserGetClipboardData for text paste (#645) > > Fix the NtUserGetClipboardData function for the synthesized text formats (CF_TEXT, CF_OEMTEXT and CF_UNICODETEXT). > CORE-11471 > --- > win32ss/user/ntuser/clipboard.c | 47 ++++++++++++++++++++++++++--------------- > 1 file changed, 30 insertions(+), 17 deletions(-) > > diff --git a/win32ss/user/ntuser/clipboard.c b/win32ss/user/ntuser/clipboard.c > index 92109953cc..04e5d22291 100644 > --- a/win32ss/user/ntuser/clipboard.c > +++ b/win32ss/user/ntuser/clipboard.c > @@ -294,8 +294,8 @@ IntAddSynthesizedFormats(PWINSTATION_OBJECT pWinStaObj) > bHaveBm = IntIsFormatAvailable(pWinStaObj, CF_BITMAP); > bHaveDib = IntIsFormatAvailable(pWinStaObj, CF_DIB); > > - /* Add CF_LOCALE format if we have CF_TEXT */ > - if (!bHaveLocale && bHaveText) > + /* Add CF_LOCALE format if we have CF_TEXT, CF_OEMTEXT or CF_UNICODETEXT */ > + if (!bHaveLocale && (bHaveText || bHaveOemText || bHaveUniText)) > { > PCLIPBOARDDATA pMemObj; > HANDLE hMem; > @@ -881,6 +881,7 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd) > HANDLE hRet = NULL; > PCLIP pElement; > PWINSTATION_OBJECT pWinStaObj; > + UINT uSourceFmt = fmt; > > TRACE("NtUserGetClipboardData(%x, %p)\n", fmt, pgcd); > > @@ -898,18 +899,7 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd) > } > > pElement = IntGetFormatElement(pWinStaObj, fmt); > - if (pElement && IS_DATA_DELAYED(pElement) && pWinStaObj->spwndClipOwner) > - { > - /* Send WM_RENDERFORMAT message */ > - pWinStaObj->fInDelayedRendering = TRUE; > - co_IntSendMessage(pWinStaObj->spwndClipOwner->head.h, WM_RENDERFORMAT, (WPARAM)fmt, 0); > - pWinStaObj->fInDelayedRendering = FALSE; > - > - /* Data should be in clipboard now */ > - pElement = IntGetFormatElement(pWinStaObj, fmt); > - } > - > - if (!pElement || IS_DATA_DELAYED(pElement)) > + if (!pElement) > goto cleanup; > > if (IS_DATA_SYNTHESIZED(pElement)) > @@ -921,20 +911,43 @@ NtUserGetClipboardData(UINT fmt, PGETCLIPBDATA pgcd) > case CF_UNICODETEXT: > case CF_TEXT: > case CF_OEMTEXT: > - pElement = IntGetFormatElement(pWinStaObj, CF_UNICODETEXT); > + uSourceFmt = CF_UNICODETEXT; > + pElement = IntGetFormatElement(pWinStaObj, uSourceFmt); > if (IS_DATA_SYNTHESIZED(pElement)) > - pElement = IntGetFormatElement(pWinStaObj, CF_TEXT); > + { > + uSourceFmt = CF_TEXT; > + pElement = IntGetFormatElement(pWinStaObj, uSourceFmt); > + } > if (IS_DATA_SYNTHESIZED(pElement)) > - pElement = IntGetFormatElement(pWinStaObj, CF_OEMTEXT); > + { > + uSourceFmt = CF_OEMTEXT; > + pElement = IntGetFormatElement(pWinStaObj, uSourceFmt); > + } > break; > + > case CF_BITMAP: > IntSynthesizeBitmap(pWinStaObj, pElement); > break; > + > default: > ASSERT(FALSE); > } > } > > + if (pElement && IS_DATA_DELAYED(pElement) && pWinStaObj->spwndClipOwner) > + { > + /* Send WM_RENDERFORMAT message */ > + pWinStaObj->fInDelayedRendering = TRUE; > + co_IntSendMessage(pWinStaObj->spwndClipOwner->head.h, WM_RENDERFORMAT, (WPARAM)uSourceFmt, 0); > + pWinStaObj->fInDelayedRendering = FALSE; > + > + /* Data should be in clipboard now */ > + pElement = IntGetFormatElement(pWinStaObj, uSourceFmt); > + } > + > + if (!pElement || IS_DATA_DELAYED(pElement)) > + goto cleanup; > + > _SEH2_TRY > { > ProbeForWrite(pgcd, sizeof(*pgcd), 1); > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

6 years, 10 months

2
1
0 0

Website migrated to a new Login system

by Colin Finck

Hello all, Our website has been migrated to a new Login system today and all components have been upgraded to their latest versions. In the course of that, the user database has also been moved into an LDAP directory and cleaned from accounts that have never been used. Please check that everything is working alright and report bugs in our JIRA: https://jira.reactos.org You are also advised to change your password in the self-service at https://reactos.org/roslogin/?p=selfservice - even to the same one. Every password change from now on will use a state-of-the-art hashing algorithm (salted SHA-512 with 6000 rounds) to protect your account from credential theft. Unfortunately, there have been several newer accounts, for which the password could not be migrated. If you encounter problems logging in, please reset your account password at https://reactos.org/roslogin/?p=forgot to regain access. Best regards, Colin Finck

6 years, 10 months

3
2
0 0

Website Maintenance on Wednesday, July 4

by Colin Finck

Hi all! The ReactOS Website along with the Forum, Wiki, and JIRA bug tracker will be down for maintenance for several hours during the day (European time) on Wednesday, July 4. In the course of this process, the user database will be migrated to the new RosLogin Single-Sign-On system (https://github.com/reactos/web/tree/master/www/www.reactos.org/roslogin) and the Forum and Wiki software will be upgraded to their latest releases. This is expected to put an end to our login weirdnesses (dead Login buttons, 30 minute propagation delay to JIRA), solve the CAPTCHA problems people were reporting, and increase the maintainability of the website. I will be on the #reactos IRC channel during the migration and give status updates there. Best regards, Colin

6 years, 10 months

1
0
0 0

Status Meeting (June 2018)

by Colin Finck

Hi all! Let me invite you to the June 2018 meeting, taking place this Thursday, June 28, 2018 at 19:00 UTC. Invited members will again receive their credentials shortly before the meeting. The current agenda is: 1. Status Reports 2. ReactOS Hackfest on August 16 - 21 3. 0.4.9 release on July 14 I'm open for additional proposals. Best regards, Colin

6 years, 10 months

4
5
0 0

Re: [ros-dev] Microsoft acquires GitHub

by Thomas Mueller

from Javier Agustìn Fernàndez Arroyo: > May this affect ReactOS? > https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-dev… I just found this new article on heise online about a new possible alternative to Github: https://www.heise.de/newsticker/meldung/Neue-Entwickler-Plattform-TeaHub-wi… (This is in German language) TeaHub will be nonprofit, URL is https://about.teahub.io/ This website is in English. Tom

6 years, 11 months

1
0
0 0

Microsoft acquires GitHub

by Javier Agustìn Fernàndez Arroyo

May this affect ReactOS? https://blogs.microsoft.com/blog/2018/06/04/microsoft-github-empowering-dev…

6 years, 11 months

8
12
0 0

Re: [ros-dev] [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning; fix few comments; fix the default empty window title string.

by Hermès BÉLUSCA-MAÏTO

This change (on my own code snippet btw, see commit 5a1a35ca5a6) was necessary because otherwise, the StringPrintf call that is done below (which would then use a WindowTitleU.Buffer == NULL) would generate the harderror dialog title: "(null)" (in addition to other strings being appended), instead of just an empty string. And so the bug is that I forgot to adjust the condition that needs to be checked before freeing the window title string (if it has been allocated). Hermès > -----Message d'origine----- > De : Thomas Faber [mailto:thomas.faber@reactos.org] > Envoyé : samedi 9 juin 2018 09:21 > À : ros-dev(a)reactos.org; Hermès Bélusca-Maïto > Objet : Re: [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning; > fix few comments; fix the default empty window title string. > > On 2018-04-08 16:17, Hermès Bélusca-Maïto wrote: > > /* Retrieve the window title of the client, if it has one */ > > - RtlInitEmptyUnicodeString(&WindowTitleU, NULL, 0); > > + RtlInitEmptyUnicodeString(&WindowTitleU, L"", 0); > > This looks like a bug. Can you explain why you think it's necessary please? > > In particular, it will break this: > > if (WindowTitleU.Buffer) RtlFreeUnicodeString(&WindowTitleU); > > > Thanks, > Thomas

6 years, 11 months

2
1
0 0

ReactOS mirror repo detected on GitLab

by Stas'M

I've found this mirror repo on GitLab, it was created today: https://gitlab.com/reactos/reactos Does it belong to the ReactOS team? If not, we may have problems. ---- Regards, Stas'M

6 years, 11 months

3
2
0 0

Re: [ros-dev] [ros-diffs] 01/01: [USERSRV] HardError: Fix compilation warning; fix few comments; fix the default empty window title string.

by Thomas Faber

On 2018-04-08 16:17, Hermès Bélusca-Maïto wrote: > /* Retrieve the window title of the client, if it has one */ > - RtlInitEmptyUnicodeString(&WindowTitleU, NULL, 0); > + RtlInitEmptyUnicodeString(&WindowTitleU, L"", 0); This looks like a bug. Can you explain why you think it's necessary please? In particular, it will break this: if (WindowTitleU.Buffer) RtlFreeUnicodeString(&WindowTitleU); Thanks, Thomas

6 years, 11 months

1
0
0 0

Interested in building developer interface mentioned in your gsoc'18 page.

by Ayush Sinha

Hey there ! Went through the reactOS GSOC’18 page. I am interested in making web interface for reactos which can show all GitHub reactos repos, commits, etc using the GitHub API. (https://www.reactos.org/wiki/Google_Summer_of_Code_2018_Ideas#Developer_Web…) Looking forward to work on the same idea for GSOC’19 under your mentorship. Need to know more about layout of the web interface. Kindly help! thanks

6 years, 11 months

1
0
0 0

Announcing the ReactOS Hackfest 2018 in Berlin

by Colin Finck

Hi all! It's official now! The ReactOS Hackfest 2018 will take place from Thursday, 16th August 2018 to Tuesday, 21st August 2018 in Berlin, Germany. Thanks to Thomas, the event location is already checked out ("definitely more space than in Cologne") and he has found a hostel nearby. All information can be found at https://reactos.org/wiki/ReactOS_Hackfest_2018, with the lists for registering yourself and collecting ideas at https://reactos.org/wiki/ReactOS_Hackfest_2018/Lists Hope to see you in August! Cheers, Colin

6 years, 11 months

2
1
0 0

Re: [ros-dev] Phoronix

by Can Tasan

I have finished for now. Please inform them.

6 years, 11 months

2
1
0 0

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, 11 months

1
0
0 0

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, 11 months

6
10
0 0

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, 11 months

2
1
0 0

Re: [ros-dev] Phoronix

by Can Tasan

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

6 years, 11 months

2
3
0 0

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, 11 months

2
1
0 0

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, 11 months

1
0
0 0

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

2
1
0 0

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

3
2
0 0

"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

11
19
0 0

logon sound remaked

by Javier Agustìn Fernàndez Arroyo

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

7 years

1
0
0 0

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

1
0
0 0

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

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev