- Ros-dev - ReactOS.org

Tr : ReactOS, AHK: offline!
by Sylvain Petreolle 27 Apr '18

27 Apr '18

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

1 0

Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null driver.
by Alex Ionescu 27 Apr '18

27 Apr '18

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 >

1 0

Status Meeting (April 2018)
by Colin Finck 26 Apr '18

26 Apr '18

Hi all! Let me invite you to the April 2018 meeting, taking place this Thursday, April 26, 2018 at 19:00 UTC. There have been no requests for additional agenda points yet and I'm not aware of any developments of the outstanding points of last meeting, so right now the agenda only includes the Status Updates. If there is something you want discussed this month, please reply to this mail. As waiting for every developer's Status Report still wastes too much time each month, I'm asking everyone to prepare a short text in advance. Unlike previous meetings, let's all try to post our status updates simultaneously this time and let the IRC server handle the congestion. This may make some reports harder to read, but we should be able to move on much quicker. Best regards, Colin

1 1

Re: [ros-dev] [ros-diffs] 01/01: [NULL] Additions for the Null driver.
by Thomas Faber 23 Apr '18

23 Apr '18

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

2 1

Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the "%02d:%02d:%02d" time format and get rid of the safe string printf because the string will NEVER be longer than 8 characters. - Rename the timer id constant because it is NOT a resource id. - Rename variables according to the coding style.
by Thomas Faber 06 Apr '18

06 Apr '18

Hey Eric, On 2018-04-02 12:58, Eric Kohl wrote: > - RtlStringCbPrintfW(strbuf, sizeof(strbuf), L"%d:%d:%d", hours, minutes, seconds); > + swprintf(szBuffer, L"%02d:%02d:%02d", iHours, iMinutes, iSeconds); Unfortunately I must disagree with this change. Buffer overflows are a big enough threat that code review and static analysis are not generally considered sufficient to protect against them. So it's best practice for new code to always verify sizes at run-time, and never to use s(w)print. Best regards, Thomas PS: from what I see, iHours can be as large as 1193046, which won't fit in 2 digits

7 7

Re: [ros-dev] [ros-diffs] 02/08: [NTOSKRNL] Forbid processes without the Tcb prvilege to perform a user-mode hard-error BSOD.
by Alex Ionescu 02 Apr '18

02 Apr '18

So to be clear, while the kernel still has tons of incompatible code and issues to barely run as a Win2003-compatible kernel, whenever there's an NT design decision you disagree with, you're going to be rewriting the little bit of code that _does work well_ to work contrary to how NT works? Did I get that right? Good luck. Best regards, Alex Ionescu On Mon, Apr 2, 2018 at 6:48 AM, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote: > Yes, to only allow programs that REALLY REALLY REALLY REALLY ….. need to > do so to trigger the hard-error “shutdown” BSOD from user-mode to do so, > and these programs would better be only those that run only in SYSTEM > rights, and more exactly these include CSRSS, WINLOGON and SMSS when > something very bad happen to them. > > I would not appreciate, for example, that when I run a program under a > not-so privileged account (like, some random user account) that has just > the shutdown privilege to shut the computer down properly, that this > program suddently “BSODS” my machine. > > To these programs, I say “f$ck these!” > > > > Regards, > > Hermès > > > > *De :* Ros-dev [mailto:ros-dev-bounces@reactos.org] *De la part de* Alex > Ionescu > *Envoyé :* lundi 2 avril 2018 04:20 > *À :* ReactOS Development List; Hermès Bélusca-Maïto > *Cc :* Linda Wang > *Objet :* Re: [ros-dev] [ros-diffs] 02/08: [NTOSKRNL] Forbid processes > without the Tcb prvilege to perform a user-mode hard-error BSOD. > > > > Is there a point to this blatant behavior change? > > > Best regards, > Alex Ionescu > > > > On Sun, Apr 1, 2018 at 3:04 PM, Hermès Bélusca-Maïto < > hermes.belusca-maito(a)reactos.org> wrote: > > https://git.reactos.org/?p=reactos.git;a=commitdiff;h= > f0729b30bb79d6f538cf2b9578ff8ebe7989f8d3 > > commit f0729b30bb79d6f538cf2b9578ff8ebe7989f8d3 > Author: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > AuthorDate: Sun Apr 1 14:46:19 2018 +0200 > Commit: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > CommitDate: Sun Apr 1 22:39:31 2018 +0200 > > [NTOSKRNL] Forbid processes without the Tcb prvilege to perform a > user-mode hard-error BSOD. > --- > ntoskrnl/ex/harderr.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/ntoskrnl/ex/harderr.c b/ntoskrnl/ex/harderr.c > index 84f409a1bb..a5200e3e74 100644 > --- a/ntoskrnl/ex/harderr.c > +++ b/ntoskrnl/ex/harderr.c > @@ -132,8 +132,18 @@ ExpRaiseHardError(IN NTSTATUS ErrorStatus, > /* Check if this error will shutdown the system */ > if (ValidResponseOptions == OptionShutdownSystem) > { > - /* Check for privilege */ > - if (!SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode)) > + /* > + * Check if we have the privileges. > + * > + * NOTE: In addition to the Shutdown privilege we also check > whether > + * the caller has the Tcb privilege. The purpose is to allow only > + * SYSTEM processes to "shutdown" the system on hard errors (BSOD) > + * while forbidding regular processes to do so. This behaviour > differs > + * from Windows, where any user-mode process, as soon as it has > the > + * Shutdown privilege, can trigger a hard-error BSOD. > + */ > + if (!SeSinglePrivilegeCheck(SeTcbPrivilege, PreviousMode) || > + !SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode)) > { > /* No rights */ > *Response = ResponseNotHandled; > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > >

1 0

Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the "%02d:%02d:%02d" time format and get rid of the safe string printf because the string will NEVER be longer than 8 character
by Hermès BÉLUSCA-MAÏTO 02 Apr '18

02 Apr '18

If I remember correctly you can make shutdowns delayed of many days on Windows (using the InitiateSystemShutdown(Ex) function), in which case the 2-digit hour won't work at all. Best, Hermès > -----Message d'origine----- > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Thomas > Faber > Envoyé : lundi 2 avril 2018 14:13 > À : Eric Kohl > Cc : ros-dev(a)reactos.org > Objet : Re: [ros-dev] [ros-diffs] 01/01: [WINLOGON] Clean up part 2 - Replace > the UNICODE_STRING usMessage by a PWSTR pszMessage. - Use the > "%02d:%02d:%02d" time format and get rid of the safe string printf because > the string will NEVER be longer than 8 character > > Hey Eric, > > On 2018-04-02 12:58, Eric Kohl wrote: > > - RtlStringCbPrintfW(strbuf, sizeof(strbuf), L"%d:%d:%d", hours, minutes, > seconds); > > + swprintf(szBuffer, L"%02d:%02d:%02d", iHours, iMinutes, > > + iSeconds); > > Unfortunately I must disagree with this change. > > Buffer overflows are a big enough threat that code review and static analysis > are not generally considered sufficient to protect against them. > So it's best practice for new code to always verify sizes at run-time, and > never to use s(w)print. > > Best regards, > Thomas > > PS: from what I see, iHours can be as large as 1193046, which won't > fit in 2 digits > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

2 1

Re: [ros-dev] [ros-diffs] 02/08: [NTOSKRNL] Forbid processes without the Tcb prvilege to perform a user-mode hard-error BSOD.
by Alex Ionescu 02 Apr '18

02 Apr '18

Is there a point to this blatant behavior change? Best regards, Alex Ionescu On Sun, Apr 1, 2018 at 3:04 PM, Hermès Bélusca-Maïto < hermes.belusca-maito(a)reactos.org> wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h= > f0729b30bb79d6f538cf2b9578ff8ebe7989f8d3 > > commit f0729b30bb79d6f538cf2b9578ff8ebe7989f8d3 > Author: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > AuthorDate: Sun Apr 1 14:46:19 2018 +0200 > Commit: Hermès Bélusca-Maïto <hermes.belusca-maito(a)reactos.org> > CommitDate: Sun Apr 1 22:39:31 2018 +0200 > > [NTOSKRNL] Forbid processes without the Tcb prvilege to perform a > user-mode hard-error BSOD. > --- > ntoskrnl/ex/harderr.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/ntoskrnl/ex/harderr.c b/ntoskrnl/ex/harderr.c > index 84f409a1bb..a5200e3e74 100644 > --- a/ntoskrnl/ex/harderr.c > +++ b/ntoskrnl/ex/harderr.c > @@ -132,8 +132,18 @@ ExpRaiseHardError(IN NTSTATUS ErrorStatus, > /* Check if this error will shutdown the system */ > if (ValidResponseOptions == OptionShutdownSystem) > { > - /* Check for privilege */ > - if (!SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode)) > + /* > + * Check if we have the privileges. > + * > + * NOTE: In addition to the Shutdown privilege we also check > whether > + * the caller has the Tcb privilege. The purpose is to allow only > + * SYSTEM processes to "shutdown" the system on hard errors (BSOD) > + * while forbidding regular processes to do so. This behaviour > differs > + * from Windows, where any user-mode process, as soon as it has > the > + * Shutdown privilege, can trigger a hard-error BSOD. > + */ > + if (!SeSinglePrivilegeCheck(SeTcbPrivilege, PreviousMode) || > + !SeSinglePrivilegeCheck(SeShutdownPrivilege, PreviousMode)) > { > /* No rights */ > *Response = ResponseNotHandled; > >

3 2

d2d1 in ReactOS
by Giovanni Mascellani 30 Mar '18

30 Mar '18

Dear ReactOS developers, I am nosing inside Wine and ReactOS code to understand something of their inner workings. I wanted to compare the code of d2d1.dll, but apparently ReactOS does not have it. Is this intentional, is it just still to be implemented, or is there any other explanation? Thanks and all the best, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

2 1

Status Meeting (March 2018)
by Colin Finck 29 Mar '18

29 Mar '18

Hi all! With GSoC and 0.4.8 approaching, and many interesting things going on, it's finally time for a monthly meeting again. Let me invite you to the March 2018 meeting, taking place next Thursday, March 29, 2018. Time will be 19:00 UTC as always. The agenda so far includes: - Status Updates ==> Please prepare a short text what you did since January, so we can finish this quickly! - GSoC - 0.4.8 Status und Release Planning - Hackfest 2018? Please let me know if you want anything else to be added to the agenda. Just as the last few times, the meeting will take place on a custom IRC server. The required credentials will be sent shortly before the meeting to a group of ReactOS members. If you think you belong to this group, but didn't get a mail last time, please also let me know in advance. See you on Thursday! Colin

3 4

GSoC 2018: Proposal for Review
by Abhishek Singh Bisht 22 Mar '18

22 Mar '18

Hello there, Here I have attached my proposal for the GSoC 2018 project regarding the search shell extension for ReactOS. Kindly let me know if any changes are required, before submitting it to Google. Thanks, Abhishek

2 1

GSoc Proposal (WebSite)
by Вова Титаренко 22 Mar '18

22 Mar '18

*GSoc ProposalProject: Developer Web InterfaceAuthor: Volodymyr Tytarenkobovatitar(a)gmail.com <bovatitar(a)gmail.com>General info:Full name: Volodymyr TytarenkoLanguages: 1. Russian (Fluently)2. Ukrainian (Fluently)3. Polish (Fluently)4. English (Intermediate)Timezone: (GMT+1) WarsawReactOS account: titarIRC Nickname: titarAbout me:I am second year student in Poland. I study informatics at University of Silesia in the specialty of developing web application. Programming is my passion. I started programming from the age of 15 and now i have 4 games for android, several programs on java for my needs and a lot of projects for freelanceTime Commitment:The main important thing, what can obligations my time in summer it’s a my University exams in June, but its only around 10 days, and i believe i will have a few exemption from the exam, because last time i had only 1 exam out of 6. Second thing it’s a 1 week holiday in end of July or start August, but it’s not 100%. I can spend 5-6 hours per day on this project including holidays.Technical skills:FrontEnd: HTML5, CSS, JavaScript and MithrillJS (arround 20)BackEnd: PHPDataBase: MySQLUX, UI, WebDesign, GitWork with different public API: GitHub, Telegram, Instagram, Facebook, VK, different weather api and other.I have experience Designing api for my own projects.My test design for a similar task (Custom ERP and CRM):Proposed Project:Develop a web system of managing and showing commits, builds, PRs and other informations for developers of ReactOS.I really want to work on a Website for ReactOS. I believe that I have enough knowledge to contribute to the operating system ReactOs in this way.Milestones: 1. Design basic interface and basic functionality. 2. Develop basic website with Integration githubAPI.3. Gradual increase of site functionality from the list of ideas reactos.org <http://reactos.org>Developing a website with the provision that at every moment we need to have a fully working website, gradually adding new features I hereby swear that I have not used nor seen the source code to any version of the Windows operating system nor any Microsoft product that may be related to the proposed project that is under a license incompatible with contribution to ReactOS, including but not limited to the leaked Windows 2000 source code and the Windows Research Kernel.*

2 1

GSoC 2018
by Abhishek Singh Bisht 22 Mar '18

22 Mar '18

Hi there, I am interested in a couple of projects under System enhancement, that I found on your projects list: 1) NT6 Recycle Bin Project 2) Search Shell extension 3) WebKit based MSHTML implementation Kindly help me choose one, if I could get some more information regarding the projects, it would be really helpful and I can go ahead with the proposal. Also, I have performed a complete build of ReactOS Live CD, and Boot CD and gave it a test run. I found it lacking a decent browser, tried to run iexplore.exe but it still couldn’t load any web pages. I might be able to create something to help improve on this. Looking forward to contribute to this reactOS. Thanks, Abhishek

4 3

ReactOS
by Кирилл Печкарев 18 Mar '18

18 Mar '18

Hello, I am a 3rd year student of Nosov MSTU, studying in the direction of Information and Computer science. I would like to develop components to support Wi-Fi, this is the third item from the list left on the site (https://habrahabr.ru/company/reactos/blog/351382/) Language know on average, can use greater part of his features. Experience in development is available since I combine study and work, I work in Department on creation of MES decisions. Fast learner, willing to allocate to the project 1-2 hours a day, maybe more( according to circumstances)

2 1

ReactOS
by Кирилл Печкарев 18 Mar '18

18 Mar '18

Здравствуйте, я студент 3 курса МГТУ им Носова, учусь на направлении Информатика и Вычислительная техника. Хотел бы заниматься разработкой компонентов для поддержки Wi-Fi, это третий пункт из списка оставленном на сайте (https://habrahabr.ru/company/reactos/blog/351382/) Язык знаю на среднем уровне, могу использовать большую часть его особенностей. Опыт в разработке имеется, т.к. совмещаю учебу и работу, работаю в отделе по созданию MES решений. Быстро учусь, готов выделять проекту 1-2 часа в день, возможно больше( по обстоятельствам)

1 0

Yet another GSoC proposal
by Victor Perevertkin 15 Mar '18

15 Mar '18

Hi all! I am a student and I want to try to participate in gsoc this year. I follow ReactOS news for 4 years, I think (and even reported a few bugs). I am a web developer but some time ago I started to study ASM and C (but no C++ yet) in my university and found it very interesting for me. I want to learn more about OSDev and maybe join your team finally :) There are some thoughts about what I want to do for ROS during this summer. 1. Make ReactOS boot from btrfs. As far as I understand, freeldr does not support btrfs and this code must be written. And boot sector ofc I prefer this task the most (as for now). But maybe you will dispel my dreams by saying that it requires too much effort for summer internship :) 2. I've already talked with Thomas Faber on IRC and he said that there are some drivers that are in need of being (re)written. NICs and bluetooth drivers may be interesting to me but I'm not sure if I can get through it. So I'm asking your advice. Are this things doable for a student? Maybe there are some other interesting low-level things for a GSoC'er? Do you have mentors for them? Basically, I want something low-level which doesn't require deep knowledge of NT internals. Thanks! Victor Perevertkin

1 0

Re: [ros-dev] [ros-diffs] 01/01: improve SHGetFileInfo (#118)
by Pierre Schweitzer 16 Feb '18

16 Feb '18

For the record, the commit doesn't match our contributing rules and should be avoided in the future. Reference: https://github.com/reactos/reactos/blob/master/.gitmessage Le 16/02/2018 à 12:00, Katayama Hirofumi MZ a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=338799bf8bf98698f3e4c… > > commit 338799bf8bf98698f3e4c1c2b885d724a9a929da > Author: Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > AuthorDate: Fri Feb 16 20:00:08 2018 +0900 > Commit: Ged Murphy <gedmurphy(a)reactos.org> > CommitDate: Fri Feb 16 11:00:08 2018 +0000 > > improve SHGetFileInfo (#118) > > This patch reduces failures of SHGetFileInfo function. CORE-7159 > * improve WideByteToWideChar calls > * fix bugs related to file attributes and SHGFI_EXETYPE > * SHGFI_USEFILEATTRIBUTES and SHGFI_ICON fix > * s/sizeof(temppsfi)/0/ > --- > dll/win32/shell32/wine/shell32_main.c | 81 +++++++++++++++++++++-------------- > 1 file changed, 49 insertions(+), 32 deletions(-) > > diff --git a/dll/win32/shell32/wine/shell32_main.c b/dll/win32/shell32/wine/shell32_main.c > index b5638f0582..e64ef7f6fb 100644 > --- a/dll/win32/shell32/wine/shell32_main.c > +++ b/dll/win32/shell32/wine/shell32_main.c > @@ -3,6 +3,7 @@ > * > * Copyright 1998 Marcus Meissner > * Copyright 1998 Juergen Schmied (jsch) * <juergen.schmied(a)metronet.de> > + * Copyright 2017 Katayama Hirofumi MZ <katayama.hirofumi.mz(a)gmail.com> > * > * This library is free software; you can redistribute it and/or > * modify it under the terms of the GNU Lesser General Public > @@ -433,7 +434,7 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > { > psfi->szDisplayName[0] = '\0'; > psfi->szTypeName[0] = '\0'; > - psfi->iIcon = 0; > + psfi->hIcon = NULL; > } > > if (!(flags & SHGFI_PIDL)) > @@ -449,12 +450,24 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > lstrcpynW(szFullPath, path, MAX_PATH); > } > } > + else > + { > + SHGetPathFromIDListW((LPITEMIDLIST)path, szFullPath); > + } > > if (flags & SHGFI_EXETYPE) > { > - if (flags != SHGFI_EXETYPE) > - return 0; > - return shgfi_get_exe_type(szFullPath); > + if (!(flags & SHGFI_SYSICONINDEX)) > + { > + if (flags & SHGFI_USEFILEATTRIBUTES) > + { > + return TRUE; > + } > + else if (GetFileAttributesW(szFullPath) != INVALID_FILE_ATTRIBUTES) > + { > + return shgfi_get_exe_type(szFullPath); > + } > + } > } > > /* > @@ -488,6 +501,8 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > (LPCITEMIDLIST*)&pidlLast ); > if (SUCCEEDED(hr)) > pidlLast = ILClone(pidlLast); > + else > + hr = S_OK; > ILFree(pidl); > } > else > @@ -505,8 +520,18 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > psfi->dwAttributes = 0xffffffff; > } > if (psfParent) > - IShellFolder_GetAttributesOf( psfParent, 1, (LPCITEMIDLIST*)&pidlLast, > - &(psfi->dwAttributes) ); > + { > + IShellFolder_GetAttributesOf(psfParent, 1, (LPCITEMIDLIST*)&pidlLast, > + &(psfi->dwAttributes)); > + } > + } > + > + if (flags & SHGFI_USEFILEATTRIBUTES) > + { > + if (flags & SHGFI_ICON) > + { > + psfi->dwAttributes = 0; > + } > } > > /* get the displayname */ > @@ -516,7 +541,7 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > { > lstrcpyW (psfi->szDisplayName, PathFindFileNameW(szFullPath)); > } > - else > + else if (psfParent) > { > STRRET str; > hr = IShellFolder_GetDisplayNameOf( psfParent, pidlLast, > @@ -618,7 +643,7 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > ret = FALSE; > } > } > - else > + else if (psfParent) > { > hr = IShellFolder_GetUIObjectOf(psfParent, 0, 1, > (LPCITEMIDLIST*)&pidlLast, &IID_IExtractIconW, > @@ -694,7 +719,7 @@ DWORD_PTR WINAPI SHGetFileInfoW(LPCWSTR path,DWORD dwFileAttributes, > } > } > } > - else > + else if (psfParent) > { > if (!(PidlToSicIndex(psfParent, pidlLast, !(flags & SHGFI_SMALLICON), > uGilFlags, &(psfi->iIcon)))) > @@ -769,33 +794,25 @@ DWORD_PTR WINAPI SHGetFileInfoA(LPCSTR path,DWORD dwFileAttributes, > pathW = temppath; > } > > - if (psfi && (flags & SHGFI_ATTR_SPECIFIED)) > - temppsfi.dwAttributes=psfi->dwAttributes; > + if (psfi) > + { > + temppsfi.hIcon = psfi->hIcon; > + temppsfi.iIcon = psfi->iIcon; > + temppsfi.dwAttributes = psfi->dwAttributes; > > - if (psfi == NULL) > - ret = SHGetFileInfoW(pathW, dwFileAttributes, NULL, 0, flags); > - else > ret = SHGetFileInfoW(pathW, dwFileAttributes, &temppsfi, sizeof(temppsfi), flags); > + psfi->hIcon = temppsfi.hIcon; > + psfi->iIcon = temppsfi.iIcon; > + psfi->dwAttributes = temppsfi.dwAttributes; > > - if (psfi) > - { > - if(flags & SHGFI_ICON) > - psfi->hIcon=temppsfi.hIcon; > - if(flags & (SHGFI_SYSICONINDEX|SHGFI_ICON|SHGFI_ICONLOCATION)) > - psfi->iIcon=temppsfi.iIcon; > - if(flags & SHGFI_ATTRIBUTES) > - psfi->dwAttributes=temppsfi.dwAttributes; > - if(flags & (SHGFI_DISPLAYNAME|SHGFI_ICONLOCATION)) > - { > - WideCharToMultiByte(CP_ACP, 0, temppsfi.szDisplayName, -1, > - psfi->szDisplayName, sizeof(psfi->szDisplayName), NULL, NULL); > - } > - if(flags & SHGFI_TYPENAME) > - { > - WideCharToMultiByte(CP_ACP, 0, temppsfi.szTypeName, -1, > - psfi->szTypeName, sizeof(psfi->szTypeName), NULL, NULL); > - } > + WideCharToMultiByte(CP_ACP, 0, temppsfi.szDisplayName, -1, > + psfi->szDisplayName, sizeof(psfi->szDisplayName), NULL, NULL); > + > + WideCharToMultiByte(CP_ACP, 0, temppsfi.szTypeName, -1, > + psfi->szTypeName, sizeof(psfi->szTypeName), NULL, NULL); > } > + else > + ret = SHGetFileInfoW(pathW, dwFileAttributes, NULL, 0, flags); > > HeapFree(GetProcessHeap(), 0, temppath); > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Re: [ros-dev] [ros-diffs] 01/01: [NTOS:KE] Replace "Fatal System Error" with "BugCheck"
by Alex Ionescu 11 Feb '18

11 Feb '18

This changes documented/external behavior. What is the point of this change? Best regards, Alex Ionescu On Wed, Feb 7, 2018 at 1:22 PM, Serge Gautherie <reactos-git_serge_171003(a)gautherie.fr> wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=6ece4e9fc22d664ea2485… > > commit 6ece4e9fc22d664ea2485d04303e8ae10047f21f > Author: Serge Gautherie <reactos-git_serge_171003(a)gautherie.fr> > AuthorDate: Wed Feb 7 06:29:02 2018 +0100 > Commit: Pierre Schweitzer <pierre(a)reactos.org> > CommitDate: Wed Feb 7 22:22:28 2018 +0100 > > [NTOS:KE] Replace "Fatal System Error" with "BugCheck" > --- > ntoskrnl/ke/bug.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/ntoskrnl/ke/bug.c b/ntoskrnl/ke/bug.c > index a92acb1bab..2127d7207c 100644 > --- a/ntoskrnl/ke/bug.c > +++ b/ntoskrnl/ke/bug.c > @@ -1070,8 +1070,8 @@ KeBugCheckWithTf(IN ULONG BugCheckCode, > if ((BugCheckCode != MANUALLY_INITIATED_CRASH) && (KdDebuggerEnabled)) > { > /* Crash on the debugger console */ > - DbgPrint("\n*** Fatal System Error: 0x%08lx\n" > - " (0x%p,0x%p,0x%p,0x%p)\n\n", > + DbgPrint("\n*** BugCheck: 0x%08lx\n" > + " (0x%p,0x%p,0x%p,0x%p)\n\n", > KiBugCheckData[0], > KiBugCheckData[1], > KiBugCheckData[2], >

4 4

Re: [ros-dev] Chemnitz Linux Tage, who will come by and support the booth?
by Daniel Reimer 11 Feb '18

11 Feb '18

Hello once more. Thanks for the single answer I got asking to take part. But I need one more booth supporter, preferred are team members. You have time till today evening to answer, otherwise I am not sure if I should blindly reply with the yes aka we will take part in CLT the team behind it is waiting for. In the end I reply and no one shows up. It is up to you. I got my holidays accepted last year already for being able to take part. What about the rest of the team who did not reply with a good reason not to take part already? Greetings Daniel Daniel Reimer <daniel.reimer(a)reactos.org> schrieb am Sa, 03.02.2018 14:54: > Hey guys, > > as every year, I need volunteers for the booth on Chemnitzer Linux Tage > (https://chemnitzer.linux-tage.de/2018/en). > > This year it's on March 10-11. Anyone who has some spare time for it? I > need at least two ppl for these days, otherwise I have to cancel it. > > Greetings > > Daniel > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

RFC: Change Rapps 'Size' field
by Mark Jansen 08 Feb '18

08 Feb '18

Hello, I'd like to propose a change for the 'Size' field: Currently this is a localized, pre-formatted field. By changing this to the actual size in bytes: - We can use StrFormatByteSizeW to format it locale dependent (without the need to manually translate it) - We can use this value to display the progress bar, in case the download itself does not provide this value (for example, web.archive does not provide this). For backwards compatibility we should probably add this as another field, so that the 'old' rapps can still read the 'Size' field. Regards, Mark

3 3

Chemnitz Linux Tage, who will come by and support the booth?
by Daniel Reimer 03 Feb '18

03 Feb '18

Hey guys, as every year, I need volunteers for the booth on Chemnitzer Linux Tage (https://chemnitzer.linux-tage.de/2018/en). This year it's on March 10-11. Anyone who has some spare time for it? I need at least two ppl for these days, otherwise I have to cancel it. Greetings Daniel

2 1

Dynamic libxml2/zlib
by Thomas Faber 03 Feb '18

03 Feb '18

Hey Amine, seeing https://jira.reactos.org/browse/CORE-14288 just prompted me to look into static vs dynamic 3rd party libraries, zlib and libxml2 in particular. We use zlib in a bunch of modules these days, and libxml2 is large and used in two, so I'm thinking we should make them dynamic. I just did the experiment for libxml2 and it resulted in at least 0.5MB binary size reduction and 2MB build folder size reduction, so clearly seems worth it.[1] I'll do the test for zlib as well to make sure that's also an improvement. However I was thinking there might be a reason why we build those statically right now. Do you (or anyone else) recall anything that makes switching to dynamic a bad idea? Thanks! -Thomas [1] Raw results: Static libxml2 (MSVC debug with RTC): msxml3.dll - 1887 KB libxslt.dll - 1142 KB libxml2.lib - 4953 KB (build dir only) Dynamic libxml2 (MSVC debug with RTC): msxml3.dll - 799 KB libxslt.dll - 259 KB libxml2.dll - 1592 KB libxml2.lib - 371 KB (build dir only) Static libxml2 (GCC debug with -O1): msxml3.dll - 3856 KB libxslt.dll - 2776 KB liblibxml2.a - 48 KB (build dir only) Dynamic libxml2 (GCC debug with -O1): msxml3.dll - 1505 KB libxslt.dll - 429 KB libxml2.dll - 2553 KB

2 1

Fwd: Re: [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225
by Erkin Alp Güney 22 Jan '18

22 Jan '18

Aka project Doors! > In the long term, we could leverage the power of Git and fork the WINE > repository on GitHub. We could then apply Wine-Staging patches and our > own changes to that repository. Syncing with upstream would now be > possible by merging commits instead of overwriting files. In the end, > DLLs from that repository could be blindly imported into the ReactOS > repo again. No more maintaining of "wininet_ros.diff" and the like > > I hope we can have a solution before branching for 0.4.8. Otherwise, > I suspect that we will lose many features of 0.4.7 and the recent > history. For instance, DXTn support just got enabled in ReactOS, but it > has always been based on Wine-Staging code. > > > As James used to say: WINE Is Not Enough!

1 0

Re: [ros-dev] [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225
by Ged Murphy 22 Jan '18

22 Jan '18

Is this really a sync up? It takes implemented functions are returns them to stubs -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of Amine Khaldi Sent: 21 January 2018 21:02 To: ros-diffs(a)reactos.org Subject: [ros-diffs] 01/01: [WTSAPI32] Sync with Wine 3.0. CORE-14225 https://git.reactos.org/?p=reactos.git;a=commitdiff;h=90f14ccef3d9d344b7021… commit 90f14ccef3d9d344b7021407b4c59a7234a19614 Author: Amine Khaldi <amine.khaldi(a)reactos.org> AuthorDate: Sun Jan 21 22:01:34 2018 +0100 Commit: Amine Khaldi <amine.khaldi(a)reactos.org> CommitDate: Sun Jan 21 22:01:34 2018 +0100 [WTSAPI32] Sync with Wine 3.0. CORE-14225 --- dll/win32/wtsapi32/wtsapi32.c | 95 ++++--------------------------------------- media/doc/README.WINE | 2 +- 2 files changed, 10 insertions(+), 87 deletions(-) diff --git a/dll/win32/wtsapi32/wtsapi32.c b/dll/win32/wtsapi32/wtsapi32.c index a7f4c873d9..92a7396f54 100644 --- a/dll/win32/wtsapi32/wtsapi32.c +++ b/dll/win32/wtsapi32/wtsapi32.c @@ -28,9 +28,6 @@ WINE_DEFAULT_DEBUG_CHANNEL(wtsapi); -/* FIXME: Inspect */ -#define GetCurrentProcessToken() ((HANDLE)~(ULONG_PTR)3) - /************************************************************ * WTSCloseServer (WTSAPI32.@) @@ -99,13 +96,8 @@ BOOL WINAPI WTSEnumerateProcessesA(HANDLE hServer, DWORD Reserved, DWORD Version BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD Reserved, DWORD Version, PWTS_PROCESS_INFOW* ppProcessInfo, DWORD* pCount) { - WTS_PROCESS_INFOW *processInfo; - SYSTEM_PROCESS_INFORMATION *spi; - ULONG size = 0x4000; - void *buf = NULL; - NTSTATUS status; - DWORD count; - WCHAR *name; + FIXME("Stub %p 0x%08x 0x%08x %p %p\n", hServer, Reserved, Version, + ppProcessInfo, pCount); if (!ppProcessInfo || !pCount || Reserved != 0 || Version != 1) { @@ -113,71 +105,9 @@ BOOL WINAPI WTSEnumerateProcessesW(HANDLE hServer, DWORD Reserved, DWORD Version return FALSE; } - if (hServer != WTS_CURRENT_SERVER_HANDLE) - { - SetLastError(ERROR_CALL_NOT_IMPLEMENTED); - return FALSE; - } - - do - { - size *= 2; - HeapFree(GetProcessHeap(), 0, buf); - buf = HeapAlloc(GetProcessHeap(), 0, size); - if (!buf) - { - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - status = NtQuerySystemInformation(SystemProcessInformation, buf, size, NULL); - } - while (status == STATUS_INFO_LENGTH_MISMATCH); - - if (status != STATUS_SUCCESS) - { - HeapFree(GetProcessHeap(), 0, buf); - SetLastError(RtlNtStatusToDosError(status)); - return FALSE; - } - - spi = buf; - count = size = 0; - for (;;) - { - size += sizeof(WTS_PROCESS_INFOW) + spi->ProcessName.Length + sizeof(WCHAR); - count++; - if (spi->NextEntryOffset == 0) break; - spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); - } - - processInfo = HeapAlloc(GetProcessHeap(), 0, size); - if (!processInfo) - { - HeapFree(GetProcessHeap(), 0, buf); - SetLastError(ERROR_OUTOFMEMORY); - return FALSE; - } - name = (WCHAR *)&processInfo[count]; - - *ppProcessInfo = processInfo; - *pCount = count; - - spi = buf; - while (count--) - { - processInfo->SessionId = 0; - processInfo->ProcessId = HandleToUlong(spi->UniqueProcessId); - processInfo->pProcessName = name; - processInfo->pUserSid = NULL; - memcpy( name, spi->ProcessName.Buffer, spi->ProcessName.Length ); - name[ spi->ProcessName.Length/sizeof(WCHAR) ] = 0; - - processInfo++; - name += (spi->ProcessName.Length + sizeof(WCHAR))/sizeof(WCHAR); - spi = (SYSTEM_PROCESS_INFORMATION *)(((PCHAR)spi) + spi->NextEntryOffset); - } + *pCount = 0; + *ppProcessInfo = NULL; - HeapFree(GetProcessHeap(), 0, buf); return TRUE; } @@ -241,7 +171,9 @@ BOOL WINAPI WTSEnumerateSessionsW(HANDLE hServer, DWORD Reserved, DWORD Version, */ void WINAPI WTSFreeMemory(PVOID pMemory) { - HeapFree(GetProcessHeap(), 0, pMemory); + static int once; + + if (!once++) FIXME("Stub %p\n", pMemory); } /************************************************************ @@ -314,16 +246,7 @@ BOOL WINAPI WTSQuerySessionInformationW( BOOL WINAPI WTSQueryUserToken(ULONG session_id, PHANDLE token) { FIXME("%u %p\n", session_id, token); - - if (!token) - { - SetLastError(ERROR_INVALID_PARAMETER); - return FALSE; - } - - return DuplicateHandle(GetCurrentProcess(), GetCurrentProcessToken(), - GetCurrentProcess(), token, - 0, FALSE, DUPLICATE_SAME_ACCESS); + return FALSE; } /************************************************************ @@ -357,7 +280,7 @@ BOOL WINAPI WTSRegisterSessionNotification(HWND hWnd, DWORD dwFlags) } /************************************************************ - * WTSRegisterSessionNotification (WTSAPI32.@) + * WTSRegisterSessionNotificationEx (WTSAPI32.@) */ BOOL WINAPI WTSRegisterSessionNotificationEx(HANDLE hServer, HWND hWnd, DWORD dwFlags) { diff --git a/media/doc/README.WINE b/media/doc/README.WINE index f366990215..69bf99b9c6 100644 --- a/media/doc/README.WINE +++ b/media/doc/README.WINE @@ -212,7 +212,7 @@ reactos/dll/win32/wmi # Synced to WineStaging-2.9 reactos/dll/win32/wmiutils # Synced to WineStaging-2.9 reactos/dll/win32/wmvcore # Synced to Wine-3.0 reactos/dll/win32/wshom.ocx # Synced to Wine-3.0 -reactos/dll/win32/wtsapi32 # Synced to WineStaging-2.9 +reactos/dll/win32/wtsapi32 # Synced to Wine-3.0 reactos/dll/win32/wuapi # Synced to WineStaging-2.9 reactos/dll/win32/xinput1_1 # Synced to WineStaging-2.9 reactos/dll/win32/xinput1_2 # Synced to WineStaging-2.9

2 1

Making bluescreens more useful
by Thomas Faber 14 Jan '18

14 Jan '18

We often get bug reports with just a screenshot of a bluescreen; we then go ahead and tell people that bluescreens are basically useless, they should get a debug log and a backtrace, and also remember to tell us what version they're using. Since there's actually no reason why bluescreens need to be useless, I thought I'd try to change that. I've attached an example. The source for this quick PoC can be found at https://github.com/ThFabba/reactos/commit/6a9f172b76bd11f763598c16e5d47299e… Thoughts?

12 16

Re: [ros-dev] Making bluescreens more useful
by Hermès BÉLUSCA - MAÏTO 13 Jan '18

13 Jan '18

2 1

First NT6+ application support in ReactOS
by Colin Finck 11 Jan '18

11 Jan '18

Hi all! Starting with build 0.4.8-dev-655-g63a3a2c, ReactOS has first support for NT6+ applications (aka programs written for Windows Vista, Windows 7, etc.). Please retest such applications under ReactOS! As newer Windows APIs are still missing in ReactOS, I would be surprised if a high number of NT6+ applications suddenly works. However, many applications may just be compiled by a new Visual Studio without using any modern APIs. They could work now. My "Hello World" compiled by VS 2017 v141 toolchain printed many messages about missing apiset DLLs in the debug log, but otherwise works well. So the next step should obviously be finishing and integrating Mark's work on the apiset DLLs in https://github.com/learn-more/reactos/commits/apisets But interestingly, the build produced by the v141_xp toolchain also looks for these apiset DLLs. Therefore, it would be possible that an application expects a full NT6 system when finding them. Consequently, application compatibility could be compromised if we just dump all apiset DLLs into ReactOS, applications now expect NT6, but the OS continues to behave like NT5 by default. This is why I suggest detecting an NT6+ application in ntdll to have it auto-apply a shim that lets ReactOS behave like an NT6 OS. The apiset DLLs should only be available in this mode, but not for the NT5 personality of ReactOS. Let's not import the apisets before the ntdll shim work is done in order to preserve our existing application compatibility. Cheers, Colin

4 3

Someone's suggestion on IRC about adapting the PS4 linux loading to boot ReactOS
by David Quintana (gigaherz) 10 Jan '18

10 Jan '18

Quoting directly from IRC: [18:22] (Figarocool): hi! [18:23] (Figarocool): is someone online? [18:23] (@gigaherz): yes [18:23] (Figarocool): you a developer? [18:24] (Figarocool): a loader was developed for a few days to load linux on ps4 [18:24] (Figarocool): https://github.com/fail0verflow/ps4-linux [18:25] (Figarocool): would it be possible to port this to start rectos? it would be something of great visibility for the reactos project [18:25] (Figarocool): loader [18:25] (Figarocool): https://github.com/valentinbreiz/PS4-Linux-Loader [18:25] (Figarocool): on firmware 4.05 [18:25] (Figarocool): ps4 runs on x86 [18:26] (Figarocool): would it be complicated to do this for you? [18:26] (@gigaherz): I don't own a ps4 and I'm not an expert in the reactos booting process, so I'm not the right person to ask [18:27] (Figarocool): could you open a discussion about this? [18:28] (@gigaherz): well this is IRC, just talking about it is already a discussion [18:28] (@gigaherz): but if you want something more "official" [18:28] (@gigaherz): you can post this information on an email to the ros-dev mailing list [18:28] (@gigaherz): (subscribe to the mailing list if you want to see the replies) [18:29] (Thedarkb1): You probably could. [18:33] (CatButts): hmmm [18:33] (CatButts): unlike PC, PS4 is single hardware configuration [18:33] (CatButts): getting ReactOS on a PS4? hmmm, that wouldn't hurt [18:34] (CatButts): [19:25] <Figarocool> it would be something of great visibility for the reactos project [18:34] (Figarocool): check: https://github.com/valentinbreiz/PS4-Linux-Loader [18:34] (Figarocool): loader to load linux (x86) and driver [18:35] (Figarocool): however, since reactos and open would be a great novelty for the knowledge of the os [18:35] (Figarocool): so it could give a lot of novelties in the media aspect [18:35] (Figarocool): you could think about it [18:36] (@gigaherz): the loading process of NT is very different from linux [18:36] (@gigaherz): but as I said, because I'm not the right person to ask [18:36] (@gigaherz): it would be best if you put the information on the mailing list [18:36] (@gigaherz): for all the people interested to read [18:36] (Figarocool): could you open the discussion on the mail? [18:37] (@gigaherz): I think it would be best if someone who is actually interested in it would do so [18:38] (Figarocool): I also say this because of the media aspect [18:39] (Figarocool): since they are now installing linux to use the console as a PC [18:39] (Figarocool): this would be great using reactos [18:39] (Figarocool): being x86 all windows games and more would be compatible

1 0

Re: [ros-dev] RAPPS Database now maintained in https://github.com/reactos/rapps-db
by hermes.belusca＠sfr.fr 08 Jan '18

08 Jan '18

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">Talking of which, what's the status of Victor's website for RAPPS submissions?<br> <br> H.‌</span> <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : gigaherz(a)gmail.com<br> A : ros-dev(a)reactos.org<br> Envoyé: lundi 8 janvier 2018 18:28<br> Objet : Re: [ros-dev] RAPPS Database now maintained in https://github.com/reactos/rapps-db<br>   <div class="gl_quoted"> <div dir="ltr"> <div>\o/ awesome!<br>  </div> It would be more awesome to have a crowdsourced (moderated) compatibility database to generate these from, but until that's done, this is a really good addition.</div> <div class="gmail_extra">  <div class="gmail_quote">On 8 January 2018 at 18:15, Colin Finck <span dir="ltr"><<a href="mailto:colin@reactos.org" target="_blank">colin(a)reactos.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all!<br> <br> We all wanted the RAPPS Database to leave the main source tree for a<br> long time. When Alexander Shaposhnikov asked me today if it was possible<br> to regenerate the rappmgr.cab on every commit, I took the opportunity<br> and split off the /media/rapps folder (including all history) into its<br> own repository: <a href="https://github.com/reactos/rapps-db" rel="noreferrer" target="_blank">https://github.com/reactos/<wbr>rapps-db</a><br> <br> As a bonus, the public database at<br> <a href="https://svn.reactos.org/packages/rappmgr.cab" rel="noreferrer" target="_blank">https://svn.reactos.org/<wbr>packages/rappmgr.cab</a> is now automatically<br> updated with every commit to that repository.<br> <br> I hope you'll like that change :)<br> <br> <br> Cheers,<br> <br> Colin<br> <br> ______________________________<wbr>_________________<br> Ros-dev mailing list<br> <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> <a href="http://www.reactos.org/mailman/listinfo/ros-dev" rel="noreferrer" target="_blank">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a></blockquote> </div> </div> <br> <br> <br> _______________________________________________<br> Ros-dev mailing list<br> Ros-dev(a)reactos.org<br> http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

2 1

RAPPS Database now maintained in https://github.com/reactos/rapps-db
by Colin Finck 08 Jan '18

08 Jan '18

Hi all! We all wanted the RAPPS Database to leave the main source tree for a long time. When Alexander Shaposhnikov asked me today if it was possible to regenerate the rappmgr.cab on every commit, I took the opportunity and split off the /media/rapps folder (including all history) into its own repository: https://github.com/reactos/rapps-db As a bonus, the public database at https://svn.reactos.org/packages/rappmgr.cab is now automatically updated with every commit to that repository. I hope you'll like that change :) Cheers, Colin

2 1

Project-tools repository converted to Git - Welcome our 18 new repos!
by Colin Finck 08 Jan '18

08 Jan '18

Hi all, I just finished converting our "project-tools" SVN repo to Git and splitting it up into individual repositories in the process. These repos have already been uploaded to GitHub (https://github.com/reactos), so you can have a look and comment easily. Welcome these 18 new repositories: * ahk_tests * buildbot_config * git-tools * irc * Message_Translator * monitoring * packmgr (Archived) * project-tools-archive (Archived) * Qemu_GUI * reactosdbg * Release_Engineering * RosBE * rosev_ircsystem * rosev_jameicaplugin * RosTE * sysreg2 * sysreg3 (Archived) * vmwaregateway I haven't given anyone write access yet. I think this is acceptable for the moment while we check if there are any outstanding issues with the conversion. Please let me know until January 7. If everything is okay by then, I will add write access again and officially move development away from the project-tools SVN repo. Have a good start into 2018! Colin

3 4

[ros-diffs] [reactos] 01/02: [PSDK] Fix definition of INVALID_PROCESSTRACE_HANDLE as suggested by Thomas. #267
by James Tabor 08 Jan '18

08 Jan '18

Just curious, why does that just look so wrong to me....... https://git.reactos.org/?p=reactos.git;a=commitdiff;h=e3459ec36ecd783d67c27… commit e3459ec36ecd783d67c27dac4e81ad9facc08605 Author: Mark Jansen <mark.jansen at reactos.org <http://www.reactos.org/mailman/listinfo/ros-diffs>> AuthorDate: Sat Jan 6 21:09:51 2018 +0100 [PSDK] Fix definition of INVALID_PROCESSTRACE_HANDLE as suggested by Thomas. #267 --- sdk/include/psdk/evntrace.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sdk/include/psdk/evntrace.h b/sdk/include/psdk/evntrace.h index dbbc660963..7056f119fa 100644 --- a/sdk/include/psdk/evntrace.h +++ b/sdk/include/psdk/evntrace.h @@ -711,7 +711,7 @@ typedef struct _ENABLE_TRACE_PARAMETERS { PEVENT_FILTER_DESCRIPTOR EnableFilterDesc; } ENABLE_TRACE_PARAMETERS, *PENABLE_TRACE_PARAMETERS; -#define INVALID_PROCESSTRACE_HANDLE ((TRACEHANDLE)INVALID_HANDLE_VALUE) +#define INVALID_PROCESSTRACE_HANDLE ((TRACEHANDLE)(ULONG_PTR)INVALID_HANDLE_VALUE) #if defined(UNICODE) || defined(_UNICODE) >From W7U SDK rc: sdkinc.v7rc/Evntrace.h:93:typedef ULONG64 TRACEHANDLE, *PTRACEHANDLE; sdkinc.v7rc/Evntrace.h:1500:#define INVALID_PROCESSTRACE_HANDLE ((TRACEHANDLE)INVALID_HANDLE_VALUE) Did this break three of the build bots?

2 1

*PREVIEW* : ReactOS 1st-stage GUI installer testing on Windows
by Hermès BÉLUSCA-MAÏTO 07 Jan '18

07 Jan '18

Hello everyone, Lately I was continuing working on my setup_improvements branch: https://github.com/HBelusca/reactos/commits/setup_improvements (whose main purpose, I recall, is to share a maximum of installation code between our working 1st-stage text-mode usetup and our 1st-stage GUI-mode reactos.exe setup that needs to be implemented). The last results of this is that I am now able to install ReactOS files to a user-provided directory using the GUI-mode setup! As Im developing under Windows I tested the file-copying part of the installer (which is, at the time of writing, the latest part of installation code I has been able to share between the two installers) on Windows. You can see the demo here: https://i.imgur.com/xF97hv1.gifv The animated gif also demonstrates the capability of the installer to halt file copying if the user pops the installation-cancel confirmation dialog out; file-copying is resumed when the user does not want to cancel the installation, but it is stopped when the user really cancels the installation. And of course, the file-copying status is displayed with an animated progress-bar. I have worked out a bit the wizard transitions, but some work remains to be done, especially for the partitioning step (currently Im hardcoding in the GUI installer the disk & partition where I want the copy to take place). One can note in the animation that the preparation of the list of files to be copied seems to take a while: indeed, the shared installation code works exclusively with NT paths. However, when this shared code is used in the win32 GUI-mode installer, this code calls inside setupapi.dll functions to manage the installation file queue (in usetup on the contrary, it uses instead a file queue implementation that works directly with NT paths). As a consequence, I need to convert the NT paths back to Win32 ones before feeding them into the setupapi functions, and this is not trivial. I want to improve this conversion by caching some of the computed results. Enjoy! Best regards, Hermès P.S.: Please dont put that on Twitter since this is under heavy work-in-progress and this demo hasnt been done under ReactOS at all.

1 0

Creative sound cards drivers
by Javier Agustìn Fernàndez Arroyo 04 Jan '18

04 Jan '18

hwy guys, did you hear about this? Maybe toese can be included with ReactOS, they are open source! https://github.com/kxproject http://kxproject.com/index.php?language=en

1 0

Postponing December Status Meeting
by Colin Finck 04 Jan '18

04 Jan '18

Hi all! If we follow our usual schedule, the December Status Meeting would be today. With such a late announcement and many people still on holidays, I suggest postponing it to next Thursday, January 4, 2018. Time will be 19:00 UTC as always. I already asked on #reactos-dev and got some approvals, so consider this the official meeting invitation :) This also gives you one week from now for agenda proposals. Additionally, we have got some new contributors in the recent months. If you think you should join the meeting or know somebody who should join, please let me know in advance. See you all next year! Colin

1 1

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [SETUP] Remove FSDs which have broken dismount implementation. This avoids issues when these partitions are formatted to FAT for setup.
by 7th Element 18 Dec '17

18 Dec '17

Hi Pierre, Isn’t this change going to remove ability to boot from those FSs? BR, Peter > On 18 Dec 2017, at 0:16, Pierre Schweitzer <pierre(a)reactos.org> wrote: > > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=806cd16328799771b8939… > > commit 806cd16328799771b89397f5c51a3d46884bce0a > Author: Pierre Schweitzer <pierre(a)reactos.org> > AuthorDate: Sun Dec 17 23:13:56 2017 +0100 > > [SETUP] Remove FSDs which have broken dismount implementation. > This avoids issues when these partitions are formatted to FAT for setup. > > For now, this commit doesn't change anything, but once IopParseDevice hack > gets removed, this will make a difference! > > CORE-6305 > --- > boot/bootdata/txtsetup.sif | 2 -- > drivers/filesystems/btrfs/CMakeLists.txt | 2 +- > drivers/filesystems/ntfs/CMakeLists.txt | 2 +- > 3 files changed, 2 insertions(+), 4 deletions(-) > > diff --git a/boot/bootdata/txtsetup.sif b/boot/bootdata/txtsetup.sif > index 3ea62974b5..822c19c8c8 100644 > --- a/boot/bootdata/txtsetup.sif > +++ b/boot/bootdata/txtsetup.sif > @@ -52,7 +52,6 @@ usbstor.sys=,,,,,,x,,,,,,4 > kbdhid.sys=,,,,,,,,,,,,4 > kbdclass.sys=,,,,,,x,,,,,,4 > l_intl.nls=,,,,,,,,,,,,2 > -ntfs.sys=,,,,,,,,,,,,4 > pci.sys=,,,,,,,,,,,,4 > scsiport.sys=,,,,,,x,,,,,,4 > storport.sys=,,,,,,x,,,,,,4 > @@ -69,7 +68,6 @@ ntdll.dll=,,,,,,,,,,,,2 > wmilib.sys=,,,,,,,,,,,,4 > ksecdd.sys=,,,,,,,,,,,,4 > mountmgr.sys=,,,,,,x,,,,,,4 > -btrfs.sys=,,,,,,x,,,,,,4 > reiserfs.sys=,,,,,,x,,,,,,4 > ffs.sys=,,,,,,x,,,,,,4 > udfs.sys=,,,,,,x,,,,,,4 > diff --git a/drivers/filesystems/btrfs/CMakeLists.txt b/drivers/filesystems/btrfs/CMakeLists.txt > index 65e61d255a..123c9f0522 100644 > --- a/drivers/filesystems/btrfs/CMakeLists.txt > +++ b/drivers/filesystems/btrfs/CMakeLists.txt > @@ -41,4 +41,4 @@ add_definitions(-D__KERNEL__) > set_module_type(btrfs kernelmodedriver) > target_link_libraries(btrfs rtlver ntoskrnl_vista zlib_solo wdmguid ${PSEH_LIB}) > add_importlibs(btrfs ntoskrnl hal) > -add_cd_file(TARGET btrfs DESTINATION reactos/system32/drivers NO_CAB FOR all) > +add_cd_file(TARGET btrfs DESTINATION reactos/system32/drivers FOR all) > diff --git a/drivers/filesystems/ntfs/CMakeLists.txt b/drivers/filesystems/ntfs/CMakeLists.txt > index 0b1af78947..5a193b449d 100644 > --- a/drivers/filesystems/ntfs/CMakeLists.txt > +++ b/drivers/filesystems/ntfs/CMakeLists.txt > @@ -25,4 +25,4 @@ set_module_type(ntfs kernelmodedriver) > target_link_libraries(ntfs ${PSEH_LIB}) > add_importlibs(ntfs ntoskrnl hal) > add_pch(ntfs ntfs.h SOURCE) > -add_cd_file(TARGET ntfs DESTINATION reactos/system32/drivers NO_CAB FOR all) > +add_cd_file(TARGET ntfs DESTINATION reactos/system32/drivers FOR all) > >

3 8

Small suggestion for the abandoned SVN mirror on GitHub
by Dmitry D. Chernov 17 Dec '17

17 Dec '17

Good day everyone. I'm talking about this repo: https://github.com/reactos/reactos-deprecated-gitsvn-dont-use To prevent pull-requesting to it I suggest to use new GitHub feature "archive this repository". To enable it, just open the "Settings" page and go to the bottom. "Archived" repos are marked as read-only and could not be pull-requested. It's also would be nice to disable unused "Projects" tab in this repo for the great justice of perfectionism. ___ Dmitry D. Chernov

4 5

ReactOS 0.4.7 to be released tomorrow, 6th December 2017 - Press Kit is online!
by Colin Finck 17 Dec '17

17 Dec '17

Hi all! With all release preparations done, we can finally give a release date for ReactOS 0.4.7: Tomorrow, Wednesday, 6th December 2017. During that day (European time), the release will be published. A Press Kit for ReactOS 0.4.7 is already available: https://sourceforge.net/projects/reactos/files/ReactOS/0.4.7/ReactOS-0.4.7-… Feel free to send it to interested parties to let them know about the upcoming release in advance. Best regards, Colin Finck

4 4

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [NTOS:MM] Fix NtFreeVirtualMemory() FreeType parameter checks. CORE-13126
by Alex Ionescu 16 Dec '17

16 Dec '17

I'm unsure how reducing the two explicit checks into a single one is a better decision. This is much less scalable and much less clear of what the caller did wrong. I'd like to see the old checks (correctly) restored. Best regards, Alex Ionescu On Fri, Dec 15, 2017 at 2:58 AM, Serge Gautherie < reactos-git_serge_171003(a)gautherie.fr> wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h= > 614ace03fa4ec1957f32727ab0975a98c858894d > > commit 614ace03fa4ec1957f32727ab0975a98c858894d > Author: Serge Gautherie <reactos-git_serge_171003(a)gautherie.fr> > AuthorDate: Sat Dec 9 12:16:44 2017 +0100 > > [NTOS:MM] Fix NtFreeVirtualMemory() FreeType parameter checks. > CORE-13126 > --- > ntoskrnl/mm/ARM3/virtual.c | 20 +++++--------------- > 1 file changed, 5 insertions(+), 15 deletions(-) > > diff --git a/ntoskrnl/mm/ARM3/virtual.c b/ntoskrnl/mm/ARM3/virtual.c > index 0e5fe77a23..fc4ea2e6d2 100644 > --- a/ntoskrnl/mm/ARM3/virtual.c > +++ b/ntoskrnl/mm/ARM3/virtual.c > @@ -5108,21 +5108,11 @@ NtFreeVirtualMemory(IN HANDLE ProcessHandle, > PAGED_CODE(); > > // > - // Only two flags are supported > + // Only two flags are supported, exclusively. > // > - if (!(FreeType & (MEM_RELEASE | MEM_DECOMMIT))) > + if (FreeType != MEM_RELEASE && FreeType != MEM_DECOMMIT) > { > - DPRINT1("Invalid FreeType\n"); > - return STATUS_INVALID_PARAMETER_4; > - } > - > - // > - // Check if no flag was used, or if both flags were used > - // > - if (!((FreeType & (MEM_DECOMMIT | MEM_RELEASE))) || > - ((FreeType & (MEM_DECOMMIT | MEM_RELEASE)) == (MEM_DECOMMIT | > MEM_RELEASE))) > - { > - DPRINT1("Invalid FreeType combination\n"); > + DPRINT1("Invalid FreeType (0x%08lx)\n", FreeType); > return STATUS_INVALID_PARAMETER_4; > } > > @@ -5200,8 +5190,8 @@ NtFreeVirtualMemory(IN HANDLE ProcessHandle, > } > } > > - DPRINT("NtFreeVirtualMemory: Process 0x%p, Adress 0x%p, size 0x%x, > FreeType %x.\n", > - Process, PBaseAddress, PRegionSize, FreeType); > + DPRINT("NtFreeVirtualMemory: Process 0x%p, Address 0x%p, Size 0x%Ix, > FreeType 0x%08lx\n", > + Process, PBaseAddress, PRegionSize, FreeType); > > // > // Lock the address space > >

1 0

[ros-diffs] [reactos] 01/01: [SDK] pnp.idl: Add a reminder comment about removed Vista/+ functions. CORE-12580
by James Tabor 15 Dec '17

15 Dec '17

Hi, Let's try not removing (ZAPPING) API due to future use okay? Just #if it out with the correct __NTZYX__ thing. So if I wish to have VISTA or Server 201X, I can select it while running the configuration script. Do it this way so someone could select Server 2003 (Default now) later on. Same or better TEAM! Think about what will be needed later on. ZAPPING OUT! James

1 0

PineappleFund
by Alexander Shaposhnikov 14 Dec '17

14 Dec '17

Hi all! Recenly a new Reddit post came up on #reactos IRC: https://redd.it/7jj0oa. Interesting stuff. A person is giving away ~5000 BTC for charitable causes. We can apply via the website but it must be done by someone from ReactOS e.V. -- Cheers, Alexander Shaposhnikov

9 11

Merging our x86 HALs
by Colin Finck 14 Dec '17

14 Dec '17

Hi all, I have been looking into our HALs recently on the promise that it is a huge mess that needs fixing. Well, as a start I could imagine merging our 6 possible x86 HALs (Legacy, ACPI, APIC, ACPI+APIC, SMP, SMP+ACPI) into a single one, even if Windows ships individual ones. I see many advantages of that: * Less duplications and reduced mess: Right now, the APIC HAL hangs at HalpCalibrateStallExecution during boot, a function that has been fixed and universally implemented in all non-APIC HALs. The APIC HAL also duplicates HalpInitializePICs as HalpInitializeLegacyPIC. If you look at the SMP code, it didn't even receive the last build system changes and has conflicting implementations for APIC functions. A single x86 HAL would ensure that all possible configurations are maintained. * Future-proof: How is one going to implement newer features like x2APIC with a structure like that? Would it get another HAL, be integrated into the APIC HAL, or what? We wouldn't have such problems with a single x86 HAL. * Less setup work and testing: Currently, 1st stage setup detects the computer type and installs the appropriate HAL. As such, every additional HAL needs to be added to 1st stage setup code. The user is also able to select a custom HAL during setup, even if it wouldn't work on the machine. We should give neither the user nor the setup the ability to decide. The HAL itself knows best at boot-up what features to enable and what not. * Convenience: The same ReactOS installation could be used on several different x86 computers. So is this the way to go or do I miss something important? Best regards, Colin

4 8

Re: [ros-dev] Merging our x86 HALs
by Alex Ionescu 14 Dec '17

14 Dec '17

I would move to the Win8+ HAL Model -- a single HAL for APIC, ACPI with runtime support for UEFI (if present) and MP (if present). If people still want to run on a PIC VM (why???) or old computer, then we can also maintain the HAL PIC x86 for UP. Hence there would only be 2 HALs. Best regards, Alex Ionescu On Mon, Dec 11, 2017 at 1:07 AM, Colin Finck <colin(a)reactos.org> wrote: > Am 11.12.2017 um 01:18 schrieb Hermès BÉLUSCA-MAÏTO:> If you basically > put all the HALs into one, then you obtain bloated stuff (which remains > in memory for the whole life of the OS). Example: standard HAL is 1MB > vs. ACPI HAL which is few kBHave you actually checked what makes up this > difference? > Hint: hal/halx86/legacy/bus/pci_vendors.ids > > > > Note that if Windows nowadays has only one hal, it's because they now > support basically only one "architecture"/platform, namely, ACPI > multiprocessor (to put it simple). It has its pros, but also a lot of cons. > > That doesn't mean we need to do the same. We can have one HAL for all > (Pentium and newer) x86 platforms. The overhead of additional checks at > boot-up is negligible. That should be a solution for 99% of the people > out there. The rest may still go and trim down our HAL to their needs. > > But let's not pretend we can maintain multiple x86 HALs for all x86 > computers out there. Do you really want to test X HALs with Y different > systems? Ensure that a legacy HAL runs on a modern ACPI system? What > would be the point? > > > > Besides this, I've a question about your observation that in the APIC > hal (not ACPI) there's different implementation of > HalpCalibrateStallExecution and HalpInitializePICs / > HalpInitializeLegacyPIC . Isn't it precisely because these stuff are > completely different from the standard PICs used in platforms for which the > standard HAL (and possibly the ACPI HAL) are used? > > Absolutely not! You need to reprogram the standard PICs also on an APIC > system, and this is precisely what both functions do. Put them into a > diff tool to see for yourself. > > The same goes for timers. Even with the introduction of ACPI Timers, > Local APIC Timers, and Time-Stamp Counters, you still need a traditional > one (like RTC or PIT) for calibration at system startup. Simply because > the newer ones don't run at a known fixed frequency. > The Legacy HAL successfully employs an algorithm based on the RTC while > the APIC HAL unsuccessfully tries to use the PIT. > > > > Actually we should, because the detection might not work (of course in > our simple case "ACPI UP/MP" vs. "Standard", it's simple, but think about > other platforms where there can be subtle differences) > > Tell me about a single one we cannot detect and which is worth to > support. I don't recall that we ever recommended our testers to choose a > different HAL at setup. > > > > And normally it's not the setup that decides about the HAL, but the > bootloader. > > That defies your previous point about the setup initializing the > registry depending on the HAL. > If we can let the user select a Legacy HAL in the boot loader after > installing with an ACPI HAL, it is also technically possible to have one > HAL that encompasses both. > > > - Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

9 15

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [UUID] Add a PCH.
by Thomas Faber 09 Dec '17

09 Dec '17

I'm a bit surprised that this works. Don't we have those big "don't use the PCH for this file" warnings in every guid.c? This library consists only of guid.c's :p On 2017-12-09 13:04, Amine Khaldi wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=69005963fb4b1378f6a66… > > commit 69005963fb4b1378f6a666c2b8b2483c222740f8 > Author: Amine Khaldi <amine.khaldi(a)reactos.org> > AuthorDate: Sat Dec 9 13:04:23 2017 +0100 > > [UUID] Add a PCH. > --- > sdk/lib/uuid/CMakeLists.txt | 4 +++- > sdk/lib/uuid/precomp.h | 10 ++++++++++ > 2 files changed, 13 insertions(+), 1 deletion(-) > > diff --git a/sdk/lib/uuid/CMakeLists.txt b/sdk/lib/uuid/CMakeLists.txt > index d99bc73a35..09efcd927f 100644 > --- a/sdk/lib/uuid/CMakeLists.txt > +++ b/sdk/lib/uuid/CMakeLists.txt > @@ -219,7 +219,9 @@ list(APPEND SOURCE > # vcguids.c > wdmguids.c > otherguids.c > - undoc.c) > + undoc.c > + precomp.h) > > add_library(uuid ${SOURCE}) > +add_pch(uuid precomp.h SOURCE) > add_dependencies(uuid psdk) > diff --git a/sdk/lib/uuid/precomp.h b/sdk/lib/uuid/precomp.h > new file mode 100644 > index 0000000000..abe35fac5e > --- /dev/null > +++ b/sdk/lib/uuid/precomp.h > @@ -0,0 +1,10 @@ > +#ifndef _UUID_PRECOMP_H_ > +#define _UUID_PRECOMP_H_ > + > +#define WIN32_NO_STATUS > +#define WIN32_LEAN_AND_MEAN > + > +#include <rpc.h> > +#include <rpcndr.h> > + > +#endif /* _UUID_PRECOMP_H_ */ >

1 0

Re: [ros-dev] AHK Bot maintenance in progress
by Sylvain Petreolle 02 Dec '17

02 Dec '17

Test KVM AHK is back on its feet. After a fight with the package update manager (bug in dnf) and a problem with the primary monitor setting,its building and testing the last push from AmineKhaldi Kind regards, Sylvain Petreolle Le Mardi 28 novembre 2017 23h06, Sylvain Petreolle <spetreolle(a)yahoo.fr> a écrit : The AHK bot crashes often these days. I uploaded a crash dump to Fedora and discovered that these crashes are due to the network emulation (SLIRP) used in KVM. For reference, here is the opened issue : https://bugzilla.redhat.com/show_bug.cgi?id=1509589 Since bugs with previous versions of Fedora take time to be resolved, I'm upgrading the bot to Fedora 27. Ideas to overcome the SLIRP problems are welcome. After all, if it crashes the virtual machine, it could also be at the source of other problems. The AHK tests show randomness in the tests that require network,related to nonblocking mode not working, but it could involve KVM too. Kind regards, Sylvain Petreolle

1 0

Status Meeting (November 2017)
by Colin Finck 30 Nov '17

30 Nov '17

Hi all! Let me invite you to the monthly status meeting taking place tomorrow, November 29, 19:00 UTC. As always, you will get credentials for our private IRC server shortly before the meeting. No agenda proposals have been submitted to me so far. If that doesn't change, we may have a short meeting just for status reports. Please have them ready, so we get it done quickly! FYI, I expect the 0.4.7 Press Release to be ready tomorrow, so we can soon send out the Press Kit and make the downloads available. See you tomorrow! Colin

2 2

AHK Bot maintenance in progress
by Sylvain Petreolle 28 Nov '17

28 Nov '17

The AHK bot crashes often these days. I uploaded a crash dump to Fedora and discovered that these crashes are due to the network emulation (SLIRP) used in KVM. For reference, here is the opened issue : https://bugzilla.redhat.com/show_bug.cgi?id=1509589 Since bugs with previous versions of Fedora take time to be resolved, I'm upgrading the bot to Fedora 27. Ideas to overcome the SLIRP problems are welcome. After all, if it crashes the virtual machine, it could also be at the source of other problems. The AHK tests show randomness in the tests that require network,related to nonblocking mode not working, but it could involve KVM too. Kind regards, Sylvain Petreolle

1 0

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [FASTFAT_NEW] This is not permitted by WDK license. We should rather import from MS GitHub and backport to NT5.2.
by Alex Ionescu 25 Nov '17

25 Nov '17

XP did not have a WDK. Did you mean XP IFS? Best regards, Alex Ionescu On Thu, Nov 23, 2017 at 4:04 AM, Pierre Schweitzer <pierre(a)reactos.org> wrote: > https://git.reactos.org/?p=reactos.git;a=commitdiff;h= > a913501626e599fba9d702149896f36046832deb > > commit a913501626e599fba9d702149896f36046832deb > Author: Pierre Schweitzer <pierre(a)reactos.org> > AuthorDate: Thu Nov 23 15:04:05 2017 +0100 > > [FASTFAT_NEW] This is not permitted by WDK license. > We should rather import from MS GitHub and backport to NT5.2. > --- > drivers/filesystems/fastfat_new/CMakeLists.txt | 44 - > drivers/filesystems/fastfat_new/acchksup.c | 374 -- > drivers/filesystems/fastfat_new/allocsup.c | 5001 ------------------ > drivers/filesystems/fastfat_new/cachesup.c | 1814 ------- > drivers/filesystems/fastfat_new/cleanup.c | 1027 ---- > drivers/filesystems/fastfat_new/close.c | 1224 ----- > drivers/filesystems/fastfat_new/create.c | 5684 > -------------------- > drivers/filesystems/fastfat_new/devctrl.c | 308 -- > drivers/filesystems/fastfat_new/deviosup.c | 3284 ------------ > drivers/filesystems/fastfat_new/dirctrl.c | 1526 ------ > drivers/filesystems/fastfat_new/dirsup.c | 3647 ------------- > drivers/filesystems/fastfat_new/dumpsup.c | 381 -- > drivers/filesystems/fastfat_new/ea.c | 2013 ------- > drivers/filesystems/fastfat_new/easup.c | 3811 -------------- > drivers/filesystems/fastfat_new/fastfat.rc | 5 - > drivers/filesystems/fastfat_new/fat.h | 729 --- > drivers/filesystems/fastfat_new/fatdata.c | 1424 ----- > drivers/filesystems/fastfat_new/fatdata.h | 328 -- > drivers/filesystems/fastfat_new/fatinit.c | 675 --- > drivers/filesystems/fastfat_new/fatprocs.h | 2817 ---------- > drivers/filesystems/fastfat_new/fatprocssrc.c | 1 - > drivers/filesystems/fastfat_new/fatstruc.h | 1614 ------ > drivers/filesystems/fastfat_new/fileinfo.c | 4635 ---------------- > drivers/filesystems/fastfat_new/filobsup.c | 547 -- > drivers/filesystems/fastfat_new/flush.c | 1261 ----- > drivers/filesystems/fastfat_new/fsctrl.c | 6726 > ------------------------ > drivers/filesystems/fastfat_new/fspdisp.c | 472 -- > drivers/filesystems/fastfat_new/lfn.h | 56 - > drivers/filesystems/fastfat_new/lockctrl.c | 726 --- > drivers/filesystems/fastfat_new/namesup.c | 1021 ---- > drivers/filesystems/fastfat_new/nodetype.h | 193 - > drivers/filesystems/fastfat_new/pnp.c | 815 --- > drivers/filesystems/fastfat_new/read.c | 1649 ------ > drivers/filesystems/fastfat_new/resrcsup.c | 807 --- > drivers/filesystems/fastfat_new/shutdown.c | 304 -- > drivers/filesystems/fastfat_new/sources | 45 - > drivers/filesystems/fastfat_new/splaysup.c | 504 -- > drivers/filesystems/fastfat_new/strucsup.c | 3626 ------------- > drivers/filesystems/fastfat_new/timesup.c | 364 -- > drivers/filesystems/fastfat_new/verfysup.c | 1853 ------- > drivers/filesystems/fastfat_new/volinfo.c | 1272 ----- > drivers/filesystems/fastfat_new/workque.c | 362 -- > drivers/filesystems/fastfat_new/write.c | 2830 ---------- > 43 files changed, 67799 deletions(-) > > diff --git a/drivers/filesystems/fastfat_new/CMakeLists.txt > b/drivers/filesystems/fastfat_new/CMakeLists.txt > deleted file mode 100644 > index f21d829e63..0000000000 > --- a/drivers/filesystems/fastfat_new/CMakeLists.txt > +++ /dev/null > @@ -1,44 +0,0 @@ > - > -list(APPEND SOURCE > - acchksup.c > - allocsup.c > - cachesup.c > - cleanup.c > - close.c > - create.c > - devctrl.c > - deviosup.c > - dirctrl.c > - dirsup.c > - dumpsup.c > - ea.c > - easup.c > - fatdata.c > - fatinit.c > - fatprocssrc.c > - fileinfo.c > - filobsup.c > - flush.c > - fsctrl.c > - fspdisp.c > - lockctrl.c > - namesup.c > - pnp.c > - read.c > - resrcsup.c > - shutdown.c > - splaysup.c > - strucsup.c > - timesup.c > - verfysup.c > - volinfo.c > - workque.c > - write.c > - fatprocs.h) > - > -add_library(fastfat SHARED ${SOURCE} fastfat.rc) > -set_module_type(fastfat kernelmodedriver) > -target_link_libraries(fastfat ${PSEH_LIB} memcmp) > -add_importlibs(fastfat ntoskrnl hal) > -add_pch(fastfat fatprocs.h SOURCE) > -add_cd_file(TARGET fastfat DESTINATION reactos/system32/drivers NO_CAB > FOR all) > diff --git a/drivers/filesystems/fastfat_new/acchksup.c > b/drivers/filesystems/fastfat_new/acchksup.c > deleted file mode 100644 > index b0c78a81a4..0000000000 > --- a/drivers/filesystems/fastfat_new/acchksup.c > +++ /dev/null > @@ -1,374 +0,0 @@ > -/*++ > - > -Copyright (c) 1989-2000 Microsoft Corporation > - > -Module Name: > - > - AcChkSup.c > - > -Abstract: > - > - This module implements the FAT access checking routine > - > - > ---*/ > - > -#include "fatprocs.h" > - > -// > -// Our debug trace level > -// > - > -#define Dbg (DEBUG_TRACE_ACCHKSUP) > - > -NTSTATUS > -FatCreateRestrictEveryoneToken( > - IN PACCESS_TOKEN Token, > - OUT PACCESS_TOKEN *RestrictedToken > - ); > - > -#ifdef ALLOC_PRAGMA > -#pragma alloc_text(PAGE, FatCheckFileAccess) > -#pragma alloc_text(PAGE, FatCreateRestrictEveryoneToken) > -#pragma alloc_text(PAGE, FatExplicitDeviceAccessGranted) > -#endif > - > - > -BOOLEAN > -FatCheckFileAccess ( > - PIRP_CONTEXT IrpContext, > - IN UCHAR DirentAttributes, > - IN PACCESS_MASK DesiredAccess > - ) > - > -/*++ > - > -Routine Description: > - > - This routine checks if a desired access is allowed to a file > represented > - by the specified DirentAttriubutes. > - > -Arguments: > - > - DirentAttributes - Supplies the Dirent attributes to check access for > - > - DesiredAccess - Supplies the desired access mask that we are checking > for > - > -Return Value: > - > - BOOLEAN - TRUE if access is allowed and FALSE otherwise > - > ---*/ > - > -{ > - BOOLEAN Result; > - > - DebugTrace(+1, Dbg, "FatCheckFileAccess\n", 0); > - DebugTrace( 0, Dbg, "DirentAttributes = %8lx\n", DirentAttributes); > - DebugTrace( 0, Dbg, "DesiredAccess = %8lx\n", *DesiredAccess); > - > - // > - // This procedures is programmed like a string of filters each > - // filter checks to see if some access is allowed, if it is not > allowed > - // the filter return FALSE to the user without further checks > otherwise > - // it moves on to the next filter. The filter check is to check for > - // desired access flags that are not allowed for a particular dirent > - // > - > - Result = TRUE; > - > - _SEH2_TRY { > - > - // > - // Check for Volume ID or Device Dirents, these are not allowed > user > - // access at all > - // > - > - if (FlagOn(DirentAttributes, FAT_DIRENT_ATTR_VOLUME_ID) || > - FlagOn(DirentAttributes, FAT_DIRENT_ATTR_DEVICE)) { > - > - DebugTrace(0, Dbg, "Cannot access volume id or device\n", 0); > - > - try_return( Result = FALSE ); > - } > - > - // > - // Check the desired access for the object - we only blackball > that > - // we do not understand. The model of filesystems using ACLs is > that > - // they do not type the ACL to the object the ACL is on. > Permissions > - // are not checked for consistency vs. the object type - > dir/file. > - // > - > - if (FlagOn(*DesiredAccess, ~(DELETE | > - READ_CONTROL | > - WRITE_OWNER | > - WRITE_DAC | > - SYNCHRONIZE | > - ACCESS_SYSTEM_SECURITY | > - FILE_WRITE_DATA | > - FILE_READ_EA | > - FILE_WRITE_EA | > - FILE_READ_ATTRIBUTES | > - FILE_WRITE_ATTRIBUTES | > - FILE_LIST_DIRECTORY | > - FILE_TRAVERSE | > - FILE_DELETE_CHILD | > - FILE_APPEND_DATA))) { > - > - DebugTrace(0, Dbg, "Cannot open object\n", 0); > - > - try_return( Result = FALSE ); > - } > - > - // > - // Check for a read-only Dirent > - // > - > - if (FlagOn(DirentAttributes, FAT_DIRENT_ATTR_READ_ONLY)) { > - > - // > - // Check the desired access for a read-only dirent, we > blackball > - // WRITE, FILE_APPEND_DATA, FILE_ADD_FILE, > - // FILE_ADD_SUBDIRECTORY, and FILE_DELETE_CHILD > - // > - > - if (FlagOn(*DesiredAccess, ~(DELETE | > - READ_CONTROL | > - WRITE_OWNER | > - WRITE_DAC | > - SYNCHRONIZE | > - ACCESS_SYSTEM_SECURITY | > - FILE_READ_DATA | > - FILE_READ_EA | > - FILE_WRITE_EA | > - FILE_READ_ATTRIBUTES | > - FILE_WRITE_ATTRIBUTES | > - FILE_EXECUTE | > - FILE_LIST_DIRECTORY | > - FILE_TRAVERSE))) { > - > - DebugTrace(0, Dbg, "Cannot open readonly\n", 0); > - > - try_return( Result = FALSE ); > - } > - } > - > - try_exit: NOTHING; > - } _SEH2_FINALLY { > - > - DebugUnwind( FatCheckFileAccess ); > - > - DebugTrace(-1, Dbg, "FatCheckFileAccess -> %08lx\n", Result); > - } _SEH2_END; > - > - UNREFERENCED_PARAMETER( IrpContext ); > - > - return Result; > -} > - > - > -NTSTATUS > -FatExplicitDeviceAccessGranted ( > - IN PIRP_CONTEXT IrpContext, > - IN PDEVICE_OBJECT DeviceObject, > - IN PACCESS_STATE AccessState, > - IN KPROCESSOR_MODE ProcessorMode > - ) > - > -/*++ > - > -Routine Description: > - > - This function asks whether the SID described in the input access > state has > - been granted any explicit access to the given device object. It does > this > - by acquiring a token stripped of its ability to acquire access via the > - Everyone SID and re-doing the access check. > - > -Arguments: > - > - DeviceObject - the device whose ACL will be checked > - > - AccessState - the access state describing the security context to be > checked > - > - ProcessorMode - the mode this check should occur against > - > -Return Value: > - > - NTSTATUS - Indicating whether explicit access was granted. > - > ---*/ > - > -{ > - NTSTATUS Status; > -#ifndef __REACTOS__ > - BOOLEAN Result; > -#endif > - > - PACCESS_TOKEN OriginalAccessToken; > - PACCESS_TOKEN RestrictedAccessToken; > - > - PACCESS_TOKEN *EffectiveToken; > - > - PRIVILEGE_SET PrivilegeSet; > - > - ACCESS_MASK GrantedAccess; > - > - // > - // If the access state indicates that specific access other > - // than traverse was acquired, either Everyone does have such > - // access or explicit access was granted. In both cases, we're > - // happy to let this proceed. > - // > - > - if (AccessState->PreviouslyGrantedAccess & (SPECIFIC_RIGHTS_ALL ^ > - FILE_TRAVERSE)) { > - > - return STATUS_SUCCESS; > - } > - > - // > - // If the manage volume privilege is held, this also permits access. > - // > - > - PrivilegeSet.PrivilegeCount = 1; > - PrivilegeSet.Control = PRIVILEGE_SET_ALL_NECESSARY; > - PrivilegeSet.Privilege[0].Luid = RtlConvertLongToLuid( > SE_MANAGE_VOLUME_PRIVILEGE ); > - PrivilegeSet.Privilege[0].Attributes = 0; > - > - if (SePrivilegeCheck( &PrivilegeSet, > - &AccessState->SubjectSecurityContext, > - ProcessorMode )) { > - > - return STATUS_SUCCESS; > - } > - > - // > - // Capture the subject context as a prelude to everything below. > - // > - > - SeLockSubjectContext( &AccessState->SubjectSecurityContext ); > - > - // > - // Convert the token in the subject context into one which does not > - // acquire access through the Everyone SID. > - // > - // The logic for deciding which token is effective comes from > - // SeQuerySubjectContextToken; since there is no natural way > - // of getting a pointer to it, do it by hand. > - // > - > - if (ARGUMENT_PRESENT( AccessState->SubjectSecurityContext.ClientToken > )) { > - EffectiveToken = &AccessState->SubjectSecurityContext. > ClientToken; > - } else { > - EffectiveToken = &AccessState->SubjectSecurityContext. > PrimaryToken; > - } > - > - OriginalAccessToken = *EffectiveToken; > - Status = FatCreateRestrictEveryoneToken( OriginalAccessToken, > &RestrictedAccessToken ); > - > - if (!NT_SUCCESS(Status)) { > - > - SeReleaseSubjectContext( &AccessState->SubjectSecurityContext ); > - return Status; > - } > - > - // > - // Now see if the resulting context has access to the device through > - // its explicitly granted access. We swap in our restricted token > - // for this check as the effective client token. > - // > - > - *EffectiveToken = RestrictedAccessToken; > - > -#ifndef __REACTOS__ > - Result = SeAccessCheck( DeviceObject->SecurityDescriptor, > -#else > - SeAccessCheck( DeviceObject->SecurityDescriptor, > -#endif > - &AccessState->SubjectSecurityContext, > - FALSE, > - AccessState->OriginalDesiredAccess, > - 0, > - NULL, > - IoGetFileObjectGenericMapping(), > - ProcessorMode, > - &GrantedAccess, > - &Status ); > - > - *EffectiveToken = OriginalAccessToken; > - > - // > - // Cleanup and return. > - // > - > - SeUnlockSubjectContext( &AccessState->SubjectSecurityContext ); > - ObDereferenceObject( RestrictedAccessToken ); > - > - return Status; > -} > - > - > -NTSTATUS > -FatCreateRestrictEveryoneToken ( > - IN PACCESS_TOKEN Token, > - OUT PACCESS_TOKEN *RestrictedToken > - ) > - > -/*++ > - > -Routine Description: > - > - This function takes a token as the input and returns a new restricted > token > - from which Everyone sid has been disabled. The resulting token may > be used > - to find out if access is available to a user-sid by explicit means. > - > -Arguments: > - > - Token - Input token from which Everyone sid needs to be deactivated. > - > - RestrictedToken - Receives the the new restricted token. > - This must be released using ObDereferenceObject(* > RestrictedToken); > - > -Return Value: > - > - NTSTATUS - Returned by SeFilterToken. > - > ---*/ > - > -{ > - // > - // Array of sids to disable. > - // > - > - TOKEN_GROUPS SidsToDisable; > - > - NTSTATUS Status = STATUS_SUCCESS; > - > - // > - // Restricted token will contain the original sids with one change: > - // If Everyone sid is present in the token, it will be marked for > DenyOnly. > - // > - > - *RestrictedToken = NULL; > - > - // > - // Put Everyone sid in the array of sids to disable. This will mark > it > - // for SE_GROUP_USE_FOR_DENY_ONLY and it'll only be applicable for > Deny aces. > - // > - > - SidsToDisable.GroupCount = 1; > - SidsToDisable.Groups[0].Attributes = 0; > - SidsToDisable.Groups[0].Sid = SeExports->SeWorldSid; > - > - Status = SeFilterToken( > - Token, // Token that needs to be restricted. > - 0, // No flags > - &SidsToDisable, // Disable everyone sid > - NULL, // Do not create any restricted sids > - NULL, // Do not delete any privileges > - RestrictedToken // Restricted token > - ); > - > - return Status; > -} > - > diff --git a/drivers/filesystems/fastfat_new/allocsup.c > b/drivers/filesystems/fastfat_new/allocsup.c > deleted file mode 100644 > index 79a9e7865a..0000000000 > --- a/drivers/filesystems/fastfat_new/allocsup.c > +++ /dev/null > @@ -1,5001 +0,0 @@ > -/*++ > - > -Copyright (c) 1990-2000 Microsoft Corporation > - > -Module Name: > - > - AllocSup.c > - > -Abstract: > - > - This module implements the Allocation support routines for Fat. > - > - > ---*/ > - > -#include "fatprocs.h" > - > -// > -// The Bug check file id for this module > -// > - > -#define BugCheckFileId (FAT_BUG_CHECK_ALLOCSUP) > - > -// > -// Local debug trace level > -// > - > -#define Dbg (DEBUG_TRACE_ALLOCSUP) > - > -#define FatMin(a, b) ((a) < (b) ? (a) : (b)) > - > -// > -// This strucure is used by FatLookupFatEntry to remember a pinned page > -// of fat. > -// > - > -typedef struct _FAT_ENUMERATION_CONTEXT { > - > - VBO VboOfPinnedPage; > - PBCB Bcb; > - PVOID PinnedPage; > - > -} FAT_ENUMERATION_CONTEXT, *PFAT_ENUMERATION_CONTEXT; > - > -// > -// Local support routine prototypes > -// > - > -VOID > -FatLookupFatEntry( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG FatIndex, > - IN OUT PULONG FatEntry, > - IN OUT PFAT_ENUMERATION_CONTEXT Context > - ); > - > -VOID > -FatSetFatRun( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG StartingFatIndex, > - IN ULONG ClusterCount, > - IN BOOLEAN ChainTogether > - ); > - > -UCHAR > -FatLogOf( > - IN ULONG Value > - ); > - > -// > -// Note that the KdPrint below will ONLY fire when the assert does. > Leave it > -// alone. > -// > - > -#if DBG > -#define ASSERT_CURRENT_WINDOW_GOOD(VCB) { > \ > - ULONG FreeClusterBitMapClear; > \ > - ASSERT( (VCB)->FreeClusterBitMap.Buffer != NULL ); > \ > - FreeClusterBitMapClear = RtlNumberOfClearBits(&(VCB)->FreeClusterBitMap); > \ > - if ((VCB)->CurrentWindow->ClustersFree != FreeClusterBitMapClear) { > \ > - KdPrint(("FAT: ClustersFree %x h != FreeClusterBitMapClear %x > h\n", \ > - (VCB)->CurrentWindow->ClustersFree, > \ > - FreeClusterBitMapClear)); > \ > - } > \ > - ASSERT( (VCB)->CurrentWindow->ClustersFree == FreeClusterBitMapClear > ); \ > -} > -#else > -#define ASSERT_CURRENT_WINDOW_GOOD(VCB) > -#endif > - > -// > -// The following macros provide a convenient way of hiding the details > -// of bitmap allocation schemes. > -// > - > - > -// > -// VOID > -// FatLockFreeClusterBitMap ( > -// IN PVCB Vcb > -// ); > -// > - > -#define FatLockFreeClusterBitMap(VCB) { \ > - ASSERT(KeAreApcsDisabled()); \ > - ExAcquireFastMutexUnsafe( &(VCB)->FreeClusterBitMapMutex ); \ > - ASSERT_CURRENT_WINDOW_GOOD(VCB) \ > -} > - > -// > -// VOID > -// FatUnlockFreeClusterBitMap ( > -// IN PVCB Vcb > -// ); > -// > - > -#define FatUnlockFreeClusterBitMap(VCB) { \ > - ASSERT_CURRENT_WINDOW_GOOD(VCB) \ > - ASSERT(KeAreApcsDisabled()); \ > - ExReleaseFastMutexUnsafe( &(VCB)->FreeClusterBitMapMutex ); \ > -} > - > -// > -// BOOLEAN > -// FatIsClusterFree ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG FatIndex > -// ); > -// > - > -#define FatIsClusterFree(IRPCONTEXT,VCB,FAT_INDEX) > \ > - (RtlCheckBit(&(VCB)->FreeClusterBitMap,(FAT_INDEX)-2) == 0) > - > -// > -// VOID > -// FatFreeClusters ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG FatIndex, > -// IN ULONG ClusterCount > -// ); > -// > - > -#define FatFreeClusters(IRPCONTEXT,VCB,FAT_INDEX,CLUSTER_COUNT) { > \ > - if ((CLUSTER_COUNT) == 1) { > \ > - FatSetFatEntry((IRPCONTEXT),(VCB),(FAT_INDEX),FAT_CLUSTER_AVAILABLE); > \ > - } else { > \ > - FatSetFatRun((IRPCONTEXT),(VCB),(FAT_INDEX),(CLUSTER_COUNT),FALSE); > \ > - } > \ > -} > - > -// > -// VOID > -// FatAllocateClusters ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG FatIndex, > -// IN ULONG ClusterCount > -// ); > -// > - > -#define FatAllocateClusters(IRPCONTEXT,VCB,FAT_INDEX,CLUSTER_COUNT) { > \ > - if ((CLUSTER_COUNT) == 1) { > \ > - FatSetFatEntry((IRPCONTEXT),(VCB),(FAT_INDEX),FAT_CLUSTER_LAST); > \ > - } else { > \ > - FatSetFatRun((IRPCONTEXT),(VCB),(FAT_INDEX),(CLUSTER_COUNT),TRUE); > \ > - } > \ > -} > - > -// > -// VOID > -// FatUnreserveClusters ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG FatIndex, > -// IN ULONG ClusterCount > -// ); > -// > - > -#define FatUnreserveClusters(IRPCONTEXT,VCB,FAT_INDEX,CLUSTER_COUNT) { > \ > - ASSERT( (FAT_INDEX) + (CLUSTER_COUNT) - 2 <= (VCB)->FreeClusterBitMap.SizeOfBitMap > ); \ > - ASSERT( (FAT_INDEX) >= 2); > \ > - RtlClearBits(&(VCB)->FreeClusterBitMap,(FAT_INDEX)-2,(CLUSTER_COUNT)); > \ > - if ((FAT_INDEX) < (VCB)->ClusterHint) { > \ > - (VCB)->ClusterHint = (FAT_INDEX); > \ > - } > \ > -} > - > -// > -// VOID > -// FatReserveClusters ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG FatIndex, > -// IN ULONG ClusterCount > -// ); > -// > -// Handle wrapping the hint back to the front. > -// > - > -#define FatReserveClusters(IRPCONTEXT,VCB,FAT_INDEX,CLUSTER_COUNT) { > \ > - ULONG _AfterRun = (FAT_INDEX) + (CLUSTER_COUNT); > \ > - ASSERT( (FAT_INDEX) + (CLUSTER_COUNT) - 2 <= (VCB)->FreeClusterBitMap.SizeOfBitMap > ); \ > - ASSERT( (FAT_INDEX) >= 2); > \ > - RtlSetBits(&(VCB)->FreeClusterBitMap,(FAT_INDEX)-2,(CLUSTER_COUNT)); > \ > - > \ > - if (_AfterRun - 2 >= (VCB)->FreeClusterBitMap.SizeOfBitMap) { > \ > - _AfterRun = 2; > \ > - } > \ > - if (RtlCheckBit(&(VCB)->FreeClusterBitMap, _AfterRun - 2)) { > \ > - (VCB)->ClusterHint = RtlFindClearBits( &(VCB)->FreeClusterBitMap, > 1, _AfterRun - 2) + 2; \ > - if (1 == (VCB)->ClusterHint) { > \ > - (VCB)->ClusterHint = 2; > \ > - } > \ > - } > \ > - else { > \ > - (VCB)->ClusterHint = _AfterRun; > \ > - } > \ > -} > - > -// > -// ULONG > -// FatFindFreeClusterRun ( > -// IN PIRP_CONTEXT IrpContext, > -// IN PVCB Vcb, > -// IN ULONG ClusterCount, > -// IN ULONG AlternateClusterHint > -// ); > -// > -// Do a special check if only one cluster is desired. > -// > - > -#define FatFindFreeClusterRun(IRPCONTEXT,VCB,CLUSTER_COUNT,CLUSTER_HINT) > ( \ > - (CLUSTER_COUNT == 1) && > \ > - FatIsClusterFree((IRPCONTEXT), (VCB), (CLUSTER_HINT)) ? > \ > - (CLUSTER_HINT) : > \ > - RtlFindClearBits( &(VCB)->FreeClusterBitMap, > \ > - (CLUSTER_COUNT), > \ > - (CLUSTER_HINT) - 2) + 2 > \ > -) > - > -// > -// FAT32: Define the maximum size of the FreeClusterBitMap to be the > -// maximum size of a FAT16 FAT. If there are more clusters on the > -// volume than can be represented by this many bytes of bitmap, the > -// FAT will be split into "buckets", each of which does fit. > -// > -// Note this count is in clusters/bits of bitmap. > -// > - > -#define MAX_CLUSTER_BITMAP_SIZE (1 << 16) > - > -// > -// Calculate the window a given cluster number is in. > -// > - > -#define FatWindowOfCluster(C) (((C) - 2) / > MAX_CLUSTER_BITMAP_SIZE) > - > -#ifdef ALLOC_PRAGMA > -#pragma alloc_text(PAGE, FatAddFileAllocation) > -#pragma alloc_text(PAGE, FatAllocateDiskSpace) > -#pragma alloc_text(PAGE, FatDeallocateDiskSpace) > -#pragma alloc_text(PAGE, FatExamineFatEntries) > -#pragma alloc_text(PAGE, FatInterpretClusterType) > -#pragma alloc_text(PAGE, FatLogOf) > -#pragma alloc_text(PAGE, FatLookupFatEntry) > -#pragma alloc_text(PAGE, FatLookupFileAllocation) > -#pragma alloc_text(PAGE, FatLookupFileAllocationSize) > -#pragma alloc_text(PAGE, FatMergeAllocation) > -#pragma alloc_text(PAGE, FatSetFatEntry) > -#pragma alloc_text(PAGE, FatSetFatRun) > -#pragma alloc_text(PAGE, FatSetupAllocationSupport) > -#pragma alloc_text(PAGE, FatSplitAllocation) > -#pragma alloc_text(PAGE, FatTearDownAllocationSupport) > -#pragma alloc_text(PAGE, FatTruncateFileAllocation) > -#endif > - > - > -INLINE > -ULONG > -FatSelectBestWindow( > - IN PVCB Vcb > - ) > -/*++ > - > -Routine Description: > - > - Choose a window to allocate clusters from. Order of preference is: > - > - 1. First window with >50% free clusters > - 2. First empty window > - 3. Window with greatest number of free clusters. > - > -Arguments: > - > - Vcb - Supplies the Vcb for the volume > - > -Return Value: > - > - 'Best window' number (index into Vcb->Windows[]) > - > ---*/ > -{ > - ULONG i, Fave = 0; > - ULONG MaxFree = 0; > - ULONG FirstEmpty = -1; > - ULONG ClustersPerWindow = MAX_CLUSTER_BITMAP_SIZE; > - > - ASSERT( 1 != Vcb->NumberOfWindows); > - > - for (i = 0; i < Vcb->NumberOfWindows; i++) { > - > - if (Vcb->Windows[i].ClustersFree == ClustersPerWindow) { > - > - if (-1 == FirstEmpty) { > - > - // > - // Keep note of the first empty window on the disc > - // > - > - FirstEmpty = i; > - } > - } > - else if (Vcb->Windows[i].ClustersFree > MaxFree) { > - > - // > - // This window has the most free clusters, so far > - // > - > - MaxFree = Vcb->Windows[i].ClustersFree; > - Fave = i; > - > - // > - // If this window has >50% free clusters, then we will take > it, > - // so don't bother considering more windows. > - // > - > - if (MaxFree >= (ClustersPerWindow >> 1)) { > - > - break; > - } > - } > - } > - > - // > - // If there were no windows with 50% or more freespace, then select > the > - // first empty window on the disc, if any - otherwise we'll just go > with > - // the one with the most free clusters. > - // > - > - if ((MaxFree < (ClustersPerWindow >> 1)) && (-1 != FirstEmpty)) { > - > - Fave = FirstEmpty; > - } > - > - return Fave; > -} > - > - > -VOID > -FatSetupAllocationSupport ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb > - ) > - > -/*++ > - > -Routine Description: > - > - This routine fills in the Allocation Support structure in the Vcb. > - Most entries are computed using fat.h macros supplied with data from > - the Bios Parameter Block. The free cluster count, however, requires > - going to the Fat and actually counting free sectors. At the same time > - the free cluster bit map is initalized. > - > -Arguments: > - > - Vcb - Supplies the Vcb to fill in. > - > ---*/ > - > -{ > -#ifndef __REACTOS__ > - ULONG BitMapSize; > - PVOID BitMapBuffer; > -#endif > - ULONG BitIndex; > - > -#ifndef __REACTOS__ > - PBCB Bcb; > - > - ULONG Page; > - ULONG Offset; > - ULONG FatIndexBitSize; > -#endif > - ULONG ClustersDescribableByFat; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatSetupAllocationSupport\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - > - // > - // Compute a number of fields for Vcb.AllocationSupport > - // > - > - Vcb->AllocationSupport.RootDirectoryLbo = FatRootDirectoryLbo( > &Vcb->Bpb ); > - Vcb->AllocationSupport.RootDirectorySize = FatRootDirectorySize( > &Vcb->Bpb ); > - > - Vcb->AllocationSupport.FileAreaLbo = FatFileAreaLbo( &Vcb->Bpb ); > - > - Vcb->AllocationSupport.NumberOfClusters = FatNumberOfClusters( > &Vcb->Bpb ); > - > - Vcb->AllocationSupport.FatIndexBitSize = FatIndexBitSize( &Vcb->Bpb > ); > - > - Vcb->AllocationSupport.LogOfBytesPerSector = FatLogOf(Vcb->Bpb. > BytesPerSector); > - Vcb->AllocationSupport.LogOfBytesPerCluster = > FatLogOf(FatBytesPerCluster( &Vcb->Bpb )); > - Vcb->AllocationSupport.NumberOfFreeClusters = 0; > - > - // > - // Deal with a bug in DOS 5 format, if the Fat is not big enough to > - // describe all the clusters on the disk, reduce this number. We > expect > - // that fat32 volumes will not have this problem. > - // > - // Turns out this was not a good assumption. We have to do this > always now. > - // > - > - ClustersDescribableByFat = ( ((FatIsFat32(Vcb)? > Vcb->Bpb.LargeSectorsPerFat : > - > Vcb->Bpb.SectorsPerFat) * > - Vcb->Bpb.BytesPerSector * 8) > - / FatIndexBitSize(&Vcb->Bpb) ) - 2; > - > - if (Vcb->AllocationSupport.NumberOfClusters > > ClustersDescribableByFat) { > - > - Vcb->AllocationSupport.NumberOfClusters = > ClustersDescribableByFat; > - } > - > - // > - // Extend the virtual volume file to include the Fat > - // > - > - { > - CC_FILE_SIZES FileSizes; > - > - FileSizes.AllocationSize.QuadPart = > - FileSizes.FileSize.QuadPart = (FatReservedBytes( &Vcb->Bpb ) + > - FatBytesPerFat( &Vcb->Bpb )); > - FileSizes.ValidDataLength = FatMaxLarge; > - > - if ( Vcb->VirtualVolumeFile->PrivateCacheMap == NULL ) { > - > - CcInitializeCacheMap( Vcb->VirtualVolumeFile, > - &FileSizes, > - TRUE, > - &FatData.CacheManagerNoOpCallbacks, > - Vcb ); > - > - } else { > - > - CcSetFileSizes( Vcb->VirtualVolumeFile, &FileSizes ); > - } > - } > - > - _SEH2_TRY { > - > - if (FatIsFat32(Vcb) && > - Vcb->AllocationSupport.NumberOfClusters > > MAX_CLUSTER_BITMAP_SIZE) { > - > - Vcb->NumberOfWindows = (Vcb->AllocationSupport.NumberOfClusters > + > - MAX_CLUSTER_BITMAP_SIZE - 1) / > - MAX_CLUSTER_BITMAP_SIZE; > - > -#ifndef __REACTOS__ > - BitMapSize = MAX_CLUSTER_BITMAP_SIZE; > -#endif > - > - } else { > - > - Vcb->NumberOfWindows = 1; > -#ifndef __REACTOS__ > - BitMapSize = Vcb->AllocationSupport.NumberOfClusters; > -#endif > - } > - > - Vcb->Windows = FsRtlAllocatePoolWithTag( PagedPool, > - Vcb->NumberOfWindows * > sizeof(FAT_WINDOW), > - TAG_FAT_WINDOW ); > - > - RtlInitializeBitMap( &Vcb->FreeClusterBitMap, > - NULL, > - 0 ); > - > - // > - // Chose a FAT window to begin operation in. > - // > - > - if (Vcb->NumberOfWindows > 1) { > - > - // > - // Read the fat and count up free clusters. We bias by the > two reserved > - // entries in the FAT. > - // > - > - FatExamineFatEntries( IrpContext, Vcb, > - 2, > - Vcb->AllocationSupport.NumberOfClusters > + 2 - 1, > - TRUE, > - NULL, > - NULL); > - > - > - // > - // Pick a window to begin allocating from > - // > - > - Vcb->CurrentWindow = &Vcb->Windows[ FatSelectBestWindow( > Vcb)]; > - > - } else { > - > - Vcb->CurrentWindow = &Vcb->Windows[0]; > - > - // > - // Carefully bias ourselves by the two reserved entries in > the FAT. > - // > - > - Vcb->CurrentWindow->FirstCluster = 2; > - Vcb->CurrentWindow->LastCluster = Vcb->AllocationSupport.NumberOfClusters > + 2 - 1; > - } > - > - // > - // Now transition to the FAT window we have chosen. > - // > - > - FatExamineFatEntries( IrpContext, Vcb, > - 0, > - 0, > - FALSE, > - Vcb->CurrentWindow, > - NULL); > - > - // > - // Now set the ClusterHint to the first free bit in our favorite > - // window (except the ClusterHint is off by two). > - // > - > - Vcb->ClusterHint = > - (BitIndex = RtlFindClearBits( &Vcb->FreeClusterBitMap, 1, 0 > )) != -1 ? > - BitIndex + 2 : 2; > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatSetupAllocationSupport ); > - > - // > - // If we hit an exception, back out. > - // > - > - if (_SEH2_AbnormalTermination()) { > - > - FatTearDownAllocationSupport( IrpContext, Vcb ); > - } > - } _SEH2_END; > - > - return; > -} > - > - > -VOID > -FatTearDownAllocationSupport ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb > - ) > - > -/*++ > - > -Routine Description: > - > - This routine prepares the volume for closing. Specifically, we must > - release the free fat bit map buffer, and uninitialize the dirty fat > - Mcb. > - > -Arguments: > - > - Vcb - Supplies the Vcb to fill in. > - > -Return Value: > - > - VOID > - > ---*/ > - > -{ > - DebugTrace(+1, Dbg, "FatTearDownAllocationSupport\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - > - PAGED_CODE(); > - > - // > - // If there are FAT buckets, free them. > - // > - > - if ( Vcb->Windows != NULL ) { > - > - ExFreePool( Vcb->Windows ); > - Vcb->Windows = NULL; > - } > - > - // > - // Free the memory associated with the free cluster bitmap. > - // > - > - if ( Vcb->FreeClusterBitMap.Buffer != NULL ) { > - > - ExFreePool( Vcb->FreeClusterBitMap.Buffer ); > - > - // > - // NULL this field as an flag. > - // > - > - Vcb->FreeClusterBitMap.Buffer = NULL; > - } > - > - // > - // And remove all the runs in the dirty fat Mcb > - // > - > - FatRemoveMcbEntry( Vcb, &Vcb->DirtyFatMcb, 0, 0xFFFFFFFF ); > - > - DebugTrace(-1, Dbg, "FatTearDownAllocationSupport -> (VOID)\n", 0); > - > - UNREFERENCED_PARAMETER( IrpContext ); > - > - return; > -} > - > - > -VOID > -FatLookupFileAllocation ( > - IN PIRP_CONTEXT IrpContext, > - IN PFCB FcbOrDcb, > - IN VBO Vbo, > - OUT PLBO Lbo, > - OUT PULONG ByteCount, > - OUT PBOOLEAN Allocated, > - OUT PBOOLEAN EndOnMax, > - OUT PULONG Index > - ) > - > -/*++ > - > -Routine Description: > - > - This routine looks up the existing mapping of VBO to LBO for a > - file/directory. The information it queries is either stored in the > - mcb field of the fcb/dcb or it is stored on in the fat table and > - needs to be retrieved and decoded, and updated in the mcb. > - > -Arguments: > - > - FcbOrDcb - Supplies the Fcb/Dcb of the file/directory being queried > - > - Vbo - Supplies the VBO whose LBO we want returned > - > - Lbo - Receives the LBO corresponding to the input Vbo if one exists > - > - ByteCount - Receives the number of bytes within the run the run > - that correpond between the input vbo and output lbo. > - > - Allocated - Receives TRUE if the Vbo does have a corresponding Lbo > - and FALSE otherwise. > - > - EndOnMax - Receives TRUE if the run ends in the maximal FAT cluster, > - which results in a fractional bytecount. > - > - Index - Receives the Index of the run > - > ---*/ > - > -{ > - VBO CurrentVbo; > - LBO CurrentLbo; > - LBO PriorLbo; > - > - VBO FirstVboOfCurrentRun; > - LBO FirstLboOfCurrentRun; > - > - BOOLEAN LastCluster; > - ULONG Runs; > - > - PVCB Vcb; > - FAT_ENTRY FatEntry; > - ULONG BytesPerCluster; > - ULARGE_INTEGER BytesOnVolume; > - > - FAT_ENUMERATION_CONTEXT Context; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatLookupFileAllocation\n", 0); > - DebugTrace( 0, Dbg, " FcbOrDcb = %8lx\n", FcbOrDcb); > - DebugTrace( 0, Dbg, " Vbo = %8lx\n", Vbo); > - DebugTrace( 0, Dbg, " Lbo = %8lx\n", Lbo); > - DebugTrace( 0, Dbg, " ByteCount = %8lx\n", ByteCount); > - DebugTrace( 0, Dbg, " Allocated = %8lx\n", Allocated); > - > - Context.Bcb = NULL; > - > - Vcb = FcbOrDcb->Vcb; > - > - *EndOnMax = FALSE; > - > - // > - // Check the trivial case that the mapping is already in our > - // Mcb. > - // > - > - if ( FatLookupMcbEntry(Vcb, &FcbOrDcb->Mcb, Vbo, Lbo, ByteCount, > Index) ) { > - > - *Allocated = TRUE; > - > - ASSERT( ByteCount != 0); > - > - // > - // Detect the overflow case, trim and claim the condition. > - // > - > - if (Vbo + *ByteCount == 0) { > - > - *EndOnMax = TRUE; > - } > - > - DebugTrace( 0, Dbg, "Found run in Mcb.\n", 0); > - DebugTrace(-1, Dbg, "FatLookupFileAllocation -> (VOID)\n", 0); > - return; > - } > - > - // > - // Initialize the Vcb, the cluster size, LastCluster, and > - // FirstLboOfCurrentRun (to be used as an indication of the first > - // iteration through the following while loop). > - // > - > - BytesPerCluster = 1 << Vcb->AllocationSupport.LogOfBytesPerCluster; > - > - BytesOnVolume.QuadPart = UInt32x32To64( Vcb->AllocationSupport.NumberOfClusters, > BytesPerCluster ); > - > - LastCluster = FALSE; > - FirstLboOfCurrentRun = 0; > - > - // > - // Discard the case that the request extends beyond the end of > - // allocation. Note that if the allocation size if not known > - // AllocationSize is set to 0xffffffff. > - // > - > - if ( Vbo >= FcbOrDcb->Header.AllocationSize.LowPart ) { > - > - *Allocated = FALSE; > - > - DebugTrace( 0, Dbg, "Vbo beyond end of file.\n", 0); > - DebugTrace(-1, Dbg, "FatLookupFileAllocation -> (VOID)\n", 0); > - return; > - } > - > - // > - // The Vbo is beyond the last Mcb entry. So we adjust Current > Vbo/Lbo > - // and FatEntry to describe the beginning of the last entry in the > Mcb. > - // This is used as initialization for the following loop. > - // > - // If the Mcb was empty, we start at the beginning of the file with > - // CurrentVbo set to 0 to indicate a new run. > - // > - > - if (FatLookupLastMcbEntry( Vcb, &FcbOrDcb->Mcb, &CurrentVbo, > &CurrentLbo, &Runs )) { > - > - DebugTrace( 0, Dbg, "Current Mcb size = %8lx.\n", CurrentVbo + 1); > - > - CurrentVbo -= (BytesPerCluster - 1); > - CurrentLbo -= (BytesPerCluster - 1); > - > - // > - // Convert an index to a count. > - // > - > - Runs += 1; > - > - } else { > - > - DebugTrace( 0, Dbg, "Mcb empty.\n", 0); > - > - // > - // Check for an FcbOrDcb that has no allocation > - // > - > - if (FcbOrDcb->FirstClusterOfFile == 0) { > - > - *Allocated = FALSE; > - > - DebugTrace( 0, Dbg, "File has no allocation.\n", 0); > - DebugTrace(-1, Dbg, "FatLookupFileAllocation -> (VOID)\n", 0); > - return; > - > - } else { > - > - CurrentVbo = 0; > - CurrentLbo = FatGetLboFromIndex( Vcb, > FcbOrDcb->FirstClusterOfFile ); > - FirstVboOfCurrentRun = CurrentVbo; > - FirstLboOfCurrentRun = CurrentLbo; > - > - Runs = 0; > - > - DebugTrace( 0, Dbg, "First Lbo of file = %8lx\n", CurrentLbo); > - } > - } > - > - // > - // Now we know that we are looking up a valid Vbo, but it is > - // not in the Mcb, which is a monotonically increasing list of > - // Vbo's. Thus we have to go to the Fat, and update > - // the Mcb as we go. We use a try-finally to unpin the page > - // of fat hanging around. Also we mark *Allocated = FALSE, so that > - // the caller wont try to use the data if we hit an exception. > - // > - > - *Allocated = FALSE; > - > - _SEH2_TRY { > - > - FatEntry = (FAT_ENTRY)FatGetIndexFromLbo( Vcb, CurrentLbo ); > - > - // > - // ASSERT that CurrentVbo and CurrentLbo are now cluster > alligned. > - // The assumption here, is that only whole clusters of Vbos and > Lbos > - // are mapped in the Mcb. > - // > - > - ASSERT( ((CurrentLbo - Vcb->AllocationSupport.FileAreaLbo) > - % BytesPerCluster == > 0) && > - (CurrentVbo % BytesPerCluster == 0) ); > - > - // > - // Starting from the first Vbo after the last Mcb entry, scan > through > - // the Fat looking for our Vbo. We continue through the Fat > until we > - // hit a noncontiguity beyond the desired Vbo, or the last > cluster. > - // > - > - while ( !LastCluster ) { > - > - // > - // Get the next fat entry, and update our Current variables. > - // > - > -#ifndef __REACTOS__ > - FatLookupFatEntry( IrpContext, Vcb, FatEntry, &FatEntry, > &Context ); > -#else > - FatLookupFatEntry( IrpContext, Vcb, FatEntry, > (PULONG)&FatEntry, &Context ); > -#endif > - > - PriorLbo = CurrentLbo; > - CurrentLbo = FatGetLboFromIndex( Vcb, FatEntry ); > - CurrentVbo += BytesPerCluster; > - > - switch ( FatInterpretClusterType( Vcb, FatEntry )) { > - > - // > - // Check for a break in the Fat allocation chain. > - // > - > - case FatClusterAvailable: > - case FatClusterReserved: > - case FatClusterBad: > - > - DebugTrace( 0, Dbg, "Break in allocation chain, entry = > %d\n", FatEntry); > - DebugTrace(-1, Dbg, "FatLookupFileAllocation -> Fat > Corrupt. Raise Status.\n", 0); > - > - FatPopUpFileCorrupt( IrpContext, FcbOrDcb ); > - FatRaiseStatus( IrpContext, STATUS_FILE_CORRUPT_ERROR ); > - break; > - > - // > - // If this is the last cluster, we must update the Mcb and > - // exit the loop. > - // > - > - case FatClusterLast: > - > - // > - // Assert we know where the current run started. If the > - // Mcb was empty when we were called, > thenFirstLboOfCurrentRun > - // was set to the start of the file. If the Mcb > contained an > - // entry, then FirstLboOfCurrentRun was set on the first > - // iteration through the loop. Thus if > FirstLboOfCurrentRun > - // is 0, then there was an Mcb entry and we are on our > first > - // iteration, meaing that the last cluster in the Mcb was > - // really the last allocated cluster, but we checked Vbo > - // against AllocationSize, and found it OK, thus > AllocationSize > - // must be too large. > - // > - // Note that, when we finally arrive here, CurrentVbo is > actually > - // the first Vbo beyond the file allocation and > CurrentLbo is > - // meaningless. > - // > - > - DebugTrace( 0, Dbg, "Read last cluster of file.\n", 0); > - > - // > - // Detect the case of the maximal file. Note that this > really isn't > - // a proper Vbo - those are zero-based, and this is a > one-based number. > - // The maximal file, of 2^32 - 1 bytes, has a maximum > byte offset of > - // 2^32 - 2. > - // > - // Just so we don't get confused here. > - // > - > - if (CurrentVbo == 0) { > - > - *EndOnMax = TRUE; > - CurrentVbo -= 1; > - } > - > - LastCluster = TRUE; > - > - if (FirstLboOfCurrentRun != 0 ) { > - > - DebugTrace( 0, Dbg, "Adding a run to the Mcb.\n", 0); > - DebugTrace( 0, Dbg, " Vbo = %08lx.\n", > FirstVboOfCurrentRun); > - DebugTrace( 0, Dbg, " Lbo = %08lx.\n", > FirstLboOfCurrentRun); > - DebugTrace( 0, Dbg, " Length = %08lx.\n", CurrentVbo > - FirstVboOfCurrentRun); > - > - (VOID)FatAddMcbEntry( Vcb, > - &FcbOrDcb->Mcb, > - FirstVboOfCurrentRun, > - FirstLboOfCurrentRun, > - CurrentVbo - > FirstVboOfCurrentRun ); > - > - Runs += 1; > - } > - > - // > - // Being at the end of allocation, make sure we have > found > - // the Vbo. If we haven't, seeing as we checked VBO > - // against AllocationSize, the real disk allocation is > less > - // than that of AllocationSize. This comes about when > the > - // real allocation is not yet known, and AllocaitonSize > - // contains MAXULONG. > - // > - // KLUDGE! - If we were called by > FatLookupFileAllocationSize > - // Vbo is set to MAXULONG - 1, and AllocationSize to the > lookup > - // hint. Thus we merrily go along looking for a match > that isn't > - // there, but in the meantime building an Mcb. If this > is > - // the case, fill in AllocationSize and return. > - // > - > - if ( Vbo == MAXULONG - 1 ) { > - > - *Allocated = FALSE; > - FcbOrDcb->Header.AllocationSize.QuadPart = > CurrentVbo; > - > - DebugTrace( 0, Dbg, "New file allocation size = > %08lx.\n", CurrentVbo); > - try_return ( NOTHING ); > - } > - > - // > - // We will lie ever so slightly if we really terminated > on the > - // maximal byte of a file. It is really allocated. > - // > - > - if (Vbo >= CurrentVbo && !*EndOnMax) { > - > - *Allocated = FALSE; > - try_return ( NOTHING ); > - } > - > - break; > - > - // > - // This is a continuation in the chain. If the run has a > - // discontiguity at this point, update the Mcb, and if we > are beyond > - // the desired Vbo, this is the end of the run, so set > LastCluster > - // and exit the loop. > - // > - > - case FatClusterNext: > - > - // > - // This is the loop check. The Vbo must not be bigger > than the size of > - // the volume, and the Vbo must not have a) wrapped and > b) not been at the > - // very last cluster in the chain, for the case of the > maximal file. > - // > - > - if ( CurrentVbo == 0 || > - (BytesOnVolume.HighPart == 0 && CurrentVbo > > BytesOnVolume.LowPart)) { > - > - FatPopUpFileCorrupt( IrpContext, FcbOrDcb ); > - FatRaiseStatus( IrpContext, STATUS_FILE_CORRUPT_ERROR > ); > - } > - > - if ( PriorLbo + BytesPerCluster != CurrentLbo ) { > - > - // > - // Note that on the first time through the loop > - // (FirstLboOfCurrentRun == 0), we don't add the > - // run to the Mcb since it curresponds to the last > - // run already stored in the Mcb. > - // > - > - if ( FirstLboOfCurrentRun != 0 ) { > - > - DebugTrace( 0, Dbg, "Adding a run to the Mcb.\n", > 0); > - DebugTrace( 0, Dbg, " Vbo = %08lx.\n", > FirstVboOfCurrentRun); > - DebugTrace( 0, Dbg, " Lbo = %08lx.\n", > FirstLboOfCurrentRun); > - DebugTrace( 0, Dbg, " Length = %08lx.\n", > CurrentVbo - FirstVboOfCurrentRun); > - > - FatAddMcbEntry( Vcb, > - &FcbOrDcb->Mcb, > - FirstVboOfCurrentRun, > - FirstLboOfCurrentRun, > - CurrentVbo - FirstVboOfCurrentRun > ); > - > - Runs += 1; > - } > - > - // > - // Since we are at a run boundry, with CurrentLbo and > - // CurrentVbo being the first cluster of the next > run, > - // we see if the run we just added encompases the > desired > - // Vbo, and if so exit. Otherwise we set up two new > - // First*boOfCurrentRun, and continue. > - // > - > - if (CurrentVbo > Vbo) { > - > - LastCluster = TRUE; > - > - } else { > - > - FirstVboOfCurrentRun = CurrentVbo; > - FirstLboOfCurrentRun = CurrentLbo; > - } > - } > - break; > - > - default: > - > - DebugTrace(0, Dbg, "Illegal Cluster Type.\n", FatEntry); > - > - FatBugCheck( 0, 0, 0 ); > - > - break; > - > - } // switch() > - } // while() > - > - // > - // Load up the return parameters. > - // > - // On exit from the loop, Vbo still contains the desired Vbo, and > - // CurrentVbo is the first byte after the run that contained the > - // desired Vbo. > - // > - > - *Allocated = TRUE; > - > - *Lbo = FirstLboOfCurrentRun + (Vbo - FirstVboOfCurrentRun); > - > - *ByteCount = CurrentVbo - Vbo; > - > - if (ARGUMENT_PRESENT(Index)) { > - > - // > - // Note that Runs only needs to be accurate with respect to > where we > - // ended. Since partial-lookup cases will occur without > exclusive > - // synchronization, the Mcb itself may be much bigger by now. > - // > - > - *Index = Runs - 1; > - } > - > - try_exit: NOTHING; > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatLookupFileAllocation ); > - > - // > - // We are done reading the Fat, so unpin the last page of fat > - // that is hanging around > - // > - > - FatUnpinBcb( IrpContext, Context.Bcb ); > - > - DebugTrace(-1, Dbg, "FatLookupFileAllocation -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -VOID > -FatAddFileAllocation ( > - IN PIRP_CONTEXT IrpContext, > - IN PFCB FcbOrDcb, > - IN PFILE_OBJECT FileObject OPTIONAL, > - IN ULONG DesiredAllocationSize > - ) > - > -/*++ > - > -Routine Description: > - > - This routine adds additional allocation to the specified > file/directory. > - Additional allocation is added by appending clusters to the > file/directory. > - > - If the file already has a sufficient allocation then this procedure > - is effectively a noop. > - > -Arguments: > - > - FcbOrDcb - Supplies the Fcb/Dcb of the file/directory being modified. > - This parameter must not specify the root dcb. > - > - FileObject - If supplied inform the cache manager of the change. > - > - DesiredAllocationSize - Supplies the minimum size, in bytes, that we > want > - allocated to the file/directory. > - > ---*/ > - > -{ > - PVCB Vcb; > - LARGE_MCB NewMcb; > - PLARGE_MCB McbToCleanup = NULL; > - PDIRENT Dirent = NULL; > - ULONG NewAllocation; > - PBCB Bcb = NULL; > - BOOLEAN UnwindWeAllocatedDiskSpace = FALSE; > - BOOLEAN UnwindAllocationSizeSet = FALSE; > - BOOLEAN UnwindCacheManagerInformed = FALSE; > - BOOLEAN UnwindWeInitializedMcb = FALSE; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatAddFileAllocation\n", 0); > - DebugTrace( 0, Dbg, " FcbOrDcb = %8lx\n", FcbOrDcb); > - DebugTrace( 0, Dbg, " DesiredAllocationSize = %8lx\n", > DesiredAllocationSize); > - > - // > - // If we haven't yet set the correct AllocationSize, do so. > - // > - > - if (FcbOrDcb->Header.AllocationSize.QuadPart == > FCB_LOOKUP_ALLOCATIONSIZE_HINT) { > - > - FatLookupFileAllocationSize( IrpContext, FcbOrDcb ); > - } > - > - // > - // Check for the benign case that the desired allocation is already > - // within the allocation size. > - // > - > - if (DesiredAllocationSize <= FcbOrDcb->Header.AllocationSize.LowPart) > { > - > - DebugTrace(0, Dbg, "Desired size within current allocation.\n", > 0); > - > - DebugTrace(-1, Dbg, "FatAddFileAllocation -> (VOID)\n", 0); > - return; > - } > - > - DebugTrace( 0, Dbg, "InitialAllocation = %08lx.\n", FcbOrDcb->Header. > AllocationSize.LowPart); > - > - // > - // Get a chunk of disk space that will fullfill our needs. If there > - // was no initial allocation, start from the hint in the Vcb, > otherwise > - // try to allocate from the cluster after the initial allocation. > - // > - // If there was no initial allocation to the file, we can just use > the > - // Mcb in the FcbOrDcb, otherwise we have to use a new one, and merge > - // it to the one in the FcbOrDcb. > - // > - > - Vcb = FcbOrDcb->Vcb; > - > - _SEH2_TRY { > - > - if (FcbOrDcb->Header.AllocationSize.LowPart == 0) { > - > - LBO FirstLboOfFile; > - > - ASSERT( FcbOrDcb->FcbCondition == FcbGood ); > - > - FatGetDirentFromFcbOrDcb( IrpContext, > - FcbOrDcb, > - &Dirent, > - &Bcb ); > - > - ASSERT( Bcb != NULL ); > - > - // > - // Set this dirty right now since this call can fail. > - // > - > - FatSetDirtyBcb( IrpContext, Bcb, Vcb, TRUE ); > - > - > - FatAllocateDiskSpace( IrpContext, > - Vcb, > - 0, > - &DesiredAllocationSize, > - FALSE, > - &FcbOrDcb->Mcb ); > - > - UnwindWeAllocatedDiskSpace = TRUE; > - McbToCleanup = &FcbOrDcb->Mcb; > - > - // > - // We have to update the dirent and FcbOrDcb copies of > - // FirstClusterOfFile since before it was 0 > - // > - > - FatLookupMcbEntry( FcbOrDcb->Vcb, > - &FcbOrDcb->Mcb, > - 0, > - &FirstLboOfFile, > - (PULONG)NULL, > - NULL ); > - > - DebugTrace( 0, Dbg, "First Lbo of file will be %08lx.\n", > FirstLboOfFile ); > - > - FcbOrDcb->FirstClusterOfFile = FatGetIndexFromLbo( Vcb, > FirstLboOfFile ); > - > - Dirent->FirstClusterOfFile = (USHORT)FcbOrDcb-> > FirstClusterOfFile; > - > - if ( FatIsFat32(Vcb) ) { > - > - Dirent->FirstClusterOfFileHi = (USHORT)(FcbOrDcb->FirstClusterOfFile > >> 16); > - } > - > - // > - // Note the size of the allocation we need to tell the > cache manager about. > - // > - > - NewAllocation = DesiredAllocationSize; > - > - } else { > - > - LBO LastAllocatedLbo; > - VBO DontCare; > - > - // > - // Get the first cluster following the current allocation. > It is possible > - // the Mcb is empty (or short, etc.) so we need to be > slightly careful > - // about making sure we don't lie with the hint. > - // > - > - (void)FatLookupLastMcbEntry( FcbOrDcb->Vcb, &FcbOrDcb->Mcb, > &DontCare, &LastAllocatedLbo, NULL ); > - > - // > - // Try to get some disk space starting from there. > - // > - > - NewAllocation = DesiredAllocationSize - FcbOrDcb->Header. > AllocationSize.LowPart; > - > - FsRtlInitializeLargeMcb( &NewMcb, PagedPool ); > - UnwindWeInitializedMcb = TRUE; > - McbToCleanup = &NewMcb; > - > - FatAllocateDiskSpace( IrpContext, > - Vcb, > - (LastAllocatedLbo != ~0 ? > - FatGetIndexFromLbo(Vcb,LastAllocatedLbo > + 1) : > - 0), > - &NewAllocation, > - FALSE, > - &NewMcb ); > - > - UnwindWeAllocatedDiskSpace = TRUE; > - } > - > - // > - // Now that we increased the allocation of the file, mark it in > the > - // FcbOrDcb. Carefully prepare to handle an inability to grow > the cache > - // structures. > - // > - > - FcbOrDcb->Header.AllocationSize.LowPart += NewAllocation; > - > - // > - // Handle the maximal file case, where we may have just > wrapped. Note > - // that this must be the precise boundary case wrap, i.e. by one > byte, > - // so that the new allocation is actually one byte "less" as far > as we're > - // concerned. This is important for the extension case. > - // > - > - if (FcbOrDcb->Header.AllocationSize.LowPart == 0) { > - > - NewAllocation -= 1; > - FcbOrDcb->Header.AllocationSize.LowPart = 0xffffffff; > - } > - > - UnwindAllocationSizeSet = TRUE; > - > - // > - // Inform the cache manager to increase the section size > - // > - > - if ( ARGUMENT_PRESENT(FileObject) && CcIsFileCached(FileObject) ) > { > - > - CcSetFileSizes( FileObject, > - (PCC_FILE_SIZES)&FcbOrDcb->Header.AllocationSize > ); > - UnwindCacheManagerInformed = TRUE; > - } > - > - // > - // In the extension case, we have held off actually gluing the > new > - // allocation onto the file. This simplifies exception cleanup > since > - // if it was already added and the section grow failed, we'd > have to > - // do extra work to unglue it. This way, we can assume that if > we > - // raise the only thing we need to do is deallocate the disk > space. > - // > - // Merge the allocation now. > - // > - > - if (FcbOrDcb->Header.AllocationSize.LowPart != NewAllocation) { > - > - // > - // Tack the new Mcb onto the end of the FcbOrDcb one. > - // > - > - FatMergeAllocation( IrpContext, > - Vcb, > - &FcbOrDcb->Mcb, > - &NewMcb ); > - } > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatAddFileAllocation ); > - > - // > - // Give FlushFileBuffer a clue here. > - // > - > - SetFlag(FcbOrDcb->FcbState, FCB_STATE_FLUSH_FAT); > - > - // > - // If we were dogged trying to complete this operation, we need > to go > - // back various things out. > - // > - > - if (_SEH2_AbnormalTermination()) { > - > - // > - // Pull off the allocation size we tried to add to this > object if > - // we failed to grow cache structures or Mcb structures. > - // > - > - if (UnwindAllocationSizeSet) { > - > - FcbOrDcb->Header.AllocationSize.LowPart -= NewAllocation; > - } > - > - if (UnwindCacheManagerInformed) { > - > - CcSetFileSizes( FileObject, > - (PCC_FILE_SIZES)&FcbOrDcb->Header.AllocationSize > ); > - } > - > - // > - // In the case of initial allocation, we used the Fcb's Mcb > and have > - // to clean that up as well as the FAT chain references. > - // > - > - if (FcbOrDcb->Header.AllocationSize.LowPart == 0) { > - > - if (Dirent != NULL) { > - > - FcbOrDcb->FirstClusterOfFile = 0; > - Dirent->FirstClusterOfFile = 0; > - > - if ( FatIsFat32(Vcb) ) { > - > - Dirent->FirstClusterOfFileHi = 0; > - } > - } > - } > - > - // > - // ... and drop the dirent Bcb if we got it. Do it now > - // so we can afford to take the exception if we have to. > - // > - > - FatUnpinBcb( IrpContext, Bcb ); > - > - _SEH2_TRY { > - > - // > - // Note this can re-raise. > - // > - > - if ( UnwindWeAllocatedDiskSpace ) { > - > - FatDeallocateDiskSpace( IrpContext, Vcb, McbToCleanup > ); > - } > - > - } _SEH2_FINALLY { > - > - // > - // We always want to clean up the non-initial allocation > temporary Mcb, > - // otherwise we have the Fcb's Mcb and we just truncate > it away. > - // > - > - if (UnwindWeInitializedMcb == TRUE) { > - > - // > - // Note that we already know a raise is in > progress. No danger > - // of encountering the normal case code below and > doing this again. > - // > - > - FsRtlUninitializeLargeMcb( McbToCleanup ); > - > - } else { > - > - if (McbToCleanup) { > - > - FsRtlTruncateLargeMcb( McbToCleanup, 0 ); > - } > - } > - } _SEH2_END; > - } > - > - DebugTrace(-1, Dbg, "FatAddFileAllocation -> (VOID)\n", 0); > - } _SEH2_END; > - > - // > - // Non-exceptional cleanup we always want to do. In handling the > re-raise possibilities > - // during exceptions we had to make sure these two steps always > happened there beforehand. > - // So now we handle the usual case. > - // > - > - FatUnpinBcb( IrpContext, Bcb ); > - > - if (UnwindWeInitializedMcb == TRUE) { > - > - FsRtlUninitializeLargeMcb( &NewMcb ); > - } > -} > - > - > -VOID > -FatTruncateFileAllocation ( > - IN PIRP_CONTEXT IrpContext, > - IN PFCB FcbOrDcb, > - IN ULONG DesiredAllocationSize > - ) > - > -/*++ > - > -Routine Description: > - > - This routine truncates the allocation to the specified file/directory. > - > - If the file is already smaller than the indicated size then this > procedure > - is effectively a noop. > - > - > -Arguments: > - > - FcbOrDcb - Supplies the Fcb/Dcb of the file/directory being modified > - This parameter must not specify the root dcb. > - > - DesiredAllocationSize - Supplies the maximum size, in bytes, that we > want > - allocated to the file/directory. It is > rounded > - up to the nearest cluster. > - > -Return Value: > - > - VOID - TRUE if the operation completed and FALSE if it had to > - block but could not. > - > ---*/ > - > -{ > - PVCB Vcb; > - PBCB Bcb = NULL; > - LARGE_MCB RemainingMcb; > - ULONG BytesPerCluster; > - PDIRENT Dirent = NULL; > - BOOLEAN UpdatedDirent = FALSE; > - > - ULONG UnwindInitialAllocationSize; > - ULONG UnwindInitialFirstClusterOfFile; > - BOOLEAN UnwindWeAllocatedMcb = FALSE; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatTruncateFileAllocation\n", 0); > - DebugTrace( 0, Dbg, " FcbOrDcb = %8lx\n", FcbOrDcb); > - DebugTrace( 0, Dbg, " DesiredAllocationSize = %8lx\n", > DesiredAllocationSize); > - > - // > - // If the Fcb isn't in good condition, we have no business whacking > around on > - // the disk after "its" clusters. > - // > - // Inspired by a Prefix complaint. > - // > - > - ASSERT( FcbOrDcb->FcbCondition == FcbGood ); > - > - // > - // If we haven't yet set the correct AllocationSize, do so. > - // > - > - if (FcbOrDcb->Header.AllocationSize.QuadPart == > FCB_LOOKUP_ALLOCATIONSIZE_HINT) { > - > - FatLookupFileAllocationSize( IrpContext, FcbOrDcb ); > - } > - > - // > - // Round up the Desired Allocation Size to the next cluster size > - // > - > - Vcb = FcbOrDcb->Vcb; > - > - BytesPerCluster = 1 << Vcb->AllocationSupport.LogOfBytesPerCluster; > - > - // > - // Note if the desired allocation is zero, to distinguish this from > - // the wrap case below. > - // > - > - if (DesiredAllocationSize != 0) { > - > - DesiredAllocationSize = (DesiredAllocationSize + (BytesPerCluster > - 1)) & > - ~(BytesPerCluster - 1); > - // > - // Check for the benign case that the file is already smaller > than > - // the desired truncation. Note that if it wraps, then a) it was > - // specifying an offset in the maximally allocatable cluster and > - // b) we're not asking to extend the file, either. So stop. > - // > - > - if (DesiredAllocationSize == 0 || > - DesiredAllocationSize >= FcbOrDcb->Header.AllocationSize.LowPart) > { > - > - DebugTrace(0, Dbg, "Desired size within current > allocation.\n", 0); > - > - DebugTrace(-1, Dbg, "FatTruncateFileAllocation -> (VOID)\n", > 0); > - return; > - } > - > - } > - > - UnwindInitialAllocationSize = FcbOrDcb->Header. > AllocationSize.LowPart; > - UnwindInitialFirstClusterOfFile = FcbOrDcb->FirstClusterOfFile; > - > - // > - // Update the FcbOrDcb allocation size. If it is now zero, we have > the > - // additional task of modifying the FcbOrDcb and Dirent copies of > - // FirstClusterInFile. > - // > - // Note that we must pin the dirent before actually deallocating the > - // disk space since, in unwind, it would not be possible to > reallocate > - // deallocated disk space as someone else may have reallocated it and > - // may cause an exception when you try to get some more disk space. > - // Thus FatDeallocateDiskSpace must be the final dangerous operation. > - // > - > - _SEH2_TRY { > - > - FcbOrDcb->Header.AllocationSize.QuadPart = DesiredAllocationSize; > - > - // > - // Special case 0 > - // > - > - if (DesiredAllocationSize == 0) { > - > - // > - // We have to update the dirent and FcbOrDcb copies of > - // FirstClusterOfFile since before it was 0 > - // > - > - ASSERT( FcbOrDcb->FcbCondition == FcbGood ); > - > - FatGetDirentFromFcbOrDcb( IrpContext, FcbOrDcb, &Dirent, &Bcb > ); > - > - ASSERT( Dirent && Bcb ); > - > - Dirent->FirstClusterOfFile = 0; > - > - if (FatIsFat32(Vcb)) { > - > - Dirent->FirstClusterOfFileHi = 0; > - } > - > - FcbOrDcb->FirstClusterOfFile = 0; > - > - FatSetDirtyBcb( IrpContext, Bcb, Vcb, TRUE ); > - UpdatedDirent = TRUE; > - > - FatDeallocateDiskSpace( IrpContext, Vcb, &FcbOrDcb->Mcb ); > - > - FatRemoveMcbEntry( FcbOrDcb->Vcb, &FcbOrDcb->Mcb, 0, > 0xFFFFFFFF ); > - > - } else { > - > - // > - // Split the existing allocation into two parts, one we will > keep, and > - // one we will deallocate. > - // > - > - FsRtlInitializeLargeMcb( &RemainingMcb, PagedPool ); > - UnwindWeAllocatedMcb = TRUE; > - > - FatSplitAllocation( IrpContext, > - Vcb, > - &FcbOrDcb->Mcb, > - DesiredAllocationSize, > - &RemainingMcb ); > - > - FatDeallocateDiskSpace( IrpContext, Vcb, &RemainingMcb ); > - > - FsRtlUninitializeLargeMcb( &RemainingMcb ); > - } > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatTruncateFileAllocation ); > - > - // > - // Is this really the right backout strategy? It would be nice > if we could > - // pretend the truncate worked if we knew that the file had > gotten into > - // a consistent state. Leaving dangled clusters is probably > quite preferable. > - // > - > - if ( _SEH2_AbnormalTermination() ) { > - > - FcbOrDcb->Header.AllocationSize.LowPart = > UnwindInitialAllocationSize; > - > - if ( (DesiredAllocationSize == 0) && (Dirent != NULL)) { > - > - if (UpdatedDirent) { > - > - // > - // If the dirent has been updated ok and marked > dirty, then we > - // failed in deallocatediscspace, and don't know > what state > - // the on disc fat chain is in. So we throw away > the mcb, > - // and potentially loose a few clusters until the > next > - // chkdsk. The operation has succeeded, but the > exception > - // will still propogate. 5.1 > - // > - > - FatRemoveMcbEntry( Vcb, &FcbOrDcb->Mcb, 0, 0xFFFFFFFF > ); > - FcbOrDcb->Header.AllocationSize.QuadPart = 0; > - } > - else { > - > - Dirent->FirstClusterOfFile = (USHORT) > UnwindInitialFirstClusterOfFile; > - > - if ( FatIsFat32(Vcb) ) { > - > - Dirent->FirstClusterOfFileHi = > - (USHORT)(UnwindInitialFirstClusterOfFile > >> 16); > - } > - > - FcbOrDcb->FirstClusterOfFile = > UnwindInitialFirstClusterOfFile; > - } > - } > - > - if ( UnwindWeAllocatedMcb ) { > - > - FsRtlUninitializeLargeMcb( &RemainingMcb ); > - } > - > - // > - // Note that in the non zero truncation case, we will also > - // leak clusters. However, apart from this, the in memory > and on disc > - // structures will agree. > - } > - > - FatUnpinBcb( IrpContext, Bcb ); > - > - // > - // Give FlushFileBuffer a clue here. > - // > - > - SetFlag(FcbOrDcb->FcbState, FCB_STATE_FLUSH_FAT); > - > - DebugTrace(-1, Dbg, "FatTruncateFileAllocation -> (VOID)\n", 0); > - } _SEH2_END; > -} > - > - > -VOID > -FatLookupFileAllocationSize ( > - IN PIRP_CONTEXT IrpContext, > - IN PFCB FcbOrDcb > - ) > - > -/*++ > - > -Routine Description: > - > - This routine retrieves the current file allocatio size for the > - specified file/directory. > - > -Arguments: > - > - FcbOrDcb - Supplies the Fcb/Dcb of the file/directory being modified > - > ---*/ > - > -{ > - LBO Lbo; > - ULONG ByteCount; > - BOOLEAN DontCare; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatLookupAllocationSize\n", 0); > - DebugTrace( 0, Dbg, " FcbOrDcb = %8lx\n", FcbOrDcb); > - > - // > - // We call FatLookupFileAllocation with Vbo of 0xffffffff - 1. > - // > - > - FatLookupFileAllocation( IrpContext, > - FcbOrDcb, > - MAXULONG - 1, > - &Lbo, > - &ByteCount, > - &DontCare, > - &DontCare, > - NULL ); > - > - // > - // FileSize was set at Fcb creation time from the contents of the > directory entry, > - // and we are only now looking up the real length of the allocation > chain. If it > - // cannot be contained, this is trash. Probably more where that > came from. > - // > - > - if (FcbOrDcb->Header.FileSize.LowPart > FcbOrDcb->Header.AllocationSize.LowPart) > { > - > - FatPopUpFileCorrupt( IrpContext, FcbOrDcb ); > - FatRaiseStatus( IrpContext, STATUS_FILE_CORRUPT_ERROR ); > - } > - > - DebugTrace(-1, Dbg, "FatLookupFileAllocationSize -> (VOID)\n", 0); > - return; > -} > - > - > -VOID > -FatAllocateDiskSpace ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG AbsoluteClusterHint, > - IN PULONG ByteCount, > - IN BOOLEAN ExactMatchRequired, > - OUT PLARGE_MCB Mcb > - ) > - > -/*++ > - > -Routine Description: > - > - This procedure allocates additional disk space and builds an mcb > - representing the newly allocated space. If the space cannot be > - allocated then this procedure raises an appropriate status. > - > - Searching starts from the hint index in the Vcb unless an alternative > - non-zero hint is given in AlternateClusterHint. If we are using the > - hint field in the Vcb, it is set to the cluster following our > allocation > - when we are done. > - > - Disk space can only be allocated in cluster units so this procedure > - will round up any byte count to the next cluster boundary. > - > - Pictorially what is done is the following (where ! denotes the end of > - the fat chain (i.e., FAT_CLUSTER_LAST)): > - > - > - Mcb (empty) > - > - becomes > - > - Mcb |--a--|--b--|--c--! > - > - ^ > - ByteCount ----------+ > - > -Arguments: > - > - Vcb - Supplies the VCB being modified > - > - AbsoluteClusterHint - Supplies an alternate hint index to start the > - search from. If this is zero we use, and > update, > - the Vcb hint field. > - > - ByteCount - Supplies the number of bytes that we are requesting, and > - receives the number of bytes that we got. > - > - ExactMatchRequired - Caller should set this to TRUE if only the > precise run requested > - is acceptable. > - > - Mcb - Receives the MCB describing the newly allocated disk space. The > - caller passes in an initialized Mcb that is filled in by this > procedure. > - > - Return Value: > - > - TRUE - Allocated ok > - FALSE - Failed to allocate exactly as requested (=> > ExactMatchRequired was TRUE) > - > ---*/ > - > -{ > - UCHAR LogOfBytesPerCluster; > - ULONG BytesPerCluster; > - ULONG StartingCluster; > - ULONG ClusterCount; > - ULONG WindowRelativeHint; > -#if DBG > -#ifndef __REACTOS__ > - ULONG i; > -#endif > - ULONG PreviousClear; > -#endif > - > - PFAT_WINDOW Window; > - BOOLEAN Wait; > - BOOLEAN Result = TRUE; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatAllocateDiskSpace\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " *ByteCount = %8lx\n", *ByteCount); > - DebugTrace( 0, Dbg, " Mcb = %8lx\n", Mcb); > - DebugTrace( 0, Dbg, " Hint = %8lx\n", AbsoluteClusterHint); > - > - ASSERT((AbsoluteClusterHint <= Vcb->AllocationSupport.NumberOfClusters > + 2) && (1 != AbsoluteClusterHint)); > - > - // > - // Make sure byte count is not zero > - // > - > - if (*ByteCount == 0) { > - > - DebugTrace(0, Dbg, "Nothing to allocate.\n", 0); > - > - DebugTrace(-1, Dbg, "FatAllocateDiskSpace -> (VOID)\n", 0); > - return; > - } > - > - // > - // Compute the cluster count based on the byte count, rounding up > - // to the next cluster if there is any remainder. Note that the > - // pathalogical case BytesCount == 0 has been eliminated above. > - // > - > - LogOfBytesPerCluster = Vcb->AllocationSupport.LogOfBytesPerCluster; > - BytesPerCluster = 1 << LogOfBytesPerCluster; > - > - *ByteCount = (*ByteCount + (BytesPerCluster - 1)) > - & ~(BytesPerCluster - 1); > - > - // > - // If ByteCount is NOW zero, then we were asked for the maximal > - // filesize (or at least for bytes in the last allocatable sector). > - // > - > - if (*ByteCount == 0) { > - > - *ByteCount = 0xffffffff; > - ClusterCount = 1 << (32 - LogOfBytesPerCluster); > - > - } else { > - > - ClusterCount = (*ByteCount >> LogOfBytesPerCluster); > - } > - > - // > - // Make sure there are enough free clusters to start with, and > - // take them now so that nobody else takes them from us. > - // > - > - ExAcquireResourceSharedLite(&Vcb->ChangeBitMapResource, TRUE); > - FatLockFreeClusterBitMap( Vcb ); > - > - if (ClusterCount <= Vcb->AllocationSupport.NumberOfFreeClusters) { > - > - Vcb->AllocationSupport.NumberOfFreeClusters -= ClusterCount; > - > - } else { > - > - FatUnlockFreeClusterBitMap( Vcb ); > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - > - DebugTrace(0, Dbg, "Disk Full. Raise Status.\n", 0); > - FatRaiseStatus( IrpContext, STATUS_DISK_FULL ); > - } > - > - // > - // Did the caller supply a hint? > - // > - > - if ((0 != AbsoluteClusterHint) && (AbsoluteClusterHint < > (Vcb->AllocationSupport.NumberOfClusters + 2))) { > - > - if (Vcb->NumberOfWindows > 1) { > - > - // > - // If we're being called upon to allocate clusters outside > the > - // current window (which happens only via MoveFile), it's a > problem. > - // We address this by changing the current window to be the > one which > - // contains the alternate cluster hint. Note that if the > user's > - // request would cross a window boundary, he doesn't really > get what > - // he wanted. > - // > - > - if (AbsoluteClusterHint < Vcb->CurrentWindow->FirstCluster || > - AbsoluteClusterHint > Vcb->CurrentWindow->LastCluster) { > - > - ULONG BucketNum = FatWindowOfCluster( AbsoluteClusterHint > ); > - > - ASSERT( BucketNum < Vcb->NumberOfWindows); > - > - // > - // Drop our shared lock on the ChangeBitMapResource, > and pick it up again > - // exclusive in preparation for making the window swap. > - // > - > - FatUnlockFreeClusterBitMap(Vcb); > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - ExAcquireResourceExclusiveLite(&Vcb->ChangeBitMapResource, > TRUE); > - FatLockFreeClusterBitMap(Vcb); > - > - Window = &Vcb->Windows[BucketNum]; > - > - // > - // Again, test the current window against the one we > want - some other > - // thread could have sneaked in behind our backs and > kindly set it to the one > - // we need, when we dropped and reacquired the > ChangeBitMapResource above. > - // > - > - if (Window != Vcb->CurrentWindow) { > - > - _SEH2_TRY { > - > - Wait = BooleanFlagOn(IrpContext->Flags, > IRP_CONTEXT_FLAG_WAIT); > - SetFlag(IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT); > - > - // > - // Change to the new window (update > Vcb->CurrentWindow) and scan it > - // to build up a freespace bitmap etc. > - // > - > - FatExamineFatEntries( IrpContext, Vcb, > - 0, > - 0, > - FALSE, > - Window, > - NULL); > - > - } _SEH2_FINALLY { > - > - if (!Wait) { > - > - ClearFlag(IrpContext->Flags, > IRP_CONTEXT_FLAG_WAIT); > - } > - > - if (_SEH2_AbnormalTermination()) { > - > - // > - // We will have raised as a result of > failing to pick up the > - // chunk of the FAT for this window move. > Release our resources > - // and return the cluster count to the > volume. > - // > - > - Vcb->AllocationSupport.NumberOfFreeClusters > += ClusterCount; > - > - FatUnlockFreeClusterBitMap( Vcb ); > - ExReleaseResourceLite(&Vcb-> > ChangeBitMapResource); > - } > - } _SEH2_END; > - } > - } > - > - // > - // Make the hint cluster number relative to the base of the > current window... > - // > - // Currentwindow->Firstcluster is baised by +2 already, so > we will lose the > - // bias already in AbsoluteClusterHint. Put it back.... > - // > - > - WindowRelativeHint = AbsoluteClusterHint - > Vcb->CurrentWindow->FirstCluster + 2; > - } > - else { > - > - // > - // Only one 'window', ie fat16/12. No modification > necessary. > - // > - > - WindowRelativeHint = AbsoluteClusterHint; > - } > - } > - else { > - > - // > - // Either no hint supplied, or it was out of range, so grab > one from the Vcb > - // > - // NOTE: Clusterhint in the Vcb is not guaranteed to be set (may > be -1) > - // > - > - WindowRelativeHint = Vcb->ClusterHint; > - AbsoluteClusterHint = 0; > - > - // > - // Vcb hint may not have been initialized yet. Force to valid > cluster. > - // > - > - if (-1 == WindowRelativeHint) { > - > - WindowRelativeHint = 2; > - } > - } > - > - ASSERT((WindowRelativeHint >= 2) && (WindowRelativeHint < > Vcb->FreeClusterBitMap.SizeOfBitMap + 2)); > - > - // > - // Keep track of the window we're allocating from, so we can clean > - // up correctly if the current window changes after we unlock the > - // bitmap. > - // > - > - Window = Vcb->CurrentWindow; > - > - // > - // Try to find a run of free clusters large enough for us. > - // > - > - StartingCluster = FatFindFreeClusterRun( IrpContext, > - Vcb, > - ClusterCount, > - WindowRelativeHint ); > - // > - // If the above call was successful, we can just update the fat > - // and Mcb and exit. Otherwise we have to look for smaller free > - // runs. > - // > - // This test is a bit funky. Note that the error return from > - // RtlFindClearBits is -1, and adding two to that is 1. > - // > - > - if ((StartingCluster != 1) && > - ((0 == AbsoluteClusterHint) || (StartingCluster == > WindowRelativeHint)) > - ) { > - > -#if DBG > - PreviousClear = RtlNumberOfClearBits( &Vcb->FreeClusterBitMap ); > -#endif // DBG > - > - // > - // Take the clusters we found, and unlock the bit map. > - // > - > - FatReserveClusters(IrpContext, Vcb, StartingCluster, > ClusterCount); > - > - Window->ClustersFree -= ClusterCount; > - > - StartingCluster += Window->FirstCluster; > - StartingCluster -= 2; > - > - ASSERT( PreviousClear - ClusterCount == Window->ClustersFree ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - > - // > - // Note that this call will never fail since there is always > - // room for one entry in an empty Mcb. > - // > - > - FatAddMcbEntry( Vcb, Mcb, > - 0, > - FatGetLboFromIndex( Vcb, StartingCluster ), > - *ByteCount); > - _SEH2_TRY { > - > - // > - // Update the fat. > - // > - > - FatAllocateClusters(IrpContext, Vcb, > - StartingCluster, > - ClusterCount); > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatAllocateDiskSpace ); > - > - // > - // If the allocate clusters failed, remove the run from the > Mcb, > - // unreserve the clusters, and reset the free cluster count. > - // > - > - if (_SEH2_AbnormalTermination()) { > - > - FatRemoveMcbEntry( Vcb, Mcb, 0, *ByteCount ); > - > - FatLockFreeClusterBitMap( Vcb ); > - > - // Only clear bits if the bitmap window is the same. > - > - if (Window == Vcb->CurrentWindow) { > - > - // Both values (startingcluster and > window->firstcluster) are > - // already biased by 2, so will cancel, so we need > to add in the 2 again. > - > - FatUnreserveClusters( IrpContext, Vcb, > - StartingCluster - > Window->FirstCluster + 2, > - ClusterCount ); > - } > - > - Window->ClustersFree += ClusterCount; > - Vcb->AllocationSupport.NumberOfFreeClusters += > ClusterCount; > - > - FatUnlockFreeClusterBitMap( Vcb ); > - } > - > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - } _SEH2_END; > - > - } else { > - > - // > - // Note that Index is a zero-based window-relative number. When > appropriate > - // it'll get converted into a true cluster number and put in > Cluster, which > - // will be a volume relative true cluster number. > - // > - > - ULONG Index; > - ULONG Cluster; > - ULONG CurrentVbo; > - ULONG PriorLastCluster; > - ULONG BytesFound; > - > - ULONG ClustersFound = 0; > - ULONG ClustersRemaining; > - > - BOOLEAN LockedBitMap = FALSE; > - BOOLEAN SelectNextContigWindow = FALSE; > - > - // > - // Drop our shared lock on the ChangeBitMapResource, and pick > it up again > - // exclusive in preparation for making a window swap. > - // > - > - FatUnlockFreeClusterBitMap(Vcb); > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - ExAcquireResourceExclusiveLite(&Vcb->ChangeBitMapResource, TRUE); > - FatLockFreeClusterBitMap(Vcb); > - LockedBitMap = TRUE; > - > - _SEH2_TRY { > - > - if ( ExactMatchRequired && (1 == Vcb->NumberOfWindows)) { > - > - // > - // Give up right now, there are no more windows to > search! RtlFindClearBits > - // searchs the whole bitmap, so we would have found any > contiguous run > - // large enough. > - // > - > - try_leave( Result = FALSE); > - } > - > - // > - // While the request is still incomplete, look for the > largest > - // run of free clusters, mark them taken, allocate the run in > - // the Mcb and Fat, and if this isn't the first time through > - // the loop link it to prior run on the fat. The Mcb will > - // coalesce automatically. > - // > - > - ClustersRemaining = ClusterCount; > - CurrentVbo = 0; > - PriorLastCluster = 0; > - > - while (ClustersRemaining != 0) { > - > - // > - // If we just entered the loop, the bit map is already > locked > - // > - > - if ( !LockedBitMap ) { > - > - FatLockFreeClusterBitMap( Vcb ); > - LockedBitMap = TRUE; > - } > - > - // > - // Find the largest run of free clusters. If the run is > - // bigger than we need, only use what we need. Note that > - // this will then be the last while() iteration. > - // > - > - // 12/3/95: need to bias bitmap by 2 bits for the defrag > - // hooks and the below macro became impossible to do > without in-line > - // procedures. > - // > - // ClustersFound = FatLongestFreeClusterRun( IrpContext, > Vcb, &Index ); > - > - ClustersFound = 0; > - > - if (!SelectNextContigWindow) { > - > - if ( 0 != WindowRelativeHint) { > - > - ULONG Desired = Vcb->FreeClusterBitMap.SizeOfBitMap > - (WindowRelativeHint - 2); > - > - // > - // We will try to allocate contiguously. Try > from the current hint the to > - // end of current window. Don't try for more > than we actually need. > - // > - > - if (Desired > ClustersRemaining) { > - > - Desired = ClustersRemaining; > - } > - > - if (RtlAreBitsClear( &Vcb->FreeClusterBitMap, > - WindowRelativeHint - 2, > - Desired)) > - { > - // > - // Clusters from hint->...windowend are > free. Take them. > - // > - > - Index = WindowRelativeHint - 2; > - ClustersFound = Desired; > - > - if (FatIsFat32(Vcb)) { > - > - // > - // We're now up against the end of the > current window, so indicate that we > - // want the next window in the sequence > next time around. (If we're not up > - // against the end of the window, then > we got what we needed and won't be > - // coming around again anyway). > - // > - > - SelectNextContigWindow = TRUE; > - WindowRelativeHint = 2; > - } > - else { > - > - // > - // FAT 12/16 - we've run up against the > end of the volume. Clear the > - // hint, since we now have no idea > where to look. > - // > - > - WindowRelativeHint = 0; > - } > -#if DBG > - PreviousClear = RtlNumberOfClearBits( > &Vcb->FreeClusterBitMap ); > -#endif // DBG > - } > - else { > - > - if (ExactMatchRequired) { > - > - // > - // If our caller required an exact > match, then we're hosed. Bail out now. > - // > - > - try_leave( Result = FALSE); > - } > - > - // > - // Hint failed, drop back to pot luck > - // > - > - WindowRelativeHint = 0; > - } > - } > - > - if ((0 == WindowRelativeHint) && (0 == > ClustersFound)) { > - > - if (ClustersRemaining <= Vcb->CurrentWindow->ClustersFree) > { > - > - // > - // The remaining allocation could be > satisfied entirely from this > - // window. We will ask only for what we > need, to try and avoid > - // unnecessarily fragmenting large runs of > space by always using > - // (part of) the largest run we can find. > This call will return the > - // first run large enough. > - // > - > - Index = RtlFindClearBits( > &Vcb->FreeClusterBitMap, ClustersRemaining, 0); > - > - if (-1 != Index) { > - > - ClustersFound = ClustersRemaining; > - } > - } > - > - if (0 == ClustersFound) { > - > - // > - // Still nothing, so just take the largest > free run we can find. > - // > - > - ClustersFound = RtlFindLongestRunClear( > &Vcb->FreeClusterBitMap, &Index ); > - > - } > -#if DBG > - PreviousClear = RtlNumberOfClearBits( > &Vcb->FreeClusterBitMap ); > -#endif // DBG > - if (ClustersFound >= ClustersRemaining) { > - > - ClustersFound = ClustersRemaining; > - } > - else { > - > - // > - // If we just ran up to the end of a > window, set up a hint that > - // we'd like the next consecutive window > after this one. (FAT32 only) > - // > - > - if ( ((Index + ClustersFound) == > Vcb->FreeClusterBitMap.SizeOfBitMap) && > - FatIsFat32( Vcb) > - ) { > - > - SelectNextContigWindow = TRUE; > - WindowRelativeHint = 2; > - } > - } > - } > - } > - > - if (ClustersFound == 0) { > - > - ULONG FaveWindow = 0; > - BOOLEAN SelectedWindow; > - > - // > - // If we found no free clusters on a single-window > FAT, > - // there was a bad problem with the free cluster > count. > - // > - > - if (1 == Vcb->NumberOfWindows) { > - > - FatBugCheck( 0, 5, 0 ); > - } > - > - // > - // Switch to a new bucket. Possibly the next one if > we're > - // currently on a roll (allocating contiguously) > - // > - > - SelectedWindow = FALSE; > - > - if ( SelectNextContigWindow) { > - > - ULONG NextWindow; > - > - NextWindow = (((ULONG)((PUCHAR)Vcb->CurrentWindow > - (PUCHAR)Vcb->Windows)) / sizeof( FAT_WINDOW)) + 1; > - > - if ((NextWindow < Vcb->NumberOfWindows) && > - ( Vcb->Windows[ NextWindow].ClustersFree > 0) > - ) { > - > - FaveWindow = NextWindow; > - SelectedWindow = TRUE; > - } > - else { > - > - if (ExactMatchRequired) { > - > - // > - // Some dope tried to allocate a run > past the end of the volume... > - // > - > - try_leave( Result = FALSE); > - } > - > - // > - // Give up on the contiguous allocation > attempts > - // > - > - WindowRelativeHint = 0; > - } > - > - SelectNextContigWindow = FALSE; > - } > - > - if (!SelectedWindow) { > - > - // > - // Select a new window to begin allocating from > - // > - > - FaveWindow = FatSelectBestWindow( Vcb); > - } > - > - // > - // By now we'd better have found a window with some > free clusters > - // > - > - if (0 == Vcb->Windows[ FaveWindow].ClustersFree) { > - > - FatBugCheck( 0, 5, 1 ); > - } > - > - Wait = BooleanFlagOn(IrpContext->Flags, > IRP_CONTEXT_FLAG_WAIT); > - SetFlag(IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT); > - > - FatExamineFatEntries( IrpContext, Vcb, > - 0, > - 0, > - FALSE, > - &Vcb->Windows[FaveWindow], > - NULL); > - > - if (!Wait) { > - > - ClearFlag(IrpContext->Flags, > IRP_CONTEXT_FLAG_WAIT); > - } > - > - // > - // Now we'll just go around the loop again, having > switched windows, > - // and allocate.... > - // > -#if DBG > - PreviousClear = RtlNumberOfClearBits( > &Vcb->FreeClusterBitMap ); > -#endif //DBG > - } // if (clustersfound == 0) > - else { > - > - // > - // Take the clusters we found, convert our index to > a cluster number > - // and unlock the bit map. > - // > - > - Window = Vcb->CurrentWindow; > - > - FatReserveClusters( IrpContext, Vcb, (Index + 2), > ClustersFound ); > - > - Cluster = Index + Window->FirstCluster; > - > - Window->ClustersFree -= ClustersFound; > - ASSERT( PreviousClear - ClustersFound == > Window->ClustersFree ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - LockedBitMap = FALSE; > - > - // > - // Add the newly alloced run to the Mcb. > - // > - > - BytesFound = ClustersFound << LogOfBytesPerCluster; > - > - FatAddMcbEntry( Vcb, Mcb, > - CurrentVbo, > - FatGetLboFromIndex( Vcb, Cluster ), > - BytesFound ); > - > - // > - // Connect the last allocated run with this one, and > allocate > - // this run on the Fat. > - // > - > - if (PriorLastCluster != 0) { > - > - FatSetFatEntry( IrpContext, > - Vcb, > - PriorLastCluster, > - (FAT_ENTRY)Cluster ); > - } > - > - // > - // Update the fat > - // > - > - FatAllocateClusters( IrpContext, Vcb, Cluster, > ClustersFound ); > - > - // > - // Prepare for the next iteration. > - // > - > - CurrentVbo += BytesFound; > - ClustersRemaining -= ClustersFound; > - PriorLastCluster = Cluster + ClustersFound - 1; > - } > - } // while (clustersremaining) > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatAllocateDiskSpace ); > - > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - > - // > - // Is there any unwinding to do? > - // > - > - if ( _SEH2_AbnormalTermination() || (FALSE == Result)) { > - > - // > - // Flag to the caller that they're getting nothing > - // > - > - *ByteCount = 0; > - > - // > - // There are three places we could have taken this > exception: > - // when switching the window (FatExamineFatEntries), > adding > - // a found run to the Mcb (FatAddMcbEntry), or when > writing > - // the changes to the FAT (FatSetFatEntry). In the > first case > - // we don't have anything to unwind before deallocation, > and > - // can detect this by seeing if we have the ClusterBitmap > - // mutex out. > - > - if (!LockedBitMap) { > - > - FatLockFreeClusterBitMap( Vcb ); > - > - // > - // In these cases, we have the possiblity that the > FAT > - // window is still in place and we need to clear the > bits. > - // If the Mcb entry isn't there (we raised trying to > add > - // it), the effect of trying to remove it is a noop. > - // > - > - if (Window == Vcb->CurrentWindow) { > - > - // > - // Cluster reservation works on cluster 2 based > window-relative > - // numbers, so we must convert. The subtraction > will lose the > - // cluster 2 base, so bias the result. > - // > - > - FatUnreserveClusters( IrpContext, Vcb, > - (Cluster - > Window->FirstCluster) + 2, > - ClustersFound ); > - } > - > - // > - // Note that FatDeallocateDiskSpace will take care > of adjusting > - // to account for the entries in the Mcb. All we > have to account > - // for is the last run that didn't make it. > - // > - > - Window->ClustersFree += ClustersFound; > - Vcb->AllocationSupport.NumberOfFreeClusters += > ClustersFound; > - > - FatUnlockFreeClusterBitMap( Vcb ); > - > - FatRemoveMcbEntry( Vcb, Mcb, CurrentVbo, BytesFound ); > - > - } else { > - > - // > - // Just drop the mutex now - we didn't manage to do > anything > - // that needs to be backed out. > - // > - > - FatUnlockFreeClusterBitMap( Vcb ); > - } > - > - _SEH2_TRY { > - > - // > - // Now we have tidied up, we are ready to just send > the Mcb > - // off to deallocate disk space > - // > - > - FatDeallocateDiskSpace( IrpContext, Vcb, Mcb ); > - > - } _SEH2_FINALLY { > - > - // > - // Now finally (really), remove all the entries from > the mcb > - // > - > - FatRemoveMcbEntry( Vcb, Mcb, 0, 0xFFFFFFFF ); > - } _SEH2_END; > - } > - > - DebugTrace(-1, Dbg, "FatAllocateDiskSpace -> (VOID)\n", 0); > - > - } _SEH2_END; // finally > - } > - > - return; > -} > - > - > -VOID > -FatDeallocateDiskSpace ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN PLARGE_MCB Mcb > - ) > - > -/*++ > - > -Routine Description: > - > - This procedure deallocates the disk space denoted by an input > - mcb. Note that the input MCB does not need to necessarily describe > - a chain that ends with a FAT_CLUSTER_LAST entry. > - > - Pictorially what is done is the following > - > - Fat |--a--|--b--|--c--| > - Mcb |--a--|--b--|--c--| > - > - becomes > - > - Fat |--0--|--0--|--0--| > - Mcb |--a--|--b--|--c--| > - > -Arguments: > - > - Vcb - Supplies the VCB being modified > - > - Mcb - Supplies the MCB describing the disk space to deallocate. Note > - that Mcb is unchanged by this procedure. > - > - > -Return Value: > - > - None. > - > ---*/ > - > -{ > - LBO Lbo; > - VBO Vbo; > - > - ULONG RunsInMcb; > - ULONG ByteCount; > - ULONG ClusterCount; > - ULONG ClusterIndex; > - ULONG McbIndex; > - > - UCHAR LogOfBytesPerCluster; > - > - PFAT_WINDOW Window; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatDeallocateDiskSpace\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " Mcb = %8lx\n", Mcb); > - > - LogOfBytesPerCluster = Vcb->AllocationSupport.LogOfBytesPerCluster; > - > - RunsInMcb = FsRtlNumberOfRunsInLargeMcb( Mcb ); > - > - if ( RunsInMcb == 0 ) { > - > - DebugTrace(-1, Dbg, "FatDeallocateDiskSpace -> (VOID)\n", 0); > - return; > - } > - > - _SEH2_TRY { > - > - // > - // Run though the Mcb, freeing all the runs in the fat. > - // > - // We do this in two steps (first update the fat, then the bitmap > - // (which can't fail)) to prevent other people from taking > clusters > - // that we need to re-allocate in the event of unwind. > - // > - > - ExAcquireResourceSharedLite(&Vcb->ChangeBitMapResource, TRUE); > - > - RunsInMcb = FsRtlNumberOfRunsInLargeMcb( Mcb ); > - > - for ( McbIndex = 0; McbIndex < RunsInMcb; McbIndex++ ) { > - > - FatGetNextMcbEntry( Vcb, Mcb, McbIndex, &Vbo, &Lbo, > &ByteCount ); > - > - // > - // Assert that Fat files have no holes. > - // > - > - ASSERT( Lbo != 0 ); > - > - // > - // Write FAT_CLUSTER_AVAILABLE to each cluster in the run. > - // > - > - ClusterCount = ByteCount >> LogOfBytesPerCluster; > - ClusterIndex = FatGetIndexFromLbo( Vcb, Lbo ); > - > - FatFreeClusters( IrpContext, Vcb, ClusterIndex, ClusterCount > ); > - } > - > - // > - // From now on, nothing can go wrong .... (as in raise) > - // > - > - FatLockFreeClusterBitMap( Vcb ); > - > - for ( McbIndex = 0; McbIndex < RunsInMcb; McbIndex++ ) { > - > - ULONG ClusterEnd; > - ULONG MyStart, MyLength, count; > -#if DBG > -#ifndef __REACTOS__ > - ULONG PreviousClear, i; > -#else > - ULONG i; > -#endif > -#endif > - > - FatGetNextMcbEntry( Vcb, Mcb, McbIndex, &Vbo, &Lbo, > &ByteCount ); > - > - // > - // Mark the bits clear in the FreeClusterBitMap. > - // > - > - ClusterCount = ByteCount >> LogOfBytesPerCluster; > - ClusterIndex = FatGetIndexFromLbo( Vcb, Lbo ); > - > - Window = Vcb->CurrentWindow; > - > - // > - // If we've divided the bitmap, elide bitmap manipulation for > - // runs that are outside the current bucket. > - // > - > - ClusterEnd = ClusterIndex + ClusterCount - 1; > - > - if (!(ClusterIndex > Window->LastCluster || > - ClusterEnd < Window->FirstCluster)) { > - > - // > - // The run being freed overlaps the current bucket, so > we'll > - // have to clear some bits. > - // > - > - if (ClusterIndex < Window->FirstCluster && > - ClusterEnd > Window->LastCluster) { > - > - MyStart = Window->FirstCluster; > - MyLength = Window->LastCluster - Window->FirstCluster > + 1; > - > - } else if (ClusterIndex < Window->FirstCluster) { > - > - MyStart = Window->FirstCluster; > - MyLength = ClusterEnd - Window->FirstCluster + 1; > - > - } else { > - > - // > - // The range being freed starts in the bucket, and > may possibly > - // extend beyond the bucket. > - // > - > - MyStart = ClusterIndex; > - > - if (ClusterEnd <= Window->LastCluster) { > - > - MyLength = ClusterCount; > - > - } else { > - > - MyLength = Window->LastCluster - ClusterIndex + 1; > - } > - } > - > - if (MyLength == 0) { > - > - continue; > - } > - > -#if DBG > -#ifndef __REACTOS__ > - PreviousClear = RtlNumberOfClearBits( > &Vcb->FreeClusterBitMap ); > -#endif > - > - > - // > - // Verify that the Bits are all really set. > - // > - > - ASSERT( MyStart + MyLength - Window->FirstCluster <= > Vcb->FreeClusterBitMap.SizeOfBitMap ); > - > - for (i = 0; i < MyLength; i++) { > - > - ASSERT( RtlCheckBit(&Vcb->FreeClusterBitMap, > - MyStart - Window->FirstCluster + i) == 1 ); > - } > -#endif // DBG > - > - FatUnreserveClusters( IrpContext, Vcb, > - MyStart - Window->FirstCluster + 2, > - MyLength ); > - } > - > - // > - // Adjust the ClustersFree count for each bitmap window, > even the ones > - // that are not the current window. > - // > - > - if (FatIsFat32(Vcb)) { > - > - Window = &Vcb->Windows[FatWindowOfCluster( ClusterIndex > )]; > - > - } else { > - > - Window = &Vcb->Windows[0]; > - } > - > - MyStart = ClusterIndex; > - > - for (MyLength = ClusterCount; MyLength > 0; MyLength -= > count) { > - > - count = FatMin(Window->LastCluster - MyStart + 1, > MyLength); > - Window->ClustersFree += count; > - > - // > - // If this was not the last window this allocation > spanned, > - // advance to the next. > - // > - > - if (MyLength != count) { > - > - Window++; > - MyStart = Window->FirstCluster; > - } > - } > - > - // > - // Deallocation is now complete. Adjust the free cluster > count. > - // > - > - Vcb->AllocationSupport.NumberOfFreeClusters += ClusterCount; > - } > - > -#if DBG > - if (Vcb->CurrentWindow->ClustersFree != > - RtlNumberOfClearBits(&Vcb->FreeClusterBitMap)) { > - > - DbgPrint("%x vs %x\n", Vcb->CurrentWindow->ClustersFree, > - RtlNumberOfClearBits(&Vcb->FreeClusterBitMap)); > - > - DbgPrint("%x for %x\n", ClusterIndex, ClusterCount); > - } > -#endif > - > - FatUnlockFreeClusterBitMap( Vcb ); > - > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatDeallocateDiskSpace ); > - > - // > - // Is there any unwinding to do? > - // > - > - ExReleaseResourceLite(&Vcb->ChangeBitMapResource); > - > - if ( _SEH2_AbnormalTermination() ) { > - > - LBO Lbo; > - VBO Vbo; > - > - ULONG Index; > - ULONG Clusters; > - ULONG FatIndex; > - ULONG PriorLastIndex; > - > - // > - // For each entry we already deallocated, reallocate it, > - // chaining together as nessecary. Note that we continue > - // up to and including the last "for" iteration even though > - // the SetFatRun could not have been successful. This > - // allows us a convienent way to re-link the final successful > - // SetFatRun. > - // > - // It is possible that the reason we got here will prevent us > - // from succeeding in this operation. > - // > - > - PriorLastIndex = 0; > - > - for (Index = 0; Index <= McbIndex; Index++) { > - > - FatGetNextMcbEntry(Vcb, Mcb, Index, &Vbo, &Lbo, > &ByteCount); > - > - FatIndex = FatGetIndexFromLbo( Vcb, Lbo ); > - Clusters = ByteCount >> LogOfBytesPerCluster; > - > - // > - // We must always restore the prior iteration's last > - // entry, pointing it to the first cluster of this run. > - // > - > - if (PriorLastIndex != 0) { > - > - FatSetFatEntry( IrpContext, > - Vcb, > - PriorLastIndex, > - (FAT_ENTRY)FatIndex ); > - } > - > - // > - // If this is not the last entry (the one that failed) > - // then reallocate the disk space on the fat. > - // > - > - if ( Index < McbIndex ) { > - > - FatAllocateClusters(IrpContext, Vcb, FatIndex, > Clusters); > - > - PriorLastIndex = FatIndex + Clusters - 1; > - } > - } > - } > - > - DebugTrace(-1, Dbg, "FatDeallocateDiskSpace -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -VOID > -FatSplitAllocation ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN OUT PLARGE_MCB Mcb, > - IN VBO SplitAtVbo, > - OUT PLARGE_MCB RemainingMcb > - ) > - > -/*++ > - > -Routine Description: > - > - This procedure takes a single mcb and splits its allocation into > - two separate allocation units. The separation must only be done > - on cluster boundaries, otherwise we bugcheck. > - > - On the disk this actually works by inserting a FAT_CLUSTER_LAST into > - the last index of the first part being split out. > - > - Pictorially what is done is the following (where ! denotes the end of > - the fat chain (i.e., FAT_CLUSTER_LAST)): > - > - > - Mcb |--a--|--b--|--c--|--d--|--e--|--f--| > - > - ^ > - SplitAtVbo ---------------------+ > - > - RemainingMcb (empty) > - > - becomes > - > - Mcb |--a--|--b--|--c--! > - > - > - RemainingMcb |--d--|--e--|--f--| > - > -Arguments: > - > - Vcb - Supplies the VCB being modified > - > - Mcb - Supplies the MCB describing the allocation being split into > - two parts. Upon return this Mcb now contains the first chain. > - > - SplitAtVbo - Supplies the VBO of the first byte for the second chain > - that we creating. > - > - RemainingMcb - Receives the MCB describing the second chain of > allocated > - disk space. The caller passes in an initialized Mcb > that > - is filled in by this procedure STARTING AT VBO 0. > - > -Return Value: > - > - VOID - TRUE if the operation completed and FALSE if it had to > - block but could not. > - > ---*/ > - > -{ > - VBO SourceVbo; > - VBO TargetVbo; > - VBO DontCare; > - > - LBO Lbo; > - > - ULONG ByteCount; > - ULONG BytesPerCluster; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatSplitAllocation\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " Mcb = %8lx\n", Mcb); > - DebugTrace( 0, Dbg, " SplitAtVbo = %8lx\n", SplitAtVbo); > - DebugTrace( 0, Dbg, " RemainingMcb = %8lx\n", RemainingMcb); > - > - BytesPerCluster = 1 << Vcb->AllocationSupport.LogOfBytesPerCluster; > - > - // > - // Assert that the split point is cluster alligned > - // > - > - ASSERT( (SplitAtVbo & (BytesPerCluster - 1)) == 0 ); > - > - // > - // We should never be handed an empty source MCB and asked to split > - // at a non zero point. > - // > - > - ASSERT( !((0 != SplitAtVbo) && (0 == FsRtlNumberOfRunsInLargeMcb( > Mcb)))); > - > - // > - // Assert we were given an empty target Mcb. > - // > - > - // > - // This assert is commented out to avoid hitting in the Ea error > - // path. In that case we will be using the same Mcb's to split the > - // allocation that we used to merge them. The target Mcb will > contain > - // the runs that the split will attempt to insert. > - // > - // > - // ASSERT( FsRtlNumberOfRunsInMcb( RemainingMcb ) == 0 ); > - // > - > - _SEH2_TRY { > - > - // > - // Move the runs after SplitAtVbo from the souce to the target > - // > - > - SourceVbo = SplitAtVbo; > - TargetVbo = 0; > - > - while (FatLookupMcbEntry(Vcb, Mcb, SourceVbo, &Lbo, &ByteCount, > NULL)) { > - > - FatAddMcbEntry( Vcb, RemainingMcb, TargetVbo, Lbo, ByteCount > ); > - > - FatRemoveMcbEntry( Vcb, Mcb, SourceVbo, ByteCount ); > - > - TargetVbo += ByteCount; > - SourceVbo += ByteCount; > - > - // > - // If SourceVbo overflows, we were actually snipping off the > end > - // of the maximal file ... and are now done. > - // > - > - if (SourceVbo == 0) { > - > - break; > - } > - } > - > - // > - // Mark the last pre-split cluster as a FAT_LAST_CLUSTER > - // > - > - if ( SplitAtVbo != 0 ) { > - > - FatLookupLastMcbEntry( Vcb, Mcb, &DontCare, &Lbo, NULL ); > - > - FatSetFatEntry( IrpContext, > - Vcb, > - FatGetIndexFromLbo( Vcb, Lbo ), > - FAT_CLUSTER_LAST ); > - } > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatSplitAllocation ); > - > - // > - // If we got an exception, we must glue back together the Mcbs > - // > - > - if ( _SEH2_AbnormalTermination() ) { > - > - TargetVbo = SplitAtVbo; > - SourceVbo = 0; > - > - while (FatLookupMcbEntry(Vcb, RemainingMcb, SourceVbo, &Lbo, > &ByteCount, NULL)) { > - > - FatAddMcbEntry( Vcb, Mcb, TargetVbo, Lbo, ByteCount ); > - > - FatRemoveMcbEntry( Vcb, RemainingMcb, SourceVbo, > ByteCount ); > - > - TargetVbo += ByteCount; > - SourceVbo += ByteCount; > - } > - } > - > - DebugTrace(-1, Dbg, "FatSplitAllocation -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -VOID > -FatMergeAllocation ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN OUT PLARGE_MCB Mcb, > - IN PLARGE_MCB SecondMcb > - ) > - > -/*++ > - > -Routine Description: > - > - This routine takes two separate allocations described by two MCBs and > - joins them together into one allocation. > - > - Pictorially what is done is the following (where ! denotes the end of > - the fat chain (i.e., FAT_CLUSTER_LAST)): > - > - > - Mcb |--a--|--b--|--c--! > - > - SecondMcb |--d--|--e--|--f--| > - > - becomes > - > - Mcb |--a--|--b--|--c--|--d--|--e--|--f--| > - > - SecondMcb |--d--|--e--|--f--| > - > - > -Arguments: > - > - Vcb - Supplies the VCB being modified > - > - Mcb - Supplies the MCB of the first allocation that is being modified. > - Upon return this Mcb will also describe the newly enlarged > - allocation > - > - SecondMcb - Supplies the ZERO VBO BASED MCB of the second allocation > - that is being appended to the first allocation. This > - procedure leaves SecondMcb unchanged. > - > -Return Value: > - > - VOID - TRUE if the operation completed and FALSE if it had to > - block but could not. > - > ---*/ > - > -{ > - VBO SpliceVbo; > - LBO SpliceLbo; > - > - VBO SourceVbo; > - VBO TargetVbo; > - > - LBO Lbo; > - > - ULONG ByteCount; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatMergeAllocation\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " Mcb = %8lx\n", Mcb); > - DebugTrace( 0, Dbg, " SecondMcb = %8lx\n", SecondMcb); > - > - _SEH2_TRY { > - > - // > - // Append the runs from SecondMcb to Mcb > - // > - > - (void)FatLookupLastMcbEntry( Vcb, Mcb, &SpliceVbo, &SpliceLbo, > NULL ); > - > - SourceVbo = 0; > - TargetVbo = SpliceVbo + 1; > - > - while (FatLookupMcbEntry(Vcb, SecondMcb, SourceVbo, &Lbo, > &ByteCount, NULL)) { > - > - FatAddMcbEntry( Vcb, Mcb, TargetVbo, Lbo, ByteCount ); > - > - SourceVbo += ByteCount; > - TargetVbo += ByteCount; > - } > - > - // > - // Link the last pre-merge cluster to the first cluster of > SecondMcb > - // > - > - FatLookupMcbEntry( Vcb, SecondMcb, 0, &Lbo, (PULONG)NULL, NULL ); > - > - FatSetFatEntry( IrpContext, > - Vcb, > - FatGetIndexFromLbo( Vcb, SpliceLbo ), > - (FAT_ENTRY)FatGetIndexFromLbo( Vcb, Lbo ) ); > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatMergeAllocation ); > - > - // > - // If we got an exception, we must remove the runs added to Mcb > - // > - > - if ( _SEH2_AbnormalTermination() ) { > - > - ULONG CutLength; > - > - if ((CutLength = TargetVbo - (SpliceVbo + 1)) != 0) { > - > - FatRemoveMcbEntry( Vcb, Mcb, SpliceVbo + 1, CutLength); > - } > - } > - > - DebugTrace(-1, Dbg, "FatMergeAllocation -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -// > -// Internal support routine > -// > - > -CLUSTER_TYPE > -FatInterpretClusterType ( > - IN PVCB Vcb, > - IN FAT_ENTRY Entry > - ) > - > -/*++ > - > -Routine Description: > - > - This procedure tells the caller how to interpret the input fat table > - entry. It will indicate if the fat cluster is available, resereved, > - bad, the last one, or the another fat index. This procedure can deal > - with both 12 and 16 bit fat. > - > -Arguments: > - > - Vcb - Supplies the Vcb to examine, yields 12/16 bit info > - > - Entry - Supplies the fat entry to examine > - > -Return Value: > - > - CLUSTER_TYPE - Is the type of the input Fat entry > - > ---*/ > - > -{ > - DebugTrace(+1, Dbg, "InterpretClusterType\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " Entry = %8lx\n", Entry); > - > - PAGED_CODE(); > - > - switch(Vcb->AllocationSupport.FatIndexBitSize ) { > - case 32: > - Entry &= FAT32_ENTRY_MASK; > - break; > - > - case 12: > - ASSERT( Entry <= 0xfff ); > - if (Entry >= 0x0ff0) { > - Entry |= 0x0FFFF000; > - } > - break; > - > - default: > - case 16: > - ASSERT( Entry <= 0xffff ); > - if (Entry >= 0x0fff0) { > - Entry |= 0x0FFF0000; > - } > - break; > - } > - > - if (Entry == FAT_CLUSTER_AVAILABLE) { > - > - DebugTrace(-1, Dbg, "FatInterpretClusterType -> > FatClusterAvailable\n", 0); > - > - return FatClusterAvailable; > - > - } else if (Entry < FAT_CLUSTER_RESERVED) { > - > - DebugTrace(-1, Dbg, "FatInterpretClusterType -> > FatClusterNext\n", 0); > - > - return FatClusterNext; > - > - } else if (Entry < FAT_CLUSTER_BAD) { > - > - DebugTrace(-1, Dbg, "FatInterpretClusterType -> > FatClusterReserved\n", 0); > - > - return FatClusterReserved; > - > - } else if (Entry == FAT_CLUSTER_BAD) { > - > - DebugTrace(-1, Dbg, "FatInterpretClusterType -> FatClusterBad\n", > 0); > - > - return FatClusterBad; > - > - } else { > - > - DebugTrace(-1, Dbg, "FatInterpretClusterType -> > FatClusterLast\n", 0); > - > - return FatClusterLast; > - } > -} > - > - > -// > -// Internal support routine > -// > - > -VOID > -FatLookupFatEntry ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG FatIndex, > - IN OUT PULONG FatEntry, > - IN OUT PFAT_ENUMERATION_CONTEXT Context > - ) > - > -/*++ > - > -Routine Description: > - > - This routine takes an index into the fat and gives back the value > - in the Fat at this index. At any given time, for a 16 bit fat, this > - routine allows only one page per volume of the fat to be pinned in > - memory. For a 12 bit bit fat, the entire fat (max 6k) is pinned. > This > - extra layer of caching makes the vast majority of requests very > - fast. The context for this caching stored in a structure in the Vcb. > - > -Arguments: > - > - Vcb - Supplies the Vcb to examine, yields 12/16 bit info, > - fat access context, etc. > - > - FatIndex - Supplies the fat index to examine. > - > - FatEntry - Receives the fat entry pointed to by FatIndex. Note that > - it must point to non-paged pool. > - > - Context - This structure keeps track of a page of pinned fat between > calls. > - > ---*/ > - > -{ > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatLookupFatEntry\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " FatIndex = %4x\n", FatIndex); > - DebugTrace( 0, Dbg, " FatEntry = %8lx\n", FatEntry); > - > - // > - // Make sure they gave us a valid fat index. > - // > - > - FatVerifyIndexIsValid(IrpContext, Vcb, FatIndex); > - > - // > - // Case on 12 or 16 bit fats. > - // > - // In the 12 bit case (mostly floppies) we always have the whole fat > - // (max 6k bytes) pinned during allocation operations. This is > possibly > - // a wee bit slower, but saves headaches over fat entries with 8 bits > - // on one page, and 4 bits on the next. > - // > - // The 16 bit case always keeps the last used page pinned until all > - // operations are done and it is unpinned. > - // > - > - // > - // DEAL WITH 12 BIT CASE > - // > - > - if (Vcb->AllocationSupport.FatIndexBitSize == 12) { > - > - // > - // Check to see if the fat is already pinned, otherwise pin it. > - // > - > - if (Context->Bcb == NULL) { > - > - FatReadVolumeFile( IrpContext, > - Vcb, > - FatReservedBytes( &Vcb->Bpb ), > - FatBytesPerFat( &Vcb->Bpb ), > - &Context->Bcb, > - &Context->PinnedPage ); > - } > - > - // > - // Load the return value. > - // > - > - > - FatLookup12BitEntry( Context->PinnedPage, FatIndex, FatEntry ); > - > - } else if (Vcb->AllocationSupport.FatIndexBitSize == 32) { > - > - // > - // DEAL WITH 32 BIT CASE > - // > - > - ULONG PageEntryOffset; > - ULONG OffsetIntoVolumeFile; > - > - // > - // Initialize two local variables that help us. > - // > - OffsetIntoVolumeFile = FatReservedBytes(&Vcb->Bpb) + FatIndex * > sizeof(FAT_ENTRY); > - PageEntryOffset = (OffsetIntoVolumeFile % PAGE_SIZE) / > sizeof(FAT_ENTRY); > - > - // > - // Check to see if we need to read in a new page of fat > - // > - > - if ((Context->Bcb == NULL) || > - (OffsetIntoVolumeFile / PAGE_SIZE != Context->VboOfPinnedPage > / PAGE_SIZE)) { > - > - // > - // The entry wasn't in the pinned page, so must we unpin the > current > - // page (if any) and read in a new page. > - // > - > - FatUnpinBcb( IrpContext, Context->Bcb ); > - > - FatReadVolumeFile( IrpContext, > - Vcb, > - OffsetIntoVolumeFile & ~(PAGE_SIZE - 1), > - PAGE_SIZE, > - &Context->Bcb, > - &Context->PinnedPage ); > - > - Context->VboOfPinnedPage = OffsetIntoVolumeFile & ~(PAGE_SIZE > - 1); > - } > - > - // > - // Grab the fat entry from the pinned page, and return > - // > - > - *FatEntry = ((PULONG)(Context->PinnedPage))[PageEntryOffset] & > FAT32_ENTRY_MASK; > - > - } else { > - > - // > - // DEAL WITH 16 BIT CASE > - // > - > - ULONG PageEntryOffset; > - ULONG OffsetIntoVolumeFile; > - > - // > - // Initialize two local variables that help us. > - // > - > - OffsetIntoVolumeFile = FatReservedBytes(&Vcb->Bpb) + FatIndex * > sizeof(USHORT); > - PageEntryOffset = (OffsetIntoVolumeFile % PAGE_SIZE) / > sizeof(USHORT); > - > - // > - // Check to see if we need to read in a new page of fat > - // > - > - if ((Context->Bcb == NULL) || > - (OffsetIntoVolumeFile / PAGE_SIZE != Context->VboOfPinnedPage > / PAGE_SIZE)) { > - > - // > - // The entry wasn't in the pinned page, so must we unpin the > current > - // page (if any) and read in a new page. > - // > - > - FatUnpinBcb( IrpContext, Context->Bcb ); > - > - FatReadVolumeFile( IrpContext, > - Vcb, > - OffsetIntoVolumeFile & ~(PAGE_SIZE - 1), > - PAGE_SIZE, > - &Context->Bcb, > - &Context->PinnedPage ); > - > - Context->VboOfPinnedPage = OffsetIntoVolumeFile & ~(PAGE_SIZE > - 1); > - } > - > - // > - // Grab the fat entry from the pinned page, and return > - // > - > - *FatEntry = ((PUSHORT)(Context->PinnedPage))[PageEntryOffset]; > - } > - > - DebugTrace(-1, Dbg, "FatLookupFatEntry -> (VOID)\n", 0); > - return; > -} > - > - > -VOID > -FatSetFatEntry ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG FatIndex, > - IN FAT_ENTRY FatEntry > - ) > - > -/*++ > - > -Routine Description: > - > - This routine takes an index into the fat and puts a value in the Fat > - at this index. The routine special cases 12, 16 and 32 bit fats. In > - all cases we go to the cache manager for a piece of the fat. > - > - We have a special form of this call for setting the DOS-style dirty > bit. > - Unlike the dirty bit in the boot sector, we do not go to special > effort > - to make sure that this hits the disk synchronously - if the system > goes > - down in the window between the dirty bit being set in the boot sector > - and the FAT index zero dirty bit being lazy written, then life is > tough. > - > - The only possible scenario is that Win9x may see what it thinks is a > clean > - volume that really isn't (hopefully Memphis will pay attention to our > dirty > - bit as well). The dirty bit will get out quickly, and if heavy > activity is > - occurring, then the dirty bit should actually be there virtually all > of the > - time since the act of cleaning the volume is the "rare" occurance. > - > - There are synchronization concerns that would crop up if we tried to > make > - this synchronous. This thread may already own the Bcb shared for the > first > - sector of the FAT (so we can't get it exclusive for a writethrough). > This > - would require some more serious replumbing to work around than I want > to > - consider at this time. > - > - We can and do, however, synchronously set the bit clean. > - > - At this point the reader should understand why the NT dirty bit is > where it is. > - > -Arguments: > - > - Vcb - Supplies the Vcb to examine, yields 12/16/32 bit info, etc. > - > - FatIndex - Supplies the destination fat index. > - > - FatEntry - Supplies the source fat entry. > - > ---*/ > - > -{ > - LBO Lbo; > - PBCB Bcb = NULL; > - ULONG SectorSize; > - ULONG OffsetIntoVolumeFile; > - ULONG WasWait = TRUE; > - BOOLEAN RegularOperation = TRUE; > - BOOLEAN CleaningOperation = FALSE; > - BOOLEAN ReleaseMutex = FALSE; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatSetFatEntry\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " FatIndex = %4x\n", FatIndex); > - DebugTrace( 0, Dbg, " FatEntry = %4x\n", FatEntry); > - > - // > - // Make sure they gave us a valid fat index if this isn't the special > - // clean-bit modifying call. > - // > - > - if (FatIndex == FAT_DIRTY_BIT_INDEX) { > - > - // > - // We are setting the clean bit state. Of course, we could > - // have corruption that would cause us to try to fiddle the > - // reserved index - we guard against this by having the > - // special entry values use the reserved high 4 bits that > - // we know that we'll never try to set. > - // > - > - // > - // We don't want to repin the FAT pages involved here. Just > - // let the lazy writer hit them when it can. > - // > - > - RegularOperation = FALSE; > - > - switch (FatEntry) { > - case FAT_CLEAN_VOLUME: > - FatEntry = FAT_CLEAN_ENTRY; > - CleaningOperation = TRUE; > - break; > - > - case FAT_DIRTY_VOLUME: > - switch (Vcb->AllocationSupport.FatIndexBitSize) { > - case 12: > - FatEntry = FAT12_DIRTY_ENTRY; > - break; > - > - case 32: > - FatEntry = FAT32_DIRTY_ENTRY; > - break; > - > - default: > - FatEntry = FAT16_DIRTY_ENTRY; > - break; > - } > - break; > - > - default: > - FatRaiseStatus( IrpContext, STATUS_FILE_CORRUPT_ERROR ); > - break; > - } > - > - // > - // Disable dirtying semantics for the duration of this > operation. Force this > - // operation to wait for the duration. > - // > - > - WasWait = FlagOn( IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT ); > - SetFlag( IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT | > IRP_CONTEXT_FLAG_DISABLE_DIRTY ); > - > - } else { > - > - ASSERT( !(FatEntry & ~FAT32_ENTRY_MASK) ); > - FatVerifyIndexIsValid(IrpContext, Vcb, FatIndex); > - } > - > - // > - // Set Sector Size > - // > - > - SectorSize = 1 << Vcb->AllocationSupport.LogOfBytesPerSector; > - > - // > - // Case on 12 or 16 bit fats. > - // > - // In the 12 bit case (mostly floppies) we always have the whole fat > - // (max 6k bytes) pinned during allocation operations. This is > possibly > - // a wee bit slower, but saves headaches over fat entries with 8 bits > - // on one page, and 4 bits on the next. > - // > - // In the 16 bit case we only read the page that we need to set the > fat > - // entry. > - // > - > - // > - // DEAL WITH 12 BIT CASE > - // > - > - _SEH2_TRY { > - > - if (Vcb->AllocationSupport.FatIndexBitSize == 12) { > - > - PVOID PinnedFat; > - > - // > - // Make sure we have a valid entry > - // > - > - FatEntry &= 0xfff; > - > - // > - // We read in the entire fat. Note that using prepare write > marks > - // the bcb pre-dirty, so we don't have to do it explicitly. > - // > - > - OffsetIntoVolumeFile = FatReservedBytes( &Vcb->Bpb ) + > FatIndex * 3 / 2; > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - FatReservedBytes( &Vcb->Bpb ), > - FatBytesPerFat( &Vcb->Bpb ), > - &Bcb, > - &PinnedFat, > - RegularOperation, > - FALSE ); > - > - // > - // Mark the sector(s) dirty in the DirtyFatMcb. This call is > - // complicated somewhat for the 12 bit case since a single > - // entry write can span two sectors (and pages). > - // > - // Get the Lbo for the sector where the entry starts, and > add it to > - // the dirty fat Mcb. > - // > - > - Lbo = OffsetIntoVolumeFile & ~(SectorSize - 1); > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize); > - > - // > - // If the entry started on the last byte of the sector, it > continues > - // to the next sector, so mark the next sector dirty as well. > - // > - // Note that this entry will simply coalese with the last > entry, > - // so this operation cannot fail. Also if we get this far, > we have > - // made it, so no unwinding will be needed. > - // > - > - if ( (OffsetIntoVolumeFile & (SectorSize - 1)) == (SectorSize > - 1) ) { > - > - Lbo += SectorSize; > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize ); > - } > - > - // > - // Store the entry into the fat; we need a little > synchonization > - // here and can't use a spinlock since the bytes might not be > - // resident. > - // > - > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > - > - FatSet12BitEntry( PinnedFat, FatIndex, FatEntry ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > - > - } else if (Vcb->AllocationSupport.FatIndexBitSize == 32) { > - > - // > - // DEAL WITH 32 BIT CASE > - // > - > - PULONG PinnedFatEntry32; > - > - // > - // Read in a new page of fat > - // > - > - OffsetIntoVolumeFile = FatReservedBytes( &Vcb->Bpb ) + > - FatIndex * sizeof( FAT_ENTRY ); > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - OffsetIntoVolumeFile, > - sizeof(FAT_ENTRY), > - &Bcb, > - (PVOID *)&PinnedFatEntry32, > - RegularOperation, > - FALSE ); > - // > - // Mark the sector dirty in the DirtyFatMcb > - // > - > - Lbo = OffsetIntoVolumeFile & ~(SectorSize - 1); > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize); > - > - // > - // Store the FatEntry to the pinned page. > - // > - // Preserve the reserved bits in FAT32 entries in the file > heap. > - // > - > -#ifdef ALPHA > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > -#endif // ALPHA > - > - if (FatIndex != FAT_DIRTY_BIT_INDEX) { > - > - *PinnedFatEntry32 = ((*PinnedFatEntry32 & > ~FAT32_ENTRY_MASK) | FatEntry); > - > - } else { > - > - *PinnedFatEntry32 = FatEntry; > - } > - > -#ifdef ALPHA > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > -#endif // ALPHA > - > - } else { > - > - // > - // DEAL WITH 16 BIT CASE > - // > - > - PUSHORT PinnedFatEntry; > - > - // > - // Read in a new page of fat > - // > - > - OffsetIntoVolumeFile = FatReservedBytes( &Vcb->Bpb ) + > - FatIndex * sizeof(USHORT); > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - OffsetIntoVolumeFile, > - sizeof(USHORT), > - &Bcb, > - (PVOID *)&PinnedFatEntry, > - RegularOperation, > - FALSE ); > - // > - // Mark the sector dirty in the DirtyFatMcb > - // > - > - Lbo = OffsetIntoVolumeFile & ~(SectorSize - 1); > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize); > - > - // > - // Store the FatEntry to the pinned page. > - // > - // We need extra synchronization here for broken > architectures > - // like the ALPHA that don't support atomic 16 bit writes. > - // > - > -#ifdef ALPHA > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > -#endif // ALPHA > - > - *PinnedFatEntry = (USHORT)FatEntry; > - > -#ifdef ALPHA > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > -#endif // ALPHA > - } > - > - } _SEH2_FINALLY { > - > - DebugUnwind( FatSetFatEntry ); > - > - // > - // Re-enable volume dirtying in case this was a dirty bit > operation. > - // > - > - ClearFlag( IrpContext->Flags, IRP_CONTEXT_FLAG_DISABLE_DIRTY ); > - > - // > - // Make this operation asynchronous again if needed. > - // > - > - if (!WasWait) { > - > - ClearFlag( IrpContext->Flags, IRP_CONTEXT_FLAG_WAIT ); > - } > - > - // > - // If we still somehow have the Mutex, release it. > - // > - > - if (ReleaseMutex) { > - > - ASSERT( _SEH2_AbnormalTermination() ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - } > - > - // > - // Unpin the Bcb. For cleaning operations, we make this > write-through. > - // > - > - if (CleaningOperation && Bcb) { > - > - IO_STATUS_BLOCK IgnoreStatus; > - > - CcRepinBcb( Bcb ); > - CcUnpinData( Bcb ); > - DbgDoit( IrpContext->PinCount -= 1 ); > - CcUnpinRepinnedBcb( Bcb, TRUE, &IgnoreStatus ); > - > - } else { > - > - FatUnpinBcb(IrpContext, Bcb); > - } > - > - DebugTrace(-1, Dbg, "FatSetFatEntry -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -// > -// Internal support routine > -// > - > -VOID > -FatSetFatRun ( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG StartingFatIndex, > - IN ULONG ClusterCount, > - IN BOOLEAN ChainTogether > - ) > - > -/*++ > - > -Routine Description: > - > - This routine sets a continuous run of clusters in the fat. If > ChainTogether > - is TRUE, then the clusters are linked together as in normal Fat > fasion, > - with the last cluster receiving FAT_CLUSTER_LAST. If ChainTogether is > - FALSE, all the entries are set to FAT_CLUSTER_AVAILABLE, effectively > - freeing all the clusters in the run. > - > -Arguments: > - > - Vcb - Supplies the Vcb to examine, yields 12/16 bit info, etc. > - > - StartingFatIndex - Supplies the destination fat index. > - > - ClusterCount - Supplies the number of contiguous clusters to work on. > - > - ChainTogether - Tells us whether to fill the entries with links, or > - FAT_CLUSTER_AVAILABLE > - > - > -Return Value: > - > - VOID > - > ---*/ > - > -{ > -#define MAXCOUNTCLUS 0x10000 > -#define COUNTSAVEDBCBS ((MAXCOUNTCLUS * sizeof(FAT_ENTRY) / PAGE_SIZE) + > 2) > - PBCB SavedBcbs[COUNTSAVEDBCBS][2]; > - > - ULONG SectorSize; > - ULONG Cluster; > - > - LBO StartSectorLbo; > - LBO FinalSectorLbo; > - LBO Lbo; > - > - PVOID PinnedFat; > - > -#ifndef __REACTOS__ > - ULONG StartingPage; > -#endif > - > - BOOLEAN ReleaseMutex = FALSE; > - > - ULONG SavedStartingFatIndex = StartingFatIndex; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "FatSetFatRun\n", 0); > - DebugTrace( 0, Dbg, " Vcb = %8lx\n", Vcb); > - DebugTrace( 0, Dbg, " StartingFatIndex = %8x\n", StartingFatIndex); > - DebugTrace( 0, Dbg, " ClusterCount = %8lx\n", ClusterCount); > - DebugTrace( 0, Dbg, " ChainTogether = %s\n", ChainTogether ? > "TRUE":"FALSE"); > - > - // > - // Make sure they gave us a valid fat run. > - // > - > - FatVerifyIndexIsValid(IrpContext, Vcb, StartingFatIndex); > - FatVerifyIndexIsValid(IrpContext, Vcb, StartingFatIndex + > ClusterCount - 1); > - > - // > - // Check special case > - // > - > - if (ClusterCount == 0) { > - > - DebugTrace(-1, Dbg, "FatSetFatRun -> (VOID)\n", 0); > - return; > - } > - > - // > - // Set Sector Size > - // > - > - SectorSize = 1 << Vcb->AllocationSupport.LogOfBytesPerSector; > - > - // > - // Case on 12 or 16 bit fats. > - // > - // In the 12 bit case (mostly floppies) we always have the whole fat > - // (max 6k bytes) pinned during allocation operations. This is > possibly > - // a wee bit slower, but saves headaches over fat entries with 8 bits > - // on one page, and 4 bits on the next. > - // > - // In the 16 bit case we only read one page at a time, as needed. > - // > - > - // > - // DEAL WITH 12 BIT CASE > - // > - > - _SEH2_TRY { > - > - if (Vcb->AllocationSupport.FatIndexBitSize == 12) { > - > -#ifndef __REACTOS__ > - StartingPage = 0; > -#endif > - > - // > - // We read in the entire fat. Note that using prepare write > marks > - // the bcb pre-dirty, so we don't have to do it explicitly. > - // > - > - RtlZeroMemory( &SavedBcbs[0], 2 * sizeof(PBCB) * 2); > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - FatReservedBytes( &Vcb->Bpb ), > - FatBytesPerFat( &Vcb->Bpb ), > - &SavedBcbs[0][0], > - &PinnedFat, > - TRUE, > - FALSE ); > - > - // > - // Mark the affected sectors dirty. Note that > FinalSectorLbo is > - // the Lbo of the END of the entry (Thus * 3 + 2). This > makes sure > - // we catch the case of a dirty fat entry straddling a > sector boundry. > - // > - // Note that if the first AddMcbEntry succeeds, all > following ones > - // will simply coalese, and thus also succeed. > - // > - > - StartSectorLbo = (FatReservedBytes( &Vcb->Bpb ) + > StartingFatIndex * 3 / 2) > - & ~(SectorSize - 1); > - > - FinalSectorLbo = (FatReservedBytes( &Vcb->Bpb ) + > ((StartingFatIndex + > - ClusterCount) * 3 + 2) / 2) & ~(SectorSize - > 1); > - > - for (Lbo = StartSectorLbo; Lbo <= FinalSectorLbo; Lbo += > SectorSize) { > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize ); > - } > - > - // > - // Store the entries into the fat; we need a little > - // synchonization here and can't use a spinlock since the > bytes > - // might not be resident. > - // > - > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > - > - for (Cluster = StartingFatIndex; > - Cluster < StartingFatIndex + ClusterCount - 1; > - Cluster++) { > - > - FatSet12BitEntry( PinnedFat, > - Cluster, > - ChainTogether ? Cluster + 1 : > FAT_CLUSTER_AVAILABLE ); > - } > - > - // > - // Save the last entry > - // > - > - FatSet12BitEntry( PinnedFat, > - Cluster, > - ChainTogether ? > - FAT_CLUSTER_LAST & 0xfff : > FAT_CLUSTER_AVAILABLE ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > - > - } else if (Vcb->AllocationSupport.FatIndexBitSize == 32) { > - > - // > - // DEAL WITH 32 BIT CASE > - // > - > - for (;;) { > - > - VBO StartOffsetInVolume; > - VBO FinalOffsetInVolume; > - > - ULONG Page; > - ULONG FinalCluster; > - PULONG FatEntry; > - ULONG ClusterCountThisRun; > - > - StartOffsetInVolume = FatReservedBytes(&Vcb->Bpb) + > - StartingFatIndex * > sizeof(FAT_ENTRY); > - > - if (ClusterCount > MAXCOUNTCLUS) { > - ClusterCountThisRun = MAXCOUNTCLUS; > - } else { > - ClusterCountThisRun = ClusterCount; > - } > - > - FinalOffsetInVolume = StartOffsetInVolume + > - (ClusterCountThisRun - 1) * > sizeof(FAT_ENTRY); > - > -#ifndef __REACTOS__ > - StartingPage = StartOffsetInVolume / PAGE_SIZE; > -#endif > - > - { > - ULONG NumberOfPages; > - ULONG Offset; > - > - NumberOfPages = (FinalOffsetInVolume / PAGE_SIZE) - > - (StartOffsetInVolume / PAGE_SIZE) + 1; > - > - RtlZeroMemory( &SavedBcbs[0][0], (NumberOfPages + 1) > * sizeof(PBCB) * 2 ); > - > - for ( Page = 0, Offset = StartOffsetInVolume & > ~(PAGE_SIZE - 1); > - Page < NumberOfPages; > - Page++, Offset += PAGE_SIZE ) { > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - Offset, > - PAGE_SIZE, > - &SavedBcbs[Page][0], > - (PVOID > *)&SavedBcbs[Page][1], > - TRUE, > - FALSE ); > - > - if (Page == 0) { > - > - FatEntry = (PULONG)((PUCHAR)SavedBcbs[0][1] + > - (StartOffsetInVolume % > PAGE_SIZE)); > - } > - } > - } > - > - // > - // Mark the run dirty > - // > - > - StartSectorLbo = StartOffsetInVolume & ~(SectorSize - 1); > - FinalSectorLbo = FinalOffsetInVolume & ~(SectorSize - 1); > - > - for (Lbo = StartSectorLbo; Lbo <= FinalSectorLbo; Lbo += > SectorSize) { > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO)Lbo, > Lbo, SectorSize ); > - } > - > - // > - // Store the entries > - // > - // We need extra synchronization here for broken > architectures > - // like the ALPHA that don't support atomic 16 bit > writes. > - // > - > -#ifdef ALPHA > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > -#endif // ALPHA > - > - FinalCluster = StartingFatIndex + ClusterCountThisRun - 1; > - Page = 0; > - > - for (Cluster = StartingFatIndex; > - Cluster <= FinalCluster; > - Cluster++, FatEntry++) { > - > - // > - // If we just crossed a page boundry (as opposed to > starting > - // on one), update our idea of FatEntry. > - > - if ( (((ULONG_PTR)FatEntry & (PAGE_SIZE-1)) == 0) && > - (Cluster != StartingFatIndex) ) { > - > - Page += 1; > - FatEntry = (PULONG)SavedBcbs[Page][1]; > - } > - > - *FatEntry = ChainTogether ? (FAT_ENTRY)(Cluster + 1) : > - FAT_CLUSTER_AVAILABLE; > - } > - > - // > - // Fix up the last entry if we were chaining together > - // > - > - if ((ClusterCount <= MAXCOUNTCLUS) && > - ChainTogether ) { > - > - *(FatEntry-1) = FAT_CLUSTER_LAST; > - } > - > -#ifdef ALPHA > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > -#endif // ALPHA > - > - { > - ULONG i = 0; > - // > - // Unpin the Bcbs > - // > - > - while ( SavedBcbs[i][0] != NULL ) { > - > - FatUnpinBcb( IrpContext, SavedBcbs[i][0] ); > - SavedBcbs[i][0] = NULL; > - > - i += 1; > - } > - } > - > - if (ClusterCount <= MAXCOUNTCLUS) { > - > - break; > - > - } else { > - > - StartingFatIndex += MAXCOUNTCLUS; > - ClusterCount -= MAXCOUNTCLUS; > - } > - } > - > - } else { > - > - // > - // DEAL WITH 16 BIT CASE > - // > - > - VBO StartOffsetInVolume; > - VBO FinalOffsetInVolume; > - > - ULONG Page; > - ULONG FinalCluster; > - PUSHORT FatEntry; > - > - StartOffsetInVolume = FatReservedBytes(&Vcb->Bpb) + > - StartingFatIndex * sizeof(USHORT); > - > - FinalOffsetInVolume = StartOffsetInVolume + > - (ClusterCount - 1) * > sizeof(USHORT); > - > -#ifndef __REACTOS__ > - StartingPage = StartOffsetInVolume / PAGE_SIZE; > -#endif > - > - // > - // Read in one page of fat at a time. We cannot read in the > - // all of the fat we need because of cache manager > limitations. > - // > - // SavedBcb was initialized to be able to hold the largest > - // possible number of pages in a fat plus and extra one to > - // accomadate the boot sector, plus one more to make sure > there > - // is enough room for the RtlZeroMemory below that needs the > mark > - // the first Bcb after all the ones we will use as an end > marker. > - // > - > - { > - ULONG NumberOfPages; > - ULONG Offset; > - > - NumberOfPages = (FinalOffsetInVolume / PAGE_SIZE) - > - (StartOffsetInVolume / PAGE_SIZE) + 1; > - > - RtlZeroMemory( &SavedBcbs[0][0], (NumberOfPages + 1) * > sizeof(PBCB) * 2 ); > - > - for ( Page = 0, Offset = StartOffsetInVolume & > ~(PAGE_SIZE - 1); > - Page < NumberOfPages; > - Page++, Offset += PAGE_SIZE ) { > - > - FatPrepareWriteVolumeFile( IrpContext, > - Vcb, > - Offset, > - PAGE_SIZE, > - &SavedBcbs[Page][0], > - (PVOID > *)&SavedBcbs[Page][1], > - TRUE, > - FALSE ); > - > - if (Page == 0) { > - > - FatEntry = (PUSHORT)((PUCHAR)SavedBcbs[0][1] + > - (StartOffsetInVolume % > PAGE_SIZE)); > - } > - } > - } > - > - // > - // Mark the run dirty > - // > - > - StartSectorLbo = StartOffsetInVolume & ~(SectorSize - 1); > - FinalSectorLbo = FinalOffsetInVolume & ~(SectorSize - 1); > - > - for (Lbo = StartSectorLbo; Lbo <= FinalSectorLbo; Lbo += > SectorSize) { > - > - FatAddMcbEntry( Vcb, &Vcb->DirtyFatMcb, (VBO) Lbo, Lbo, > SectorSize ); > - } > - > - // > - // Store the entries > - // > - // We need extra synchronization here for broken > architectures > - // like the ALPHA that don't support atomic 16 bit writes. > - // > - > -#ifdef ALPHA > - FatLockFreeClusterBitMap( Vcb ); > - ReleaseMutex = TRUE; > -#endif // ALPHA > - > - FinalCluster = StartingFatIndex + ClusterCount - 1; > - Page = 0; > - > - for (Cluster = StartingFatIndex; > - Cluster <= FinalCluster; > - Cluster++, FatEntry++) { > - > - // > - // If we just crossed a page boundry (as opposed to > starting > - // on one), update our idea of FatEntry. > - > - if ( (((ULONG_PTR)FatEntry & (PAGE_SIZE-1)) == 0) && > - (Cluster != StartingFatIndex) ) { > - > - Page += 1; > - FatEntry = (PUSHORT)SavedBcbs[Page][1]; > - } > - > - *FatEntry = (USHORT) (ChainTogether ? (FAT_ENTRY)(Cluster > + 1) : > - > FAT_CLUSTER_AVAILABLE); > - } > - > - // > - // Fix up the last entry if we were chaining together > - // > - > - if ( ChainTogether ) { > - > - *(FatEntry-1) = (USHORT)FAT_CLUSTER_LAST; > - } > -#ifdef ALPHA > - FatUnlockFreeClusterBitMap( Vcb ); > - ReleaseMutex = FALSE; > -#endif // ALPHA > - } > - > - } _SEH2_FINALLY { > - > - ULONG i = 0; > - > - DebugUnwind( FatSetFatRun ); > - > - // > - // If we still somehow have the Mutex, release it. > - // > - > - if (ReleaseMutex) { > - > - ASSERT( _SEH2_AbnormalTermination() ); > - > - FatUnlockFreeClusterBitMap( Vcb ); > - } > - > - // > - // Unpin the Bcbs > - // > - > - while ( SavedBcbs[i][0] != NULL ) { > - > - FatUnpinBcb( IrpContext, SavedBcbs[i][0] ); > - > - i += 1; > - } > - > - // > - // At this point nothing in this finally clause should have > raised. > - // So, now comes the unsafe (sigh) stuff. > - // > - > - if ( _SEH2_AbnormalTermination() && > - (Vcb->AllocationSupport.FatIndexBitSize == 32) ) { > - > - // > - // Fat32 unwind > - // > - // This case is more complex because the FAT12 and FAT16 > cases > - // pin all the needed FAT pages (128K max), after which it > - // can't fail, before changing any FAT entries. In the Fat32 > - // case, it may not be practical to pin all the needed FAT > - // pages, because that could span many megabytes. So Fat32 > - // attacks in chunks, and if a failure occurs once the first > - // chunk has been updated, we have to back out the updates. > - // > - // The unwind consists of walking back over each FAT entry we > - // have changed, setting it back to the previous value. Note > - // that the previous value with either be > FAT_CLUSTER_AVAILABLE > - // (if ChainTogether==TRUE) or a simple link to the successor > - // (if ChainTogether==FALSE). > - // > - // We concede that any one of these calls could fail too; our > - // objective is to make this case no more likely than the > case > - // for a file consisting of multiple disjoint runs. > - // > - > - while ( StartingFatIndex > SavedStartingFatIndex ) { > - > - StartingFatIndex--; > - > - FatSetFatEntry( IrpContext, Vcb, StartingFatIndex, > - ChainTogether ? > - StartingFatIndex + 1 : FAT_CLUSTER_AVAILABLE ); > - } > - } > - > - DebugTrace(-1, Dbg, "FatSetFatRun -> (VOID)\n", 0); > - } _SEH2_END; > - > - return; > -} > - > - > -// > -// Internal support routine > -// > - > -UCHAR > -FatLogOf ( > - IN ULONG Value > - ) > - > -/*++ > - > -Routine Description: > - > - This routine just computes the base 2 log of an integer. It is only > used > - on objects that are know to be powers of two. > - > -Arguments: > - > - Value - The value to take the base 2 log of. > - > -Return Value: > - > - UCHAR - The base 2 log of Value. > - > ---*/ > - > -{ > - UCHAR Log = 0; > - > - PAGED_CODE(); > - > - DebugTrace(+1, Dbg, "LogOf\n", 0); > - DebugTrace( 0, Dbg, " Value = %8lx\n", Value); > - > - // > - // Knock bits off until we we get a one at position 0 > - // > - > - while ( (Value & 0xfffffffe) != 0 ) { > - > - Log++; > - Value >>= 1; > - } > - > - // > - // If there was more than one bit set, the file system messed up, > - // Bug Check. > - // > - > - if (Value != 0x1) { > - > - DebugTrace( 0, Dbg, "Received non power of 2.\n", 0); > - > - FatBugCheck( Value, Log, 0 ); > - } > - > - DebugTrace(-1, Dbg, "LogOf -> %8lx\n", Log); > - > - return Log; > -} > - > - > -VOID > -FatExamineFatEntries( > - IN PIRP_CONTEXT IrpContext, > - IN PVCB Vcb, > - IN ULONG StartIndex OPTIONAL, > - IN ULONG EndIndex OPTIONAL, > - IN BOOLEAN SetupWindows, > - IN PFAT_WINDOW SwitchToWindow OPTIONAL, > - IN PULONG BitMapBuffer OPTIONAL > - ) > -/*++ > - > -Routine Description: > - > - This routine handles scanning a segment of the FAT into in-memory > structures. > - > - There are three fundamental cases, with variations depending on the > FAT type: > - > - 1) During volume setup, FatSetupAllocations > - > ... 63110 lines suppressed ... > >

2 1

RosTests/RosApps in GitHub CI
by Thomas Faber 03 Nov '17

03 Nov '17

IIUC we currently always build rostests, but never rosapps in CI. Would it be possible to analyze the changed paths instead and * enable rostests iff modules/rostests/ or sdk/ was changed * enable rosapps iff modules/rosapps/ or sdk/ was changed? That should speed up builds that don't change rostests, while also making sure that changes to rosapps aren't let into master if they break build. If this is nontrivial I may have a look at it myself but someone would need to point me to the right configuration/scripts please. Thanks! -Thomas

3 3

Re: [ros-dev] [ros-diffs] [reactos] 01/01: CID 1206831 Dereference after null check
by Jerome Gardou 31 Oct '17

31 Oct '17

HI, that doesn't look good, as shown by https://reactos.org/testman/compare.php?ids=56275,56276 Jérôme Le 29/10/2017 à 11:17, Samuel Serapion a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=b3b2a23f05e5188dc1475… > > commit b3b2a23f05e5188dc1475961fcd7f036f0046d25 > Author: Samuel Serapion <samcharly(a)hotmail.com> > AuthorDate: Fri Oct 20 14:00:32 2017 -0400 > > CID 1206831 Dereference after null check > > BytesRead is an optional out parameter and must be checked before being written to. > --- > sdk/lib/rtl/memstream.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/sdk/lib/rtl/memstream.c b/sdk/lib/rtl/memstream.c > index 0549424ca4..8fe4169fb1 100644 > --- a/sdk/lib/rtl/memstream.c > +++ b/sdk/lib/rtl/memstream.c > @@ -185,7 +185,8 @@ RtlReadMemoryStream( > > Stream->Current = (PUCHAR)Stream->Current + CopyLength; > > - *BytesRead = CopyLength; > + if (BytesRead) > + *BytesRead = CopyLength; > > return S_OK; > } >

3 2

Re: [ros-dev] [ros-diffs] [reactos] 01/01: CID 1206831 Dereference after null check
by hermes.belusca＠sfr.fr 31 Oct '17

31 Oct '17

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">Certainly not a "feature", but just that (certainly because it is only for user-mode AND the out pointer is not optional) the MS dev who introduced these functions didn't want to (or just more simply forgot to) not check for such NULL pointer.</span><br> <span style="font-family:arial,helvetica,sans-serif; font-size:12px">And thus, if you pass NULL, it's just your fault if your app crashes.</span><br> <span style="font-family:arial,helvetica,sans-serif; font-size:12px">And of course, since ReactOS also want to behave similarly... we don't check for NULL either!</span><br> <br> <span style="font-family:arial,helvetica,sans-serif; font-size:12px">H.</span> <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;"> <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : xxxx<br> A : ros-dev(a)reactos.org<br> Envoyé: mardi 31 octobre 2017 16:10<br> Objet : Re: [ros-dev] [ros-diffs] [reactos] 01/01: CID 1206831 Dereference after null check<br>   <div class="gl_quoted"> <div dir="ltr">Seems like this API has a 'feature' where by it throws exceptions if <span style="font-size:12.8px">BytesRead is null?</span></div> <div class="gmail_extra">  <div class="gmail_quote">On Sun, Oct 29, 2017 at 8:02 AM, Jerome Gardou <span dir="ltr"><<a href="mailto:jerome.gardou@reactos.org" target="_blank">jerome.gardou(a)reactos.org</a>></span> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">HI,<br> <br> that doesn't look good, as shown by <a href="https://reactos.org/testman/compare.php?ids=56275,56276" rel="noreferrer" target="_blank">https://reactos.org/testman/co<wbr>mpare.php?ids=56275,56276</a><br> <br> Jérôme<br> <br> <br> Le 29/10/2017 à 11:17, Samuel Serapion a écrit : <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><a href="https://git.reactos.org/?p=reactos.git;a=commitdiff;h=b3b2a23f05e5188dc1475…" rel="noreferrer" target="_blank">https://git.reactos.org/?p=rea<wbr>ctos.git;a=commitdiff;h=b3b2a2<wbr>3f05e5188dc1475961fcd7f036f004<wbr>6d25</a><br> <br> commit b3b2a23f05e5188dc1475961fcd7f0<wbr>36f0046d25<br> Author: Samuel Serapion <<a href="mailto:samcharly@hotmail.com" target="_blank">samcharly(a)hotmail.com</a>><br> AuthorDate: Fri Oct 20 14:00:32 2017 -0400<br> <br>      CID 1206831 Dereference after null check<br>           BytesRead is an optional out parameter and must be checked before being written to.<br> ---<br>   sdk/lib/rtl/memstream.c | 3 ++-<br>   1 file changed, 2 insertions(+), 1 deletion(-)<br> <br> diff --git a/sdk/lib/rtl/memstream.c b/sdk/lib/rtl/memstream.c<br> index 0549424ca4..8fe4169fb1 100644<br> --- a/sdk/lib/rtl/memstream.c<br> +++ b/sdk/lib/rtl/memstream.c<br> @@ -185,7 +185,8 @@ RtlReadMemoryStream(<br>         Stream->Current = (PUCHAR)Stream->Current + CopyLength;<br>   -    *BytesRead = CopyLength;<br> +    if (BytesRead)<br> +        *BytesRead = CopyLength;<br>         return S_OK;<br>   }<br>  </blockquote> <br> <br> ______________________________<wbr>_________________<br> Ros-dev mailing list<br> <a href="mailto:Ros-dev@reactos.org" target="_blank">Ros-dev(a)reactos.org</a><br> <a href="http://www.reactos.org/mailman/listinfo/ros-dev" rel="noreferrer" target="_blank">http://www.reactos.org/mailman<wbr>/listinfo/ros-dev</a></blockquote> </div> </div> <br> <br> <br> _______________________________________________<br> Ros-dev mailing list<br> Ros-dev(a)reactos.org<br> http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div> </div>

1 0

Re: [ros-dev] [ros-diffs] [reactos] 01/01: [CRT] fix bug in _rotr implementation
by Jerome Gardou 28 Oct '17

28 Oct '17

Hmpf, somehow the change on my github profile was messed up. Sorry about that, the next commit should be under my real name. Jérôme Le 28/10/2017 à 10:28, zefklop a écrit : > https://git.reactos.org/?p=reactos.git;a=commitdiff;h=07c72955457267ee26f60… > > commit 07c72955457267ee26f6086e75c5595fbce76e06 > Author: zefklop <zefklop(a)users.noreply.github.com> > AuthorDate: Sat Oct 28 10:28:27 2017 +0200 > > [CRT] fix bug in _rotr implementation > --- > sdk/lib/crt/stdlib/rot.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/sdk/lib/crt/stdlib/rot.c b/sdk/lib/crt/stdlib/rot.c > index 825a76d3ed..7637a5e9b6 100644 > --- a/sdk/lib/crt/stdlib/rot.c > +++ b/sdk/lib/crt/stdlib/rot.c > @@ -38,7 +38,7 @@ unsigned int _rotr( unsigned int value, int shift ) > if ( shift < 0 ) > return _rotl(value,-shift); > > - if ( shift > max_bits<<3 ) > + if ( shift > max_bits ) > shift = shift % max_bits; > return (value >> shift) | (value << (max_bits-shift)); > } >

1 0

Status Meeting (October 2017)
by Giannis Adamopoulos 26 Oct '17

26 Oct '17

Hi all! Let me invite you to the monthly status meeting taking place today, October 26, 19:00 UTC. As of now we know that both Colin and Pierre will not be able to attend, or be able to control our IRC server so unless we get any further notice from either of them, the meeting will take place in #reactos-meeting in freenode. No agenda proposals have been submitted to me so far. You are welcome to suggest some points to discuss. One that I would like to propose is about the upcoming release that should be branched soon. Of course we will have our status reports. So please have them ready, so we get it done quickly! Giannis

3 2

JIRA up again - Do we still need FishEye?
by Colin Finck 16 Oct '17

16 Oct '17

Hi all! Our two Atlassian tools JIRA and FishEye have been unavailable for some hours again. I have brought JIRA back up, but FishEye has been eating RAM and CPU like crazy again. In my opinion, this is unacceptable for a tool that is just a simple commit browser to us. Also I don't have any time to constantly monitor it this weekend, so I'm leaving it shut down for now. With us having https://github.com/reactos/reactos/commits/master and https://git.reactos.org/?p=reactos.git;a=summary now, do we still need FishEye at all? If so, please tell me what features of it you would miss if it stays down. Maybe there are other alternatives. My last FishEye "performance" bug report took 3 months to resolve, and I'm reluctant to go the same route again for another such bug.. Cheers, Colin

3 2

Question about commits with no commit log, or commits with no files but just the log, on Git.
by Hermès BÉLUSCA - MAÏTO 16 Oct '17

16 Oct '17

‌Hello all,<br> <br> After having noticed https://github.com/reactos/reactos/commit/50ae5e7c5268222718174221366169e2b…<br> I am wondering whether it is possible to add mechanisms (like git pre-commit hooks) that check for, and<br> prevent potential problematic commits like, commits without commit log, or commits with no files (but with a log).<br> <br> Any ideas?<br> <br> Cheers,<br> Hermes

4 3

Testing Pull Requests
by Colin Finck 14 Oct '17

14 Oct '17

Hi all! Apart from basic build testing through AppVeyor and Travis-CI, you can now also run all regression tests for the code belonging to a Pull Request. Just log in to our BuildBot at https://build.reactos.org with your development account credentials (formerly "SVN credentials"), select a builder in the waterfall view and fill the field "Branch" in the "Force a Build" section. You have two options here: * "refs/pull/<ID>/head" Builds your branch, unmodified. That means, if you haven't kept your branch up to date with the main ReactOS repo, latest changes won't be included. * "refs/pull/<ID>/merge" Builds the changes of your branch merged to the main ReactOS repo. That means, latest changes in the main ReactOS repo will be included. Replace <ID> by the number of your Pull Request. As the resulting hash may be hard to predict, the "prepare source" step will now give detailed information about the latest commit included in your build: https://build.reactos.org/builders/Build%20GCCLin_x86/builds/19201/steps/pr… Have fun! Colin

3 3

GitHub Newbie Question
by Hermès BÉLUSCA - MAÏTO 10 Oct '17

10 Oct '17

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">‌Hi all,<br> <br> I've a newbie question related to GitHub pull requests: How can one see whether commits pertaining to a pull request have both a valid full committer name and email set? So far I can only see the nicknames.<br> <br> Cheers,<br> Hermes</span>

3 2

Re: [ros-dev] GitHub Newbie Question
by hermes.belusca＠sfr.fr 10 Oct '17

10 Oct '17

<span style="font-family:arial,helvetica,sans-serif; font-size:12px">Oops yeah sorry, it was about "author name", not committer name. But you've understood my point.<br> Thanks!</span><br>   <div class="gl_quote" style="margin-top: 20px; padding-top: 5px;">De : gigaherz(a)gmail.com<br> A : hermes.belusca@sfr.fr,ros-dev@reactos.org<br> Envoyé: mardi 10 octobre 2017 12:06<br> Objet : Re: [ros-dev] GitHub Newbie Question<br>   <div class="gl_quoted">Open the commit URL, such as https://github.com/reactos/reactos/commit/44060c284194546703805453f3985ed2b…, but with .patch appended to the end. This shows the author name as part of the "From:" line. The commiter doens't matter since it will be set to whoever presses the merge button. On 10 October 2017 at 11:56, Hermès BÉLUSCA - MAÏTO wrote: > ‌Hi all, > > I've a newbie question related to GitHub pull requests: How can one see > whether commits pertaining to a pull request have both a valid full > committer name and email set? So far I can only see the nicknames. > > Cheers, > Hermes > _______________________________________________ > 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</div> <div class="gl_quoted"> </div> </div>

1 0

Re: [ros-dev] [ros-diffs] [reactos] 01/01: Fix remaining text file line endings in the tree. (#18)
by Colin Finck 06 Oct '17

06 Oct '17

Sorry for the huge diff E-Mail to ros-diffs! I have just configured git_multimail.py to a maximum of 5000 lines to not let that happen again. We can again reduce the limit later on if it turns out to be still too much. Best regards, Colin Finck

1 0

Re: [ros-dev] ReactOS Repository migrated to GitHub
by Can Tasan 04 Oct '17

04 Oct '17

Congrats for switching into Github! Just a little question. Is there any way to return using revision numbers? Current hash-based commit tagging might be confusing, hard to find, not reflecting at-the-time state of development since we have relied on SVN for a long time. Also for bug reporting, revision numbers is more helpful. Secondly, for example, Wine don't (and probably won't) care for hashes as everyone out there uses release builds, and release period is just 2 weeks. That's not the case for ReactOS. In just a few commits big changes might occur, and everyone retests. 3 months? Avalanche! If it isn't viable, could we seek for another solution? (e.g timestamp...) Lastly, git.reactos.org is quite simple for watching the stream, and perfect! Best regards, Can

2 1

Re: [ros-dev] ReactOS Repository migrated to GitHub
by hermes.belusca＠sfr.fr 03 Oct '17

03 Oct '17

<span style="font-family: arial,helvetica,sans-serif; font-size: 12px;">Ahah!! Correct, you've a watchful eye!<br> Thank you very much!<br> <br> Hermès.‌</span> <div class="gl_quote" style="padding-top: 5px; margin-top: 20px;">De : magnusjjj(a)gmail.com<br> A : ros-dev(a)reactos.org<br> Envoyé: mardi 3 octobre 2017 20:09<br> Objet : Re: [ros-dev] ReactOS Repository migrated to GitHub<br>   <div class="gl_quoted"> <div dir="ltr">Are they not under the branches dropdown? Top left, three columns down? There is a handy drop down there. There are at least all the gsoc's, and a ton of other branches there? :). Check it out?</div> <div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2">  <table style="border-top-color: rgb(211, 212, 222); border-top-width: 1px; border-top-style: solid;"> <tbody> <tr> <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&ut…" target="_blank"><img width="46" height="29" style="width: 46px; height: 29px;" alt="" src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-anima…"></a></td> <td style="width: 470px; color: rgb(65, 66, 78); line-height: 18px; padding-top: 12px; font-family: Arial,Helvetica,sans-serif; font-size: 13px;">Virus-free. <a style="color: rgb(68, 83, 234);" href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&ut…" target="_blank">www.avast.com</a></td> </tr> </tbody> </table> </div> <div class="gmail_extra">  <div class="gmail_quote">2017-10-03 19:45 GMT+02:00 Hermès BÉLUSCA-MAÏTO <span dir="ltr"><<a href="mailto:hermes.belusca@sfr.fr" target="_blank">hermes.belusca(a)sfr.fr</a>></span>: <blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: solid;">Thank you very much Colin !! \o/ \o/ \o/ \o/<br> <br> A little question, although: Where are our (experimental) branches now? :P<br> <br> Hermès<br> <br> > -----Message d'origine-----<br> > De : Ros-dev [mailto:<a href="mailto:ros-dev-bounces@reactos.org">ros-dev-bounces@<wbr>reactos.org</a>] De la part de Colin Finck<br> > Envoyé : mardi 3 octobre 2017 19:40<br> > À : <a href="mailto:ros-announce@reactos.org">ros-announce(a)reactos.org</a>; <a href="mailto:ros-general@reactos.org">ros-general(a)reactos.org</a>; 'ReactOS<br> > Development List'<br> > Objet : [ros-dev] ReactOS Repository migrated to GitHub <div class="HOEnZb"> <div class="h5">><br> > Today, the ReactOS Source Code has been migrated from a central Subversion<br> > instance to a decentralized Git repository. Together with that, ReactOS joins the<br> > list of projects using the popular GitHub service for developing software:<br> > <a href="https://github.com/reactos/reactos" target="_blank" rel="noreferrer">https://github.com/reactos/<wbr>reactos</a><br> > We expect that this move greatly improves the way we collaborate on ReactOS<br> > development and reduces the barriers for newcomers. Just fork our repository<br> > on GitHub, commit your changes and send us a Pull Request!<br> ><br> > Migrating a source code history of more than 20 years that had seen multiple<br> > version control systems was not a straightforward task.<br> > Deciding on a decentralized version control system has not been either.<br> > First discussions already started back in 2009, when neither Git nor Mercurial<br> > were able to fully convert a large SVN repository like ours and Git’s Windows<br> > support was still neglected. Things improved massively over the years, with<br> > GitHub and Git for Windows emerging as reliable tools for software<br> > development. But the ReactOS Project still took advantage of some Subversion<br> > features, so only a smooth migration using a two-way SVN-Git mirror was<br> > attempted in 2016. This failed miserably, however important lessons were<br> > learned for a future complete migration to Git. The tipping point was reached<br> > in early 2017 when a majority of ReactOS developers spoke out in favor of<br> > moving to Git. Finally, the ReactOS Hackfest in August offered a forum to try<br> > out things and discuss every little detail of the planned migration. And this is<br> > what got us here today!<br> ><br> > The development documentation is still in the process of being rewritten to<br> > account for the Git migration. You may currently find outdated information<br> > here and there. However, most of that is on the Wiki, so you are more than<br> > welcome to help us!<br> > The SVN Repository has been turned read-only and will be kept online for a<br> > while at the last revision r76032. Our Git mirror now mirrors the GitHub<br> > repository. If you have already been using our old Git mirror, please note that<br> > you have to do a fresh clone of our new repository (from either GitHub or the<br> > mirror) as the old and new ones are incompatible.<br> > JIRA continues to be used for bug tracking, BuildBot for continuous integration,<br> > and FishEye as a code browser.<br> ><br> > I would like to thank all the people who have helped with this migration, be it<br> > on IRC, the mailing lists or at the Hackfest! Special thanks also go to the KDE<br> > Project for their excellent svn-all-fast-export tool that was used for the<br> > conversion. If you are ever in a similar situation, have a look at my conversion<br> > scripts as well as the Git helpers for our infrastructure.<br> ><br> ><br> > Colin Finck<br> ><br> > ______________________________<wbr>_________________<br> > Ros-dev mailing list<br> > <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> > <a href="http://www.reactos.org/mailman/listinfo/ros-dev" target="_blank" rel="noreferrer">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a><br> <br> <br> ______________________________<wbr>_________________<br> Ros-dev mailing list<br> <a href="mailto:Ros-dev@reactos.org">Ros-dev(a)reactos.org</a><br> <a href="http://www.reactos.org/mailman/listinfo/ros-dev" target="_blank" rel="noreferrer">http://www.reactos.org/<wbr>mailman/listinfo/ros-dev</a></div> </div> </blockquote> </div> </div> <br> <br> <br> _______________________________________________<br> Ros-dev mailing list<br> Ros-dev(a)reactos.org<br> http://www.reactos.org/mailman/listinfo/ros-dev</div> <div class="gl_quoted"> </div> </div>

1 0

ReactOS Repository migrated to GitHub
by Colin Finck 03 Oct '17

03 Oct '17

Today, the ReactOS Source Code has been migrated from a central Subversion instance to a decentralized Git repository. Together with that, ReactOS joins the list of projects using the popular GitHub service for developing software: https://github.com/reactos/reactos We expect that this move greatly improves the way we collaborate on ReactOS development and reduces the barriers for newcomers. Just fork our repository on GitHub, commit your changes and send us a Pull Request! Migrating a source code history of more than 20 years that had seen multiple version control systems was not a straightforward task. Deciding on a decentralized version control system has not been either. First discussions already started back in 2009, when neither Git nor Mercurial were able to fully convert a large SVN repository like ours and Git’s Windows support was still neglected. Things improved massively over the years, with GitHub and Git for Windows emerging as reliable tools for software development. But the ReactOS Project still took advantage of some Subversion features, so only a smooth migration using a two-way SVN-Git mirror was attempted in 2016. This failed miserably, however important lessons were learned for a future complete migration to Git. The tipping point was reached in early 2017 when a majority of ReactOS developers spoke out in favor of moving to Git. Finally, the ReactOS Hackfest in August offered a forum to try out things and discuss every little detail of the planned migration. And this is what got us here today! The development documentation is still in the process of being rewritten to account for the Git migration. You may currently find outdated information here and there. However, most of that is on the Wiki, so you are more than welcome to help us! The SVN Repository has been turned read-only and will be kept online for a while at the last revision r76032. Our Git mirror now mirrors the GitHub repository. If you have already been using our old Git mirror, please note that you have to do a fresh clone of our new repository (from either GitHub or the mirror) as the old and new ones are incompatible. JIRA continues to be used for bug tracking, BuildBot for continuous integration, and FishEye as a code browser. I would like to thank all the people who have helped with this migration, be it on IRC, the mailing lists or at the Hackfest! Special thanks also go to the KDE Project for their excellent svn-all-fast-export tool that was used for the conversion. If you are ever in a similar situation, have a look at my conversion scripts as well as the Git helpers for our infrastructure. Colin Finck

3 2

Regression in r75772 broke multiple disk drive support
by Dimitrij Klingbeil 03 Oct '17

03 Oct '17

Hi all, It looks like revision 75772 (removed a "DeviceExt->OpenHandleCount--;") has introduced some significant unintended consequences. Ever since I can't get ReactOS to recognize a second hard drive. My configuration is like this: - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 - VM configured for Windows 2003 32-bit, with 1 CPU - Emulated Chipset: PIIX3, no USB, no Audio, no Serial - AMD-V active, Nested Paging active, - No paravirtualization interface, no guest additions - Emulated Storage: SATA controller with 4 ports - Port 0: First Hard disk (has partition C) - Port 1: Second Hard disk (has partition D) - Port 3: CDROM (to install ReactOS from, E) - Each hard disk has one single primary partition (FAT formatted by an older ReactOS setup) - On C I install ReactOS (re-formatting the partition in the process) - On D there is some data (a small collection of program installers to try out) Now, inside ReactOS I cannot see the contents of D. The drive itself shows up, but unformatted and of a zero size. In the revisions before 75772 there were no problems, I could see the drive and use the data on it. Re-installing r75771 shows that the drive image is OK and the data is still there, so it's not the data that was corrupted. If I insert a CDROM image (with ReactOS already running), the CDROM drive (E) suddently disappears and D now has the CDROM in it (so happened just now with r75872). When I eject the CDROM, D becomes empty but still shows the icon for a CDROM. E does not re-appear. 75772 looks like a very small change, but something must have gone really off the rails... Regards, Dimitrij P.S. This was at first sent from the wrong (not subscribed to the list) address by mistake. I think the first one was rejected by the list SW, but sorry if the message appears twice.

2 4

Status Meeting (September 2017)
by Colin Finck 28 Sep '17

28 Sep '17

Hi all! Let me invite you to the monthly status meeting taking place today, September 28, 19:00 UTC. As always, you will get credentials for our private IRC server shortly before the meeting. No agenda proposals have been submitted to me so far. If that doesn't change, we will have a meeting just for the status reports. Please have them ready, so we get it done quickly! A lot of tasks from our long last meeting are also still in progress (not just the Git migration), so I wouldn't mind having a short meeting this time. See you in a few hours! Colin

1 1

once agaon about ReactOS trademark infringement by Facebook
by Alexander Rechitskiy 28 Sep '17

28 Sep '17

3 2

Re: [ros-dev] once agaon about ReactOS trademark infringement by Facebook
by David Quintana (gigaherz) 28 Sep '17

28 Sep '17

Your email client is showing you the raw HTML, which contains "&" in place of the & sign. The real link is: https://www.reactos.org/forum/viewtopic.php?f=2&t=16671 You may want to get an email client with HTML support ;P On 28 September 2017 at 09:37, Thomas Mueller <mueller6723(a)twc.com> wrote: > from Alexander Rechitskiy : > >> <div>Hi!</div><div> </div><div> </div><div>Please, read this!</div><div> </div><div>https://www.reactos.org/forum/viewtopic.php?f=2&t=16671</div><div> </div><div>-- <br />Best regards, Alexander Rechitskiy</div><div> </div> > > I copied and pasted your link with the mouse and got > > > Board index > Change font size > > Information > > The requested topic does not exist. > > Board index > The team • Delete all board cookies • All times are UTC + 2 hours > > But the link created by removing "amp;" following "f=2" seemed to work. > > Tom > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Git Migration on October 3!
by Colin Finck 22 Sep '17

22 Sep '17

Hi all! With our infra/toolchain now being fully prepared for the Git migration, I can finally say that there are no more blockers holding us back. Therefore I'm announcing that the migration from SVN to Git will take place on TUESDAY, OCTOBER 3, 2017 During that day (European time) SVN will be turned read-only forever and some of our services may expect temporary downtime. Let's see who will get the last commit ever to SVN :) The new repository will then be available at https://github.com/reactos/reactos, with https://git.reactos.org providing a mirror. The following things are still on the To-Do list, but I don't consider them blockers. We can work on them iteratively after the migration: * Writing a new .gitignore file. * Writing a .gitattributes file to enforce EOL style. * Writing Git guides on our Wiki for beginners and SVN users. Best regards, Colin

2 2

Re: [ros-dev] Regression in r75772 broke multiple disk drive support - format also does not work
by Dimitrij Klingbeil 20 Sep '17

20 Sep '17

Something else seems to be off the rails too... It does't seem possible to format the drive from within ReactOS either. Here's what happens when I try the command-line format utility: - Fill drive D with enough stuff (to see a clear size difference) - Start cmd.exe, then "Format D: /Q" - Format appears to run, writing a new FS - At the end, Format will display a drive size summary - The "used" size is wrong, the drive is still as full as before (!) - When going there with Explorer, the contents have not disappeared (!) - The FS structure seems to be messed up however, as - after a reboot the drive is no longer there (not raw but missing) It looks like Format does not properly unmount the drive before formatting and / or it does not re-mount it after formatting either, or at least that these steps somehow fail to work. The result seems to be a corrupted FS. However I'm not sure if formatting has ever worked - never tried before. Regards Dimitrij ----- Original Message ----- From: "Dimitrij Klingbeil" <dklingb(a)gmail.com> To: "ReactOS Development List" <ros-dev(a)reactos.org> Sent: Wednesday, September 20, 2017 9:07 PM Subject: Re: [ros-dev] Regression in r75772 broke multiple disk drive support > Hi Pierre > > Some parts of this issue seem fixed, but not all - at least not reliably. > > The second drive does appear at first. But as soon as something is done > with it (like starting a program / an installer from it), the system will > become rather temperamental. While the program does run, after the next > ReactOS reboot, the drive disappears again, and this time it completely > disappears rather than looking empty or raw-mounted. After the subsequent > reboot, the drive appears again. Hard to tell, why. > > At least that's what I've tried with an otherwise freshly formatted drive: > > - Create a directory "Software" > - Put inside the Firefox 45.9.0-ESR installer > - Start the installer > - Wait until it finishes extracting its contents in a temp location > - The installer will greet one with its "Welcome" screen > - Rather than continuing, reboot ReactOS now > - After the reboot, drive D is no longer there > - Reboot ReactOS again > - Drive D re-appears and its contents are still in place > - Try the installer again (possibly letting it finish) > - Reboot again, and the drive disappears > - Reboot an additional time, and the drive re-appears > - etc. repetitively, ad infinitum > - One reboot "breaks" something, the next one "fixes" it again > > This was seen with ReactOS r75915, tested just a moment ago. > > Regards > Dimitrij > > > ----- Original Message ----- > From: "Pierre Schweitzer" <pierre(a)reactos.org> > To: <ros-dev(a)reactos.org> > Sent: Wednesday, September 20, 2017 10:48 AM > Subject: Re: [ros-dev] Regression in r75772 broke multiple disk drive > support > > >> This regression got fixed with r75911. >> Can you confirm it's OK on your side? >> >> Le 18/09/2017 à 22:41, Pierre Schweitzer a écrit : >>> Ack. See https://jira.reactos.org/browse/CORE-13805 >>> >>> Thanks for the report. >>> >>> Le 17/09/2017 à 17:39, Dimitrij Klingbeil a écrit : >>>> Hi all, >>>> >>>> It looks like revision 75772 (removed a >>>> "DeviceExt->OpenHandleCount--;") >>>> has introduced some significant unintended consequences. >>>> Ever since I can't get ReactOS to recognize a second hard drive. >>>> >>>> My configuration is like this: >>>> - ReactOS in a VirtualBox VM, VirtualBox version 5.11.18 >>>> - VM configured for Windows 2003 32-bit, with 1 CPU >>>> - Emulated Chipset: PIIX3, no USB, no Audio, no Serial >>>> - AMD-V active, Nested Paging active, >>>> - No paravirtualization interface, no guest additions >>>> - Emulated Storage: SATA controller with 4 ports >>>> - Port 0: First Hard disk (has partition C) >>>> - Port 1: Second Hard disk (has partition D) >>>> - Port 3: CDROM (to install ReactOS from, E) >>>> - Each hard disk has one single primary partition (FAT formatted by an >>>> older >>>> ReactOS setup) >>>> - On C I install ReactOS (re-formatting the partition in the process) >>>> - On D there is some data (a small collection of program installers to >>>> try >>>> out) >>>> >>>> Now, inside ReactOS I cannot see the contents of D. The drive itself >>>> shows >>>> up, but unformatted and of a zero size. In the revisions before 75772 >>>> there >>>> were no problems, I could see the drive and use the data on it. >>>> Re-installing r75771 shows that the drive image is OK and the data is >>>> still >>>> there, so it's not the data that was corrupted. >>>> >>>> If I insert a CDROM image (with ReactOS already running), the CDROM >>>> drive >>>> (E) suddently disappears and D now has the CDROM in it (so happened >>>> just >>>> now >>>> with r75872). When I eject the CDROM, D becomes empty but still shows >>>> the >>>> icon for a CDROM. E does not re-appear. >>>> >>>> 75772 looks like a very small change, but something must have gone >>>> really >>>> off the rails... >>>> >>>> Regards, >>>> Dimitrij >>>> >>>> >>>> >>>> P.S. This was at first sent from the wrong (not subscribed to the list) >>>> address by mistake. I think the first one was rejected by the list SW, >>>> but sorry if the message appears twice. >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >>> >> >> >> -- >> Pierre Schweitzer <pierre at reactos.org> >> System & Network Administrator >> Senior Kernel Developer >> ReactOS Deutschland e.V. >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Rethinking our Git merge workflow
by Colin Finck 19 Sep '17

19 Sep '17

Hi all! After playing around with GitHub's features in https://github.com/colinfinck/sandbox for the last few days, it turns out that its server-side settings hardly prevent repository mess. Although I have set master to be a "protected branch" and enabled the option "Require branches to be up to date before merging", it allows me to push just everything that doesn't rewrite history. This includes any kind of merge commits, even the nasty automatic merges that occur when you commit to your outdated local master and then do the requested "git pull" before pushing. GitHub Staff confirmed to me that GitHub has no way of enforcing a rebase-only workflow. For a self-hosted Git, a simple pre-receive hook like https://stackoverflow.com/a/5493549 would do the trick. The only other option GitHub offers is requiring each commit to go to a branch. Changes to master can only happen through an approved Pull Request then. This would drastically change our workflow though, and I don't think we want this additional burden for every minor change. Before we now reverse our decision for a GitHub master repo, let's verify that a self-hosted Git repo with an enforced rebase-only workflow is really what we want: - It would ensure a linear history in the "master" branch, just like WINE has. If you sort by "Commit Date" instead of "Author Date", the history would even be chronological. - When contributing changes from a branch back to "master" using "git rebase", every single commit is reapplied with a new hash. Except for the author dates, these commits have no link to the original branch. - Without GitHub as the master repo, we would lose the ability to merge Pull Requests directly from the website. That would sooner or later turn the entire Pull Request feature of GitHub useless for us. Contrary to what people told me, GitHub doesn't detect when you merge the Pull Request locally and push these changes back to GitHub. On the other hand, what would an unrestricted GitHub provide us: - Discussing, improving, and later merging Pull Requests directly on the website. Merging, squash merging, and rebase merging is supported. Not just for our own branches, but also for forks of the ReactOS repo. - Our history graph in the "master" branch will inevitably become a stream of parallel lines, making it harder to follow the history chronologically. Worst-case example is the Linux kernel: http://fs5.directupload.net/images/170914/h5pddxx7.png (ok, admittedly gitk renders this graph a bit nicer) Allowing merges used to be an even bigger problem when we still wanted a linear history to replicate SVN revision numbers. But we now replaced revision numbers by the output of "git describe". So maybe merge commits are ok now? At least, we should be able to prevent automatic merge commits by instructing every committer to use "git fetch && git rebase origin" instead of "git pull" when syncing with the server. A nicely written and illustrated (Tortoise)Git guide on the Wiki should do the job :) I tend to favor the second option right now and allow merges, but I definitely need more input on this from you. Best regards, Colin

5 7

Re: [ros-dev] Rethinking our Git merge workflow
by Alex Ionescu 15 Sep '17

15 Sep '17

Yes, I prefer GitHub too. I just meant GitLab > BitBucket :) Best regards, Alex Ionescu On Fri, Sep 15, 2017 at 4:02 PM, Colin Finck <colin(a)reactos.org> wrote: > Am 15.09.2017 um 02:26 schrieb Alex Ionescu: > > Have you looked at GitLabs? BitBucket is a shit show. > > GitLab would be my option if we ever need to move away from GitHub. > But as long as people are okay with contributing exclusively through > Pull Requests, GitHub is a viable solution for us. > I think the added exposure and easier access for newcomers are worth > changing our development model. > > > Cheers, > > Colin > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] Rethinking our Git merge workflow
by Alex Ionescu 15 Sep '17

15 Sep '17

Have you looked at GitLabs? BitBucket is a shit show. Best regards, Alex Ionescu On Fri, Sep 15, 2017 at 1:07 AM, Thomas Faber <thomas.faber(a)reactos.org> wrote: > I'm wary of opening up pushing to master. If we really want a linear > history, it should be enforced. Accidents with version control happen > all the time (when was the last time the SVN pre-commit hook stopped you > from committing because you forgot to set eol-style?). > > I wouldn't mind forcing the use of pull requests, assuming we can set it > up so that merge is allowed with no reviews (those would be recommended, > but enforcing them seems too much). > > Though I'm also okay with giving up the linear history idea altogether, > or hosting the repo elsewhere (e.g. we could host a Bitbucket instance). > > > On 2017-09-14 17:48, David Quintana (gigaherz) wrote: > >> I vote for recommending devs to use pull requests, and to make it a >> semi-strict policy that devs who push directly to master should ALWAYS >> make >> sure to pull and rebase before pushing. >> >> I myself intend on almost exclusively contribute through pull requests. >> This means: >> >> 1. I'll push to my own fork, and work backed by the fork >> 2. When I'm done doing something, I will use the pull request feature, >> rather than "git push upstream/master" >> 3. If the changes are non-trivial, I'll ask for a second opinion from >> some other developer >> 4. I'll push "merge with rebase" myself, but only when I feel the >> changes are "sufficiently approved" >> >> I would vote for using such a workflow as a primary way of contributing, >> since it avoids all sorts of issues, and has the added benefit of the >> automatic "merge with rebase". >> >> On 14 September 2017 at 17:23, Colin Finck <colin(a)reactos.org> wrote: >> >> Hi all! >>> >>> After playing around with GitHub's features in >>> https://github.com/colinfinck/sandbox for the last few days, it turns >>> out that its server-side settings hardly prevent repository mess. >>> >>> Although I have set master to be a "protected branch" and enabled the >>> option "Require branches to be up to date before merging", it allows me >>> to push just everything that doesn't rewrite history. This includes any >>> kind of merge commits, even the nasty automatic merges that occur when >>> you commit to your outdated local master and then do the requested "git >>> pull" before pushing. >>> GitHub Staff confirmed to me that GitHub has no way of enforcing a >>> rebase-only workflow. For a self-hosted Git, a simple pre-receive hook >>> like https://stackoverflow.com/a/5493549 would do the trick. >>> >>> The only other option GitHub offers is requiring each commit to go to a >>> branch. Changes to master can only happen through an approved Pull >>> Request then. This would drastically change our workflow though, and I >>> don't think we want this additional burden for every minor change. >>> >>> Before we now reverse our decision for a GitHub master repo, let's >>> verify that a self-hosted Git repo with an enforced rebase-only workflow >>> is really what we want: >>> >>> - It would ensure a linear history in the "master" branch, just like >>> WINE has. If you sort by "Commit Date" instead of "Author Date", the >>> history would even be chronological. >>> - When contributing changes from a branch back to "master" using "git >>> rebase", every single commit is reapplied with a new hash. Except for >>> the author dates, these commits have no link to the original branch. >>> - Without GitHub as the master repo, we would lose the ability to merge >>> Pull Requests directly from the website. That would sooner or later turn >>> the entire Pull Request feature of GitHub useless for us. >>> Contrary to what people told me, GitHub doesn't detect when you merge >>> the Pull Request locally and push these changes back to GitHub. >>> >>> >>> On the other hand, what would an unrestricted GitHub provide us: >>> >>> - Discussing, improving, and later merging Pull Requests directly on the >>> website. Merging, squash merging, and rebase merging is supported. Not >>> just for our own branches, but also for forks of the ReactOS repo. >>> - Our history graph in the "master" branch will inevitably become a >>> stream of parallel lines, making it harder to follow the history >>> chronologically. Worst-case example is the Linux kernel: >>> http://fs5.directupload.net/images/170914/h5pddxx7.png >>> (ok, admittedly gitk renders this graph a bit nicer) >>> >>> Allowing merges used to be an even bigger problem when we still wanted a >>> linear history to replicate SVN revision numbers. But we now replaced >>> revision numbers by the output of "git describe". So maybe merge commits >>> are ok now? >>> At least, we should be able to prevent automatic merge commits by >>> instructing every committer to use "git fetch && git rebase origin" >>> instead of "git pull" when syncing with the server. A nicely written and >>> illustrated (Tortoise)Git guide on the Wiki should do the job :) >>> >>> >>> I tend to favor the second option right now and allow merges, but I >>> definitely need more input on this from you. >>> >>> >>> Best regards, >>> >>> Colin >>> >> > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

2 1

Git Migration Newsletter #2
by Colin Finck 13 Sep '17

13 Sep '17

Hi all! Let me give a short update on the Git Migration: * The data from the committer table has been converted into an identity map for the SVN->Git conversion tool: https://github.com/ColinFinck/reactos-git-conversion-scripts/blob/master/re… Together with my hacked version of svn-all-fast-export (https://github.com/ColinFinck/svn2git), this results in a really nice and clean Git repo :) Further changes to your names or E-Mail addresses in that committer table won't be taken into account. Please add your GitHub usernames to that table though! * As you can imagine, our tree and tools need several changes to deal with the change from SVN revision numbers to Git commit hashes. My first patch for reporting the "Git revision" in our codebase is ready and open for discussion: https://github.com/ColinFinck/reactos-git-conversion-scripts/commit/0aaa6ff… More to follow! Cheers, Colin

1 0

Git Migration Newsletter
by Colin Finck 12 Sep '17

12 Sep '17

Hi all! Let me give a public update about our Git Migration Decisions after the last meeting: * The migration of our SVN repository "reactos" is going to happen in September/October. * https://github.com/reactos/reactos will become our master repository as we want to take advantage of GitHub's Pull Request features. This means, all developers must register for GitHub accounts now. * git.reactos.org will remain as a replication slave. If we ever have severe problems with GitHub, we can switch back to a self-hosted Git in no time. * We will enforce a linear history in the "master" branch through server-side GitHub settings. You may create and push as many branches as you want and do whatever you want there, but when you want to commit the changes back to "master", you can only do so over a "git rebase". * BuildBot builds will get a naming scheme like: reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z That means 344 commits after the tag "0.4.7-dev" has been created, with this particular commit having the short hash "5f3c53e2a". Whenever we branch for a release like "0.4.6", we will now not just create the branch, but also tag "master" with "0.4.7-dev" to make this naming scheme possible. More newsletters like this may follow when I have more information to share or get the impression that some decisions haven't reached all developers yet. Best regards, Colin

4 6

Re: [ros-dev] Git Migration Newsletter
by David Quintana (gigaherz) 10 Sep '17

10 Sep '17

The git repository data is compressed, and takes in the order of 100 mb. The checkout size will be somilar but the .git folder is much more compact than the .svn folder. On 10 Sep 2017 10:08 am, "Michael Fritscher" <michael(a)fritscher.net> wrote: Hi, are there estimation about the size of a git clone vs. a svn checkout? I'm afraid that I'll need to free much space beforehand... Best regards, Michael Fritscher > If you mean your local working copy: clone into a separate folder, and > copy > over the files. Subversion checkout is only the current commit data, while > git clones contain ALL THE HISTORY, so you can't "migrate" anything, > because the svn metadata doesn't contain any of the needed info. Even if > you could somehow migrate using a tool, the tool would still have to > perform a clone, and would just import the file status. > > On 6 September 2017 at 23:06, Thomas Mueller <mueller6723(a)twc.com> wrote: > >> from Colin Finck: >> >> > Let me give a public update about our Git Migration Decisions after >> the >> last >> > meeting: >> >> > * The migration of our SVN repository "reactos" is going to happen in >> > September/October. >> >> > * https://github.com/reactos/reactos will become our master repository >> as we >> > want to take advantage of GitHub's Pull Request features. >> > This means, all developers must register for GitHub accounts now. >> >> > * git.reactos.org will remain as a replication slave. If we ever have >> severe >> > problems with GitHub, we can switch back to a self-hosted Git in no >> time. >> >> > * We will enforce a linear history in the "master" branch through >> server-side >> > GitHub settings. You may create and push as many branches as you want >> and do >> > whatever you want there, but when you want to commit the changes back >> to >> > "master", you can only do so over a "git rebase". >> >> > * BuildBot builds will get a naming scheme like: >> >> > reactos-bootcd-0.4.7-dev+344-5f3c53e2a-gcc.7z >> >> > That means 344 commits after the tag "0.4.7-dev" has been created, >> with this >> > particular commit having the short hash "5f3c53e2a". >> > Whenever we branch for a release like "0.4.6", we will now not just >> create the >> > branch, but also tag "master" with "0.4.7-dev" to make this naming >> scheme >> > possible. >> >> >> > More newsletters like this may follow when I have more information to >> share or >> > get the impression that some decisions haven't reached all developers >> yet. >> >> Is there a convenient way to migrate an svn tree to git, or would it be >> necessary to git-clone to a separate tree? >> >> Will the boot CD images be in 7z (p7zip) format: >> >> What has kept me from trying ReactOS is not having a place to put it, >> considering ReactOS does not successfully boot from USB. >> >> My hard drives are partitioned GPT. >> >> Tom >> >> >> _______________________________________________ >> 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

2 3

Git Migration: The documentation, rossubsys and wallpapers directories
by Colin Finck 09 Sep '17

09 Sep '17

Hi all! As you know, we have to give up our "modules" directory concept when switching to Git, because Git doesn't support checking out an arbitrary directory into a subdirectory of a Git clone. Therefore, the first commit to the migrated repository will make the "reactos" directory the new root and move "rosapps" and "rostests" permanently into "modules". We can then introduce an environment variable/CMake variable/something else to enable or disable building of them on demand (suggestions are welcome!) But what will happen to the remaining directories in /trunk, namely "documentation", "rossubsys", and "wallpapers"? * Commits to "documentation" never had a relation to "reactos" commits, so nothing is lost if we put that directory into a separate repo "documentation.git" and remove all traces to it from the history of "reactos.git". I'd go this way if there are no objections. * I don't get the idea of that "rossubsys" directory created in 2014.. These subsystems are all stubs, never built with modern ReactOS, and no work has happened since "reviving" them. I would just go and remove them again. You can always find them in our repository history. * The "wallpapers" directory is a harder candidate. On the one hand, we don't want to bloat our ReactOS builds by including wallpapers in every build. Also the number of wallpapers may increase in the future, which could bloat the "reactos.git" repo even more. On the other hand, the wallpapers have always accompanied our release branches, so there is a value of having them tracked next to our code. I could put them in a separate repository "wallpapers.git" now and remove all traces to them in the "reactos.git" repo. But then again, how are they picked up by the build process in the future if we can't check them out into a subdirectory of "modules"? Another alternative is moving them to "modules/wallpapers_disabled". Then they are not picked up by the build process until they are renamed to "modules/wallpapers" for releases. What are your opinions on this? Cheers, Colin

8 15

un-official Builds of ReactOS 0.4.6 with USB support
by Alexander Rechitskiy 07 Sep '17

07 Sep '17

1 0

Bluetooth Stack
by Alexander T. 04 Sep '17

04 Sep '17

Hi all! I have to do a semester project on operating systems in my university. In GSoC 2017 ideas there is problem called «Bluetooth stack». So, is this problem already solved? If not, then could anyone tell me more about it? Sincerely, Alexandr Tsukanov

2 1

Status Meeting (August 2017)
by Colin Finck 31 Aug '17

31 Aug '17

Hi all! Let me invite you to the monthly status meeting taking place on Thursday, August 31, 19:00 UTC. As always, you will get credentials for our private IRC server shortly before the meeting. Agenda proposals so far include: - Short report from my side regarding the Hackfest - Git/GitHub migration in September/October - Finalizing the 0.4.6 release, possibly planning 0.4.7 Please post any additional agenda proposals here. Also don't forget that we're in the final week of GSoC :) Mentors, now that all code has been submitted, don't forget about evaluating your students! See you on Thursday! Colin

1 1

who is the administrator of ReactOS Facebook Group?
by Alexander Rechitskiy 30 Aug '17

30 Aug '17

4 3

Re: [ros-dev] [ros-diffs] [cfinck] 75630: [FS_REC] - Add a detection routine for CDFS (ISO-9660) volumes that verifies the Primary Volume Descriptor. - Use this to also detect CDFS on disks and load the CDFS driver if it ha...
by Pierre Schweitzer 22 Aug '17

22 Aug '17

Hi Colin, Thanks for your work. This commit is likely breaking UDFS recognition when media has a protective CDFS partition with UDFS afterwards, while both FSD are unloaded. You'll first match the CDFS recognizer and not the UDFS recognizer. I would suggest you modify FsRecRegisterFs() so that you can register low priority FS. Cheers, Pierre Le 20/08/2017 à 17:30, cfinck(a)svn.reactos.org a écrit : > Author: cfinck > Date: Sun Aug 20 15:30:59 2017 > New Revision: 75630 > > URL: http://svn.reactos.org/svn/reactos?rev=75630&view=rev > Log: > [FS_REC] > - Add a detection routine for CDFS (ISO-9660) volumes that verifies the Primary Volume Descriptor. > - Use this to also detect CDFS on disks and load the CDFS driver if it has not been loaded yet (e.g. when a bootcd/livecd flashed USB drive is inserted at boot of an installed ReactOS). > - Fix a comment in udfs.c. > > Added: > trunk/reactos/drivers/filesystems/fs_rec/cdfs.h (with props) > Modified: > trunk/reactos/drivers/filesystems/fs_rec/cdfs.c > trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c > trunk/reactos/drivers/filesystems/fs_rec/udfs.c > > Modified: trunk/reactos/drivers/filesystems/fs_rec/cdfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/cdfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/cdfs.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -1,10 +1,10 @@ > /* > - * COPYRIGHT: See COPYING in the top level directory > - * PROJECT: ReactOS File System Recognizer > - * FILE: drivers/filesystems/fs_rec/cdfs.c > - * PURPOSE: CDFS Recognizer > - * PROGRAMMER: Alex Ionescu (alex.ionescu(a)reactos.org) > - * Eric Kohl > + * PROJECT: ReactOS File System Recognizer > + * LICENSE: GPL-2.0 (https://spdx.org/licenses/GPL-2.0) > + * PURPOSE: CDFS Recognizer > + * COPYRIGHT: Copyright 2002 Eric Kohl > + * Copyright 2007 Alex Ionescu <alex.ionescu(a)reactos.org> > + * Copyright 2017 Colin Finck <colin(a)reactos.org> > */ > > /* INCLUDES *****************************************************************/ > @@ -14,13 +14,60 @@ > #define NDEBUG > #include <debug.h> > > +#include "cdfs.h" > + > /* FUNCTIONS ****************************************************************/ > + > +BOOLEAN > +NTAPI > +FsRecIsCdfsVolume(IN PDEVICE_OBJECT DeviceObject, > + IN ULONG SectorSize) > +{ > + BOOLEAN bReturnValue = FALSE; > + LARGE_INTEGER Offset; > + PVD_HEADER pVdHeader = NULL; > + PAGED_CODE(); > + > + // Read the Primary Volume Descriptor. > + Offset.QuadPart = VD_HEADER_OFFSET; > + if (!FsRecReadBlock(DeviceObject, &Offset, sizeof(VD_HEADER), SectorSize, (PVOID*)&pVdHeader, NULL)) > + { > + // We cannot read this block, so no reason to let the CDFS driver try it. > + goto Cleanup; > + } > + > + // Verify the fields. > + if (pVdHeader->Type != VD_TYPE_PRIMARY) > + goto Cleanup; > + > + DPRINT("pVdHeader->Type verified!\n"); > + > + if (RtlCompareMemory(pVdHeader->Identifier, VD_IDENTIFIER, VD_IDENTIFIER_LENGTH) != VD_IDENTIFIER_LENGTH) > + goto Cleanup; > + > + DPRINT("pVdHeader->Identifier verified!\n"); > + > + if (pVdHeader->Version != VD_VERSION) > + goto Cleanup; > + > + DPRINT("pVdHeader->Version verified! This is a CDFS volume!\n"); > + > + bReturnValue = TRUE; > + > +Cleanup: > + if (pVdHeader) > + ExFreePool(pVdHeader); > + > + return bReturnValue; > +} > > NTSTATUS > NTAPI > FsRecCdfsFsControl(IN PDEVICE_OBJECT DeviceObject, > IN PIRP Irp) > { > + PDEVICE_OBJECT MountDevice; > + ULONG SectorSize; > PIO_STACK_LOCATION Stack; > NTSTATUS Status; > PAGED_CODE(); > @@ -31,8 +78,21 @@ > { > case IRP_MN_MOUNT_VOLUME: > > - /* We don't validate */ > - Status = STATUS_FS_DRIVER_REQUIRED; > + /* Assume failure */ > + Status = STATUS_UNRECOGNIZED_VOLUME; > + > + /* Get the device object and request the sector size */ > + MountDevice = Stack->Parameters.MountVolume.DeviceObject; > + if (FsRecGetDeviceSectorSize(MountDevice, &SectorSize)) > + { > + /* Check if it's an actual CDFS (ISO-9660) volume */ > + if (FsRecIsCdfsVolume(MountDevice, SectorSize)) > + { > + /* It is! */ > + Status = STATUS_FS_DRIVER_REQUIRED; > + } > + } > + > break; > > case IRP_MN_LOAD_FILE_SYSTEM: > > Added: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/cdfs.h (added) > +++ trunk/reactos/drivers/filesystems/fs_rec/cdfs.h [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -0,0 +1,24 @@ > +/* > + * PROJECT: ReactOS File System Recognizer > + * LICENSE: GPL-2.0 (https://spdx.org/licenses/GPL-2.0+) > + * PURPOSE: CDFS Recognizer > + * COPYRIGHT: Copyright 2017 Colin Finck <colin(a)reactos.org> > + */ > + > +// Information from http://wiki.osdev.org/ISO_9660#Volume_Descriptors > + > +// Structures > +typedef struct _VD_HEADER > +{ > + char Type; > + char Identifier[5]; > + char Version; > +} > +VD_HEADER, *PVD_HEADER; > + > +// Constants > +#define VD_HEADER_OFFSET 32768 // Offset of the VD Header > +#define VD_IDENTIFIER "CD001" // Identifier that must be in the Volume Descriptor > +#define VD_IDENTIFIER_LENGTH 5 // Character count of VD_IDENTIFIER > +#define VD_TYPE_PRIMARY 1 // Type code for Primary Volume Descriptor > +#define VD_VERSION 1 // Volume Descriptor Version > > Propchange: trunk/reactos/drivers/filesystems/fs_rec/cdfs.h > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/fs_rec.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -316,6 +316,7 @@ > { > ULONG DeviceCount = 0; > NTSTATUS Status; > + PDEVICE_OBJECT CdfsObject; > PDEVICE_OBJECT UdfsObject; > PAGED_CODE(); > > @@ -340,14 +341,24 @@ > DriverObject->MajorFunction[IRP_MJ_FILE_SYSTEM_CONTROL] = FsRecFsControl; > DriverObject->DriverUnload = FsRecUnload; > > - /* Register CDFS */ > - Status = FsRecRegisterFs(DriverObject, > - NULL, > - NULL, > + /* Register CDFS for CDs */ > + Status = FsRecRegisterFs(DriverObject, > + NULL, > + &CdfsObject, > L"\\Cdfs", > L"\\FileSystem\\CdfsRecognizer", > FS_TYPE_CDFS, > FILE_DEVICE_CD_ROM_FILE_SYSTEM); > + if (NT_SUCCESS(Status)) DeviceCount++; > + > + /* Register CDFS for HDDs */ > + Status = FsRecRegisterFs(DriverObject, > + CdfsObject, > + NULL, > + L"\\CdfsHdd", > + L"\\FileSystem\\CdfsHddRecognizer", > + FS_TYPE_CDFS, > + FILE_DEVICE_DISK_FILE_SYSTEM); > if (NT_SUCCESS(Status)) DeviceCount++; > > /* Register UDFS for CDs */ > > Modified: trunk/reactos/drivers/filesystems/fs_rec/udfs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/filesystems/fs_rec… > ============================================================================== > --- trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/filesystems/fs_rec/udfs.c [iso-8859-1] Sun Aug 20 15:30:59 2017 > @@ -125,7 +125,7 @@ > MountDevice = Stack->Parameters.MountVolume.DeviceObject; > if (FsRecGetDeviceSectorSize(MountDevice, &SectorSize)) > { > - /* Check if it's an actual FAT volume */ > + /* Check if it's an actual UDF volume */ > if (FsRecIsUdfsVolume(MountDevice, SectorSize)) > { > /* It is! */ > > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

2 1

Re: [ros-dev] undelate
by Magnus Johnsson 21 Aug '17

21 Aug '17

1. Send a mail to the list unsubscribe address, which will be of the form LISTNAME-leave@DOMAIN. The subject and body of this message will be ignored, so it doesn't matter what you put there. not sure if you found out this yet. Quick google for mailman, which seems to be what is used :) 2017-08-20 19:39 GMT+02:00 gmusume <gmusume(a)correo.ugr.es>: > > hi I want undelate of the group > thank > > > Enviado desde mi smartphone Samsung Galaxy. > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] [ros-diffs] [cfinck] 75586: - Add 0x96 as ISO9660 partition type to ntdddisk.h (from https://en.wikipedia.org/wiki/Partition_type) and detect it using IsRecognizedPartition. - Make our isohybrid create an MBR ...
by Alex Ionescu 21 Aug '17

21 Aug '17

This is cool work but you do realize that adding non-Windows partition types and changing Windows headers (and Windows macros) to work with them, as well as forking our CDFS from the Windows CDFS... doesn't really help compatibility move forward... It would be nice to discuss about how these changes can be done to keep our 'special' USB livecd boot and CDFS changes, without twisting the system away from its NT roots. My suggestion would be a filter driver on top of CDFS, and a re-definition of this macro to be used by the filter (or whatever code relies on it). This sounds like it would give you the best of both worlds... Best regards, Alex Ionescu On Thu, Aug 17, 2017 at 1:03 PM, <cfinck(a)svn.reactos.org> wrote: > Author: cfinck > Date: Thu Aug 17 11:03:40 2017 > New Revision: 75586 > > URL: http://svn.reactos.org/svn/reactos?rev=75586&view=rev > Log: > - Add 0x96 as ISO9660 partition type to ntdddisk.h (from > https://en.wikipedia.org/wiki/Partition_type) and detect it using > IsRecognizedPartition. > - Make our isohybrid create an MBR with partition type 0x96. > > This properly assigns a drive letter to the Live-CD and lets me boot into > desktop using "qemu -hda livecd.iso". > Fixes CORE-13184 > > Modified: > trunk/reactos/boot/CMakeLists.txt > trunk/reactos/sdk/include/psdk/ntdddisk.h > > Modified: trunk/reactos/boot/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/ > CMakeLists.txt?rev=75586&r1=75585&r2=75586&view=diff > ============================================================ > ================== > --- trunk/reactos/boot/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/boot/CMakeLists.txt [iso-8859-1] Thu Aug 17 11:03:40 > 2017 > @@ -68,7 +68,7 @@ > -eltorito-boot loader/isoboot.bin -no-emul-boot -boot-load-size 4 > -eltorito-alt-boot -eltorito-platform efi -eltorito-boot loader/efisys.bin > -no-emul-boot -hide boot.catalog > -sort ${CMAKE_CURRENT_BINARY_DIR}/bootfiles.sort > -no-cache-inodes -graft-points -path-list > ${CMAKE_CURRENT_BINARY_DIR}/bootcd.lst > - COMMAND native-isohybrid -b ${_isombr_file} > ${REACTOS_BINARY_DIR}/bootcd.iso > + COMMAND native-isohybrid -b ${_isombr_file} -t 0x96 > ${REACTOS_BINARY_DIR}/bootcd.iso > DEPENDS isombr native-isohybrid native-mkisofs > VERBATIM) > > @@ -83,7 +83,7 @@ > -eltorito-boot loader/isobtrt.bin -no-emul-boot -boot-load-size 4 > -eltorito-alt-boot -eltorito-platform efi -eltorito-boot loader/efisys.bin > -no-emul-boot -hide boot.catalog > -sort ${CMAKE_CURRENT_BINARY_DIR}/bootfiles.sort > -no-cache-inodes -graft-points -path-list > ${CMAKE_CURRENT_BINARY_DIR}/bootcdregtest.lst > - COMMAND native-isohybrid -b ${_isombr_file} ${REACTOS_BINARY_DIR}/ > bootcdregtest.iso > + COMMAND native-isohybrid -b ${_isombr_file} -t 0x96 > ${REACTOS_BINARY_DIR}/bootcdregtest.iso > DEPENDS isombr native-isohybrid native-mkisofs > VERBATIM) > > @@ -126,7 +126,7 @@ > -eltorito-boot loader/isoboot.bin -no-emul-boot -boot-load-size 4 > -eltorito-alt-boot -eltorito-platform efi -eltorito-boot loader/efisys.bin > -no-emul-boot -hide boot.catalog > -sort ${CMAKE_CURRENT_BINARY_DIR}/bootfiles.sort > -no-cache-inodes -graft-points -path-list > ${CMAKE_CURRENT_BINARY_DIR}/livecd.lst > - COMMAND native-isohybrid -b ${_isombr_file} > ${REACTOS_BINARY_DIR}/livecd.iso > + COMMAND native-isohybrid -b ${_isombr_file} -t 0x96 > ${REACTOS_BINARY_DIR}/livecd.iso > DEPENDS isombr native-isohybrid native-mkisofs > VERBATIM) > > @@ -169,7 +169,7 @@ > -eltorito-boot loader/isoboot.bin -no-emul-boot -boot-load-size 4 > -eltorito-alt-boot -eltorito-platform efi -eltorito-boot loader/efisys.bin > -no-emul-boot -hide boot.catalog > -sort ${CMAKE_CURRENT_BINARY_DIR}/bootfiles.sort > -duplicates-once -no-cache-inodes -graft-points -path-list > ${CMAKE_CURRENT_BINARY_DIR}/hybridcd.lst > - COMMAND native-isohybrid -b ${_isombr_file} ${REACTOS_BINARY_DIR}/ > hybridcd.iso > + COMMAND native-isohybrid -b ${_isombr_file} -t 0x96 > ${REACTOS_BINARY_DIR}/hybridcd.iso > DEPENDS bootcd livecd > VERBATIM) > > > Modified: trunk/reactos/sdk/include/psdk/ntdddisk.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/sdk/ > include/psdk/ntdddisk.h?rev=75586&r1=75585&r2=75586&view=diff > ============================================================ > ================== > --- trunk/reactos/sdk/include/psdk/ntdddisk.h [iso-8859-1] (original) > +++ trunk/reactos/sdk/include/psdk/ntdddisk.h [iso-8859-1] Thu Aug 17 > 11:03:40 2017 > @@ -223,6 +223,7 @@ > #ifdef __REACTOS__ > #define PARTITION_OLD_LINUX 0x43 > #define PARTITION_LINUX 0x83 > +#define PARTITION_ISO9660 0x96 > #define PARTITION_FREEBSD 0xA5 > #define PARTITION_OPENBSD 0xA6 > #define PARTITION_NETBSD 0xA9 > @@ -253,6 +254,7 @@ > ((PartitionType) == PARTITION_XINT13) || \ > ((PartitionType) == PARTITION_LINUX) || \ > ((PartitionType) == PARTITION_OLD_LINUX) || \ > + ((PartitionType) == PARTITION_ISO9660) || \ > ((PartitionType) == PARTITION_FREEBSD) || \ > ((PartitionType) == PARTITION_OPENBSD) || \ > ((PartitionType) == PARTITION_NETBSD)) > > >

2 1

undelate
by gmusume 20 Aug '17

20 Aug '17

hi I want undelate of the group thank Enviado desde mi smartphone Samsung Galaxy.

1 0

finish
by gmusume 20 Aug '17

20 Aug '17

ni. i don twant more email spam. thank u Enviado desde mi smartphone Samsung Galaxy.

1 0

Licensing - Make ReactOS conform again!
by Colin Finck 20 Aug '17

20 Aug '17

Hi all! I've held a presentation at Hackfest today regarding Licensing Best Practices, different positions about the GPL and its influence, and ways to improve ReactOS' conformance with all involved licenses. I think we should treat this subject even more seriously than others, given that we are an Open-Source project trying to provide an alternative to a proprietary product. Also licensing questions arise from time to time, which is why we should collect some answers. Please watch the video at https://youtu.be/OTVVz9VLisU or see the slides at https://svn.reactos.org/press-media/trunk/Events/2017%20-%20Hackfest/Licens… Discussions are open now! :) But if there are no objections, let's introduce SPDX license headers, .ABOUT files, and a complete license list as soon as possible. Cheers, Colin

2 2

Re: [ros-dev] [ros-diffs] [ekohl] 75611: [STOBJECT] - Add support for the hotplug icon. - Set default menu items in the context menus. - Use a timer to properly distinguish between a single and a double click on an icon. - ...
by Colin Finck 18 Aug '17

18 Aug '17

Hey Eric, The Battery icon, Hotplug icon and Quick Launch toolbars are currently developed as part of the Google Summer of Code "Taskbar Shell Extensions for ReactOS" project. Summer of Code ends next week, so you are welcome to join the Code Review at https://code.reactos.org. I guess CR-122 will be shortly updated with the latest changes there. Let's try to not duplicate efforts here ;) Best regards, Colin

2 1

ReactOS now listed in AppDB
by Erkin Alp Güney 12 Aug '17

12 Aug '17

I have recently added ReactOS as a distribution into Wine Application Compatibility database as ReactOS uses most of Wine components. ReactOS-Windows incompatibilities can now be tracked like Wine-Windows incompatibilies.

2 1

Re: [ros-dev] Ethereum for fundraiser
by Nicolò Altamura 11 Aug '17

11 Aug '17

Why not Monero too? Sent from UNKNOWN SMARTPHONE - K91820 -------- Messaggio originale -------- Da: Erkin Alp Güney <erkinalp9035(a)gmail.com> Data: 13/07/17 21:52 (GMT+01:00) A: ros-dev(a)reactos.org Oggetto: [ros-dev] Ethereum for fundraiser Ethereum is a decentralised cryptocurrency based on proof of work and proof of stake consensus with Turing-complete scripting. Utilising Ethereum for fundraiser will allow us to remove the middlemen from raising funds and allow us to distribute them more directly. I want to be first contract programmer for ReactOS ethereum account. Any kind of release schemes may be developed. However, this will need detailed discussion and official approval first. Yours, faithfully Erkin Alp _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

3 3

Re: [ros-dev] Modularizing the ReactOS repo in Git
by Alex Ionescu 04 Aug '17

04 Aug '17

I would strongly suggest using one master repo. Multi-repo projects and their brethren are a mess. Best regards, Alex Ionescu On Wed, Aug 2, 2017 at 1:18 PM, David Quintana (gigaherz) < gigaherz(a)gmail.com> wrote: > We have! If you look at Colin's email, it has a link to a google doc, we > list Repo in it, and why we think it's not fit for our use :) > > That aside, I had a new idea, which I mentioned on IRC. I have added it to > the document. > > On 2 August 2017 at 11:52, Alexander Sh. <chaez.san(a)gmail.com> wrote: > >> Have a look at Repo: https://code.google.com/archive/p/git-repo/ >> It is used by Android devs. >> >> 2 авг. 2017 г. 12:28 пользователь "David Quintana (gigaherz)" < >> gigaherz(a)gmail.com> написал: >> >> The issue comes when we have to do regression-testing. We would need a >>> tool that knows how to match up core, system, tests, ... otherwise >>> debugging regressions is going to be hellish. >>> >>> On 2 August 2017 at 11:17, Alexander Sh. <chaez.san(a)gmail.com> wrote: >>> >>>> Since we have RosBE, we can have multiple repositories without actually >>>> binding them and download them on demand. Or we can make a build script for >>>> every new small module that downloads (clones) repos it needs. >>>> >>>> 2 авг. 2017 г. 11:41 пользователь "Colin Finck" <colin(a)reactos.org> >>>> написал: >>>> >>>> Hi all! >>>> >>>> After David has successfully tested a first SVN -> Git conversion of >>>> our repo, here comes the next challenge: Finding a way to preserve our >>>> current modularization into reactos, rosapps, rostests and paving the way >>>> for even more modularization. >>>> My vision for the future is a small "core" repo that only contains our >>>> host tools and SDK. We could also split off subprojects like fast486/ntvdm >>>> or Paint into individual repos. Now that Microsoft has abandoned them under >>>> Windows, they may individually attract developers who would never hack on >>>> the entire ReactOS repo. Furthermore, 3rd party components could be >>>> imported through their repo instead of copy-pasting their code without >>>> history (as we do now). >>>> Even if that vision is a distant goal, the technology for it is already >>>> required for a reactos, rosapps, rostests modularization. >>>> >>>> Isn't that a perfect scenario for Git submodules? >>>> Not sure: I'm not aware that they support the concept of optional >>>> modules. You could only check out the "core" repo with all defined >>>> submodules. This would make it impossible to use "core" only to build >>>> Paint. There also seem to be other drawbacks when using submodules: >>>> https://codingkilledthecat.wordpress.com/2012/04/28/why-your >>>> -company-shouldnt-use-git-submodules/ >>>> >>>> Alternatives like Git subtrees, Google Repo, and Gitslave exist, but >>>> there is even less information about them. Furthermore, I think a good >>>> integration into GUI tools like TortoiseGit is also a requirement for most >>>> of us. >>>> >>>> David and I have started to write down our findings: >>>> https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3V >>>> Mq2uxyw5MpnUXbT8z6w/edit >>>> Your input on this is very welcome! >>>> >>>> I guess any migration to Git is blocked before we have a solution here. >>>> >>>> >>>> Cheers, >>>> >>>> Colin >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ros-dev mailing list >>>> Ros-dev(a)reactos.org >>>> http://www.reactos.org/mailman/listinfo/ros-dev >>>> >>> >>> >>> _______________________________________________ >>> Ros-dev mailing list >>> Ros-dev(a)reactos.org >>> http://www.reactos.org/mailman/listinfo/ros-dev >>> >> >> _______________________________________________ >> 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 > >

1 0

Status Meeting (July 2017)
by Colin Finck 03 Aug '17

03 Aug '17

Hi all! We're going to have the missed monthly status meeting for July tomorrow. Time will be 19:00 UTC as always and you will get your credentials shortly before the meeting. Agenda proposals so far include: - The 0.4.6 release - The upcoming Hackfest - Design of the RAPPS setup mode Please post any additional agenda proposals here. See you tomorrow! Colin

1 1

Re: [ros-dev] Modularizing the ReactOS repo in Git
by Alexander Sh. 02 Aug '17

02 Aug '17

Since we have RosBE, we can have multiple repositories without actually binding them and download them on demand. Or we can make a build script for every new small module that downloads (clones) repos it needs. 2 авг. 2017 г. 11:41 пользователь "Colin Finck" <colin(a)reactos.org> написал: Hi all! After David has successfully tested a first SVN -> Git conversion of our repo, here comes the next challenge: Finding a way to preserve our current modularization into reactos, rosapps, rostests and paving the way for even more modularization. My vision for the future is a small "core" repo that only contains our host tools and SDK. We could also split off subprojects like fast486/ntvdm or Paint into individual repos. Now that Microsoft has abandoned them under Windows, they may individually attract developers who would never hack on the entire ReactOS repo. Furthermore, 3rd party components could be imported through their repo instead of copy-pasting their code without history (as we do now). Even if that vision is a distant goal, the technology for it is already required for a reactos, rosapps, rostests modularization. Isn't that a perfect scenario for Git submodules? Not sure: I'm not aware that they support the concept of optional modules. You could only check out the "core" repo with all defined submodules. This would make it impossible to use "core" only to build Paint. There also seem to be other drawbacks when using submodules: https://codingkilledthecat.wor dpress.com/2012/04/28/why-your-company-shouldnt-use-git-submodules/ Alternatives like Git subtrees, Google Repo, and Gitslave exist, but there is even less information about them. Furthermore, I think a good integration into GUI tools like TortoiseGit is also a requirement for most of us. David and I have started to write down our findings: https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3V Mq2uxyw5MpnUXbT8z6w/edit Your input on this is very welcome! I guess any migration to Git is blocked before we have a solution here. Cheers, Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 3

Modularizing the ReactOS repo in Git
by Colin Finck 02 Aug '17

02 Aug '17

Hi all! After David has successfully tested a first SVN -> Git conversion of our repo, here comes the next challenge: Finding a way to preserve our current modularization into reactos, rosapps, rostests and paving the way for even more modularization. My vision for the future is a small "core" repo that only contains our host tools and SDK. We could also split off subprojects like fast486/ntvdm or Paint into individual repos. Now that Microsoft has abandoned them under Windows, they may individually attract developers who would never hack on the entire ReactOS repo. Furthermore, 3rd party components could be imported through their repo instead of copy-pasting their code without history (as we do now). Even if that vision is a distant goal, the technology for it is already required for a reactos, rosapps, rostests modularization. Isn't that a perfect scenario for Git submodules? Not sure: I'm not aware that they support the concept of optional modules. You could only check out the "core" repo with all defined submodules. This would make it impossible to use "core" only to build Paint. There also seem to be other drawbacks when using submodules: https://codingkilledthecat.wordpress.com/2012/04/28/why-your-company-should… Alternatives like Git subtrees, Google Repo, and Gitslave exist, but there is even less information about them. Furthermore, I think a good integration into GUI tools like TortoiseGit is also a requirement for most of us. David and I have started to write down our findings: https://docs.google.com/document/d/1Ey1xdS_0GcG7p7ZgHZBh4A3VMq2uxyw5MpnUXbT… Your input on this is very welcome! I guess any migration to Git is blocked before we have a solution here. Cheers, Colin

1 0

Enabling themes in 3rd stage
by Giannis Adamopoulos 31 Jul '17

31 Jul '17

Hello, After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. Thanks, Giannis Adamopoulos

7 8

Re: [ros-dev] Enabling themes in 3rd stage
by Robert Naumann 31 Jul '17

31 Jul '17

I'd vote for a page in 2nd stage. If we would make it by default then only in the releases. Am 31.07.2017 16:31 schrieb "Giannis Adamopoulos" < giannis.adamopoulos(a)reactos.org>: Hello, After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. Thanks, Giannis Adamopoulos _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] Enabling themes in 3rd stage
by Javier Agustìn Fernàndez Arroyo 31 Jul '17

31 Jul '17

I didnt say so, lol El 31/07/2017 20:38, "Giannis Adamopoulos" <giannis.adamopoulos(a)reactos.org> escribió: So you volunteer to create a theme? Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote on Mon, July 31st, 2017, 6:24 PM: > What about the « Whistler » - like theme ? ^^ > > > > H. > > > > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Mark Jansen > Envoyé : lundi 31 juillet 2017 17:18 > À : ReactOS Development List > Objet : Re: [ros-dev] Enabling themes in 3rd stage > > > > I like this theme! > > > > Op 31 jul. 2017 16:44 schreef "Ged Murphy" <gedmurphy.maillists(a)gmail.com >: > > A link to the theme I mentioned would probably help... > http://aportz19.deviantart.com/art/Basic-Lite-and-Basic- 8-Visual-Style-for-Windows-XP-393826050 > > > -----Original Message----- > From: Ged Murphy [mailto:gedmurphy.maillists@gmail.com] > Sent: 31 July 2017 15:43 > To: 'ReactOS Development List' <ros-dev(a)reactos.org> > Subject: RE: [ros-dev] Enabling themes in 3rd stage > > Do you have some pics?? > > I've always been a big fan of seeing the Basic Lite theme being on by default, which would give ros a much more modern look and feel. > We're missing the start menu implementation for this though. > > > > -----Original Message----- > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Giannis Adamopoulos > Sent: 31 July 2017 15:29 > To: ros-dev(a)reactos.org > Subject: [ros-dev] Enabling themes in 3rd stage > > Hello, > After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. > > Thanks, > Giannis Adamopoulos > > _______________________________________________ > 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

1 0

Re: [ros-dev] Enabling themes in 3rd stage
by Giannis Adamopoulos 31 Jul '17

31 Jul '17

So you volunteer to create a theme? Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote on Mon, July 31st, 2017, 6:24 PM: > What about the « Whistler » - like theme ? ^^ > > > > H. > > > > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Mark Jansen > Envoyé : lundi 31 juillet 2017 17:18 > À : ReactOS Development List > Objet : Re: [ros-dev] Enabling themes in 3rd stage > > > > I like this theme! > > > > Op 31 jul. 2017 16:44 schreef "Ged Murphy" <gedmurphy.maillists(a)gmail.com>: > > A link to the theme I mentioned would probably help... > http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-8-Visual-Style-for-… > > > -----Original Message----- > From: Ged Murphy [mailto:gedmurphy.maillists@gmail.com] > Sent: 31 July 2017 15:43 > To: 'ReactOS Development List' <ros-dev(a)reactos.org> > Subject: RE: [ros-dev] Enabling themes in 3rd stage > > Do you have some pics?? > > I've always been a big fan of seeing the Basic Lite theme being on by default, which would give ros a much more modern look and feel. > We're missing the start menu implementation for this though. > > > > -----Original Message----- > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Giannis Adamopoulos > Sent: 31 July 2017 15:29 > To: ros-dev(a)reactos.org > Subject: [ros-dev] Enabling themes in 3rd stage > > Hello, > After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. > > Thanks, > Giannis Adamopoulos > > _______________________________________________ > 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

2 1

Re: [ros-dev] Enabling themes in 3rd stage
by Javier Agustìn Fernàndez Arroyo 31 Jul '17

31 Jul '17

hi all, honestly, i dont think theming is a crucial choose when installing. i would not add that screen, at 2nd stage at least. Maybe at 3rd, right after 1st run.... El 31/07/2017 18:28, "Hermès BÉLUSCA-MAÏTO" <hermes.belusca(a)sfr.fr> escribió: What about the « Whistler » - like theme ? ^^ H. *De :* Ros-dev [mailto:ros-dev-bounces@reactos.org] *De la part de* Mark Jansen *Envoyé :* lundi 31 juillet 2017 17:18 *À :* ReactOS Development List *Objet :* Re: [ros-dev] Enabling themes in 3rd stage I like this theme! Op 31 jul. 2017 16:44 schreef "Ged Murphy" <gedmurphy.maillists(a)gmail.com>: A link to the theme I mentioned would probably help... http://aportz19.deviantart.com/art/Basic-Lite-and-Basic- 8-Visual-Style-for-Windows-XP-393826050 -----Original Message----- From: Ged Murphy [mailto:gedmurphy.maillists@gmail.com] Sent: 31 July 2017 15:43 To: 'ReactOS Development List' <ros-dev(a)reactos.org> Subject: RE: [ros-dev] Enabling themes in 3rd stage Do you have some pics?? I've always been a big fan of seeing the Basic Lite theme being on by default, which would give ros a much more modern look and feel. We're missing the start menu implementation for this though. -----Original Message----- From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Giannis Adamopoulos Sent: 31 July 2017 15:29 To: ros-dev(a)reactos.org Subject: [ros-dev] Enabling themes in 3rd stage Hello, After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. Thanks, Giannis Adamopoulos _______________________________________________ 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

1 1

Re: [ros-dev] Enabling themes in 3rd stage
by Giannis Adamopoulos 31 Jul '17

31 Jul '17

Lautus: http://i.imgur.com/lqrqvtu.png Basic lite (without any font changes): http://i.imgur.com/BcTIF9m.png To make basic lite look better needs to substitute its fonts with some we already have. Ged Murphy <gedmurphy.maillists(a)gmail.com> wrote on Mon, July 31st, 2017, 4:44 PM: > A link to the theme I mentioned would probably help... > http://aportz19.deviantart.com/art/Basic-Lite-and-Basic-8-Visual-Style-for-… > > > -----Original Message----- > From: Ged Murphy [mailto:gedmurphy.maillists@gmail.com] > Sent: 31 July 2017 15:43 > To: 'ReactOS Development List' <ros-dev(a)reactos.org> > Subject: RE: [ros-dev] Enabling themes in 3rd stage > > Do you have some pics?? > > I've always been a big fan of seeing the Basic Lite theme being on by default, which would give ros a much more modern look and feel. > We're missing the start menu implementation for this though. > > > > -----Original Message----- > From: Ros-dev [mailto:ros-dev-bounces@reactos.org] On Behalf Of Giannis Adamopoulos > Sent: 31 July 2017 15:29 > To: ros-dev(a)reactos.org > Subject: [ros-dev] Enabling themes in 3rd stage > > Hello, > After recent changes in explorer, comctl32 and uxtheme the state of themes in reactos was improved a lot. I would like to ask your opinions about enabling themes in 3rd stage. It is also possible to have an option in 2nd stage to select if we want 3rd stage to have themes enabled. Do you think this should be enabled by default or not? All ideas are welcome. My intention is to complete it ASAP so that it can make in the release. > > Thanks, > Giannis Adamopoulos > > _______________________________________________ > 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

4 3

Another Hackfest update
by Colin Finck 26 Jul '17

26 Jul '17

Hi all! With the Hackfest less than 3 weeks away, let me give you another status update: * It is important that you now add yourself to https://reactos.org/wiki/ReactOS_Hackfest_2017/Lists or fix up your information there. Further E-Mails will only go to the people listed there. * As many of us also attend FrOSCon on Saturday and Sunday (19-20), I'm also going to book the loft for this night. There may be options closer to FrOSCon, but I think not having to hastily check out early on Saturday with the entire equipment outweighs the 1 hour trip between the loft and FrOSCon. * The Ideas list looks very promising. In order to make the most out of the Hackfest, preparations should begin now. For example, I really want the Git move to happen in October, so let's not hesitate with all necessary source tree restructuring and testing. There has been no meeting announced for tomorrow, so I'm unsure whether we will have one. In case we do, let's handle any outstanding questions tomorrow. Cheers, Colin

1 0

About ATL wrappers - atlex
by Alexander Sh. 16 Jul '17

16 Jul '17

Hello, I am sanchaez (Alexander Shaposhnikov) - a GSoC student working on RAPPS. I've found a set of useful wrappers for ATL on Github - https://github.com/Amebis/atlex. I have some questions: 1. It is GPLv3. Is it compatible with ROS license? Can I use them? 2. If I can, where to place it in the source folders? P.S. I've rushed a little by committing it to my branch. "It lies in reactos\sdk\include\reactos" for now. Thanks in advance, Alexander

2 3

Ethereum for fundraiser
by Erkin Alp Güney 13 Jul '17

13 Jul '17

Ethereum is a decentralised cryptocurrency based on proof of work and proof of stake consensus with Turing-complete scripting. Utilising Ethereum for fundraiser will allow us to remove the middlemen from raising funds and allow us to distribute them more directly. I want to be first contract programmer for ReactOS ethereum account. Any kind of release schemes may be developed. However, this will need detailed discussion and official approval first. Yours, faithfully Erkin Alp

1 0

Help me
by katahiromz . 10 Jul '17

10 Jul '17

Dear Sirs/Madams, I have to implement the PATHOBJ routines. Please help me. CORE-13536 https://jira.reactos.org/browse/CORE-13536 Thanks, Katayama Hirofumi MZ

1 0

Hackfest update
by Colin Finck 08 Jul '17

08 Jul '17

Hi all! As the first flight to the Hackfest has been booked today, I have clarified the dates on https://reactos.org/wiki/ReactOS_Hackfest_2017 I will book the loft also for the night from Sunday to Monday (August 13 to 14), so you have the option to arrive earlier and the Hackfest can definitely begin on Monday. Please check your travelling options to see whether Sunday or Monday is the better option for you, and update https://reactos.org/wiki/ReactOS_Hackfest_2017/Lists Cheers, Colin

1 0

AHK Bot down for the week end
by Sylvain Petreolle 07 Jul '17

07 Jul '17

Due to my family presence, I need to stop the Test KVM AHK bot during this week end."I'll be back." Kind regards, Sylvain Petreolle

1 0

Re: [ros-dev] About the bootcd and livecd, and the 1st-stage GUI setup
by Giannis Adamopoulos 05 Jul '17

05 Jul '17

I'd say that we should show: - Run or install ReactOS - Boot from hard disk - Advanced options Nothing more should be needed and the first option should be clear that can either lead to a live environment or a setup. David Quintana (gigaherz) <gigaherz(a)gmail.com> wrote on Tue, July 4th, 2017, 10:45 PM: > I feel like the boot menu is going to be far too busy for the end user. I'd > go with something closer to > > blah blah: > > - Install Now > - Try without installing > - Show advanced options... > > where: > > - Install now -- boots into the graphical installer (no desktop unless > you cancel or something) > - Try without installing -- boots into livecd desktop (backed by RAM, I > guess) > - Show advanced options... -- opens a second-level menu with > - Text-mode installer > - Live boot without Ramdisk > - etc. > > > > On 4 July 2017 at 21:45, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote: > > > Hello everyone, > > > > > > > > One of the long-term plan for ReactOS was to have a graphical user-mode > > interface for the 1st-stage setup, similar to e.g. what may be found in > > newer versions of Windows (Vista+), as an alternative to our current 1st-stage > > setup in text-mode > > > > (note that I say “alternative”, not “replacement”, because both of them > > can live together without fundamental changes to either ReactOS or our ISO > > images, both of them can share core functionality, and finally because some > > people may prefer the text-mode either for unattended installations or for > > low-memory conditions). > > > > > > > > You can find some information about the 1st-stage GUI setup here: > > https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it > > can be found in base/setup/reactos/ . Currently only most of the screens > > have been implemented, while the core functionality is not present. However > > this functionality can somehow be taken by reusing the source code of > > USETUP (see my branch https://svn.reactos.org/svn/reactos/branches/setup_ > > improvements/base/setup/ ). > > > > > > > > > > > > Abstract (aka. TL;DR): I explain below the needed changes introduced > > experimentally in the “setup-improvements” branch, revision 75273, to > > generate an all-in-one ReactOS bootcd, that includes both the 1st-stage > > text-mode setup + 1st-stage GUI setup alternative + live-demo > > functionality. This is meant to replace our currently separated “bootcd” / > > “livecd” ISOs, where the latter currently do not offer the possibility to > > install ReactOS. Some currently known potential problems are evoked. > > > > > > > > Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; > > Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png . > > > > > > > > > > > > Having a 1st-stage GUI setup also means that it’ll also use the > > already-existing functionality that we offer in our “Live-CD” ISOs. > > Currently, the “Live-CD” ISOs we provide only allow for demonstration > > purposes, while the ReactOS installation proper is found in our so-called > > “Boot-CD” ISOs (which currently only contain text-mode setup). Thus, the 1 > > st-stage GUI setup, as an alternative to the 1st-stage setup in > > text-mode, means that both ISOs can be merged all in one, and we won’t have > > to make a distinction between both: they will be able to offer both the 1 > > st-stage in text mode AND a graphical mode (à la “Live-CD”) where it is > > possible to choose whether to test ReactOS in demo mode, or to install it > > via the GUI setup. > > > > Such an all-in-one ISO capability was already present in the trunk under > > the name “hybridcd”, but was used only when we built ISO images for the > > public events where ReactOS participated (FOSDEM, CLT, …). But now, having > > the setup process both in text mode and in graphics mode, in addition to > > the Live-CD demonstration capability, really suggests just using the > > all-in-one ISO and stop doing the “Boot-CD” (aka. only setup) vs. “Live-CD” > > (aka. only demo) separation. We would just generate only one type of ISO > > that contains everything. > > > > > > > > With that in mind, I have committed in my branch “setup_improvements”, in > > revision 75273 : https://svn.reactos.org/svn/reactos?view=revision& > > revision=75273 such changes to be able to only build an ISO that contains > > everything. These changes are minimal, in the sense that I haven’t > > purposelessly changed the names of the build targets just to be fancy. Such > > changes may be done later, but not now. > > > > > > > > The needed changes are the following: First, the build target that will > > generate the all-in-one CD is called “bootcd”, because this also was the > > main build target for ISOs before the change. Second, I completely remove > > the “hybridcd” build target, because its functionality are now absorbed by > > “bootcd”. Third, the build target “livecd” is reduced to its strict > > minimum. For the sake of building a RAMDISK boot drive (see comments > > after), I continue to generate an ISO for “livecd”. But I’ve changed the > > generated name to “liveimage.iso”, to emphasize the point that it has to be > > understood as a (virtual) disk image for RAMDISK purposes, not just as a > > ISO image. Note that I haven’t renamed the build target “livecd” to, say, > > “liveimage” to reduce my commit changes (such a renaming may be done > > later). The “livecd” target builds a list of files that need to be present > > in the image. The generated liveimage.iso is no-more a bootable ISO, I’ve > > removed inclusion of freeloader + El-Torito boot-sector + the > > USB-ISO-Hybrid functionality for it. > > > > The “bootcd” target has been slightly changed in order to include the > > liveimage.iso as a file (for RAMDISK), and to also add the contents of this > > image in a flattened tree within the bootcd iso: the two directories > > “Profiles” and “reactos”. > > > > The 1st-stage text-mode setup is kept, as said before, but its > > corresponding files + the installation CAB source + the 1st-stage GUI > > setup application proper goes into a (renamed) directory called “i386”, > > corresponding to installation files for an i386 installation (technically, > > 1 per architecture when we’ll have a ReactOS ported to other archs). These > > files cannot be present in the same “reactos” directory as the ones from > > the flattened LiveImage, because some of the files are different (smss.exe, > > registry, etc…) Our FreeLdr knows from where to boot the 1st-stage > > text-mode (from i386), as well as the Live-demo in graphics mode (from > > reactos). > > > > I need to adjust the code of few setup components for them to stop relying > > on hardcoded “reactos/” path, and instead use a more “dynamic” (determined > > at runtime) path. > > > > > > > > NOTE FOR DEVS/SYSADMINS: The “bootcdregtest” build target, generating the > > special ISO that is fed to our test bots, remains exactly the same, and the > > files contained in the generated ISO have not changed. > > > > > > > > NOTE about the RAMDISK feature: I enabled it so that a user can remove the > > demo media (CD, …) and reuse the drive for other purposes, while still > > being able to use ReactOS. Of course this requires a large amount of RAM > > available. And that’s also why I include the flattened liveimage files so > > that one can use the demo without the RAMDISK (when few memory is > > available). > > > > As is currently implemented, this makes the ReactOS all-in-one bootcd > > large (it gains a good 100 MB) due to duplicated space (the flattened > > files, plus the same inside “liveimage.iso”). I cannot do better (unless > > ditching either the RAMDISK, or keeping it but not include the flattened > > files) because ReactOS currently doesn’t have a way to boot from disk > > images **that are not meant to be a RAMDISK**. The day when this > > difficulty is removed, a single disk image could be used either as the > > RAMDISK or the (non-removable) installation. > > > > A second remark is that I don’t plan to have the 1st-stage GUI setup > > available when booting ReactOS in RAMDISK mode because, as a consequence of > > its current implementation, I would otherwise need to duplicate the > > installation CAB source in the RAMDISK image too, making it again larger. > > > > > > > > NOTE about the FreeLdr Boot Menu: Since ReactOS is not that stable > > currently, we like to boot it in debug mode, and redirect the output to a > > serial port (usually COM1). However some people don’t have serial ports on > > real hardware, so we propose to boot with debug output redirected to > > screen. However this may slow ReactOS down, so we also like to boot ReactOS > > with debug mode disabled. That’s why I proposed the declination of these > > boot modes for each ReactOS installation contained in the BootCD > > (Live+Setup, with or without RAMDISK, and with debug enabled or not). The > > problem is that it clutters a lot the boot menu. A remedy would be to > > implement in FreeLdr the functionality of editing **existing** boot > > entries to change their associated boot options, so that one could add by > > hand the options to enable (or disable) debugging. This is currently > > unimplemented. The only implemented feature is to set up a new boot entry > > on the fly to boot ReactOS afterwards. > > > > > > > > NOTE for regress-testers: Possible remark that I may hear: “I only care > > about installing ReactOS (perhaps just in unattended mode) and I don’t care > > at all about the GUI setup nor about the Live-demo thingie, and your new > > BootCD is too large. I want to be able to download & use the good-old > > bootcd for regress-testing.” . So what to do? Since we currently build and > > store the “bootcdregtest” ISOs, but are not publicly available through our > > www.reactos.org/getbuilds interface, I would suggest here to make them > > available to people, so that those who want to quickly DL and/or > > install/regress-test ReactOS could use these ISOs instead (which are really > > just the good old BootCDs, but with unattended installation enabled **and** > > with our test-suite included). They are not that much large, just a bit > > more than the old regular bootcd. > > > > > > > > Please let me know whether you have other remarks/comments/questions/suggestions/etc… > > to make the new BootCDs better. > > > > > > > > > > > > Best, > > > > > > > > Hermès > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > >

5 4

About the bootcd and livecd, and the 1st-stage GUI setup
by Hermès BÉLUSCA-MAÏTO 04 Jul '17

04 Jul '17

Hello everyone, One of the long-term plan for ReactOS was to have a graphical user-mode interface for the 1st-stage setup, similar to e.g. what may be found in newer versions of Windows (Vista+), as an alternative to our current 1st-stage setup in text-mode (note that I say alternative, not replacement, because both of them can live together without fundamental changes to either ReactOS or our ISO images, both of them can share core functionality, and finally because some people may prefer the text-mode either for unattended installations or for low-memory conditions). You can find some information about the 1st-stage GUI setup here: https://reactos.org/wiki/First_Stage_GUI_Setup . In our source code, it can be found in base/setup/reactos/ . Currently only most of the screens have been implemented, while the core functionality is not present. However this functionality can somehow be taken by reusing the source code of USETUP (see my branch https://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/ ). Abstract (aka. TL;DR): I explain below the needed changes introduced experimentally in the setup-improvements branch, revision 75273, to generate an all-in-one ReactOS bootcd, that includes both the 1st-stage text-mode setup + 1st-stage GUI setup alternative + live-demo functionality. This is meant to replace our currently separated bootcd / livecd ISOs, where the latter currently do not offer the possibility to install ReactOS. Some currently known potential problems are evoked. Images: Proposed BootCD contents : http://i.imgur.com/EBA6JHd.png ; Proposed Boot Menu : http://i.imgur.com/14n5Ryi.png . Having a 1st-stage GUI setup also means that itll also use the already-existing functionality that we offer in our Live-CD ISOs. Currently, the Live-CD ISOs we provide only allow for demonstration purposes, while the ReactOS installation proper is found in our so-called Boot-CD ISOs (which currently only contain text-mode setup). Thus, the 1st-stage GUI setup, as an alternative to the 1st-stage setup in text-mode, means that both ISOs can be merged all in one, and we wont have to make a distinction between both: they will be able to offer both the 1st-stage in text mode AND a graphical mode (à la Live-CD) where it is possible to choose whether to test ReactOS in demo mode, or to install it via the GUI setup. Such an all-in-one ISO capability was already present in the trunk under the name hybridcd, but was used only when we built ISO images for the public events where ReactOS participated (FOSDEM, CLT, ). But now, having the setup process both in text mode and in graphics mode, in addition to the Live-CD demonstration capability, really suggests just using the all-in-one ISO and stop doing the Boot-CD (aka. only setup) vs. Live-CD (aka. only demo) separation. We would just generate only one type of ISO that contains everything. With that in mind, I have committed in my branch setup_improvements, in revision 75273 : https://svn.reactos.org/svn/reactos?view=revision <https://svn.reactos.org/svn/reactos?view=revision&revision=75273> &revision=75273 such changes to be able to only build an ISO that contains everything. These changes are minimal, in the sense that I havent purposelessly changed the names of the build targets just to be fancy. Such changes may be done later, but not now. The needed changes are the following: First, the build target that will generate the all-in-one CD is called bootcd, because this also was the main build target for ISOs before the change. Second, I completely remove the hybridcd build target, because its functionality are now absorbed by bootcd. Third, the build target livecd is reduced to its strict minimum. For the sake of building a RAMDISK boot drive (see comments after), I continue to generate an ISO for livecd. But Ive changed the generated name to liveimage.iso, to emphasize the point that it has to be understood as a (virtual) disk image for RAMDISK purposes, not just as a ISO image. Note that I havent renamed the build target livecd to, say, liveimage to reduce my commit changes (such a renaming may be done later). The livecd target builds a list of files that need to be present in the image. The generated liveimage.iso is no-more a bootable ISO, Ive removed inclusion of freeloader + El-Torito boot-sector + the USB-ISO-Hybrid functionality for it. The bootcd target has been slightly changed in order to include the liveimage.iso as a file (for RAMDISK), and to also add the contents of this image in a flattened tree within the bootcd iso: the two directories Profiles and reactos. The 1st-stage text-mode setup is kept, as said before, but its corresponding files + the installation CAB source + the 1st-stage GUI setup application proper goes into a (renamed) directory called i386, corresponding to installation files for an i386 installation (technically, 1 per architecture when well have a ReactOS ported to other archs). These files cannot be present in the same reactos directory as the ones from the flattened LiveImage, because some of the files are different (smss.exe, registry, etc) Our FreeLdr knows from where to boot the 1st-stage text-mode (from i386), as well as the Live-demo in graphics mode (from reactos). I need to adjust the code of few setup components for them to stop relying on hardcoded reactos/ path, and instead use a more dynamic (determined at runtime) path. NOTE FOR DEVS/SYSADMINS: The bootcdregtest build target, generating the special ISO that is fed to our test bots, remains exactly the same, and the files contained in the generated ISO have not changed. NOTE about the RAMDISK feature: I enabled it so that a user can remove the demo media (CD, ) and reuse the drive for other purposes, while still being able to use ReactOS. Of course this requires a large amount of RAM available. And thats also why I include the flattened liveimage files so that one can use the demo without the RAMDISK (when few memory is available). As is currently implemented, this makes the ReactOS all-in-one bootcd large (it gains a good 100 MB) due to duplicated space (the flattened files, plus the same inside liveimage.iso). I cannot do better (unless ditching either the RAMDISK, or keeping it but not include the flattened files) because ReactOS currently doesnt have a way to boot from disk images *that are not meant to be a RAMDISK*. The day when this difficulty is removed, a single disk image could be used either as the RAMDISK or the (non-removable) installation. A second remark is that I dont plan to have the 1st-stage GUI setup available when booting ReactOS in RAMDISK mode because, as a consequence of its current implementation, I would otherwise need to duplicate the installation CAB source in the RAMDISK image too, making it again larger. NOTE about the FreeLdr Boot Menu: Since ReactOS is not that stable currently, we like to boot it in debug mode, and redirect the output to a serial port (usually COM1). However some people dont have serial ports on real hardware, so we propose to boot with debug output redirected to screen. However this may slow ReactOS down, so we also like to boot ReactOS with debug mode disabled. Thats why I proposed the declination of these boot modes for each ReactOS installation contained in the BootCD (Live+Setup, with or without RAMDISK, and with debug enabled or not). The problem is that it clutters a lot the boot menu. A remedy would be to implement in FreeLdr the functionality of editing *existing* boot entries to change their associated boot options, so that one could add by hand the options to enable (or disable) debugging. This is currently unimplemented. The only implemented feature is to set up a new boot entry on the fly to boot ReactOS afterwards. NOTE for regress-testers: Possible remark that I may hear: I only care about installing ReactOS (perhaps just in unattended mode) and I dont care at all about the GUI setup nor about the Live-demo thingie, and your new BootCD is too large. I want to be able to download & use the good-old bootcd for regress-testing. . So what to do? Since we currently build and store the bootcdregtest ISOs, but are not publicly available through our www.reactos.org/getbuilds interface, I would suggest here to make them available to people, so that those who want to quickly DL and/or install/regress-test ReactOS could use these ISOs instead (which are really just the good old BootCDs, but with unattended installation enabled *and* with our test-suite included). They are not that much large, just a bit more than the old regular bootcd. Please let me know whether you have other remarks/comments/questions/suggestions/etc to make the new BootCDs better. Best, Hermès

3 3

Status Meeting (June 2017)
by Aleksey Bragin 29 Jun '17

29 Jun '17

Hello, Let me invite you to the monthly status meeting taking place 29th of June, 19:00 UTC. We do it either in #reactos-meeting on Freenode, or on a very own standalone IRC server. In that case your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. And everyone is fine with that. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

2 1

SVN url change?
by Hermès BÉLUSCA-MAÏTO 28 Jun '17

28 Jun '17

Hello all, Today I noticed that our buildbots couldnt connect to SVN to upload the commit changes, and therefore failed to build. Also I noticed that the usual SVN ViewVC address (which was previously https://svn.reactos.org/svn/reactos , for example) changed to https://svn.reactos.org/viewcvs/reactos/ (granted, there appear to be an automatic redirection to this new address). Is it an intentional change, or an unintentional one? We didnt seem to be warned prior to this on the mailing list! Cheers, Hermès

2 2

Please don't read Windows source code
by katahiromz . 24 Jun '17

24 Jun '17

According to The Register, Windows 10 source has been leaked. But reading that codes is still illegal for ReactOS development, so we might fire you if you read in the case. ---- Please don't read the leaked source. Thanks, Katayama Hirofumi MZ 片山博文MZ

2 1

ReactOS Hackfest 2017 - Are you in?
by Colin Finck 23 Jun '17

23 Jun '17

Hi all! I'm currently planning the ReactOS Hackfest 2017 in the Cologne/Bonn area in Germany. Currently, the plan is to book a meeting room from Monday, August 14 to Friday, August 18. We can then use the weekend before to get to Cologne and explore the city a bit. After the Hackfest, everybody interested can join us at FrOSCon in Bonn the weekend after. As booking a room there involves significant costs, I'd like to know who of you can definitely make it for the Hackfest and who of you is definitely out. Please reply now to prevent me from bugging you on IRC all the time! ;) Cheers, Colin

8 8

Re: [ros-dev] [ros-diffs] [hbelusca] 75164: [SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based on code by Samuel Serapion & MSDN. What needs to be fixed here, is the client/server code to communicate the...
by Colin Finck 22 Jun '17

22 Jun '17

hbelusca(a)svn.reactos.org wrote: > [SECUR32_APITEST]: Add the beginnings of an apitest for secur32, based > on code by Samuel Serapion & MSDN. What needs to be fixed here, is the > client/server code to communicate the results back to the main test > app being running. Work in progress. I have implemented short and simple WineTest-compatible client/server code in localspl_apitest. The server is the application that is tested through rosautotest. For every test, it starts the client, sends the test name over a pipe and outputs the received testing output. The client simply has stdout redirected to a pipe and can then use usual WineTest ok() functions for testing. Check out rostests/apitests/localspl (server) and rostests/apitests/localspl/dll (client). Hope that helps! - Colin

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75083: [NTOS]: Use SEH inside CmQueryKey(), as it can be called with user-mode parameter KeyInformation. Remove unused code in CmLoadKey(). I've noticed that in cmapi.c / ntapi.c we do n...
by Alex Ionescu 20 Jun '17

20 Jun '17

On Sun, Jun 18, 2017 at 1:34 AM, <hbelusca(a)svn.reactos.org> wrote: > - if (!(CmpProfileLoaded) && !(CmpWasSetupBoot)) > + if (!CmpProfileLoaded && !CmpWasSetupBoot) > Why do you keep re-formatting other people's code in unrelated patches? You've been repeatedly asked to stop doing this. Best regards, Alex Ionescu

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75133: [NTOS]: Revert the pool tag change from r75128, and explain in comment why we cannot actually use it.
by Thomas Faber 19 Jun '17

19 Jun '17

On 2017-06-19 18:29, hbelusca(a)svn.reactos.org wrote: > + /* > + * Free it from the pool. > + * > + * We cannot use here ExFreePoolWithTag(..., OB_NAME_TAG); , because > + * the object name may have been massaged during operation by different > + * object parse routines. If the latter ones have to resolve a symbolic > + * link (e.g. as is done by CmpParseKey() and CmpGetSymbolicLink()), > + * the original object name is freed and re-allocated from the pool, > + * possibly with a different pool tag. At the end of the day, the new > + * object name can be reallocated and completely different, but we > + * should still be able to free it! > + */ > + ExFreePool(Buffer); I feel like ExFreePoolWithTag(Buffer, 0) conveys that same message without needing a huge comment?

2 1

GPU testing machine is ready!
by Colin Finck 13 Jun '17

13 Jun '17

Hi all! A picture says more than a thousand words: http://fs5.directupload.net/images/170613/u4d8a59a.png As promised in the last meeting, I have brought to life a machine for testing GPU drivers with real GPUs under ReactOS. It combines a QEMU virtual machine with PCIe GPU Passthrough together with a KVM-over-IP card for feeding the real video signal back to a window. What you see in the screenshot is a real NVIDIA GeForce 9300 GPU attached to a ReactOS VM. We can now test the NVIDIA driver installation while enjoying the easy debuggability of a VM. My first report is already out: https://jira.reactos.org/browse/CORE-13423 Every developer interested in working on this can drop me a line and I will send you credentials for the server. Soon I will also add an AMD Graphics Card along with another KVM-over-IP card to let us debug the other big driver package. Thanks go out to Mr. Kromdijk for the generous server donation, Christoph for the KVM-over-IP card, and Hervé for the QEMU hints! Let's all get some flashy 3D acceleration into ReactOS!! :) Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 75008: [USETUP]: Introduce SetupDeleteFile() and SetupMoveFile() (in addition to the already-existing SetupCopyFile()) in order to implement moving / renaming existing files. Will be use...
by Thomas Faber 12 Jun '17

12 Jun '17

On 2017-06-12 01:58, hbelusca(a)svn.reactos.org wrote: > +NTSTATUS > +SetupMoveFile( > + IN PCWSTR ExistingFileName, > + IN PCWSTR NewFileName, > + IN ULONG Flags) > +{ > + NTSTATUS Status; > + IO_STATUS_BLOCK IoStatusBlock; > + OBJECT_ATTRIBUTES ObjectAttributes; > + PFILE_RENAME_INFORMATION RenameInfo; > + UNICODE_STRING NewPathU, ExistingPathU; > + HANDLE SourceHandle = NULL; This variable fulfills the requirements for _SEH2_VOLATILE > + BOOLEAN ReplaceIfExists; > + > + RtlInitUnicodeString(&ExistingPathU, ExistingFileName); > + RtlInitUnicodeString(&NewPathU, NewFileName); > + > + _SEH2_TRY > + { Which part of this code needs SEH? That looks like it's purely hiding bugs.

2 1

Re: [ros-dev] [ros-diffs] [tthompson] 74970: [NTFS] - Add the most basic support for file creation. Expand diagnostic output, especially in NtfsDumpIndexRootAttribute(). Replace an ExFreePool() with ExFreePoolWithTag(). Add...
by Thomas Faber 12 Jun '17

12 Jun '17

On 2017-06-09 05:14, tthompson(a)svn.reactos.org wrote: > + RtlZeroMemory(&FilenameNoPath, sizeof(UNICODE_STRING)); > + FilenameNoPath.Buffer = Buffer; > + FilenameNoPath.MaximumLength = MAX_PATH; > + RtlInitEmptyUnicodeString does this for you On 2017-06-09 05:14, tthompson(a)svn.reactos.org wrote: > + FileNameAttribute->NameLength = FilenameNoPath.Length / 2; sizeof(WCHAR)?

1 0

Re: [ros-dev] [ros-diffs] [phater] 74750: [MSWSOCK] Call explicitly DnsQuery_W. Copy host aliases if available as answer from the query
by Thomas Faber 09 Jun '17

09 Jun '17

On 2017-06-02 19:52, phater(a)svn.reactos.org wrote: > + aDstNextStr = (char*)((DWORD)aDstNextStr + (DWORD)bItmLen); DWORD cannot always fit a pointer. You want DWORD_PTR for this kind of math (or simply use char *).

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74742: [USETUP]: Creating a registry key with zero access is just plainly invalid. Fix it. It was not caught before because, we never ever booted a 1st-stage setup with a valid mounted e...
by Thomas Faber 02 Jun '17

02 Jun '17

On 2017-06-02 02:44, hbelusca(a)svn.reactos.org wrote: > @@ -341,7 +341,7 @@ > } > > InitializeObjectAttributes(&ObjectAttributes, &ServicesU, OBJ_CASE_INSENSITIVE, NULL, NULL); > - Status = NtCreateKey(&hServices, 0, &ObjectAttributes, 0, NULL, 0, NULL); > + Status = NtCreateKey(&hServices, KEY_ALL_ACCESS, &ObjectAttributes, 0, NULL, 0, NULL); > if (!NT_SUCCESS(Status)) > { > DPRINT1("NtCreateKey('%wZ') failed with status 0x%08lx\n", &ServicesU, Status); > > It doesn't really need full access, does it? Could have gone for something closer to the original, like READ_CONTROL.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74741: [MKHIVE][CMAKE]: Make mkhive a bit more flexible, so that it can generate only specific hives on-demand (and not all of them always at once). I need this for building a single boo...
by Thomas Faber 02 Jun '17

02 Jun '17

I understand not making the change to how 1st stage deals with the registry in trunk. Why not the tool change though? Can't you have the new mkhive do the exact same thing it does now, and do it in trunk? The smaller your branch merge commit the easier it will be to avoid/pinpoint/fix regressions. On 2017-06-02 02:34, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Fri Jun 2 00:34:10 2017 > New Revision: 74741 > > URL: http://svn.reactos.org/svn/reactos?rev=74741&view=rev > Log: > [MKHIVE][CMAKE]: Make mkhive a bit more flexible, so that it can generate only specific hives on-demand (and not all of them always at once). I need this for building a single bootcd registry hive. > I commit these changes in my branch because it's too much über-advanced code for our trunk, yet... (and it will uncover deep "setup" hacks in NTOS' iomgr & pnpmgr as soon as I'll enable 1-st stage setup to have a proper registry present as done on windows). > CORE-13347 #comment Committed in r74741 but just in the setup_improvements branch for the moment.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74733: [NTOS]: Minor code formatting + don't leak a handle in case of failure, in CmpInitializeHardwareConfiguration().
by Thomas Faber 02 Jun '17

02 Jun '17

On 2017-06-01 20:27, hbelusca(a)svn.reactos.org wrote: > /* EISA */ > case EisaAdapter: > - > + { > /* Fixup information */ > Interface = Eisa; > Bus = CmpTypeCount[EisaAdapter]++; > break; > + } This is a completely unnecessary change to somebody else's code that has no basis in our documented coding style. Uh... don't do that?

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74739: [MKHIVE]: Formatting changes only + sync back the names of the reg-inf functions with the ones where they are coming from (aka. Wine's setupapi/install.c).
by Thomas Faber 02 Jun '17

02 Jun '17

On 2017-06-02 02:00, hbelusca(a)svn.reactos.org wrote: > [MKHIVE]: Formatting changes only + sync back the names of the reg-inf functions with the ones where they are coming from (aka. Wine's setupapi/install.c). Those two goals clearly conflict with either other. Either keep Wine's function names AND formatting to keep things comparable/sync-able, or make the code follow our style.

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74735: [NTOS]: Better clean up behind ourselves on failure paths (aka. closing handles). These functions are clearly not written with correct cleanup-on-failure concept in mind...
by Thomas Faber 02 Jun '17

02 Jun '17

On 2017-06-01 20:37, hbelusca(a)svn.reactos.org wrote: > + if (!NT_SUCCESS(Status)) > + { > + /* We failed, close all the opened handles and return */ > + // NtClose(KeyHandle); Please don't add commented-out code. What is that supposed to even mean? "I was too lazy to test this"? "All the other code depends on this leak"? "I think it would look prettier here"?

1 0

Status Meeting - rescheduled
by Aleksey Bragin 01 Jun '17

01 Jun '17

Hello, I propose to reschedule our monthly meeting to Thursday next week (1st of June), as tomorrow is a holiday in some countries, and also I have tight meetings schedule this week. Regards, Aleksey Bragin

4 3

mplayer -- branded name?
by Javier Agustìn Fernàndez Arroyo 01 Jun '17

01 Jun '17

Hey guys, An idea has just come to my mind, mplayer is an application that already exists for Linux: https://www.mplayerhq.hu/design7/news.html maybe we should change ReactOS´ player name so that we avoid possible future demands? what do u think?

1 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74698: [USETUP]: Minor fixes & simplifications: - Remove a redundant NtClose call; - Return failure if NtQuerySymbolicLinkObject fails; - Use RTL_CONSTANT_STRING and RtlInitEmptyUnicodeS...
by Colin Finck 31 May '17

31 May '17

hbelusca(a)svn.reactos.org wrote: > -/* > - * ReactOS kernel > - * Copyright (C) 2002 ReactOS Team > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License as published by > - * the Free Software Foundation; either version 2 of the License, or > - * (at your option) any later version. > - * > - * This program is distributed in the hope that it will be useful, > - * but WITHOUT ANY WARRANTY; without even the implied warranty of > - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > - * GNU General Public License for more details. > - * > - * You should have received a copy of the GNU General Public License along > - * with this program; if not, write to the Free Software Foundation, Inc., > - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA. > - */ > /* > * COPYRIGHT: See COPYING in the top level directory > * PROJECT: ReactOS text-mode setup You're taking away the information that this file is licensed under GPLv2 or any later version (as opposed to GPLv2-only, what some developers prefer). Also the entire license information is lost when this file is used as part of a different source tree. I have visited a seminar by our friend Nuno Brito last week, who has founded a company that deals with such topics (www.triplecheck.tech). There are some simple best practices we can apply here to get consistent and useful headers once and for all. The first would be using the established SPDX license identifiers from https://spdx.org/licenses (here: "GPL-2.0+"). This would also make our source files easily scannable by tools to get an overview of all licenses involved in our code and imported third-party components. If you or someone else is interested in working on this, let's draft a universal header for our files that is compatible with SPDX. Otherwise, I will have a look when there's more time.. Cheers, Colin

2 1

Re: [ros-dev] [ros-diffs] [mjansen] 74693: [KERNEL32] Initial implementation for BaseCheckRunApp, calling into apphelp to check for compatibility fixes CORE-10368
by Thomas Faber 29 May '17

29 May '17

Testbots seem to dislike this commit, looks like 3rd stage boot is broken in some way. :( On 2017-05-28 21:27, mjansen(a)svn.reactos.org wrote: > Author: mjansen > Date: Sun May 28 19:27:51 2017 > New Revision: 74693 > > URL: http://svn.reactos.org/svn/reactos?rev=74693&view=rev > Log: > [KERNEL32] Initial implementation for BaseCheckRunApp, calling into apphelp to check for compatibility fixes CORE-10368 > > Modified: > trunk/reactos/dll/win32/kernel32/client/appcache.c > trunk/reactos/dll/win32/kernel32/client/utils.c > > Modified: trunk/reactos/dll/win32/kernel32/client/appcache.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/appcache.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/appcache.c [iso-8859-1] Sun May 28 19:27:51 2017 > @@ -16,7 +16,20 @@ > /* GLOBALS ********************************************************************/ > > ULONG g_ShimsEnabled; > - > +static BOOL g_ApphelpInitialized = FALSE; > +static PVOID g_pApphelpCheckRunAppEx; > +static PVOID g_pSdbPackAppCompatData; > + > +typedef BOOL (WINAPI *tApphelpCheckRunAppEx)(HANDLE FileHandle, PVOID Unk1, PVOID Unk2, PWCHAR ApplicationName, PVOID Environment, USHORT ExeType, PULONG Reason, > + PVOID* SdbQueryAppCompatData, PULONG SdbQueryAppCompatDataSize, PVOID* SxsData, PULONG SxsDataSize, > + PULONG FusionFlags, PULONG64 SomeFlag1, PULONG SomeFlag2); > +typedef BOOL (WINAPI *tSdbPackAppCompatData)(PVOID hsdb, PVOID pQueryResult, PVOID* ppData, DWORD *dwSize); > + > +#define APPHELP_VALID_RESULT 0x10000 > +#define APPHELP_RESULT_NOTFOUND 0x20000 > +#define APPHELP_RESULT_FOUND 0x40000 > + > + > /* FUNCTIONS ******************************************************************/ > > BOOLEAN > @@ -136,7 +149,120 @@ > DPRINT("BaseCheckAppcompatCache is UNIMPLEMENTED\n"); > > if (Reason) *Reason = 0; > - return TRUE; > + > + // We don't know this app. > + return FALSE; > +} > + > +static > +VOID > +BaseInitApphelp(VOID) > +{ > + WCHAR Buffer[MAX_PATH*2]; > + UNICODE_STRING DllPath = {0}; > + PVOID ApphelpAddress; > + PVOID pApphelpCheckRunAppEx = NULL, pSdbPackAppCompatData = NULL; > + > + RtlInitEmptyUnicodeString(&DllPath, Buffer, sizeof(Buffer)); > + RtlCopyUnicodeString(&DllPath, &BaseWindowsDirectory); > + RtlAppendUnicodeToString(&DllPath, L"\\system32\\apphelp.dll"); > + > + if (NT_SUCCESS(LdrLoadDll(NULL, NULL, &DllPath, &ApphelpAddress))) > + { > + ANSI_STRING ProcName; > + > + RtlInitAnsiString(&ProcName, "ApphelpCheckRunAppEx"); > + if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, &ProcName, 0, &pApphelpCheckRunAppEx))) > + pApphelpCheckRunAppEx = NULL; > + > + RtlInitAnsiString(&ProcName, "SdbPackAppCompatData"); > + if (!NT_SUCCESS(LdrGetProcedureAddress(ApphelpAddress, &ProcName, 0, &pSdbPackAppCompatData))) > + pSdbPackAppCompatData = NULL; > + } > + > + if (InterlockedCompareExchangePointer(&g_pApphelpCheckRunAppEx, RtlEncodeSystemPointer(pApphelpCheckRunAppEx), NULL) == NULL) > + { > + g_pSdbPackAppCompatData = RtlEncodeSystemPointer(pSdbPackAppCompatData); > + } > +} > + > +/* > + * > + */ > +BOOL > +WINAPI > +BaseCheckRunApp(IN HANDLE FileHandle, > + IN PWCHAR ApplicationName, > + IN PWCHAR Environment, > + IN USHORT ExeType, > + IN PULONG pReason, > + IN PVOID* SdbQueryAppCompatData, > + IN PULONG SdbQueryAppCompatDataSize, > + IN PVOID* SxsData, > + IN PULONG SxsDataSize, > + OUT PULONG FusionFlags) > +{ > + ULONG Reason = 0; > + ULONG64 Flags1 = 0; > + ULONG Flags2 = 0; > + BOOL Continue, NeedCleanup = FALSE; > + tApphelpCheckRunAppEx pApphelpCheckRunAppEx; > + tSdbPackAppCompatData pSdbPackAppCompatData; > + PVOID QueryResult = NULL; > + ULONG QueryResultSize = 0; > + > + if (!g_ApphelpInitialized) > + { > + BaseInitApphelp(); > + g_ApphelpInitialized = TRUE; > + } > + > + pApphelpCheckRunAppEx = RtlDecodeSystemPointer(g_pApphelpCheckRunAppEx); > + pSdbPackAppCompatData = RtlDecodeSystemPointer(g_pSdbPackAppCompatData); > + > + if (!pApphelpCheckRunAppEx || !pSdbPackAppCompatData) > + return TRUE; > + > + if (pReason) > + Reason = *pReason; > + > + Continue = pApphelpCheckRunAppEx(FileHandle, NULL, NULL, ApplicationName, Environment, ExeType, &Reason, > + &QueryResult, &QueryResultSize, SxsData, SxsDataSize, FusionFlags, &Flags1, &Flags2); > + > + if (pReason) > + *pReason = Reason; > + > + if (Continue) > + { > + if ((Reason & (APPHELP_VALID_RESULT|APPHELP_RESULT_FOUND)) == (APPHELP_VALID_RESULT|APPHELP_RESULT_FOUND)) > + { > + if (!pSdbPackAppCompatData(NULL, QueryResult, SdbQueryAppCompatData, SdbQueryAppCompatDataSize)) > + { > + DPRINT1("SdbPackAppCompatData returned a failure!\n"); > + NeedCleanup = TRUE; > + } > + } > + else > + { > + NeedCleanup = TRUE; > + } > + } > + > + if (QueryResult) > + RtlFreeHeap(RtlGetProcessHeap(), 0, QueryResult); > + > + if (NeedCleanup) > + { > + BasepFreeAppCompatData(*SdbQueryAppCompatData, *SxsData); > + *SdbQueryAppCompatData = NULL; > + if (SdbQueryAppCompatDataSize) > + *SdbQueryAppCompatDataSize = 0; > + *SxsData = NULL; > + if (SxsDataSize) > + *SxsDataSize = 0; > + } > + > + return Continue; > } > > /* > @@ -171,9 +297,11 @@ > Environment, > &Reason)) > { > - /* We don't support this yet */ > - UNIMPLEMENTED; > - Status = STATUS_ACCESS_DENIED; > + if (!BaseCheckRunApp(FileHandle, ApplicationName, Environment, ExeType, &Reason, > + SdbQueryAppCompatData, SdbQueryAppCompatDataSize, SxsData, SxsDataSize, FusionFlags)) > + { > + Status = STATUS_ACCESS_DENIED; > + } > } > } > > > Modified: trunk/reactos/dll/win32/kernel32/client/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/utils.c [iso-8859-1] Sun May 28 19:27:51 2017 > @@ -904,26 +904,6 @@ > /* > * @unimplemented > */ > -BOOL > -WINAPI > -BaseCheckRunApp(IN DWORD Unknown1, > - IN DWORD Unknown2, > - IN DWORD Unknown3, > - IN DWORD Unknown4, > - IN DWORD Unknown5, > - IN DWORD Unknown6, > - IN DWORD Unknown7, > - IN DWORD Unknown8, > - IN DWORD Unknown9, > - IN DWORD Unknown10) > -{ > - STUB; > - return FALSE; > -} > - > -/* > - * @unimplemented > - */ > NTSTATUS > WINAPI > BasepCheckWinSaferRestrictions(IN HANDLE UserToken, > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74621: [USETUP]: SetupLib: Add an ARC path to (and from) NT path resolver. It allows mapping between an ARC path as specified in freeldr.ini / boot.ini , to its corresponding NT path, if...
by Thomas Faber 22 May '17

22 May '17

On 2017-05-22 03:09, hbelusca(a)svn.reactos.org wrote: > --- branches/setup_improvements/base/setup/lib/arcname.c (added) > +++ branches/setup_improvements/base/setup/lib/arcname.c [iso-8859-1] Mon May 22 01:09:35 2017 > +PCSTR > +ArcGetNextTokenA( > + IN PCSTR ArcPath, > + OUT PANSI_STRING TokenSpecifier, > + OUT PULONG Key) > +{ > + HRESULT hr; > + PCSTR p = ArcPath; > + ULONG SpecifierLength; > + ULONG KeyValue; > + > + /* > + * We must have a valid "specifier(key)" string, where 'specifier' > + * cannot be the empty string, and is followed by '('. > + */ > + p = strchr(p, '('); > + if (p == NULL) > + return NULL; /* No '(' found */ > + if (p == ArcPath) > + return NULL; /* Path starts with '(' and is thus invalid */ > + > + SpecifierLength = (p - ArcPath) * sizeof(CHAR); > + > + /* > + * The strtoul function skips any leading whitespace. > + * > + * Note that if the token is "specifier()" then strtoul won't perform > + * any conversion and return 0, therefore effectively making the token > + * equivalent to "specifier(0)", as it should be. > + */ > + // KeyValue = atoi(p); > + KeyValue = strtoul(p, (PSTR*)&p, 10); > + > + /* Skip any trailing whitespace */ > + while (*p && isspace(*p)) ++p; isspace(0) is false so you don't need the *p check. > +PCWSTR > +ArcGetNextTokenU( > + IN PCWSTR ArcPath, > + OUT PUNICODE_STRING TokenSpecifier, > + OUT PULONG Key) > +{ > + HRESULT hr; > + PCWSTR p = ArcPath; > + ULONG SpecifierLength; > + ULONG KeyValue; > + > + /* > + * We must have a valid "specifier(key)" string, where 'specifier' > + * cannot be the empty string, and is followed by '('. > + */ > + p = wcschr(p, L'('); > + if (p == NULL) > + return NULL; /* No '(' found */ > + if (p == ArcPath) > + return NULL; /* Path starts with '(' and is thus invalid */ > + > + SpecifierLength = (p - ArcPath) * sizeof(WCHAR); > + > + ++p; > + > + /* > + * The strtoul function skips any leading whitespace. > + * > + * Note that if the token is "specifier()" then strtoul won't perform > + * any conversion and return 0, therefore effectively making the token > + * equivalent to "specifier(0)", as it should be. > + */ > + // KeyValue = _wtoi(p); > + KeyValue = wcstoul(p, (PWSTR*)&p, 10); > + ASSERT(p); This assert seems superfluous, you just dereferenced the pointer. Also, you incremented it just above and also (rightly) assumed it was larger than ArcPath. > +static NTSTATUS > +ResolveArcNameManually( > + OUT PUNICODE_STRING NtName, > + IN OUT PCWSTR* ArcNamePath, > + IN PPARTLIST PartList OPTIONAL) > +{ > [...] > +Quit: > + if (FAILED(hr)) > + { > + /* > + * We can directly cast the HRESULTs into NTSTATUS since the error codes > + * returned by StringCbPrintfW: > + * STRSAFE_E_INVALID_PARAMETER == 0x80070057, > + * STRSAFE_E_INSUFFICIENT_BUFFER == 0x8007007a, > + * do not have assigned values in the NTSTATUS space. > + */ > + return (NTSTATUS)hr; To me that sounds like an argument of why you _can't_ do that. (You know the Rtl versions of these functions give you an NTSTATUS btw, right?) > --- branches/setup_improvements/base/setup/lib/arcname_tests.c (added) > +++ branches/setup_improvements/base/setup/lib/arcname_tests.c [iso-8859-1] Mon May 22 01:09:35 2017 > @@ -0,0 +1,142 @@ > +/* > + * Tests for the arcname.c functions: > + * - ArcPathNormalize(), > + * - ArcPathToNtPath(). > + * > + * You should certainly fix the included headers before being able > + * to compile this file (as I didn't bother to have it compilable > + * under our (P/N)DK, but just under VS). > + */ Wine's test framework works okay for unit tests. You can make this an apitest by just #include'ing the C source file, then it can run on Testbot.

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74619: [USETUP]: filesup module: - Add a NtPathToDiskPartComponents helper, that takes in input a fully qualified NT path to a file on hard disk, e.g.: \Device\Harddisk1\Partition2\foo\b...
by Thomas Faber 22 May '17

22 May '17

On 2017-05-22 01:45, hbelusca(a)svn.reactos.org wrote: > +BOOLEAN > +NtPathToDiskPartComponents( > + IN PCWSTR NtPath, > + OUT PULONG pDiskNumber, > + OUT PULONG pPartNumber, > + OUT PCWSTR* PathComponent OPTIONAL) > +{ > + ULONG DiskNumber, PartNumber; > + PCWSTR Path; > + > + *pDiskNumber = 0; > + *pPartNumber = 0; > + if (PathComponent) *PathComponent = NULL; > + > + Path = NtPath; > + > + if (_wcsnicmp(Path, L"\\Device\\Harddisk", 16) != 0) > + { > + /* The NT path doesn't start with the prefix string, thus it cannot be a hard disk device path */ > + DPRINT1("'%S' : Not a possible hard disk device.\n", NtPath); > + return FALSE; > + } > + > + Path += 16; Avoiding these magic numbers would be nice. Options include: * static string à la static const WCHAR DeviceHarddiskPath[] = L"\\Device\\Harddisk"; _wcsnicmp(Path, DeviceHarddiskPath, ARRAYSIZE(DeviceHarddiskPath) - 1) * simply using wcslen(L"\\Device\\Harddisk") (which should get optimized) * making a "starts with" function * using RtlPrefixUnicodeString > @@ -593,6 +705,31 @@ > { > DPRINT1("Failed to open file %wZ, Status 0x%08lx\n", &Name, Status); > return Status; > + } > + > + if (FileSize) > + { > + /* Query the file size */ > + FILE_STANDARD_INFORMATION FileInfo; > + Status = NtQueryInformationFile(*FileHandle, > + &IoStatusBlock, > + &FileInfo, > + sizeof(FileInfo), > + FileStandardInformation); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT("NtQueryInformationFile() failed (Status %lx)\n", Status); > + NtClose(*FileHandle); > + *FileHandle = NULL; > + return Status; > + } > + > + if (FileInfo.EndOfFile.HighPart != 0) > + DPRINT1("WARNING!! The file %wZ is too large!\n", Name); Did you mean &Name?

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74618: [USETUP]: Move all the code that retrieves the version resources from PE executable, out of osdetect.c, and place it in its own module inside the setuplib. Remove also some commen...
by Thomas Faber 22 May '17

22 May '17

On 2017-05-22 01:41, hbelusca(a)svn.reactos.org wrote: > +static PCVS_VERSION_INFO_STRUCT32 > +VersionInfo32_FindChild( > + IN PCVS_VERSION_INFO_STRUCT32 info, > + IN PCWSTR szKey, > + IN UINT cbKey) > +{ > + PCVS_VERSION_INFO_STRUCT32 child = VersionInfo32_Children(info); > + > + while ((ULONG_PTR)child < (ULONG_PTR)info + info->wLength) > + { > + if (!_wcsnicmp(child->szKey, szKey, cbKey) && !child->szKey[cbKey]) You're using cbKey in two places that need a character count here. > + return child; > + > + if (child->wLength == 0) return NULL; > + child = VersionInfo32_Next(child); > + } > + > + return NULL; > +}

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74617: [USETUP]: PartList module: Add a couple of disk/partition getters: GetDiskByBiosNumber, GetDiskByNumber, GetDiskBySCSI, GetDiskBySignature, GetPartition, GetDiskOrPartition. They ...
by Thomas Faber 22 May '17

22 May '17

On 2017-05-22 01:36, hbelusca(a)svn.reactos.org wrote: > --- branches/setup_improvements/base/setup/lib/partlist.c [iso-8859-1] (original) > +++ branches/setup_improvements/base/setup/lib/partlist.c [iso-8859-1] Sun May 21 23:36:13 2017 > @@ -1333,8 +1348,204 @@ > RtlFreeHeap(ProcessHeap, 0, List); > } > > +PDISKENTRY > +GetDiskByBiosNumber( > + IN PPARTLIST List, > + IN ULONG BiosDiskNumber) > +{ > + PDISKENTRY DiskEntry; > + PLIST_ENTRY Entry; > + > + /* Check for empty disks */ > + if (IsListEmpty(&List->DiskListHead)) > + return NULL; These empty list checks look superfluous.

1 0

A surprising epic win: Wolfram Mathematica on ReactOS
by Hermès BÉLUSCA-MAÏTO 22 May '17

22 May '17

Hi all, I was pleasantly surprised to notice that the symbolic computation program « Wolfram Mathematica », in its version 8.0.4 (later versions are for Vista+ only), actually works quite pretty well on ReactOS (as of r74550): see the screen-capture at http://i.imgur.com/KegyW79.png . This software is broadly used in many scientific, engineering, mathematical, and computing fields. This is for example used intensively in theoretical physics (in high-energy physics, statistical physics etc.) due to the existence of numerous packages that have been developed for it. The only problem of this software resides in its price On the screen-capture I demonstrate an infinitesimal portion of what Mathematica can do: for the non-connoisseurs :) the picture shows the computation of the integral (area under the curve) of the 1-dimensional Gaussian function over the whole real axis (the result is square-root of pi), and then I plot in 3 dimensions the map of a 2-D Gaussian function, where on the horizontal plane there are the x and y axes, and the vertical axis is the z axis. The 3-D graph can be rotated, zoomed-in and out with the mouse, it can be edited, etc The software also proposes an extensive and interactive help documentation. Finally I show the fancy text-mode only interface of Mathematica, that nobody actually uses (it is only used when computing stuff in batch-mode). There are almost no graphical glitches. Few font problems can be seen (see the about-box, and the minus signs on the graph replaced by boxes). There are few keyboard shortcut problems such as pressing (on French keyboards) AltGr-5 to enter [ doesnt work, but anyways Enjoy! Best, Hermès

2 1

Re: [ros-dev] About the recent USETUP improvements in the branch
by Robert Naumann 22 May '17

22 May '17

I'd say it should stay as fallback solution. Am 21.05.2017 18:27 schrieb "Colin Finck" <colin(a)reactos.org>: Hey Hermès, Great work on the setup components! I especially like the library that paves the way for a feature-rich graphical installer :) Am 18.05.2017 um 20:02 schrieb Hermès BÉLUSCA-MAÏTO: > P.S.: Using a 8x8 font for the installer quickly hurts the eyes (and it > has been like that since ages). It would be great to use a more readable > resolution / font size… Oh yes, I'm all for a good looking installer with nicely readable texts in all languages. Which brings us to the GUI installer and to the question what we would still need the text-mode installer for when the GUI one is perfect? - Colin _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

2 1

About the recent USETUP improvements in the branch
by Hermès BÉLUSCA-MAÏTO 21 May '17

21 May '17

Hi all, Im writing a short mail to explain the recent USETUP improvements Im doing in the https://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/ branch. The aim is three-fold: - To improve multi-OSes / bootloaders detection and solve https://jira.reactos.org/browse/CORE-4870 , https://jira.reactos.org/browse/CORE-12672 , https://jira.reactos.org/browse/CORE-13188 , https://jira.reactos.org/browse/CORE-13226 in a consistent & reliable way, and possibly having a look at https://jira.reactos.org/browse/CORE-13205 and https://jira.reactos.org/browse/CORE-10898 (low priority for me at the moment). - A bit related to the previous point, have the possibility to automatically detect existing installations of ReactOS (and of Windows) to allow simple upgrade. For this latter part I have code that almost works: it browses all the available partitions on all the disks, and for each, attempts to see whether either freeldr or ntldr is installed, and if so, open their respective configuration files, browse the latter, and from that, deduce the candidate NT installations. On the following screenshot : http://i.imgur.com/Nq67J1o.png , a Windows installation actually exists on partition(1) but is not listed because it happens to be on an NTFS partition. Then there is a ReactOS installation on a FAT partition(2), and finally a Windows installation on another FAT partition(4) (all on the same disk). The installation detector has respectively parsed freeldr.ini, and boot.ini, to deduce the installations, and have removed installations having the same disk and partition numbers and SystemRoot (otherwise you would have seen many ReactOS (xxx) entries). - To facilitate the future implementation of the 1st-stage GUI setup by someone, all the code that can be made common between USETUP and this future GUI setup, is placed into a library. At the time of writing, this concerns the so-called generic lists functionality as well as the partition lists & some file-system-related routines. It will certainly grow up later. Cheers, Hermès P.S.: Using a 8x8 font for the installer quickly hurts the eyes (and it has been like that since ages). It would be great to use a more readable resolution / font size

2 1

Re: [ros-dev] [ros-diffs] [gedmurphy] 74590: [FLTMGR] - Add a rather messy header that I've been slowly building as I'm starting to understand the internals. - Mostly taken from the MS PDBs and info gained from OSR and Alex...
by Alex Ionescu 20 May '17

20 May '17

Hey Ged, The full internal internal filter manager header was published by microsoft in the "minwin" folder of the TH1 and TH2 WDK+SDK. Same place where Timo and Thomas have been using "ntosp.h" from. Best regards, Alex Ionescu On Fri, May 19, 2017 at 2:42 AM, <gedmurphy(a)svn.reactos.org> wrote: > Author: gedmurphy > Date: Fri May 19 09:42:00 2017 > New Revision: 74590 > > URL: http://svn.reactos.org/svn/reactos?rev=74590&view=rev > Log: > [FLTMGR] > - Add a rather messy header that I've been slowly building as I'm starting > to understand the internals. > - Mostly taken from the MS PDBs and info gained from OSR and Alex Carp's > blog. (https://fsfilters.blogspot.co.uk) > > Added: > trunk/reactos/drivers/filters/fltmgr/fltmgrint.h (with props) > > Added: trunk/reactos/drivers/filters/fltmgr/fltmgrint.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/ > filters/fltmgr/fltmgrint.h?rev=74590 > ============================================================ > ================== > --- trunk/reactos/drivers/filters/fltmgr/fltmgrint.h (added) > +++ trunk/reactos/drivers/filters/fltmgr/fltmgrint.h [iso-8859-1] Fri > May 19 09:42:00 2017 > @@ -0,0 +1,284 @@ > +#ifndef _FLTMGR_INTERNAL_H > +#define _FLTMGR_INTERNAL_H > + > + > +#define MAX_CONTEXT_TYPES 6 > + > + > +typedef enum _FLT_OBJECT_FLAGS > +{ > + FLT_OBFL_DRAINING = 1, > + FLT_OBFL_ZOMBIED = 2, > + FLT_OBFL_TYPE_INSTANCE = 0x1000000, > + FLT_OBFL_TYPE_FILTER = 0x2000000, > + FLT_OBFL_TYPE_VOLUME = 0x4000000 > + > +} FLT_OBJECT_FLAGS, *PFLT_OBJECT_FLAGS; > + > +typedef enum _FLT_FILTER_FLAGS > +{ > + FLTFL_MANDATORY_UNLOAD_IN_PROGRESS = 1, > + FLTFL_FILTERING_INITIATED = 2 > + > +} FLT_FILTER_FLAGS, *PFLT_FILTER_FLAGS; > + > +typedef struct _FLT_OBJECT // size = 0x14 > +{ > + volatile FLT_OBJECT_FLAGS Flags; > + ULONG PointerCount; > + EX_RUNDOWN_REF RundownRef; > + LIST_ENTRY PrimaryLink; > + > +} FLT_OBJECT, *PFLT_OBJECT; > + > +typedef struct _ALLOCATE_CONTEXT_HEADER > +{ > + PFLT_FILTER Filter; > + PFLT_CONTEXT_CLEANUP_CALLBACK ContextCleanupCallback; > + struct _ALLOCATE_CONTEXT_HEADER *Next; > + FLT_CONTEXT_TYPE ContextType; > + char Flags; > + char AllocationType; > + > +} ALLOCATE_CONTEXT_HEADER, *PALLOCATE_CONTEXT_HEADER; > + > +typedef struct _FLT_RESOURCE_LIST_HEAD > +{ > + ERESOURCE rLock; > + LIST_ENTRY rList; > + ULONG rCount; > + > +} FLT_RESOURCE_LIST_HEAD, *PFLT_RESOURCE_LIST_HEAD; > + > +typedef struct _FLT_MUTEX_LIST_HEAD > +{ > + FAST_MUTEX mLock; > + LIST_ENTRY mList; > + ULONG mCount; > + > +} FLT_MUTEX_LIST_HEAD, *PFLT_MUTEX_LIST_HEAD; > + > +typedef struct _FLT_FILTER // size = 0x120 > +{ > + FLT_OBJECT Base; > + PVOID Frame; //FLTP_FRAME > + UNICODE_STRING Name; > + UNICODE_STRING DefaultAltitude; > + FLT_FILTER_FLAGS Flags; > + PDRIVER_OBJECT DriverObject; > + FLT_RESOURCE_LIST_HEAD InstanceList; > + PVOID VerifierExtension; > + PFLT_FILTER_UNLOAD_CALLBACK FilterUnload; > + PFLT_INSTANCE_SETUP_CALLBACK InstanceSetup; > + PFLT_INSTANCE_QUERY_TEARDOWN_CALLBACK InstanceQueryTeardown; > + PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownStart; > + PFLT_INSTANCE_TEARDOWN_CALLBACK InstanceTeardownComplete; > + PALLOCATE_CONTEXT_HEADER SupportedContextsListHead; > + PALLOCATE_CONTEXT_HEADER SupportedContexts[MAX_CONTEXT_TYPES]; > + PVOID PreVolumeMount; > + PVOID PostVolumeMount; > + PFLT_GENERATE_FILE_NAME GenerateFileName; > + PFLT_NORMALIZE_NAME_COMPONENT NormalizeNameComponent; > + PFLT_NORMALIZE_CONTEXT_CLEANUP NormalizeContextCleanup; > + PFLT_OPERATION_REGISTRATION Operations; > + PFLT_FILTER_UNLOAD_CALLBACK OldDriverUnload; > + FLT_MUTEX_LIST_HEAD ActiveOpens; > + FLT_MUTEX_LIST_HEAD ConnectionList; > + FLT_MUTEX_LIST_HEAD PortList; > + EX_PUSH_LOCK PortLock; > + > +} FLT_FILTER, *PFLT_FILTER; > + > +typedef enum _FLT_yINSTANCE_FLAGS > +{ > + INSFL_CAN_BE_DETACHED = 0x01, > + INSFL_DELETING = 0x02, > + INSFL_INITING = 0x04 > + > +} FLT_INSTANCE_FLAGS, *PFLT_INSTANCE_FLAGS; > + > +typedef struct _FLT_TYPE > +{ > + USHORT Signature; > + USHORT Size; > + > +} FLT_TYPE, *PFLT_TYPE; > + > +typedef struct _FLT_INSTANCE // size = 0x144 (324) > +{ > + FLT_OBJECT Base; > + ULONG OperationRundownRef; > + PVOID Volume; //PFLT_VOLUME > + PFLT_FILTER Filter; > + FLT_INSTANCE_FLAGS Flags; > + UNICODE_STRING Altitude; > + UNICODE_STRING Name; > + LIST_ENTRY FilterLink; > + ERESOURCE ContextLock; > + PVOID Context; //PCONTEXT_NODE > + PVOID TrackCompletionNodes; //PRACK_COMPLETION_NODES > + PVOID CallbackNodes[50]; //PCALLBACK_NODE > + > +} FLT_INSTANCE, *PFLT_INSTANCE; > + > +// http://fsfilters.blogspot.co.uk/2010/02/filter-manager- > concepts-part-1.html > +typedef struct _FLTP_FRAME > +{ > + FLT_TYPE Type; > + LIST_ENTRY Links; > + unsigned int FrameID; > + ERESOURCE AltitudeLock; > + UNICODE_STRING AltitudeIntervalLow; > + UNICODE_STRING AltitudeIntervalHigh; > + char LargeIrpCtrlStackSize; > + char SmallIrpCtrlStackSize; > + FLT_RESOURCE_LIST_HEAD RegisteredFilters; > + FLT_RESOURCE_LIST_HEAD AttachedVolumes; > + LIST_ENTRY MountingVolumes; > + FLT_MUTEX_LIST_HEAD AttachedFileSystems; > + FLT_MUTEX_LIST_HEAD ZombiedFltObjectContexts; > + ERESOURCE FilterUnloadLock; > + FAST_MUTEX DeviceObjectAttachLock; > + //FLT_PRCB *Prcb; > + void *PrcbPoolToFree; > + void *LookasidePoolToFree; > + //FLTP_IRPCTRL_STACK_PROFILER IrpCtrlStackProfiler; > + NPAGED_LOOKASIDE_LIST SmallIrpCtrlLookasideList; > + NPAGED_LOOKASIDE_LIST LargeIrpCtrlLookasideList; > + //STATIC_IRP_CONTROL GlobalSIC; > + > +} FLTP_FRAME, *PFLTP_FRAME; > + > + > +// http://fsfilters.blogspot.co.uk/2010/02/filter-manager- > concepts-part-6.html > +typedef struct _STREAM_LIST_CTRL // size = 0xC8 (200) > +{ > + FLT_TYPE Type; > + FSRTL_PER_STREAM_CONTEXT ContextCtrl; > + LIST_ENTRY VolumeLink; > + //STREAM_LIST_CTRL_FLAGS Flags; > + int UseCount; > + ERESOURCE ContextLock; > + //CONTEXT_LIST_CTRL StreamContexts; > + //CONTEXT_LIST_CTRL StreamHandleContexts; > + ERESOURCE NameCacheLock; > + LARGE_INTEGER LastRenameCompleted; > + //NAME_CACHE_LIST_CTRL NormalizedNameCache; > + // NAME_CACHE_LIST_CTRL ShortNameCache; > + // NAME_CACHE_LIST_CTRL OpenedNameCache; > + int AllNameContextsTemporary; > + > +} STREAM_LIST_CTRL, *PSTREAM_LIST_CTRL; > + > + > +typedef struct _FLT_SERVER_PORT_OBJECT > +{ > + LIST_ENTRY FilterLink; > + PFLT_CONNECT_NOTIFY ConnectNotify; > + PFLT_DISCONNECT_NOTIFY DisconnectNotify; > + PFLT_MESSAGE_NOTIFY MessageNotify; > + PFLT_FILTER Filter; > + PVOID Cookie; > + ULONG Flags; > + LONG NumberOfConnections; > + LONG MaxConnections; > + > +} FLT_SERVER_PORT_OBJECT, *PFLT_SERVER_PORT_OBJECT; > + > + > +typedef struct _FLT_PORT_OBJECT > +{ > + LIST_ENTRY FilterLink; > + PFLT_SERVER_PORT_OBJECT ServerPort; > + PVOID Cookie; > + EX_RUNDOWN_REF MsgNotifRundownRef; > + FAST_MUTEX Lock; > + PVOID MsgQ; // FLT_MESSAGE_WAITER_QUEUE MsgQ; > + ULONGLONG MessageId; > + KEVENT DisconnectEvent; > + BOOLEAN Disconnected; > + > +} FLT_PORT_OBJECT, *PFLT_PORT_OBJECT; > + > + > + > + > + > +VOID > +FltpExInitializeRundownProtection( > + _Out_ PEX_RUNDOWN_REF RundownRef > +); > + > +BOOLEAN > +FltpExAcquireRundownProtection( > + _Inout_ PEX_RUNDOWN_REF RundownRef > +); > + > +BOOLEAN > +FltpExReleaseRundownProtection( > + _Inout_ PEX_RUNDOWN_REF RundownRef > +); > + > +NTSTATUS > +NTAPI > +FltpObjectRundownWait( > + _Inout_ PEX_RUNDOWN_REF RundownRef > +); > + > +BOOLEAN > +FltpExRundownCompleted( > + _Inout_ PEX_RUNDOWN_REF RundownRef > +); > + > + > +NTSTATUS > +FltpGetBaseDeviceObjectName( > + _In_ PDEVICE_OBJECT DeviceObject, > + _Inout_ PUNICODE_STRING ObjectName > +); > + > +NTSTATUS > +FltpGetObjectName( > + _In_ PVOID Object, > + _Inout_ PUNICODE_STRING ObjectName > +); > + > +ULONG > +FltpObjectPointerReference( > + _In_ PFLT_OBJECT Object > +); > + > +VOID > +FltpObjectPointerDereference( > + _In_ PFLT_OBJECT Object > +); > + > +NTSTATUS > +FltpReallocateUnicodeString( > + _In_ PUNICODE_STRING String, > + _In_ SIZE_T NewLength, > + _In_ BOOLEAN CopyExisting > +); > + > +VOID > +FltpFreeUnicodeString( > + _In_ PUNICODE_STRING String > +); > + > + > + > +NTSTATUS > +FltpDeviceControlHandler( > + _In_ PDEVICE_OBJECT DeviceObject, > + _Inout_ PIRP Irp > +); > + > +NTSTATUS > +FltpDispatchHandler( > + _In_ PDEVICE_OBJECT DeviceObject, > + _Inout_ PIRP Irp > +); > + > + > + > +#endif /* _FLTMGR_INTERNAL_H */ > > Propchange: trunk/reactos/drivers/filters/fltmgr/fltmgrint.h > ------------------------------------------------------------ > ------------------ > svn:eol-style = native > > >

2 1

Re: [ros-dev] [ros-diffs] [phater] 74577: [MSTSC] Fix BSOD when we can't acquire context from CryptoAPI. CORE-13263 #resolve
by Ged Murphy 18 May '17

18 May '17

Fixing a bugcheck from usermode??? I'm guessing you mean avoid a bugcheck, and the real crash still needs investigating and fixing? -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of phater(a)svn.reactos.org Sent: 18 May 2017 09:48 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [phater] 74577: [MSTSC] Fix BSOD when we can't acquire context from CryptoAPI. CORE-13263 #resolve Author: phater Date: Thu May 18 08:47:30 2017 New Revision: 74577 URL: http://svn.reactos.org/svn/reactos?rev=74577&view=rev Log: [MSTSC] Fix BSOD when we can't acquire context from CryptoAPI. CORE-13263 #resolve

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue implementing the NT OS installation detector. What remains to be done here, besides cleaning up the code from temporary comments and DPRINTs (and fixing potenti...
by Thomas Faber 16 May '17

16 May '17

Hi again, some comments inline. On 2017-05-15 03:59, hbelusca(a)svn.reactos.org wrote: > --- branches/setup_improvements/base/setup/usetup/osdetect.c [iso-8859-1] (original) > +++ branches/setup_improvements/base/setup/usetup/osdetect.c [iso-8859-1] Mon May 15 01:59:28 2017 > @@ -19,6 +19,9 @@ > /* GLOBALS ******************************************************************/ > > extern PPARTLIST PartitionList; > + > +/* Language-independent Vendor strings */ > +static const PCWSTR KnownVendors[] = { L"ReactOS", L"Microsoft" }; > > > /* VERSION RESOURCE API ******************************************************/ > @@ -361,36 +364,331 @@ > > #endif > > + > +/*** > +*wchar_t *wcsstr(string1, string2) - search for string2 in string1 > +* (wide strings) Copypasta? > +* > +*Purpose: > +* finds the first occurrence of string2 in string1 (wide strings) > +* > +*Entry: > +* wchar_t *string1 - string to search in > +* wchar_t *string2 - string to search for > +* > +*Exit: > +* returns a pointer to the first occurrence of string2 in > +* string1, or NULL if string2 does not occur in string1 > +* > +*Uses: > +* > +*Exceptions: > +* > +*******************************************************************************/ > +PWSTR FindSubStrI(PCWSTR str, PCWSTR strSearch) > +{ > + PWSTR cp = (PWSTR)str; > + PWSTR s1, s2; > + > + if (!*strSearch) > + return (PWSTR)str; > + > + while (*cp) > + { > + s1 = cp; > + s2 = (PWSTR)strSearch; > + > + while (*s1 && *s2 && (towupper(*s1) == towupper(*s2))) > + ++s1, ++s2; > + > + if (!*s2) > + return cp; > + > + ++cp; > + } > + > + return NULL; > +} > + > static BOOLEAN > -IsRecognizedOS( > +CheckForValidPEAndVendor( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName OPTIONAL, > + IN PCWSTR FileName, // OPTIONAL > + IN PCWSTR VendorName // Better would be OUT PCWSTR*, and the function returning NTSTATUS ? > + ) > +{ > + BOOLEAN Success = FALSE; > + NTSTATUS Status; > + HANDLE FileHandle, SectionHandle; > + // SIZE_T ViewSize; > + PVOID ViewBase; > + PVOID VersionBuffer = NULL; // Read-only > + PVOID pvData = NULL; > + UINT BufLen = 0; > + > + Status = OpenAndMapFile(RootDirectory, PathName, FileName, > + &FileHandle, &SectionHandle, &ViewBase); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to open and map file %wZ, Status 0x%08lx\n", &FileName, Status); > + return FALSE; // Status; > + } > + > + /* Make sure it's a valid PE file */ > + if (!RtlImageNtHeader(ViewBase)) > + { > + DPRINT1("File %wZ does not seem to be a valid PE, bail out\n", &FileName); > + Status = STATUS_INVALID_IMAGE_FORMAT; > + goto UnmapFile; > + } > + > + /* > + * Search for a valid executable version and vendor. > + * NOTE: The module is loaded as a data file, it should be marked as such. > + */ > + Status = NtGetVersionResource((PVOID)((ULONG_PTR)ViewBase | 1), &VersionBuffer, NULL); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to get version resource for file %wZ, Status 0x%08lx\n", &FileName, Status); > + goto UnmapFile; > + } > + > + Status = NtVerQueryValue(VersionBuffer, L"\\VarFileInfo\\Translation", &pvData, &BufLen); > + if (NT_SUCCESS(Status)) > + { > + USHORT wCodePage = 0, wLangID = 0; > + WCHAR FileInfo[MAX_PATH]; > + UNICODE_STRING Vendor; > + > + wCodePage = LOWORD(*(ULONG*)pvData); > + wLangID = HIWORD(*(ULONG*)pvData); > + > + StringCchPrintfW(FileInfo, ARRAYSIZE(FileInfo), > + L"StringFileInfo\\%04X%04X\\CompanyName", > + wCodePage, wLangID); > + > + Status = NtVerQueryValue(VersionBuffer, FileInfo, &pvData, &BufLen); > + if (NT_SUCCESS(Status) && pvData) > + { > + /* BufLen includes the NULL terminator count */ > + RtlInitEmptyUnicodeString(&Vendor, pvData, BufLen * sizeof(WCHAR)); > + Vendor.Length = Vendor.MaximumLength - sizeof(UNICODE_NULL); > + > + DPRINT1("Found version vendor: \"%wZ\" for file %wZ\n", &Vendor, &FileName); > + > + Success = !!FindSubStrI(pvData, VendorName); > + } > + else > + { > + DPRINT1("No version vendor found for file %wZ\n", &FileName); > + } > + } > + > +UnmapFile: > + /* Finally, unmap and close the file */ > + UnMapFile(SectionHandle, ViewBase); > + NtClose(FileHandle); This seems clumsy. If there's a single function to open and map the file, why isn't there one function to unmap and close? > + > + return Success; > +} > + > +static BOOLEAN > +IsValidNTOSInstallation( > + IN HANDLE PartitionHandle, > + IN PCWSTR SystemRoot) > +{ > + BOOLEAN Success = FALSE; > + USHORT i; > + WCHAR PathBuffer[MAX_PATH]; > + > + // DoesPathExist(PartitionHandle, SystemRoot, L"System32\\"); etc... > + > + /* Check for the existence of \SystemRoot\System32 */ > + StringCchPrintfW(PathBuffer, ARRAYSIZE(PathBuffer), L"%s%s", SystemRoot, L"System32\\"); > + if (!DoesPathExist(PartitionHandle, PathBuffer)) > + { > + // DPRINT1("Failed to open directory %wZ, Status 0x%08lx\n", &FileName, Status); You know there's DPRINT for exactly this purpose, right? > + return FALSE; > + } > + > + /* Check for the existence of \SystemRoot\System32\drivers */ > + StringCchPrintfW(PathBuffer, ARRAYSIZE(PathBuffer), L"%s%s", SystemRoot, L"System32\\drivers\\"); > + if (!DoesPathExist(PartitionHandle, PathBuffer)) > + { > + // DPRINT1("Failed to open directory %wZ, Status 0x%08lx\n", &FileName, Status); > + return FALSE; > + } > + > + /* Check for the existence of \SystemRoot\System32\config */ > + StringCchPrintfW(PathBuffer, ARRAYSIZE(PathBuffer), L"%s%s", SystemRoot, L"System32\\config\\"); > + if (!DoesPathExist(PartitionHandle, PathBuffer)) > + { > + // DPRINT1("Failed to open directory %wZ, Status 0x%08lx\n", &FileName, Status); > + return FALSE; > + } > + > +#if 0 > + /* > + * Check for the existence of SYSTEM and SOFTWARE hives in \SystemRoot\System32\config > + * (but we don't check here whether they are actually valid). > + */ > + if (!DoesFileExist(PartitionHandle, SystemRoot, L"System32\\config\\SYSTEM")) > + { > + // DPRINT1("Failed to open file %wZ, Status 0x%08lx\n", &FileName, Status); > + return FALSE; > + } > + if (!DoesFileExist(PartitionHandle, SystemRoot, L"System32\\config\\SOFTWARE")) > + { > + // DPRINT1("Failed to open file %wZ, Status 0x%08lx\n", &FileName, Status); > + return FALSE; > + } > +#endif > + > + for (i = 0; i < ARRAYSIZE(KnownVendors); ++i) > + { > + /* Check for the existence of \SystemRoot\System32\ntoskrnl.exe and verify its version */ > + Success = CheckForValidPEAndVendor(PartitionHandle, SystemRoot, L"System32\\ntoskrnl.exe", KnownVendors[i]); > + > + /* OPTIONAL: Check for the existence of \SystemRoot\System32\ntkrnlpa.exe */ > + > + /* Check for the existence of \SystemRoot\System32\ntdll.dll */ > + Success = CheckForValidPEAndVendor(PartitionHandle, SystemRoot, L"System32\\ntdll.dll", KnownVendors[i]); > + > + /* We have found a correct vendor combination */ > + if (Success) > + break; > + } > + > + return Success; > +} > + > +typedef struct _NTOS_INSTALLATION > +{ > + LIST_ENTRY ListEntry; > + ULONG DiskNumber; > + ULONG PartitionNumber; > +// Vendor???? > + WCHAR SystemRoot[MAX_PATH]; > +/**/WCHAR InstallationName[MAX_PATH];/**/ > +} NTOS_INSTALLATION, *PNTOS_INSTALLATION; > + > +static VOID > +ListNTOSInstalls( > + IN PGENERIC_LIST List) > +{ > + PGENERIC_LIST_ENTRY Entry; > + PNTOS_INSTALLATION NtOsInstall; > + ULONG NtOsInstallsCount = GetNumberOfListEntries(List); > + > + DPRINT1("There %s %d installation%s detected:\n", > + NtOsInstallsCount >= 2 ? "are" : "is", > + NtOsInstallsCount, > + NtOsInstallsCount >= 2 ? "s" : ""); > + > + Entry = GetFirstListEntry(List); > + while (Entry) > + { > + NtOsInstall = (PNTOS_INSTALLATION)GetListEntryUserData(Entry); Casts from PVOID to other pointer types are unnecessary. Thanks, Thomas

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 74550: [USETUP]: Continue implementing the NT OS installation detector. What remains to be done here, besides cleaning up the code from temporary comments and DPRINTs (and fixing potenti...
by Thomas Faber 16 May '17

16 May '17

On 2017-05-15 03:59, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon May 15 01:59:28 2017 > New Revision: 74550 > > URL: http://svn.reactos.org/svn/reactos?rev=74550&view=rev > Log: > [USETUP]: Continue implementing the NT OS installation detector. > What remains to be done here, besides cleaning up the code from temporary comments and DPRINTs (and fixing potential bugs), is to actually parse the NTOS loader configuration files (freeldr.ini in ROS' case, or boot.ini in Win2k3's case, etc...) to retrieve the actual installation paths. So far these are currently hardcoded for testing purposes only. > Note that I try to distinguish between ROS and Windows installations by checking at the company name vendor of the ntoskrnl.exe & ntdll.dll files, in order to allow the upgrade of ROS installations only. > Suggestions are always welcome. We should totally allow "upgrading" Windows installations with ROS. We're obviously better ;)

2 1

Re: [ros-dev] [ros-diffs] [gadamopoulos] 74552: [UXTHEME] -ThemeDrawCaptionText: Try to avoid a heap allocation when getting the window caption.
by Thomas Faber 16 May '17

16 May '17

Hi, comments inline. On 2017-05-15 18:05, gadamopoulos(a)svn.reactos.org wrote: > --- trunk/reactos/dll/win32/uxtheme/nonclient.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/uxtheme/nonclient.c [iso-8859-1] Mon May 15 16:05:14 2017 > @@ -100,16 +100,7 @@ > return hIcon; > } > > -WCHAR *UserGetWindowCaption(HWND hwnd) > -{ > - INT len = 512; > - WCHAR *text; > - text = (WCHAR*)HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); > - if (text) InternalGetWindowText(hwnd, text, len); > - return text; > -} > - > -HRESULT WINAPI ThemeDrawCaptionText(PDRAW_CONTEXT pcontext, RECT* pRect, int iPartId, int iStateId, LPCWSTR pszText) > +HRESULT WINAPI ThemeDrawCaptionText(PDRAW_CONTEXT pcontext, RECT* pRect, int iPartId, int iStateId) > { > HRESULT hr; > HFONT hFont = NULL; > @@ -117,6 +108,25 @@ > LOGFONTW logfont; > COLORREF textColor; > COLORREF oldTextColor; > + > + WCHAR buffer[50]; > + WCHAR *pszText = buffer; > + INT len; > + > + len = InternalGetWindowText(pcontext->hWnd, NULL, 0); > + if (!len) > + return S_OK; > + > + len++; /* From now on this is the size of the buffer so include the null */ > + > + if (len > 50) _countof(buffer), or ARRAYSIZE, or whatever people use these days. > + { > + pszText = (WCHAR*)HeapAlloc(GetProcessHeap(), 0, len * sizeof(WCHAR)); Unnecessary cast. > + if (!pszText) > + return E_FAIL; Ewwww. Worst error code. Thanks. -Thomas

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74549: [USETUP]: Add & modify some file utility functions that are going to be used in the next commit. - ConcatPaths that concatenates paths (or a path and a file name); - OpenAndMapFil...
by Thomas Faber 16 May '17

16 May '17

Basic source control rule: please don't change things and move them around at the same time. Unless your goal is to make sure noone reviews your changes, of course. Thanks. -Thomas On 2017-05-15 03:52, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon May 15 01:52:34 2017 > New Revision: 74549 > > URL: http://svn.reactos.org/svn/reactos?rev=74549&view=rev > Log: > [USETUP]: Add & modify some file utility functions that are going to be used in the next commit. > - ConcatPaths that concatenates paths (or a path and a file name); > - OpenAndMapFile (resp. UnMapFile), whose purpose is to open a file and map it in memory (resp. unmap it from memory). > - Add extra optional parameters to DoesPathExist and DoesFileExist: an optional "RootDirectory" handle and, for DoesFileExist only, an optional PathName. > > Modified: > branches/setup_improvements/base/setup/usetup/filesup.c > branches/setup_improvements/base/setup/usetup/filesup.h > > Modified: branches/setup_improvements/base/setup/usetup/filesup.c > URL: http://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/u… > ============================================================================== > --- branches/setup_improvements/base/setup/usetup/filesup.c [iso-8859-1] (original) > +++ branches/setup_improvements/base/setup/usetup/filesup.c [iso-8859-1] Mon May 15 01:52:34 2017 > @@ -93,59 +93,6 @@ > return Status; > } > > - > -static > -BOOLEAN > -DoesPathExist( > - PWSTR PathName) > -{ > - OBJECT_ATTRIBUTES ObjectAttributes; > - IO_STATUS_BLOCK IoStatusBlock; > - UNICODE_STRING Name; > - HANDLE FileHandle; > - NTSTATUS Status; > - > - RtlInitUnicodeString(&Name, PathName); > - > - InitializeObjectAttributes(&ObjectAttributes, > - &Name, > - OBJ_CASE_INSENSITIVE, > - NULL, > - NULL); > - > - Status = NtOpenFile(&FileHandle, > - GENERIC_READ | SYNCHRONIZE, > - &ObjectAttributes, > - &IoStatusBlock, > - 0, > - FILE_SYNCHRONOUS_IO_NONALERT); > - if (NT_SUCCESS(Status)) > - NtClose(FileHandle); > - > - return NT_SUCCESS(Status); > -} > - > - > -BOOLEAN > -IsValidPath( > - PWCHAR InstallDir, > - ULONG Length) > -{ > - UINT i; > - > - // TODO: Add check for 8.3 too. > - > - /* Check for whitespaces */ > - for (i = 0; i < Length; i++) > - { > - if (isspace(InstallDir[i])) > - return FALSE; > - } > - > - return TRUE; > -} > - > - > NTSTATUS > SetupCreateDirectory( > PWCHAR PathName) > @@ -183,7 +130,7 @@ > *Ptr = 0; > > DPRINT("PathBuffer: %S\n", PathBuffer); > - if (!DoesPathExist(PathBuffer)) > + if (!DoesPathExist(NULL, PathBuffer)) > { > DPRINT("Create: %S\n", PathBuffer); > Status = SetupCreateSingleDirectory(PathBuffer); > @@ -197,7 +144,7 @@ > Ptr++; > } > > - if (!DoesPathExist(PathBuffer)) > + if (!DoesPathExist(NULL, PathBuffer)) > { > DPRINT("Create: %S\n", PathBuffer); > Status = SetupCreateSingleDirectory(PathBuffer); > @@ -212,7 +159,6 @@ > > return Status; > } > - > > NTSTATUS > SetupCopyFile( > @@ -233,7 +179,6 @@ > SIZE_T SourceSectionSize = 0; > LARGE_INTEGER ByteOffset; > > -#ifdef __REACTOS__ > RtlInitUnicodeString(&FileName, > SourceFileName); > > @@ -254,20 +199,6 @@ > DPRINT1("NtOpenFile failed: %x, %wZ\n", Status, &FileName); > goto done; > } > -#else > - FileHandleSource = CreateFileW(SourceFileName, > - GENERIC_READ, > - FILE_SHARE_READ, > - NULL, > - OPEN_EXISTING, > - 0, > - NULL); > - if (FileHandleSource == INVALID_HANDLE_VALUE) > - { > - Status = STATUS_UNSUCCESSFUL; > - goto done; > - } > -#endif > > Status = NtQueryInformationFile(FileHandleSource, > &IoStatusBlock, > @@ -484,44 +415,254 @@ > } > #endif > > + > +BOOLEAN > +IsValidPath( > + IN PWCHAR InstallDir, > + IN ULONG Length) > +{ > + UINT i; > + > + // TODO: Add check for 8.3 too. > + > + /* Check for whitespaces */ > + for (i = 0; i < Length; i++) > + { > + if (isspace(InstallDir[i])) > + return FALSE; > + } > + > + return TRUE; > +} > + > +HRESULT > +ConcatPaths( > + IN OUT PWSTR PathElem1, > + IN SIZE_T cchPathSize, > + IN PCWSTR PathElem2 OPTIONAL) > +{ > + HRESULT hr; > + SIZE_T cchPathLen; > + > + if (!PathElem2) > + return S_OK; > + if (cchPathSize <= 1) > + return S_OK; > + > + cchPathLen = min(cchPathSize, wcslen(PathElem1)); > + > + if (PathElem2[0] != L'\\' && cchPathLen > 0 && PathElem1[cchPathLen-1] != L'\\') > + { > + /* PathElem2 does not start with '\' and PathElem1 does not end with '\' */ > + hr = StringCchCatW(PathElem1, cchPathSize, L"\\"); > + if (FAILED(hr)) > + return hr; > + } > + else if (PathElem2[0] == L'\\' && cchPathLen > 0 && PathElem1[cchPathLen-1] == L'\\') > + { > + /* PathElem2 starts with '\' and PathElem1 ends with '\' */ > + while (*PathElem2 == L'\\') > + ++PathElem2; // Skip any backslash > + } > + hr = StringCchCatW(PathElem1, cchPathSize, PathElem2); > + return hr; > +} > + > +// > +// NOTE: It may be possible to merge both DoesPathExist and DoesFileExist... > +// > +BOOLEAN > +DoesPathExist( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName) > +{ > + NTSTATUS Status; > + HANDLE FileHandle; > + OBJECT_ATTRIBUTES ObjectAttributes; > + IO_STATUS_BLOCK IoStatusBlock; > + UNICODE_STRING Name; > + > + RtlInitUnicodeString(&Name, PathName); > + > + InitializeObjectAttributes(&ObjectAttributes, > + &Name, > + OBJ_CASE_INSENSITIVE, > + RootDirectory, > + NULL); > + > + Status = NtOpenFile(&FileHandle, > + FILE_LIST_DIRECTORY | SYNCHRONIZE, > + &ObjectAttributes, > + &IoStatusBlock, > + FILE_SHARE_READ | FILE_SHARE_WRITE, > + FILE_SYNCHRONOUS_IO_NONALERT | FILE_DIRECTORY_FILE); > + if (NT_SUCCESS(Status)) > + NtClose(FileHandle); > + else > + DPRINT1("Failed to open directory %wZ, Status 0x%08lx\n", &Name, Status); > + > + return NT_SUCCESS(Status); > +} > + > BOOLEAN > DoesFileExist( > - PWSTR PathName, > - PWSTR FileName) > -{ > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName OPTIONAL, > + IN PCWSTR FileName) > +{ > + NTSTATUS Status; > + HANDLE FileHandle; > OBJECT_ATTRIBUTES ObjectAttributes; > IO_STATUS_BLOCK IoStatusBlock; > UNICODE_STRING Name; > WCHAR FullName[MAX_PATH]; > - HANDLE FileHandle; > - NTSTATUS Status; > - > - wcscpy(FullName, PathName); > - if (FileName != NULL) > - { > - if (FileName[0] != L'\\') > - wcscat(FullName, L"\\"); > - wcscat(FullName, FileName); > - } > + > + if (PathName) > + StringCchCopyW(FullName, ARRAYSIZE(FullName), PathName); > + else > + FullName[0] = UNICODE_NULL; > + > + if (FileName) > + ConcatPaths(FullName, ARRAYSIZE(FullName), FileName); > > RtlInitUnicodeString(&Name, FullName); > > InitializeObjectAttributes(&ObjectAttributes, > &Name, > OBJ_CASE_INSENSITIVE, > - NULL, > + RootDirectory, > NULL); > > Status = NtOpenFile(&FileHandle, > GENERIC_READ | SYNCHRONIZE, > &ObjectAttributes, > &IoStatusBlock, > - 0, > - FILE_SYNCHRONOUS_IO_NONALERT); > + FILE_SHARE_READ | FILE_SHARE_WRITE, > + FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE); > if (NT_SUCCESS(Status)) > NtClose(FileHandle); > + else > + DPRINT1("Failed to open file %wZ, Status 0x%08lx\n", &Name, Status); > > return NT_SUCCESS(Status); > } > > +NTSTATUS > +OpenAndMapFile( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName OPTIONAL, > + IN PCWSTR FileName, // OPTIONAL > + OUT PHANDLE FileHandle, // IN OUT PHANDLE OPTIONAL > + OUT PHANDLE SectionHandle, > + OUT PVOID* BaseAddress) > +{ > + NTSTATUS Status; > + OBJECT_ATTRIBUTES ObjectAttributes; > + IO_STATUS_BLOCK IoStatusBlock; > + SIZE_T ViewSize; > + PVOID ViewBase; > + UNICODE_STRING Name; > + WCHAR FullName[MAX_PATH]; > + > + if (PathName) > + StringCchCopyW(FullName, ARRAYSIZE(FullName), PathName); > + else > + FullName[0] = UNICODE_NULL; > + > + if (FileName) > + ConcatPaths(FullName, ARRAYSIZE(FullName), FileName); > + > + RtlInitUnicodeString(&Name, FullName); > + > + InitializeObjectAttributes(&ObjectAttributes, > + &Name, > + OBJ_CASE_INSENSITIVE, > + RootDirectory, > + NULL); > + > + *FileHandle = NULL; > + *SectionHandle = NULL; > + > + Status = NtOpenFile(FileHandle, > + GENERIC_READ | SYNCHRONIZE, > + &ObjectAttributes, > + &IoStatusBlock, > + FILE_SHARE_READ, > + FILE_SYNCHRONOUS_IO_NONALERT | FILE_NON_DIRECTORY_FILE); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to open file %wZ, Status 0x%08lx\n", &Name, Status); > + return Status; > + } > + > + /* Map the file in memory */ > + > + /* Create the section */ > + Status = NtCreateSection(SectionHandle, > + SECTION_MAP_READ, > + NULL, > + NULL, > + PAGE_READONLY, > + SEC_COMMIT /* | SEC_IMAGE (_NO_EXECUTE) */, > + *FileHandle); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to create a memory section for file %wZ, Status 0x%08lx\n", &Name, Status); > + NtClose(*FileHandle); > + *FileHandle = NULL; > + return Status; > + } > + > + /* Map the section */ > + ViewSize = 0; > + ViewBase = NULL; > + Status = NtMapViewOfSection(*SectionHandle, > + NtCurrentProcess(), > + &ViewBase, > + 0, 0, > + NULL, > + &ViewSize, > + ViewShare, > + 0, > + PAGE_READONLY); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Failed to map a view for file %wZ, Status 0x%08lx\n", &Name, Status); > + NtClose(*SectionHandle); > + *SectionHandle = NULL; > + NtClose(*FileHandle); > + *FileHandle = NULL; > + return Status; > + } > + > + *BaseAddress = ViewBase; > + return STATUS_SUCCESS; > +} > + > +BOOLEAN > +UnMapFile( > + IN HANDLE SectionHandle, > + IN PVOID BaseAddress) > +{ > + NTSTATUS Status; > + BOOLEAN Success = TRUE; > + > + Status = NtUnmapViewOfSection(NtCurrentProcess(), BaseAddress); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("UnMapFile: NtUnmapViewOfSection(0x%p) failed with Status 0x%08lx\n", > + BaseAddress, Status); > + Success = FALSE; > + } > + Status = NtClose(SectionHandle); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("UnMapFile: NtClose(0x%p) failed with Status 0x%08lx\n", > + SectionHandle, Status); > + Success = FALSE; > + } > + > + return Success; > +} > + > /* EOF */ > > Modified: branches/setup_improvements/base/setup/usetup/filesup.h > URL: http://svn.reactos.org/svn/reactos/branches/setup_improvements/base/setup/u… > ============================================================================== > --- branches/setup_improvements/base/setup/usetup/filesup.h [iso-8859-1] (original) > +++ branches/setup_improvements/base/setup/usetup/filesup.h [iso-8859-1] Mon May 15 01:52:34 2017 > @@ -41,14 +41,41 @@ > PWCHAR SourceFileName, > PWCHAR DestinationFileName); > > -BOOLEAN > -DoesFileExist( > - PWSTR PathName, > - PWSTR FileName); > > BOOLEAN > IsValidPath( > - PWCHAR InstallDir, > - ULONG Length); > + IN PWCHAR InstallDir, > + IN ULONG Length); > + > +HRESULT > +ConcatPaths( > + IN OUT PWSTR PathElem1, > + IN SIZE_T cchPathSize, > + IN PCWSTR PathElem2 OPTIONAL); > + > +BOOLEAN > +DoesPathExist( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName); > + > +BOOLEAN > +DoesFileExist( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName OPTIONAL, > + IN PCWSTR FileName); > + > +NTSTATUS > +OpenAndMapFile( > + IN HANDLE RootDirectory OPTIONAL, > + IN PCWSTR PathName OPTIONAL, > + IN PCWSTR FileName, // OPTIONAL > + OUT PHANDLE FileHandle, // IN OUT PHANDLE OPTIONAL > + OUT PHANDLE SectionHandle, > + OUT PVOID* BaseAddress); > + > +BOOLEAN > +UnMapFile( > + IN HANDLE SectionHandle, > + IN PVOID BaseAddress); > > /* EOF */ > >

1 0

Re: [ros-dev] [ros-diffs] [ion] 74546: BL Library now works 100% in paging, protected mode. A picture is worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg [BOOTLIB]: Add support for protocol open/close/lookup while p...
by Alex Ionescu 16 May '17

16 May '17

The logo is just a temporary hack to prove stuff works. It will be removed at some point, so I don't think bin2c'ing is worth it... Best regards, Alex Ionescu On Mon, May 15, 2017 at 5:51 AM, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr > wrote: > What about using standard PE resources? Is it doable even in the EFI > applications? > Hermès > > -----Message d'origine----- > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Thomas > Faber > Envoyé : lundi 15 mai 2017 12:04 > À : Alex Ionescu > Cc : ros-dev(a)reactos.org > Objet : Re: [ros-dev] [ros-diffs] [ion] 74546: BL Library now works 100% > in paging, protected mode. A picture is worth a thousand commits: > http://i.imgur.com/Zx2nQ6x.jpg [BOOTLIB]: Add support for protocol > open/close/lookup while p... > > We have a bin2c tool that would make including the boot logo much nicer. > You'll want to use something like the attached patch, and add the bmp file > as app/rosload/logo.bmp. Then just include "logo.h" > instead of the g_Logo array in rosload.c. > > > On 2017-05-15 03:38, ion(a)svn.reactos.org wrote: > > Author: ion > > Date: Mon May 15 01:38:49 2017 > > New Revision: 74546 > > > > URL: http://svn.reactos.org/svn/reactos?rev=74546&view=rev > > Log: > > BL Library now works 100% in paging, protected mode. A picture is > > worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg > > [BOOTLIB]: Add support for protocol open/close/lookup while paging and > protected mode is enabled. > > [BOOTLIB]: Implement support for dozens of UEFI functions while under > protected mode. > > [BOOTLIB]: Fix bugs in existing UEFI functions which were switching to > _protected_ mode instead of _real mode_ before making the UEFI call. > > [BOOTLIB]: Free dynamic descriptor in MmMdFreeDescriptor. > > [BOOTLIB]: Implement BlHtDelete. > > [BOOTLIB]: Implement re-initialize-all path in DsppInitialize. > > [BOOTLIB]: Fix small bug in BlDisplayInvalidateOemBitmap > > [BOOTLIB]: Fix bigger bug in BlDisplayGetOemBitmap :) > > > > Modified: > > trunk/reactos/boot/environ/app/rosload/rosload.c > > trunk/reactos/boot/environ/include/bl.h > > trunk/reactos/boot/environ/lib/firmware/efi/firmware.c > > trunk/reactos/boot/environ/lib/io/device.c > > trunk/reactos/boot/environ/lib/io/display/display.c > > trunk/reactos/boot/environ/lib/io/display/efi/gop.c > > trunk/reactos/boot/environ/lib/misc/util.c > > trunk/reactos/boot/environ/lib/mm/descriptor.c > > trunk/reactos/boot/environ/lib/platform/time.c > > > > [This mail would be too long, it was shortened to contain the URLs > > only.] > > > > Modified: trunk/reactos/boot/environ/app/rosload/rosload.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/app/rosl > > oad/rosload.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/include/bl.h > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/include/ > > bl.h?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/firmware/efi/firmware.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/firm > > ware/efi/firmware.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/io/device.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d > > evice.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/io/display/display.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d > > isplay/display.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/io/display/efi/gop.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/d > > isplay/efi/gop.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/misc/util.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/misc > > /util.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/mm/descriptor.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/mm/d > > escriptor.c?rev=74546&r1=74545&r2=74546&view=diff > > > > Modified: trunk/reactos/boot/environ/lib/platform/time.c > > URL: > > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/plat > > form/time.c?rev=74546&r1=74545&r2=74546&view=diff > > > > > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

1 0

Re: [ros-dev] [ros-diffs] [ion] 74546: BL Library now works 100% in paging, protected mode. A picture is worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg [BOOTLIB]: Add support for protocol open/close/lookup while p...
by Thomas Faber 15 May '17

15 May '17

We have a bin2c tool that would make including the boot logo much nicer. You'll want to use something like the attached patch, and add the bmp file as app/rosload/logo.bmp. Then just include "logo.h" instead of the g_Logo array in rosload.c. On 2017-05-15 03:38, ion(a)svn.reactos.org wrote: > Author: ion > Date: Mon May 15 01:38:49 2017 > New Revision: 74546 > > URL: http://svn.reactos.org/svn/reactos?rev=74546&view=rev > Log: > BL Library now works 100% in paging, protected mode. A picture is worth a thousand commits: http://i.imgur.com/Zx2nQ6x.jpg > [BOOTLIB]: Add support for protocol open/close/lookup while paging and protected mode is enabled. > [BOOTLIB]: Implement support for dozens of UEFI functions while under protected mode. > [BOOTLIB]: Fix bugs in existing UEFI functions which were switching to _protected_ mode instead of _real mode_ before making the UEFI call. > [BOOTLIB]: Free dynamic descriptor in MmMdFreeDescriptor. > [BOOTLIB]: Implement BlHtDelete. > [BOOTLIB]: Implement re-initialize-all path in DsppInitialize. > [BOOTLIB]: Fix small bug in BlDisplayInvalidateOemBitmap > [BOOTLIB]: Fix bigger bug in BlDisplayGetOemBitmap :) > > Modified: > trunk/reactos/boot/environ/app/rosload/rosload.c > trunk/reactos/boot/environ/include/bl.h > trunk/reactos/boot/environ/lib/firmware/efi/firmware.c > trunk/reactos/boot/environ/lib/io/device.c > trunk/reactos/boot/environ/lib/io/display/display.c > trunk/reactos/boot/environ/lib/io/display/efi/gop.c > trunk/reactos/boot/environ/lib/misc/util.c > trunk/reactos/boot/environ/lib/mm/descriptor.c > trunk/reactos/boot/environ/lib/platform/time.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/boot/environ/app/rosload/rosload.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/app/rosload/r… > > Modified: trunk/reactos/boot/environ/include/bl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/include/bl.h?… > > Modified: trunk/reactos/boot/environ/lib/firmware/efi/firmware.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/firmware/… > > Modified: trunk/reactos/boot/environ/lib/io/device.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/device… > > Modified: trunk/reactos/boot/environ/lib/io/display/display.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/displa… > > Modified: trunk/reactos/boot/environ/lib/io/display/efi/gop.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/io/displa… > > Modified: trunk/reactos/boot/environ/lib/misc/util.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/misc/util… > > Modified: trunk/reactos/boot/environ/lib/mm/descriptor.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/mm/descri… > > Modified: trunk/reactos/boot/environ/lib/platform/time.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/environ/lib/platform/… > >

4 3

Re: [ros-dev] [ros-diffs] [hbelusca] 74528: Code simplifications.
by Thomas Faber 14 May '17

14 May '17

On 2017-05-13 18:13, hbelusca(a)svn.reactos.org wrote: > --- branches/setup_improvements/base/setup/usetup/filesup.c [iso-8859-1] (original) > +++ branches/setup_improvements/base/setup/usetup/filesup.c [iso-8859-1] Sat May 13 16:13:49 2017 > @@ -524,14 +523,10 @@ > &IoStatusBlock, > 0, > FILE_SYNCHRONOUS_IO_NONALERT); > - if (!NT_SUCCESS(Status)) > - { > - return FALSE; > - } > > NtClose(FileHandle); > > - return TRUE; > + return NT_SUCCESS(Status); > } Not an improvement. You're now closing an uninitialized handle on failure.

3 2

Re: [ros-dev] [ros-diffs] [hbelusca] 69160: [EFISYS]: Add 'bcd_hive' as a dependency. [FATTEN]: Fix help message. Functions with no parameters are void. Remove an hardcoded array size.
by Thomas Faber 14 May '17

14 May '17

Hey Hermès, I'm fixing how the BCD hive is generated and this just showed up in an svn blame for me. Can you explain why this bcd_hive dependency is needed? I don't see the command depending on the hive file. Thanks, Thomas On 2015-09-09 21:48, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Wed Sep 9 19:48:15 2015 > New Revision: 69160 > > URL: http://svn.reactos.org/svn/reactos?rev=69160&view=rev > Log: > [EFISYS]: Add 'bcd_hive' as a dependency. > [FATTEN]: Fix help message. Functions with no parameters are void. Remove an hardcoded array size. > > Modified: > trunk/reactos/boot/CMakeLists.txt > trunk/reactos/tools/fatten/fatten.c > > Modified: trunk/reactos/boot/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/CMakeLists.txt?rev=69… > ============================================================================== > --- trunk/reactos/boot/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/boot/CMakeLists.txt [iso-8859-1] Wed Sep 9 19:48:15 2015 > @@ -17,7 +17,7 @@ > > add_custom_target(efisys > COMMAND native-fatten ${CMAKE_CURRENT_BINARY_DIR}/efisys.bin -format 2880 EFIBOOT -boot ${CMAKE_CURRENT_BINARY_DIR}/freeldr/bootsect/fat.bin -mkdir EFI -mkdir EFI/BOOT -add $<TARGET_FILE:bootmgfw> EFI/BOOT/boot${EFI_PLATFORM_ID}.efi -add ${CMAKE_BINARY_DIR}/boot/bootdata/BCD EFI/BOOT/BCD > - DEPENDS native-fatten bootmgfw fat > + DEPENDS native-fatten fat bootmgfw bcd_hive > VERBATIM) > > ##bootcd >

2 1

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 10 May '17

10 May '17

Sounds like a bug in their migration/etc tool. MS has history going back to 1984 and migrated everything to Git with zero problems. At some point you should apply Ionescu's Razor: "Hmmm, a company of 150,000 developers and the most complicated and oldest series of repositories in the world, was able to move to Git, including while employing people who have been there for 30 years and used to other, older systems.... but 30 open source developers can't make that change because X". It follows from this that X is bullshit. On the polluting history, again, just read commits that have [FOOBAR] in them, and ignore others. Write a post-commit hook to rewrite/squash them. Best regards, Alex Ionescu On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden <drakekaizer666(a)gmail.com> wrote: > The project that I worked with using git has history going back to 1988. > They certainly didn't start with git, nor did they necessarily start with > any revision control at the beginning, but after they migrated to it they > discovered the history problem. > > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck <colin(a)reactos.org> wrote: >> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu: >> > That being said, that type of "dirty history" only happens if you >> > heavily work with branches. That's not how reactos developers work -- we >> > don't open PRs and separate branches for every checkin. >> > >> > These ALL sound like manufactured problems or poor/strange use of git. >> >> That merge hell is easily reproducible using my default Git setup: >> >> 1) Change something in your clone of master and do a "git commit". >> 2) Let someone else change something in his clone of master and let him >> "git commit" and "git push" it. >> 3) Try to "git push" your commit, won't work because of the commit of >> the other person. >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an >> automatic merge of both masters and pollute your history. >> >> You see, not a single extra branch is involved and yet we get two >> parallel streams of history. >> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we >> enforce that somehow? >> >> >> - Colin >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

3 2

Re: [ros-dev] [ros-diffs] [hbelusca] 74493: [NTOS]: Capture the counted BaseDllName unicode string into a local NULL-terminated buffer before calling wcsrchr on it (actually I think it would be better to create & use a simi...
by Thomas Faber 08 May '17

08 May '17

On 2017-05-07 20:15, hbelusca(a)svn.reactos.org wrote: > --- trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] Sun May 7 18:15:12 2017 > @@ -884,7 +884,7 @@ > PDEVICE_NODE DeviceNode; > PDRIVER_OBJECT DriverObject; > NTSTATUS Status; > - PWCHAR FileNameWithoutPath; > + PWCHAR Buffer, FileNameWithoutPath; > PWSTR FileExtension; > PUNICODE_STRING ModuleName = &BootLdrEntry->BaseDllName; > PLDR_DATA_TABLE_ENTRY LdrEntry; > @@ -898,13 +898,19 @@ > IopDisplayLoadingMessage(ModuleName); > InbvIndicateProgress(); > > + Buffer = ExAllocatePool(PagedPool, ModuleName->Length + sizeof(UNICODE_NULL)); > + ASSERT(Buffer); Please don't call ExAllocatePool. And please check for allocation failure. An assert is not acceptable.

2 2

Community Changelogs - Spread them!
by Can Tasan 04 May '17

04 May '17

Hello, folks! As most of you already know, ReactOS Community Changelogs are a community based effort to describe development progress better, directly to end-user. This increases both developers' and users' morale. Adress: https://reactos.org/wiki/Community_Changelogs All infastructure work on Wiki are complete, this means that the Changelogs can be announced now. Would you consider doing this when announcing ReactOS 0.4.5? Finally, I want to send my big thanks to anyone who helped! Comments and suggestions are always welcome! With my best regards! Can Taşan

1 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 74457: [UXTHEME] -Use GdiDrawStream in UXTHEME_DrawImageGlyph and UXTHEME_DrawImageBackground.
by Giannis Adamopoulos 04 May '17

04 May '17

Hi, are you sure that 1 means original and 9 means nine grid? I kept fields that I don't know what are for as ... unknown. Peter Hater <7element(a)mail.bg> wrote on Wed, May 3rd, 2017, 8:23 PM: > Hi, > > Why not use constant for 0x44727753 and rename unknown1 and unknown2 to srcImageType and dstImageType (or something similar) and use defines for these types also 1 = OriginalImage, 9 = NineGridImage (or similar). > This will make code a little bit less magical :) IMHO > > BR, > Peter > > > On May 3, 2017, at 14:13, gadamopoulos(a)svn.reactos.org wrote: > > > > Author: gadamopoulos > > Date: Wed May 3 11:13:23 2017 > > New Revision: 74457 > > > > URL: http://svn.reactos.org/svn/reactos?rev=74457&view=rev > > Log: > > [UXTHEME] -Use GdiDrawStream in UXTHEME_DrawImageGlyph and UXTHEME_DrawImageBackground. > > > > Modified: > > trunk/reactos/dll/win32/uxtheme/draw.c > > trunk/reactos/dll/win32/uxtheme/uxthemep.h > > > > Modified: trunk/reactos/dll/win32/uxtheme/draw.c > > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/uxtheme/draw.c?r… > > ============================================================================== > > --- trunk/reactos/dll/win32/uxtheme/draw.c [iso-8859-1] (original) > > +++ trunk/reactos/dll/win32/uxtheme/draw.c [iso-8859-1] Wed May 3 11:13:23 2017 > > @@ -269,163 +269,6 @@ > > return S_OK; > > } > > > > -/*********************************************************************** > > - * UXTHEME_StretchBlt > > - * > > - * Pseudo TransparentBlt/StretchBlt > > - */ > > -static inline BOOL UXTHEME_StretchBlt(HDC hdcDst, int nXOriginDst, int nYOriginDst, int nWidthDst, int nHeightDst, > > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, int nWidthSrc, int nHeightSrc, > > - INT transparent, COLORREF transcolor) > > -{ > > - static const BLENDFUNCTION blendFunc = > > - { > > - AC_SRC_OVER, /* BlendOp */ > > - 0, /* BlendFlag */ > > - 255, /* SourceConstantAlpha */ > > - AC_SRC_ALPHA /* AlphaFormat */ > > - }; > > - > > - BOOL ret = TRUE; > > - int old_stretch_mode; > > - POINT old_brush_org; > > - > > - old_stretch_mode = SetStretchBltMode(hdcDst, HALFTONE); > > - SetBrushOrgEx(hdcDst, nXOriginDst, nYOriginDst, &old_brush_org); > > - > > - if (transparent == ALPHABLEND_BINARY) { > > - /* Ensure we don't pass any negative values to TransparentBlt */ > > - ret = TransparentBlt(hdcDst, nXOriginDst, nYOriginDst, abs(nWidthDst), abs(nHeightDst), > > - hdcSrc, nXOriginSrc, nYOriginSrc, abs(nWidthSrc), abs(nHeightSrc), > > - transcolor); > > - } else if ((transparent == ALPHABLEND_NONE) || > > - !AlphaBlend(hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > > - blendFunc)) > > - { > > - ret = StretchBlt(hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > > - SRCCOPY); > > - } > > - > > - SetBrushOrgEx(hdcDst, old_brush_org.x, old_brush_org.y, NULL); > > - SetStretchBltMode(hdcDst, old_stretch_mode); > > - > > - return ret; > > -} > > - > > -/*********************************************************************** > > - * UXTHEME_Blt > > - * > > - * Simplify sending same width/height for both source and dest > > - */ > > -static inline BOOL UXTHEME_Blt(HDC hdcDest, int nXOriginDest, int nYOriginDest, int nWidthDest, int nHeightDest, > > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, > > - INT transparent, COLORREF transcolor) > > -{ > > - return UXTHEME_StretchBlt(hdcDest, nXOriginDest, nYOriginDest, nWidthDest, nHeightDest, > > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthDest, nHeightDest, > > - transparent, transcolor); > > -} > > - > > -/*********************************************************************** > > - * UXTHEME_SizedBlt > > - * > > - * Stretches or tiles, depending on sizingtype. > > - */ > > -static inline BOOL UXTHEME_SizedBlt (HDC hdcDst, int nXOriginDst, int nYOriginDst, > > - int nWidthDst, int nHeightDst, > > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, > > - int nWidthSrc, int nHeightSrc, > > - int sizingtype, > > - INT transparent, COLORREF transcolor) > > -{ > > - if (sizingtype == ST_TILE) > > - { > > - HDC hdcTemp; > > - BOOL result = FALSE; > > - > > - if (!nWidthSrc || !nHeightSrc) return TRUE; > > - > > - /* For destination width/height less than or equal to source > > - width/height, do not bother with memory bitmap optimization */ > > - if (nWidthSrc >= nWidthDst && nHeightSrc >= nHeightDst) > > - { > > - int bltWidth = min (nWidthDst, nWidthSrc); > > - int bltHeight = min (nHeightDst, nHeightSrc); > > - > > - return UXTHEME_Blt (hdcDst, nXOriginDst, nYOriginDst, bltWidth, bltHeight, > > - hdcSrc, nXOriginSrc, nYOriginSrc, > > - transparent, transcolor); > > - } > > - > > - /* Create a DC with a bitmap consisting of a tiling of the source > > - bitmap, with standard GDI functions. This is faster than an > > - iteration with UXTHEME_Blt(). */ > > - hdcTemp = CreateCompatibleDC(hdcSrc); > > - if (hdcTemp != 0) > > - { > > - HBITMAP bitmapTemp; > > - HBITMAP bitmapOrig; > > - int nWidthTemp, nHeightTemp; > > - int xOfs, xRemaining; > > - int yOfs, yRemaining; > > - int growSize; > > - > > - /* Calculate temp dimensions of integer multiples of source dimensions */ > > - nWidthTemp = ((nWidthDst + nWidthSrc - 1) / nWidthSrc) * nWidthSrc; > > - nHeightTemp = ((nHeightDst + nHeightSrc - 1) / nHeightSrc) * nHeightSrc; > > - bitmapTemp = CreateCompatibleBitmap(hdcSrc, nWidthTemp, nHeightTemp); > > - bitmapOrig = SelectObject(hdcTemp, bitmapTemp); > > - > > - /* Initial copy of bitmap */ > > - BitBlt(hdcTemp, 0, 0, nWidthSrc, nHeightSrc, hdcSrc, nXOriginSrc, nYOriginSrc, SRCCOPY); > > - > > - /* Extend bitmap in the X direction. Growth of width is exponential */ > > - xOfs = nWidthSrc; > > - xRemaining = nWidthTemp - nWidthSrc; > > - growSize = nWidthSrc; > > - while (xRemaining > 0) > > - { > > - growSize = min(growSize, xRemaining); > > - BitBlt(hdcTemp, xOfs, 0, growSize, nHeightSrc, hdcTemp, 0, 0, SRCCOPY); > > - xOfs += growSize; > > - xRemaining -= growSize; > > - growSize *= 2; > > - } > > - > > - /* Extend bitmap in the Y direction. Growth of height is exponential */ > > - yOfs = nHeightSrc; > > - yRemaining = nHeightTemp - nHeightSrc; > > - growSize = nHeightSrc; > > - while (yRemaining > 0) > > - { > > - growSize = min(growSize, yRemaining); > > - BitBlt(hdcTemp, 0, yOfs, nWidthTemp, growSize, hdcTemp, 0, 0, SRCCOPY); > > - yOfs += growSize; > > - yRemaining -= growSize; > > - growSize *= 2; > > - } > > - > > - /* Use temporary hdc for source */ > > - result = UXTHEME_Blt (hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > > - hdcTemp, 0, 0, > > - transparent, transcolor); > > - > > - SelectObject(hdcTemp, bitmapOrig); > > - DeleteObject(bitmapTemp); > > - } > > - DeleteDC(hdcTemp); > > - return result; > > - } > > - else > > - { > > - return UXTHEME_StretchBlt (hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > > - transparent, transcolor); > > - } > > -} > > - > > /* Get transparency parameters passed to UXTHEME_StretchBlt() - the parameters > > * depend on whether the image has full alpha or whether it is > > * color-transparent or just opaque. */ > > @@ -468,8 +311,6 @@ > > { > > HRESULT hr; > > HBITMAP bmpSrc = NULL; > > - HDC hdcSrc = NULL; > > - HGDIOBJ oldSrc = NULL; > > RECT rcSrc; > > INT transparent = 0; > > COLORREF transparentcolor; > > @@ -477,18 +318,13 @@ > > int halign = HA_CENTER; > > POINT dstSize; > > POINT srcSize; > > - POINT topleft; > > BOOL hasAlpha; > > + RECT rcDst; > > + GDI_DRAW_STREAM DrawStream; > > > > hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, TRUE, > > &bmpSrc, &rcSrc, &hasAlpha); > > if(FAILED(hr)) return hr; > > - hdcSrc = CreateCompatibleDC(hdc); > > - if(!hdcSrc) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - return hr; > > - } > > - oldSrc = SelectObject(hdcSrc, bmpSrc); > > > > dstSize.x = pRect->right-pRect->left; > > dstSize.y = pRect->bottom-pRect->top; > > @@ -500,22 +336,37 @@ > > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_VALIGN, &valign); > > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_HALIGN, &halign); > > > > - topleft.x = pRect->left; > > - topleft.y = pRect->top; > > - if(halign == HA_CENTER) topleft.x += (dstSize.x/2)-(srcSize.x/2); > > - else if(halign == HA_RIGHT) topleft.x += dstSize.x-srcSize.x; > > - if(valign == VA_CENTER) topleft.y += (dstSize.y/2)-(srcSize.y/2); > > - else if(valign == VA_BOTTOM) topleft.y += dstSize.y-srcSize.y; > > - > > - if(!UXTHEME_Blt(hdc, topleft.x, topleft.y, srcSize.x, srcSize.y, > > - hdcSrc, rcSrc.left, rcSrc.top, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - } > > - > > - SelectObject(hdcSrc, oldSrc); > > - DeleteDC(hdcSrc); > > - return hr; > > + rcDst = *pRect; > > + if(halign == HA_CENTER) rcDst.left += (dstSize.x/2)-(srcSize.x/2); > > + else if(halign == HA_RIGHT) rcDst.left += dstSize.x-srcSize.x; > > + if(valign == VA_CENTER) rcDst.top += (dstSize.y/2)-(srcSize.y/2); > > + else if(valign == VA_BOTTOM) rcDst.top += dstSize.y-srcSize.y; > > + > > + rcDst.right = rcDst.left + srcSize.x; > > + rcDst.bottom = rcDst.top + srcSize.y; > > + > > + DrawStream.signature = 0x44727753; > > + DrawStream.reserved = 0; > > + DrawStream.unknown1 = 1; > > + DrawStream.unknown2 = 9; > > + DrawStream.hDC = hdc; > > + DrawStream.hImage = bmpSrc; > > + DrawStream.crTransparent = transparentcolor; > > + DrawStream.rcSrc = rcSrc; > > + DrawStream.rcDest = rcDst; > > + DrawStream.leftSizingMargin = 0; > > + DrawStream.rightSizingMargin = 0; > > + DrawStream.topSizingMargin = 0; > > + DrawStream.bottomSizingMargin = 0; > > + DrawStream.drawOption = DS_TRUESIZE; > > + > > + if (transparent == ALPHABLEND_FULL) > > + DrawStream.drawOption |= DS_TRANSPARENTALPHA; > > + else if (transparent == ALPHABLEND_BINARY) > > + DrawStream.drawOption |= DS_TRANSPARENTCLR; > > + > > + GdiDrawStream(hdc, sizeof(DrawStream), &DrawStream); > > + return HRESULT_FROM_WIN32(GetLastError()); > > } > > > > /*********************************************************************** > > @@ -655,40 +506,33 @@ > > const DTBGOPTS *pOptions) > > { > > HRESULT hr = S_OK; > > - HBITMAP bmpSrc, bmpSrcResized = NULL; > > - HGDIOBJ oldSrc; > > - HDC hdcSrc, hdcOrigSrc = NULL; > > + HBITMAP bmpSrc; > > RECT rcSrc; > > RECT rcDst; > > POINT dstSize; > > - POINT srcSize; > > POINT drawSize; > > int sizingtype = ST_STRETCH; > > INT transparent; > > COLORREF transparentcolor = 0; > > BOOL hasAlpha; > > - > > - hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, FALSE, > > - &bmpSrc, &rcSrc, &hasAlpha); > > - if(FAILED(hr)) return hr; > > - hdcSrc = CreateCompatibleDC(hdc); > > - if(!hdcSrc) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > + MARGINS sm; > > + GDI_DRAW_STREAM DrawStream; > > + > > + hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, FALSE, &bmpSrc, &rcSrc, &hasAlpha); > > + if(FAILED(hr)) > > return hr; > > - } > > - oldSrc = SelectObject(hdcSrc, bmpSrc); > > + get_transparency (hTheme, iPartId, iStateId, hasAlpha, &transparent, &transparentcolor, FALSE); > > > > rcDst = *pRect; > > - > > - get_transparency (hTheme, iPartId, iStateId, hasAlpha, &transparent, > > - &transparentcolor, FALSE); > > - > > dstSize.x = rcDst.right-rcDst.left; > > dstSize.y = rcDst.bottom-rcDst.top; > > - srcSize.x = rcSrc.right-rcSrc.left; > > - srcSize.y = rcSrc.bottom-rcSrc.top; > > - > > + > > + GetThemeMargins(hTheme, hdc, iPartId, iStateId, TMT_SIZINGMARGINS, NULL, &sm); > > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_SIZINGTYPE, &sizingtype); > > + > > + /*FIXME: Is this ever used? */ > > + /*GetThemeBool(hTheme, iPartId, iStateId, TMT_BORDERONLY, &borderonly);*/ > > + > > if(sizingtype == ST_TRUESIZE) { > > int valign = VA_CENTER, halign = HA_CENTER; > > > > @@ -706,161 +550,36 @@ > > rcDst.top = rcDst.bottom - drawSize.y; > > rcDst.right = rcDst.left + drawSize.x; > > rcDst.bottom = rcDst.top + drawSize.y; > > - if(!UXTHEME_StretchBlt(hdc, rcDst.left, rcDst.top, drawSize.x, drawSize.y, > > - hdcSrc, rcSrc.left, rcSrc.top, srcSize.x, srcSize.y, > > - transparent, transparentcolor)) > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - } > > - else { > > - HDC hdcDst = NULL; > > - MARGINS sm; > > - POINT org; > > - > > - dstSize.x = abs(dstSize.x); > > - dstSize.y = abs(dstSize.y); > > - > > - GetThemeMargins(hTheme, hdc, iPartId, iStateId, TMT_SIZINGMARGINS, NULL, &sm); > > - > > - /* Resize source image if destination smaller than margins */ > > -#ifndef __REACTOS__ > > - /* Revert Wine Commit 2b650fa as it breaks themed Explorer Toolbar Separators > > - FIXME: Revisit this when the bug is fixed. CORE-9636 and Wine Bug #38538 */ > > - if (sm.cyTopHeight + sm.cyBottomHeight > dstSize.y || sm.cxLeftWidth + sm.cxRightWidth > dstSize.x) { > > - if (sm.cyTopHeight + sm.cyBottomHeight > dstSize.y) { > > - sm.cyTopHeight = MulDiv(sm.cyTopHeight, dstSize.y, srcSize.y); > > - sm.cyBottomHeight = dstSize.y - sm.cyTopHeight; > > - srcSize.y = dstSize.y; > > - } > > - > > - if (sm.cxLeftWidth + sm.cxRightWidth > dstSize.x) { > > - sm.cxLeftWidth = MulDiv(sm.cxLeftWidth, dstSize.x, srcSize.x); > > - sm.cxRightWidth = dstSize.x - sm.cxLeftWidth; > > - srcSize.x = dstSize.x; > > - } > > - > > - hdcOrigSrc = hdcSrc; > > - hdcSrc = CreateCompatibleDC(NULL); > > - bmpSrcResized = CreateBitmap(srcSize.x, srcSize.y, 1, 32, NULL); > > - SelectObject(hdcSrc, bmpSrcResized); > > - > > - UXTHEME_StretchBlt(hdcSrc, 0, 0, srcSize.x, srcSize.y, hdcOrigSrc, rcSrc.left, rcSrc.top, > > - rcSrc.right - rcSrc.left, rcSrc.bottom - rcSrc.top, transparent, transparentcolor); > > - > > - rcSrc.left = 0; > > - rcSrc.top = 0; > > - rcSrc.right = srcSize.x; > > - rcSrc.bottom = srcSize.y; > > - } > > -#endif /* __REACTOS__ */ > > - > > - hdcDst = hdc; > > - OffsetViewportOrgEx(hdcDst, rcDst.left, rcDst.top, &org); > > - > > - /* Upper left corner */ > > - if(!UXTHEME_Blt(hdcDst, 0, 0, sm.cxLeftWidth, sm.cyTopHeight, > > - hdcSrc, rcSrc.left, rcSrc.top, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - /* Upper right corner */ > > - if(!UXTHEME_Blt (hdcDst, dstSize.x-sm.cxRightWidth, 0, > > - sm.cxRightWidth, sm.cyTopHeight, > > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.top, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - /* Lower left corner */ > > - if(!UXTHEME_Blt (hdcDst, 0, dstSize.y-sm.cyBottomHeight, > > - sm.cxLeftWidth, sm.cyBottomHeight, > > - hdcSrc, rcSrc.left, rcSrc.bottom-sm.cyBottomHeight, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - /* Lower right corner */ > > - if(!UXTHEME_Blt (hdcDst, dstSize.x-sm.cxRightWidth, dstSize.y-sm.cyBottomHeight, > > - sm.cxRightWidth, sm.cyBottomHeight, > > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.bottom-sm.cyBottomHeight, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - > > - if ((sizingtype == ST_STRETCH) || (sizingtype == ST_TILE)) { > > - int destCenterWidth = dstSize.x - (sm.cxLeftWidth + sm.cxRightWidth); > > - int srcCenterWidth = srcSize.x - (sm.cxLeftWidth + sm.cxRightWidth); > > - int destCenterHeight = dstSize.y - (sm.cyTopHeight + sm.cyBottomHeight); > > - int srcCenterHeight = srcSize.y - (sm.cyTopHeight + sm.cyBottomHeight); > > - > > - if(destCenterWidth > 0) { > > - /* Center top */ > > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, 0, > > - destCenterWidth, sm.cyTopHeight, > > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.top, > > - srcCenterWidth, sm.cyTopHeight, > > - sizingtype, transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - /* Center bottom */ > > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, dstSize.y-sm.cyBottomHeight, > > - destCenterWidth, sm.cyBottomHeight, > > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.bottom-sm.cyBottomHeight, > > - srcCenterWidth, sm.cyBottomHeight, > > - sizingtype, transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - } > > - if(destCenterHeight > 0) { > > - /* Left center */ > > - if(!UXTHEME_SizedBlt (hdcDst, 0, sm.cyTopHeight, > > - sm.cxLeftWidth, destCenterHeight, > > - hdcSrc, rcSrc.left, rcSrc.top+sm.cyTopHeight, > > - sm.cxLeftWidth, srcCenterHeight, > > - sizingtype, > > - transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - /* Right center */ > > - if(!UXTHEME_SizedBlt (hdcDst, dstSize.x-sm.cxRightWidth, sm.cyTopHeight, > > - sm.cxRightWidth, destCenterHeight, > > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.top+sm.cyTopHeight, > > - sm.cxRightWidth, srcCenterHeight, > > - sizingtype, transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - } > > - if(destCenterHeight > 0 && destCenterWidth > 0) { > > - BOOL borderonly = FALSE; > > - GetThemeBool(hTheme, iPartId, iStateId, TMT_BORDERONLY, &borderonly); > > - if(!borderonly) { > > - /* Center */ > > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, sm.cyTopHeight, > > - destCenterWidth, destCenterHeight, > > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.top+sm.cyTopHeight, > > - srcCenterWidth, srcCenterHeight, > > - sizingtype, transparent, transparentcolor)) { > > - hr = HRESULT_FROM_WIN32(GetLastError()); > > - goto draw_error; > > - } > > - } > > - } > > - } > > - > > -draw_error: > > - SetViewportOrgEx (hdcDst, org.x, org.y, NULL); > > - } > > - SelectObject(hdcSrc, oldSrc); > > - DeleteDC(hdcSrc); > > - if (bmpSrcResized) DeleteObject(bmpSrcResized); > > - if (hdcOrigSrc) DeleteDC(hdcOrigSrc); > > - *pRect = rcDst; > > - return hr; > > + *pRect = rcDst; > > + } > > + > > + DrawStream.signature = 0x44727753; > > + DrawStream.reserved = 0; > > + DrawStream.unknown1 = 1; > > + DrawStream.unknown2 = 9; > > + DrawStream.hDC = hdc; > > + DrawStream.hImage = bmpSrc; > > + DrawStream.crTransparent = transparentcolor; > > + DrawStream.rcSrc = rcSrc; > > + DrawStream.rcDest = rcDst; > > + DrawStream.leftSizingMargin = sm.cxLeftWidth; > > + DrawStream.rightSizingMargin = sm.cxRightWidth; > > + DrawStream.topSizingMargin = sm.cyTopHeight; > > + DrawStream.bottomSizingMargin = sm.cyBottomHeight; > > + DrawStream.drawOption = 0; > > + > > + if (transparent == ALPHABLEND_FULL) > > + DrawStream.drawOption |= DS_TRANSPARENTALPHA; > > + else if (transparent == ALPHABLEND_BINARY) > > + DrawStream.drawOption |= DS_TRANSPARENTCLR; > > + > > + if (sizingtype == ST_TILE) > > + DrawStream.drawOption |= DS_TILE; > > + else if (sizingtype == ST_TRUESIZE) > > + DrawStream.drawOption |= DS_TRUESIZE; > > + > > + GdiDrawStream(hdc, sizeof(DrawStream), &DrawStream); > > + return HRESULT_FROM_WIN32(GetLastError()); > > } > > > > /*********************************************************************** > > @@ -1050,7 +769,9 @@ > > /* This should never happen, and hence I don't know what to return */ > > hr = E_FAIL; > > } > > +#if 0 > > if(SUCCEEDED(hr)) > > +#endif > > { > > RECT rcGlyph = *pRect; > > MARGINS margin; > > > > Modified: trunk/reactos/dll/win32/uxtheme/uxthemep.h > > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/uxtheme/uxthemep… > > ============================================================================== > > --- trunk/reactos/dll/win32/uxtheme/uxthemep.h [iso-8859-1] (original) > > +++ trunk/reactos/dll/win32/uxtheme/uxthemep.h [iso-8859-1] Wed May 3 11:13:23 2017 > > @@ -14,6 +14,7 @@ > > #include <winnls.h> > > #include <windowsx.h> > > #include <undocuser.h> > > +#include <undocgdi.h> > > #include <uxtheme.h> > > #include <uxundoc.h> > > #include <vfwmsgs.h> > > > > > > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev

2 1

ReactOS is the MOST VOTED project in the "Best IT Community" category in the #OpenAwards
by victor martinez 04 May '17

04 May '17

Congrats Community! You did it!! Thanks to your votes casted, ReactOS is finalist in the "Best IT Community" category. Even more! ReactOS was the MOST VOTED project in such category! https://a.cstmapp.com/p/18092?fromgroup=1 ReactOS: 229 votes 2nd. KeepCoding: 190 votes As you may know, ReactOS was also trying to be finalist as the "Best Innovative project". We were literally just ONE vote away to be one of the five finalists. 202 casted, 203 needed. https://a.cstmapp.com/entries/18085/sort:votes/direction:desc So even if we weren't finalist it in this category I want to thank in name of the ReactOS project all your help, votes, and support to make it possible. Our strategy of waiting until last minute helped us to overtake and surprise really big and amazing projects as the Drupal Association, Geo developers or gvSig, but also projects supported/created by well stablished companies and public governments. Thanks Community! We'll keep you updated! More info soon as a blogpost! Víctor Martinez Calvo ReactOS PR & Product strategy coordinator

1 0

Re: [ros-dev] [ros-diffs] [gadamopoulos] 74457: [UXTHEME] -Use GdiDrawStream in UXTHEME_DrawImageGlyph and UXTHEME_DrawImageBackground.
by Peter Hater 04 May '17

04 May '17

Hi, Why not use constant for 0x44727753 and rename unknown1 and unknown2 to srcImageType and dstImageType (or something similar) and use defines for these types also 1 = OriginalImage, 9 = NineGridImage (or similar). This will make code a little bit less magical :) IMHO BR, Peter > On May 3, 2017, at 14:13, gadamopoulos(a)svn.reactos.org wrote: > > Author: gadamopoulos > Date: Wed May 3 11:13:23 2017 > New Revision: 74457 > > URL: http://svn.reactos.org/svn/reactos?rev=74457&view=rev > Log: > [UXTHEME] -Use GdiDrawStream in UXTHEME_DrawImageGlyph and UXTHEME_DrawImageBackground. > > Modified: > trunk/reactos/dll/win32/uxtheme/draw.c > trunk/reactos/dll/win32/uxtheme/uxthemep.h > > Modified: trunk/reactos/dll/win32/uxtheme/draw.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/uxtheme/draw.c?r… > ============================================================================== > --- trunk/reactos/dll/win32/uxtheme/draw.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/uxtheme/draw.c [iso-8859-1] Wed May 3 11:13:23 2017 > @@ -269,163 +269,6 @@ > return S_OK; > } > > -/*********************************************************************** > - * UXTHEME_StretchBlt > - * > - * Pseudo TransparentBlt/StretchBlt > - */ > -static inline BOOL UXTHEME_StretchBlt(HDC hdcDst, int nXOriginDst, int nYOriginDst, int nWidthDst, int nHeightDst, > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, int nWidthSrc, int nHeightSrc, > - INT transparent, COLORREF transcolor) > -{ > - static const BLENDFUNCTION blendFunc = > - { > - AC_SRC_OVER, /* BlendOp */ > - 0, /* BlendFlag */ > - 255, /* SourceConstantAlpha */ > - AC_SRC_ALPHA /* AlphaFormat */ > - }; > - > - BOOL ret = TRUE; > - int old_stretch_mode; > - POINT old_brush_org; > - > - old_stretch_mode = SetStretchBltMode(hdcDst, HALFTONE); > - SetBrushOrgEx(hdcDst, nXOriginDst, nYOriginDst, &old_brush_org); > - > - if (transparent == ALPHABLEND_BINARY) { > - /* Ensure we don't pass any negative values to TransparentBlt */ > - ret = TransparentBlt(hdcDst, nXOriginDst, nYOriginDst, abs(nWidthDst), abs(nHeightDst), > - hdcSrc, nXOriginSrc, nYOriginSrc, abs(nWidthSrc), abs(nHeightSrc), > - transcolor); > - } else if ((transparent == ALPHABLEND_NONE) || > - !AlphaBlend(hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > - blendFunc)) > - { > - ret = StretchBlt(hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > - SRCCOPY); > - } > - > - SetBrushOrgEx(hdcDst, old_brush_org.x, old_brush_org.y, NULL); > - SetStretchBltMode(hdcDst, old_stretch_mode); > - > - return ret; > -} > - > -/*********************************************************************** > - * UXTHEME_Blt > - * > - * Simplify sending same width/height for both source and dest > - */ > -static inline BOOL UXTHEME_Blt(HDC hdcDest, int nXOriginDest, int nYOriginDest, int nWidthDest, int nHeightDest, > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, > - INT transparent, COLORREF transcolor) > -{ > - return UXTHEME_StretchBlt(hdcDest, nXOriginDest, nYOriginDest, nWidthDest, nHeightDest, > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthDest, nHeightDest, > - transparent, transcolor); > -} > - > -/*********************************************************************** > - * UXTHEME_SizedBlt > - * > - * Stretches or tiles, depending on sizingtype. > - */ > -static inline BOOL UXTHEME_SizedBlt (HDC hdcDst, int nXOriginDst, int nYOriginDst, > - int nWidthDst, int nHeightDst, > - HDC hdcSrc, int nXOriginSrc, int nYOriginSrc, > - int nWidthSrc, int nHeightSrc, > - int sizingtype, > - INT transparent, COLORREF transcolor) > -{ > - if (sizingtype == ST_TILE) > - { > - HDC hdcTemp; > - BOOL result = FALSE; > - > - if (!nWidthSrc || !nHeightSrc) return TRUE; > - > - /* For destination width/height less than or equal to source > - width/height, do not bother with memory bitmap optimization */ > - if (nWidthSrc >= nWidthDst && nHeightSrc >= nHeightDst) > - { > - int bltWidth = min (nWidthDst, nWidthSrc); > - int bltHeight = min (nHeightDst, nHeightSrc); > - > - return UXTHEME_Blt (hdcDst, nXOriginDst, nYOriginDst, bltWidth, bltHeight, > - hdcSrc, nXOriginSrc, nYOriginSrc, > - transparent, transcolor); > - } > - > - /* Create a DC with a bitmap consisting of a tiling of the source > - bitmap, with standard GDI functions. This is faster than an > - iteration with UXTHEME_Blt(). */ > - hdcTemp = CreateCompatibleDC(hdcSrc); > - if (hdcTemp != 0) > - { > - HBITMAP bitmapTemp; > - HBITMAP bitmapOrig; > - int nWidthTemp, nHeightTemp; > - int xOfs, xRemaining; > - int yOfs, yRemaining; > - int growSize; > - > - /* Calculate temp dimensions of integer multiples of source dimensions */ > - nWidthTemp = ((nWidthDst + nWidthSrc - 1) / nWidthSrc) * nWidthSrc; > - nHeightTemp = ((nHeightDst + nHeightSrc - 1) / nHeightSrc) * nHeightSrc; > - bitmapTemp = CreateCompatibleBitmap(hdcSrc, nWidthTemp, nHeightTemp); > - bitmapOrig = SelectObject(hdcTemp, bitmapTemp); > - > - /* Initial copy of bitmap */ > - BitBlt(hdcTemp, 0, 0, nWidthSrc, nHeightSrc, hdcSrc, nXOriginSrc, nYOriginSrc, SRCCOPY); > - > - /* Extend bitmap in the X direction. Growth of width is exponential */ > - xOfs = nWidthSrc; > - xRemaining = nWidthTemp - nWidthSrc; > - growSize = nWidthSrc; > - while (xRemaining > 0) > - { > - growSize = min(growSize, xRemaining); > - BitBlt(hdcTemp, xOfs, 0, growSize, nHeightSrc, hdcTemp, 0, 0, SRCCOPY); > - xOfs += growSize; > - xRemaining -= growSize; > - growSize *= 2; > - } > - > - /* Extend bitmap in the Y direction. Growth of height is exponential */ > - yOfs = nHeightSrc; > - yRemaining = nHeightTemp - nHeightSrc; > - growSize = nHeightSrc; > - while (yRemaining > 0) > - { > - growSize = min(growSize, yRemaining); > - BitBlt(hdcTemp, 0, yOfs, nWidthTemp, growSize, hdcTemp, 0, 0, SRCCOPY); > - yOfs += growSize; > - yRemaining -= growSize; > - growSize *= 2; > - } > - > - /* Use temporary hdc for source */ > - result = UXTHEME_Blt (hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > - hdcTemp, 0, 0, > - transparent, transcolor); > - > - SelectObject(hdcTemp, bitmapOrig); > - DeleteObject(bitmapTemp); > - } > - DeleteDC(hdcTemp); > - return result; > - } > - else > - { > - return UXTHEME_StretchBlt (hdcDst, nXOriginDst, nYOriginDst, nWidthDst, nHeightDst, > - hdcSrc, nXOriginSrc, nYOriginSrc, nWidthSrc, nHeightSrc, > - transparent, transcolor); > - } > -} > - > /* Get transparency parameters passed to UXTHEME_StretchBlt() - the parameters > * depend on whether the image has full alpha or whether it is > * color-transparent or just opaque. */ > @@ -468,8 +311,6 @@ > { > HRESULT hr; > HBITMAP bmpSrc = NULL; > - HDC hdcSrc = NULL; > - HGDIOBJ oldSrc = NULL; > RECT rcSrc; > INT transparent = 0; > COLORREF transparentcolor; > @@ -477,18 +318,13 @@ > int halign = HA_CENTER; > POINT dstSize; > POINT srcSize; > - POINT topleft; > BOOL hasAlpha; > + RECT rcDst; > + GDI_DRAW_STREAM DrawStream; > > hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, TRUE, > &bmpSrc, &rcSrc, &hasAlpha); > if(FAILED(hr)) return hr; > - hdcSrc = CreateCompatibleDC(hdc); > - if(!hdcSrc) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - return hr; > - } > - oldSrc = SelectObject(hdcSrc, bmpSrc); > > dstSize.x = pRect->right-pRect->left; > dstSize.y = pRect->bottom-pRect->top; > @@ -500,22 +336,37 @@ > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_VALIGN, &valign); > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_HALIGN, &halign); > > - topleft.x = pRect->left; > - topleft.y = pRect->top; > - if(halign == HA_CENTER) topleft.x += (dstSize.x/2)-(srcSize.x/2); > - else if(halign == HA_RIGHT) topleft.x += dstSize.x-srcSize.x; > - if(valign == VA_CENTER) topleft.y += (dstSize.y/2)-(srcSize.y/2); > - else if(valign == VA_BOTTOM) topleft.y += dstSize.y-srcSize.y; > - > - if(!UXTHEME_Blt(hdc, topleft.x, topleft.y, srcSize.x, srcSize.y, > - hdcSrc, rcSrc.left, rcSrc.top, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - } > - > - SelectObject(hdcSrc, oldSrc); > - DeleteDC(hdcSrc); > - return hr; > + rcDst = *pRect; > + if(halign == HA_CENTER) rcDst.left += (dstSize.x/2)-(srcSize.x/2); > + else if(halign == HA_RIGHT) rcDst.left += dstSize.x-srcSize.x; > + if(valign == VA_CENTER) rcDst.top += (dstSize.y/2)-(srcSize.y/2); > + else if(valign == VA_BOTTOM) rcDst.top += dstSize.y-srcSize.y; > + > + rcDst.right = rcDst.left + srcSize.x; > + rcDst.bottom = rcDst.top + srcSize.y; > + > + DrawStream.signature = 0x44727753; > + DrawStream.reserved = 0; > + DrawStream.unknown1 = 1; > + DrawStream.unknown2 = 9; > + DrawStream.hDC = hdc; > + DrawStream.hImage = bmpSrc; > + DrawStream.crTransparent = transparentcolor; > + DrawStream.rcSrc = rcSrc; > + DrawStream.rcDest = rcDst; > + DrawStream.leftSizingMargin = 0; > + DrawStream.rightSizingMargin = 0; > + DrawStream.topSizingMargin = 0; > + DrawStream.bottomSizingMargin = 0; > + DrawStream.drawOption = DS_TRUESIZE; > + > + if (transparent == ALPHABLEND_FULL) > + DrawStream.drawOption |= DS_TRANSPARENTALPHA; > + else if (transparent == ALPHABLEND_BINARY) > + DrawStream.drawOption |= DS_TRANSPARENTCLR; > + > + GdiDrawStream(hdc, sizeof(DrawStream), &DrawStream); > + return HRESULT_FROM_WIN32(GetLastError()); > } > > /*********************************************************************** > @@ -655,40 +506,33 @@ > const DTBGOPTS *pOptions) > { > HRESULT hr = S_OK; > - HBITMAP bmpSrc, bmpSrcResized = NULL; > - HGDIOBJ oldSrc; > - HDC hdcSrc, hdcOrigSrc = NULL; > + HBITMAP bmpSrc; > RECT rcSrc; > RECT rcDst; > POINT dstSize; > - POINT srcSize; > POINT drawSize; > int sizingtype = ST_STRETCH; > INT transparent; > COLORREF transparentcolor = 0; > BOOL hasAlpha; > - > - hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, FALSE, > - &bmpSrc, &rcSrc, &hasAlpha); > - if(FAILED(hr)) return hr; > - hdcSrc = CreateCompatibleDC(hdc); > - if(!hdcSrc) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > + MARGINS sm; > + GDI_DRAW_STREAM DrawStream; > + > + hr = UXTHEME_LoadImage(hTheme, hdc, iPartId, iStateId, pRect, FALSE, &bmpSrc, &rcSrc, &hasAlpha); > + if(FAILED(hr)) > return hr; > - } > - oldSrc = SelectObject(hdcSrc, bmpSrc); > + get_transparency (hTheme, iPartId, iStateId, hasAlpha, &transparent, &transparentcolor, FALSE); > > rcDst = *pRect; > - > - get_transparency (hTheme, iPartId, iStateId, hasAlpha, &transparent, > - &transparentcolor, FALSE); > - > dstSize.x = rcDst.right-rcDst.left; > dstSize.y = rcDst.bottom-rcDst.top; > - srcSize.x = rcSrc.right-rcSrc.left; > - srcSize.y = rcSrc.bottom-rcSrc.top; > - > + > + GetThemeMargins(hTheme, hdc, iPartId, iStateId, TMT_SIZINGMARGINS, NULL, &sm); > GetThemeEnumValue(hTheme, iPartId, iStateId, TMT_SIZINGTYPE, &sizingtype); > + > + /*FIXME: Is this ever used? */ > + /*GetThemeBool(hTheme, iPartId, iStateId, TMT_BORDERONLY, &borderonly);*/ > + > if(sizingtype == ST_TRUESIZE) { > int valign = VA_CENTER, halign = HA_CENTER; > > @@ -706,161 +550,36 @@ > rcDst.top = rcDst.bottom - drawSize.y; > rcDst.right = rcDst.left + drawSize.x; > rcDst.bottom = rcDst.top + drawSize.y; > - if(!UXTHEME_StretchBlt(hdc, rcDst.left, rcDst.top, drawSize.x, drawSize.y, > - hdcSrc, rcSrc.left, rcSrc.top, srcSize.x, srcSize.y, > - transparent, transparentcolor)) > - hr = HRESULT_FROM_WIN32(GetLastError()); > - } > - else { > - HDC hdcDst = NULL; > - MARGINS sm; > - POINT org; > - > - dstSize.x = abs(dstSize.x); > - dstSize.y = abs(dstSize.y); > - > - GetThemeMargins(hTheme, hdc, iPartId, iStateId, TMT_SIZINGMARGINS, NULL, &sm); > - > - /* Resize source image if destination smaller than margins */ > -#ifndef __REACTOS__ > - /* Revert Wine Commit 2b650fa as it breaks themed Explorer Toolbar Separators > - FIXME: Revisit this when the bug is fixed. CORE-9636 and Wine Bug #38538 */ > - if (sm.cyTopHeight + sm.cyBottomHeight > dstSize.y || sm.cxLeftWidth + sm.cxRightWidth > dstSize.x) { > - if (sm.cyTopHeight + sm.cyBottomHeight > dstSize.y) { > - sm.cyTopHeight = MulDiv(sm.cyTopHeight, dstSize.y, srcSize.y); > - sm.cyBottomHeight = dstSize.y - sm.cyTopHeight; > - srcSize.y = dstSize.y; > - } > - > - if (sm.cxLeftWidth + sm.cxRightWidth > dstSize.x) { > - sm.cxLeftWidth = MulDiv(sm.cxLeftWidth, dstSize.x, srcSize.x); > - sm.cxRightWidth = dstSize.x - sm.cxLeftWidth; > - srcSize.x = dstSize.x; > - } > - > - hdcOrigSrc = hdcSrc; > - hdcSrc = CreateCompatibleDC(NULL); > - bmpSrcResized = CreateBitmap(srcSize.x, srcSize.y, 1, 32, NULL); > - SelectObject(hdcSrc, bmpSrcResized); > - > - UXTHEME_StretchBlt(hdcSrc, 0, 0, srcSize.x, srcSize.y, hdcOrigSrc, rcSrc.left, rcSrc.top, > - rcSrc.right - rcSrc.left, rcSrc.bottom - rcSrc.top, transparent, transparentcolor); > - > - rcSrc.left = 0; > - rcSrc.top = 0; > - rcSrc.right = srcSize.x; > - rcSrc.bottom = srcSize.y; > - } > -#endif /* __REACTOS__ */ > - > - hdcDst = hdc; > - OffsetViewportOrgEx(hdcDst, rcDst.left, rcDst.top, &org); > - > - /* Upper left corner */ > - if(!UXTHEME_Blt(hdcDst, 0, 0, sm.cxLeftWidth, sm.cyTopHeight, > - hdcSrc, rcSrc.left, rcSrc.top, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - /* Upper right corner */ > - if(!UXTHEME_Blt (hdcDst, dstSize.x-sm.cxRightWidth, 0, > - sm.cxRightWidth, sm.cyTopHeight, > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.top, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - /* Lower left corner */ > - if(!UXTHEME_Blt (hdcDst, 0, dstSize.y-sm.cyBottomHeight, > - sm.cxLeftWidth, sm.cyBottomHeight, > - hdcSrc, rcSrc.left, rcSrc.bottom-sm.cyBottomHeight, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - /* Lower right corner */ > - if(!UXTHEME_Blt (hdcDst, dstSize.x-sm.cxRightWidth, dstSize.y-sm.cyBottomHeight, > - sm.cxRightWidth, sm.cyBottomHeight, > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.bottom-sm.cyBottomHeight, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - > - if ((sizingtype == ST_STRETCH) || (sizingtype == ST_TILE)) { > - int destCenterWidth = dstSize.x - (sm.cxLeftWidth + sm.cxRightWidth); > - int srcCenterWidth = srcSize.x - (sm.cxLeftWidth + sm.cxRightWidth); > - int destCenterHeight = dstSize.y - (sm.cyTopHeight + sm.cyBottomHeight); > - int srcCenterHeight = srcSize.y - (sm.cyTopHeight + sm.cyBottomHeight); > - > - if(destCenterWidth > 0) { > - /* Center top */ > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, 0, > - destCenterWidth, sm.cyTopHeight, > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.top, > - srcCenterWidth, sm.cyTopHeight, > - sizingtype, transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - /* Center bottom */ > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, dstSize.y-sm.cyBottomHeight, > - destCenterWidth, sm.cyBottomHeight, > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.bottom-sm.cyBottomHeight, > - srcCenterWidth, sm.cyBottomHeight, > - sizingtype, transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - } > - if(destCenterHeight > 0) { > - /* Left center */ > - if(!UXTHEME_SizedBlt (hdcDst, 0, sm.cyTopHeight, > - sm.cxLeftWidth, destCenterHeight, > - hdcSrc, rcSrc.left, rcSrc.top+sm.cyTopHeight, > - sm.cxLeftWidth, srcCenterHeight, > - sizingtype, > - transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - /* Right center */ > - if(!UXTHEME_SizedBlt (hdcDst, dstSize.x-sm.cxRightWidth, sm.cyTopHeight, > - sm.cxRightWidth, destCenterHeight, > - hdcSrc, rcSrc.right-sm.cxRightWidth, rcSrc.top+sm.cyTopHeight, > - sm.cxRightWidth, srcCenterHeight, > - sizingtype, transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - } > - if(destCenterHeight > 0 && destCenterWidth > 0) { > - BOOL borderonly = FALSE; > - GetThemeBool(hTheme, iPartId, iStateId, TMT_BORDERONLY, &borderonly); > - if(!borderonly) { > - /* Center */ > - if(!UXTHEME_SizedBlt (hdcDst, sm.cxLeftWidth, sm.cyTopHeight, > - destCenterWidth, destCenterHeight, > - hdcSrc, rcSrc.left+sm.cxLeftWidth, rcSrc.top+sm.cyTopHeight, > - srcCenterWidth, srcCenterHeight, > - sizingtype, transparent, transparentcolor)) { > - hr = HRESULT_FROM_WIN32(GetLastError()); > - goto draw_error; > - } > - } > - } > - } > - > -draw_error: > - SetViewportOrgEx (hdcDst, org.x, org.y, NULL); > - } > - SelectObject(hdcSrc, oldSrc); > - DeleteDC(hdcSrc); > - if (bmpSrcResized) DeleteObject(bmpSrcResized); > - if (hdcOrigSrc) DeleteDC(hdcOrigSrc); > - *pRect = rcDst; > - return hr; > + *pRect = rcDst; > + } > + > + DrawStream.signature = 0x44727753; > + DrawStream.reserved = 0; > + DrawStream.unknown1 = 1; > + DrawStream.unknown2 = 9; > + DrawStream.hDC = hdc; > + DrawStream.hImage = bmpSrc; > + DrawStream.crTransparent = transparentcolor; > + DrawStream.rcSrc = rcSrc; > + DrawStream.rcDest = rcDst; > + DrawStream.leftSizingMargin = sm.cxLeftWidth; > + DrawStream.rightSizingMargin = sm.cxRightWidth; > + DrawStream.topSizingMargin = sm.cyTopHeight; > + DrawStream.bottomSizingMargin = sm.cyBottomHeight; > + DrawStream.drawOption = 0; > + > + if (transparent == ALPHABLEND_FULL) > + DrawStream.drawOption |= DS_TRANSPARENTALPHA; > + else if (transparent == ALPHABLEND_BINARY) > + DrawStream.drawOption |= DS_TRANSPARENTCLR; > + > + if (sizingtype == ST_TILE) > + DrawStream.drawOption |= DS_TILE; > + else if (sizingtype == ST_TRUESIZE) > + DrawStream.drawOption |= DS_TRUESIZE; > + > + GdiDrawStream(hdc, sizeof(DrawStream), &DrawStream); > + return HRESULT_FROM_WIN32(GetLastError()); > } > > /*********************************************************************** > @@ -1050,7 +769,9 @@ > /* This should never happen, and hence I don't know what to return */ > hr = E_FAIL; > } > +#if 0 > if(SUCCEEDED(hr)) > +#endif > { > RECT rcGlyph = *pRect; > MARGINS margin; > > Modified: trunk/reactos/dll/win32/uxtheme/uxthemep.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/uxtheme/uxthemep… > ============================================================================== > --- trunk/reactos/dll/win32/uxtheme/uxthemep.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/uxtheme/uxthemep.h [iso-8859-1] Wed May 3 11:13:23 2017 > @@ -14,6 +14,7 @@ > #include <winnls.h> > #include <windowsx.h> > #include <undocuser.h> > +#include <undocgdi.h> > #include <uxtheme.h> > #include <uxundoc.h> > #include <vfwmsgs.h> > > >

2 2

OpenAwards: Last 24 hours to cast votes for ReactOS!
by victor martinez 28 Apr '17

28 Apr '17

Hi guys! We made it! But we need your help to be in the top 5! Just 24 hours to do it! ReactOS has been selected as one of the most important projects in two different categories in the OpenAwards, an international opensource event based in Madrid. The 5 most voted will be widely announced, PRed, and finally one of them will be selected as a winner. The exposure is a need for us, you know that, so please help us by casting a vote. Takes just a second. Categories are: - Best Opensource Community: https://a.cstmapp.com/p/18092?fromgroup=1# <https://a.cstmapp.com/p/18092?fromgroup=1#> - Most innovative project: https://a.cstmapp.com/p/18085?fromgroup=1 Instructions: - Find ReactOS in each link. - Click in the button which says "Votar" (Vote) next to it. - It asks for a Name, Surname, an a valid email. Please confirm the vote!. - Done. I'm sure we can push ReactOS to the top! Let's surprise them with our voting boost!

2 1

New ideas added to GSoC Ideas list
by Colin Finck 25 Apr '17

25 Apr '17

Hi all! Daniel and me collected some additional ideas for GSoC today, which I've added to our Wiki Ideas list: https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas In particular: * Fundamental WiFi components * USBXHCI driver for supporting USB 3.x controllers * Bluetooth Stack * WebKit-based MSHTML implementation I'm open for comments and suggestions! We can still add ideas until March 20, so let's give students a large pool to draw from. Cheers, Colin

7 16

Status Meeting (April 2017)
by Aleksey Bragin 24 Apr '17

24 Apr '17

Hello, Let me invite you to the monthly status meeting taking place 27th of April, 19:00 UTC. We do it either in #reactos-meeting on Freenode, or on a very own standalone IRC server. In that case your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. And everyone is fine with that. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

1 0

retiring 'shellext/slayer'
by Mark Jansen 22 Apr '17

22 Apr '17

The shell extension 'slayer' will soon be removed. It has been surpassed by the shell extension 'acppage'. Since neither of the modules is yet active, this should not pose a problem. Related issues: CORE-10375 and CORE-13111 Regards, Mark.

1 0

Test KVM AHK Bot Upgrade
by Sylvain Petreolle 18 Apr '17

18 Apr '17

Hello all, I'm currently upgrading my AHK Testbot to Fedora 25, 24 only receives backports and Fedora 26 is already on the way. I never upgraded it before, so I don't know if it will take one or several hours to be back online. Kind regards, Sylvain Petreolle

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 74305: [NTOS:KE] - Gracefully handle page faults during V86 code execution. This is a bit of a hack because with our limited use of V86 code it is unclear how a page fault can even occur. ...
by Alex Ionescu 14 Apr '17

14 Apr '17

So why implement this code path if we have nothing that hits it? Best regards, Alex Ionescu On Fri, Apr 14, 2017 at 4:18 AM, <tfaber(a)svn.reactos.org> wrote: > Author: tfaber > Date: Fri Apr 14 11:18:22 2017 > New Revision: 74305 > > URL: http://svn.reactos.org/svn/reactos?rev=74305&view=rev > Log: > [NTOS:KE] > - Gracefully handle page faults during V86 code execution. This is a bit > of a hack because with our limited use of V86 code it is unclear how a page > fault can even occur. > CORE-12993 #resolve > > Modified: > trunk/reactos/ntoskrnl/include/internal/i386/ke.h > trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > trunk/reactos/ntoskrnl/vdm/vdmexec.c > > Modified: trunk/reactos/ntoskrnl/include/internal/i386/ke.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/include/internal/i386/ke.h?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] > (original) > +++ trunk/reactos/ntoskrnl/include/internal/i386/ke.h [iso-8859-1] Fri > Apr 14 11:18:22 2017 > @@ -478,6 +478,12 @@ > NTAPI > VdmDispatchBop( > IN PKTRAP_FRAME TrapFrame > +); > + > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame > ); > > BOOLEAN > > Modified: trunk/reactos/ntoskrnl/ke/i386/traphdlr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/ke/i386/traphdlr.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/traphdlr.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -1304,8 +1304,20 @@ > UNIMPLEMENTED_FATAL(); > } > #endif > + > /* Check for VDM trap */ > - ASSERT((KiVdmTrap(TrapFrame)) == FALSE); > + if (KiVdmTrap(TrapFrame)) > + { > + DPRINT1("VDM PAGE FAULT at %lx:%lx for address %lx\n", > + TrapFrame->SegCs, TrapFrame->Eip, Cr2); > + if (VdmDispatchPageFault(TrapFrame)) > + { > + /* Return and end VDM execution */ > + DPRINT1("VDM page fault with status 0x%lx resolved\n", > Status); > + KiEoiHelper(TrapFrame); > + } > + DPRINT1("VDM page fault with status 0x%lx NOT resolved\n", > Status); > + } > > /* Either kernel or user trap (non VDM) so dispatch exception */ > if (Status == STATUS_ACCESS_VIOLATION) > > Modified: trunk/reactos/ntoskrnl/vdm/vdmexec.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ > ntoskrnl/vdm/vdmexec.c?rev=74305&r1=74304&r2=74305&view=diff > ============================================================ > ================== > --- trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/vdm/vdmexec.c [iso-8859-1] Fri Apr 14 > 11:18:22 2017 > @@ -239,7 +239,7 @@ > KeLowerIrql(OldIrql); > return STATUS_INVALID_SYSTEM_SERVICE; > } > - > + > /* Now do the VDM Swap */ > VdmSwapContext(VdmFrame, &VdmTib->MonitorContext, &VdmContext); > > @@ -269,7 +269,7 @@ > > /* Make a copy of the monitor context */ > Context = VdmTib->MonitorContext; > - > + > /* Check if V86 mode was enabled or the trap was edited */ > if ((Context.EFlags & EFLAGS_V86_MASK) || (Context.SegCs & > FRAME_EDITED)) > { > @@ -291,7 +291,7 @@ > /* Remove real IF flag */ > VdmTib->VdmContext.EFlags &= ~EFLAGS_INTERRUPT_MASK; > } > - > + > /* Turn off VIP and VIF */ > TrapFrame->EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > VdmTib->VdmContext.EFlags &= ~(EFLAGS_VIP | EFLAGS_VIF); > @@ -362,4 +362,45 @@ > return TRUE; > } > > - > +BOOLEAN > +NTAPI > +VdmDispatchPageFault( > + _In_ PKTRAP_FRAME TrapFrame) > +{ > + NTSTATUS Status; > + PVDM_TIB VdmTib; > + > + PAGED_CODE(); > + > + /* Get the VDM TIB so we can terminate V86 execution */ > + Status = VdmpGetVdmTib(&VdmTib); > + if (!NT_SUCCESS(Status)) > + { > + /* Not a proper VDM fault, keep looking */ > + DPRINT1("VdmDispatchPageFault: no VDM TIB, Vdm=%p\n", > NtCurrentTeb()->Vdm); > + return FALSE; > + } > + > + /* Must be coming from V86 code */ > + ASSERT(TrapFrame->EFlags & EFLAGS_V86_MASK); > + > + _SEH2_TRY > + { > + /* Fill out a VDM Event */ > + VdmTib->EventInfo.Event = VdmMemAccess; > + VdmTib->EventInfo.InstructionSize = 0; > + > + /* End VDM Execution */ > + VdmEndExecution(TrapFrame, VdmTib); > + } > + _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER) > + { > + Status = _SEH2_GetExceptionCode(); > + } > + _SEH2_END; > + > + /* Consider the exception handled if we succeeded */ > + DPRINT1("VdmDispatchPageFault EFlags %lx exit with 0x%lx\n", > TrapFrame->EFlags, Status); > + return NT_SUCCESS(Status); > +} > + > > >

2 1

Re: [ros-dev] Definite Decision about ISO lifetimes at iso.reactos.org
by Colin Finck 09 Apr '17

09 Apr '17

Am 16.03.2017 um 00:00 schrieb Giannis Adamopoulos: > I was wondering if it is possible to delete every second iso instead of purging all isos before some time? That's a good idea and makes sense for the bootcd-dbg ISOs. So my final proposal is this one: bootcd-dbg: 5 years (after that every second ISO is purged) bootcd-dbgwin: 0.5 years bootcd-rel: 0.5 years bootcdregtest: 1 week livecd-dbg: 0.5 years livecd-dbgwin: 0.5 years livecd-rel: 0.5 years I'll be away until the beginning of April, so there is enough time for any objections. Otherwise, it will be set up exactly this way when I'm back. - Colin

1 1

Building/Testing infrastructure back on steroids!
by Colin Finck 09 Apr '17

09 Apr '17

Hi all! As of today, our high-performance servers Carrier, Mothership and Testee are finally back in service for building and testing! They take over many tasks from HotelLux, the generously provided server from Aleksey, which had to bear the load of previously 3 separate machines for over a year. You should notice faster builds on the Windows buildslaves, a returned VBox testslave, and more reliable ISO downloads. The VMware testslave is not back yet, but I'll be reinstalling this one as well. In June, we also plan to upgrade our best-performing server even more, using the donated 64GB of RAM and CPU upgrades that are cheaply available these days. This should decrease build times even more! Cheers, Colin

1 0

Vgal USB patches
by Alexander Rechitskiy 05 Apr '17

05 Apr '17

8 13

Re: [ros-dev] Retiring rapps
by Can Tasan 03 Apr '17

03 Apr '17

Hi! What does new RAPPS bring compared to old one, could you summarize main points? I need this for Community Changelogs. Thanks! Can

2 2

GSoC drivers mentor status
by Alexander 02 Apr '17

02 Apr '17

Cheers, I am student and i want help to develop ROS in GSoC. In part, i got intereted in drivers idea. I on 3rd year undergraduate by speciality applied mathematics and informatics and i have experience in C/C++. I would like to work in part intel high defenition audio bus driver. Can you point me to the mentor? Thank you. Best regards, Alexander

1 0

GSoC Terminal Services mentor status
by Dumitru Savva 01 Apr '17

01 Apr '17

Greetings, I am a student that wants to work on developing ReactOS during this summer. I got interested in Terminal Services idea. I have experience with C++ (and bit of C) and Transport/Application layers network programming. I would like to work on the part that is network related. Is anyone available to mentor me for this task? Thank you. Best regards, Dumitru

2 1

GSoC Mentor
by Muhammad abdul Rehman 01 Apr '17

01 Apr '17

Hello everyone, I am a Masters student and want to do the GSoC with this organization this summer. I have gone through the list and found some projects domain interesting but I couldn't research in the depth of the project due to resource and time constraint at the moment. I have some professional background in working with embedded software development (mostly C programming), networking stacks and an RTOS porting. Did some work in Linux development as well. I will be thankful if someone can guide me chose the best suitable project that is beneficial for myself and the organization at the same time. Currently, I have a look at following projects: Bluetooth Stack Integrating SMB into ReactOS Kernel mode test suite WebKit-based MSHTML implementation Support for the GPT Partitioning Scheme Taskbar Shell extensions If someone is interested in mentoring anyone of the above project, I will be happy to talk more on that and submit a timely proposal. Thanks a lot and best regards, -- M Abdul Rehman

2 1

GSOC, mentor status for USB xHCI,
by Rama Teja G 01 Apr '17

01 Apr '17

Dear all, I'm a student interested in working for ReactOS. I've previously worked with ReactOS(not GSOC). I've looked into xHci project, as I don't have prev experience in writing drivers I'm a bit baffled. >From what I've seen Johannes Anderwald , Michael Martin and Hervé Poussineau have contributed most to the development of USB code. Is anyone available to mentor me for this project? Thanks in advance, Rama Teja.G

2 1

Gsoc audio project mentor status
by Pranay Pratyush 30 Mar '17

30 Mar '17

Hi there, I am under the impression that no mentor can be assigned to my audio mixer proposal. Can someone confirm this or the opposite? If so I would like to create a proposal on "Improving the quality of our Registry Hive implementation", but since I don't have much time left and I haven't gone through the relevant code, I would really appreciate it if you point me to the mentor for this project. Thank You -- *Pranay Pratyush,* 3rd year undergraduate , Computer Science and Engineering Department Indian Institute Of Technology, Kharagpur --

2 3

Google summer of code.
by atemafac kingsley 29 Mar '17

29 Mar '17

Hello . I am call atemafac kingsley. i am an undergraduate computer engineering student. please i will like to take part on google summer of code . this is the time i am applying . so i will like to be directed on how i can contribute . thanks. University of Beua Cameroon.

3 2

Opening up #reactos-dev to the public
by Colin Finck 28 Mar '17

28 Mar '17

Hi all! As you all know, our #reactos-dev IRC channel has been a moderated IRC channel for decades, and only operators (devs) and voiced people can talk. While we always tried to keep discussions dev-related there, no topic has ever been enforced on #reactos. The result is that I see a notable number of developers only on #reactos-dev these days. This is a pretty bad situation! Emerging developers hardly have a way to interact with all existing devs on IRC. Often enough, legitimate questions from them remain unanswered on #reactos. Moreover, we don't maintain the list of voiced people thoroughly, so even some contributors have to ask for temporary voice on #reactos-dev. Keep in mind that we're currently in the GSoC phase where students shall submit their proposals and get in touch with the developers. How are they going to do this on IRC if #reactos-dev continues to be an exclusive club? Because of these reasons, I'm proposing to remove the moderation bit on #reactos-dev and let everybody talk there. Its development topic should be enforced though! As soon as people get too off-topic, they should be directed to #reactos and kicked if nothing else helps. Given that all devs are already operators on #reactos-dev, it's fully in their hands. Cheers, Colin

14 18

Re: [ros-dev] Opening up #reactos-dev to the public
by Alex Ionescu 25 Mar '17

25 Mar '17

I don't agree. Maintain the auto-voice lists and get someone in charge of operations, like I used to be for many years on IRC. Instead, why not create a #reactos-gsoc or something? Best regards, Alex Ionescu On Fri, Mar 24, 2017 at 11:19 AM, Mark Jansen <learn0more+ros(a)gmail.com> wrote: > We can always try it out? > If it doesnt work, restoring it is a simple as setting a flag on the > channel. > > On 24 March 2017 at 16:31, David Quintana (gigaherz) <gigaherz(a)gmail.com> > wrote: > > I disagree -- if we can be firm about the channel being only for > development > > talk, things should remain mostly as they are now. > > > > In any community, there's inevitably going to be idle talk, offtopic > > conversations, etc. If you only have ONE place to talk in, all those > thigns > > are going to be mixed in with actual dev talk, but if you have clear > rooms > > set for each thing, the majority of people will be happy to leave all the > > offtopic talk to the main channel, and dev talk to the dev channel. > > > > It works for plenty other projects and communities so there's no reason > to > > be pessimistic and think that "our idiots are worse". It's simply not > true. > > > > I vote for trying, and we can always put back the +m if things get out of > > hand. > > > > On 24 March 2017 at 16:13, Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> > > wrote: > >> > >> I don’t approve the idea. The fact is that if the devs quit originally > >> #reactos, it’s because it was generally too noisy, etc… . If we remove > the > >> moderation irc bit in #reactos-dev, you may expect the same phenomenon > to > >> occur in #reactos-dev too. > >> > >> > >> > >> De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de David > >> Quintana (gigaherz) > >> Envoyé : vendredi 24 mars 2017 11:35 > >> À : ReactOS Development List > >> Objet : Re: [ros-dev] Opening up #reactos-dev to the public > >> > >> > >> > >> I approve the idea. > >> > >> > >> > >> On 24 March 2017 at 11:21, Colin Finck <colin(a)reactos.org> wrote: > >> > >> Hi all! > >> > >> As you all know, our #reactos-dev IRC channel has been a moderated IRC > >> channel for decades, and only operators (devs) and voiced people can > >> talk. While we always tried to keep discussions dev-related there, no > >> topic has ever been enforced on #reactos. The result is that I see a > >> notable number of developers only on #reactos-dev these days. > >> > >> This is a pretty bad situation! Emerging developers hardly have a way to > >> interact with all existing devs on IRC. Often enough, legitimate > >> questions from them remain unanswered on #reactos. Moreover, we don't > >> maintain the list of voiced people thoroughly, so even some contributors > >> have to ask for temporary voice on #reactos-dev. > >> > >> Keep in mind that we're currently in the GSoC phase where students shall > >> submit their proposals and get in touch with the developers. > >> How are they going to do this on IRC if #reactos-dev continues to be an > >> exclusive club? > >> > >> Because of these reasons, I'm proposing to remove the moderation bit on > >> #reactos-dev and let everybody talk there. > >> Its development topic should be enforced though! As soon as people get > >> too off-topic, they should be directed to #reactos and kicked if nothing > >> else helps. Given that all devs are already operators on #reactos-dev, > >> it's fully in their hands. > >> > >> > >> Cheers, > >> > >> Colin > >> > >> _______________________________________________ > >> Ros-dev mailing list > >> Ros-dev(a)reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > >> > >> > >> > >> > >> _______________________________________________ > >> Ros-dev mailing list > >> Ros-dev(a)reactos.org > >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

9 14

Re: [ros-dev] [ros-diffs] [gadamopoulos] 74151: [BROWSEUI] -CExplorerBand: Stub QueryService method and set the site of the context menu so as to let the context menu find the SID_IShellBrowser when the open menu item is cl...
by Thomas Faber 23 Mar '17

23 Mar '17

On 2017-03-12 10:48, gadamopoulos(a)svn.reactos.org wrote: > // *** IServiceProvider methods *** > HRESULT STDMETHODCALLTYPE CExplorerBand::QueryService(REFGUID guidService, REFIID riid, void **ppvObject) > { > - UNIMPLEMENTED; > - return E_NOTIMPL; > + /* FIXME: we probably want to handle more services here */ > + return IUnknown_QueryService(pSite, SID_SShellBrowser, riid, ppvObject); > } This seems dangerous. If someone requests something other than SID_SShellBrowser, we'll just return them a different object without any indication that something is wrong. Shouldn't we either pass guidService down or fail somehow if it's not asking for ShellBrowser?

1 0

Re: [ros-dev] [ros-diffs] [khornicek] 74209: [RAPPS] - Add a custom build of the Mesa 3D Graphics Library. This build contains mesa, gallium and llvmpipe. It provides an enormous performance boost over the software implemen...
by Colin Finck 22 Mar '17

22 Mar '17

khornicek(a)svn.reactos.org wrote: > [RAPPS] > - Add a custom build of the Mesa 3D Graphics Library. This build > contains mesa, gallium and llvmpipe. It provides an enormous > performance boost over the software implementation present in > opengl32. That sounds fantastic! I'm just wondering, if it is better than our current OpenGL software rendering in every regard, can't we just have it as the default in our tree? - Colin

10 13

Re: [ros-dev] [ros-diffs] [sgasiorek] 74179: [DXG] DdHmgLock - use PLONG instead of PBYTE.
by Kay Dohmann 22 Mar '17

22 Mar '17

This looks wrong to me since both lines produce different results. For example: (PBYTE)0x00000000 + 4 == (PBYTE)0x00000004 but (PLONG)0x00000000 + 4 == (PLONG)0x00000010 > if ( Index < gcMaxDdHmgr ) > { > - pEntry = (PDD_ENTRY)((PBYTE)gpentDdHmgr + (sizeof(DD_ENTRY) * Index)); > + pEntry = (PDD_ENTRY)((PLONG)gpentDdHmgr + (sizeof(DD_ENTRY) * Index)); > > if ( VerifyObjectOwner(pEntry) ) > { > >

2 1

New dev doubts/questions
by Pranay Pratyush 19 Mar '17

19 Mar '17

Hi there, I feel extremely enthusiastic about contributing to reactos through gsoc. I looked into the idea list for 2017 and "Audio Mixer" looks the most interesting to me. But I have absolutely no experience writing windows services, let alone kernel streaming. I have experience with linux internals and I have used Windows APIs in the past. I am really interested in this. How do I get a mental map of what all things I need to do to achieve this? What all stuff do I learn for this and how? Also suggest me if I should drop this entirely and conribute through coding something less "ambitious". -- *Pranay Pratyush,* 3rd year undergraduate , Computer Science and Engineering Department Indian Institute Of Technology, Kharagpur --

1 0

Legal advice concerning contribution to ReactOS
by tobias.k＠posteo.de 19 Mar '17

19 Mar '17

Hi, I've a question concerning legal restrictions. As mentioned on this page https://reactos.org/wiki/Subversion#Prerequisites I'm not allowed to contribute to ReactOS when I'm an employee of Microsoft or of any subsidiary of Microsoft. In the past, I worked for a German company which was a Certified Partner of Microsoft. As far as I know, it was not a subsidiary of Microsoft. It's not even listed here https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitions_by_Microsoft (but I don't know if this list is complete). Since a Certified Partner is not automatically a MS subsidiary or equivalent to it in a sense (as I think), there shouldn't be a problem for me contributing to ReactOS. Is there anybody who can confirm that? Tobias

4 4

JIRA/FishEye upgrade on March 8
by Colin Finck 18 Mar '17

18 Mar '17

Hi all! Let me announce a definite date for our JIRA/FishEye upgrade: Wednesday, March 8, around 9:00 UTC Expect downtimes of several hours at https://code.reactos.org and https://jira.reactos.org around this time. I can say for sure that I will have enough time on this day and the following to deal with all possible incidents that could happen during the complex upgrade. This also allows me to get direct in-person feedback from all the devs attending CLT on the weekend after that :) The upgrade to JIRA 7.x is a major one, and Atlassian recommends everyone to have a look at the new features: https://confluence.atlassian.com/migration/jira-7/server_jira_product-chang… Best regards, Colin

6 10

Re: [ros-dev] New ideas added to GSoC Ideas list
by Can Tasan 17 Mar '17

17 Mar '17

Wine still maintains and even improves Windows 3.x support! I hope they don't give up! Can we use Wine code while implementing WoW16?

2 3

YNT: New ideas added to GSoC Ideas list
by Can Tasan 17 Mar '17

17 Mar '17

Dear Ricardo, Firstly, Win16 application support doesn't interrupt our project. It strengthens us. On technical view, supporting them doesn't make any design change to NT architecture, apps won't be able to access hardware directly. Like any app, they'll obey the rules. Secondly, there are a number of reasons to support Win16: 1) Many people and corporations still use DOS and Win16 apps today, thus their system can't be upgraded easily. Most of the cases, DOSBOX will do the job but what if any problem occurs, or integration with system is needed? With Win16 support out of the box, people will get much more technical support and security updates. 2) Many apps released in 90s have 16 bit setups, even they are actually 32-bit. In this case, compatibility and usability of ReactOS greatly decreases. 3) Sometimes emulation may be not enough for special cases. 4) There are many games from 16 bit age which is still played today. Supporting them makes a bonus. In my opinion, this cases makes WoW16 support viable. Apologizes if I forget something and sending this twice, accidentally pressed the send button. Best regards, Can

2 1

Re: [ros-dev] New ideas added to GSoC Ideas list
by Can Tasan 17 Mar '17

17 Mar '17

Wine still maintains and even improves Windows 3.x support! I hope they don't give up! Can we use Wine code while implementing WoW16?

1 0

Re: [ros-dev] New ideas added to GSoC Ideas list
by Can Tasan 17 Mar '17

17 Mar '17

I also have some ideas here, not fully sure about their feasibility. Tried to be wise as much as I can. -Continuing USB work that vardanm started. Yes, I know a developer is working on that. Another joining student would be great and speed up things. -Continuing TCP/IP stack work if noone is working on rewrite. -Working on DirectX support: bringing new features, fixing bugs, optimising, if possible fixing some driver issues... -Fixing driver unloading/fallback problem (CORE-8294) I think it's a hurdle on our hardware compatibility, but not sure its priority. -Would some kind of Win32 subsystem work be too hard? -Implementing some missing things in shell. -Implementing more user mode stuff, or is it enough for now? -Extending printing support. -Fixing current audio support, if our devs don't want to tinker with it. -Implementing WoW16 support. I suppose that'll draw attention. And as said before, proper application compatibility database. :) By the way, I'm too pleased to join and see you here all! With my best regards, Can Taşan

7 9

Definite Decision about ISO lifetimes at iso.reactos.org
by Colin Finck 16 Mar '17

16 Mar '17

Hi all! We used to remove any ISOs at https://iso.reactos.org that were older than 2 years. Then some devs wanted access for a little longer and we stopped deleting any. Now we recently ran out of space on that server... Even though we are about to double our storage capacity, I want a definite decision about the lifetime of ISOs at iso.reactos.org. Something that serves us well over the next few years. Otherwise, we will just run into the same problem again in the near future. My proposal =========== bootcd-dbg: 5 years bootcd-dbg-msvc: 5 years bootcd-rel: 0.5 years bootcdregtest: 1 week livecd-dbg: 0.5 years livecd-dbg-msvc: 0.5 years livecd-rel: 0.5 years Having the DBG Boot-CDs up for 5 years should cover all reasonable regression testing in my opinion. I'm not that much into testing as you though, so if any of these lifetimes are too short for you, please speak up now. Otherwise, I'm going to implement this by next Wednesday, March 22. Cheers, Colin

2 2

Re: [ros-dev] New ideas added to GSoC Ideas list
by Ștefan Fulea 15 Mar '17

15 Mar '17

Marți, 14 martie 2017 12:00:02 +0000, Mark Jansen <learn0more+ros(a)gmail.com> a scris: > How about a better way to translate ros? > For example integrating .po files with our rc files (possibly needs a > preprocess step or something tho), > Or creating a resource editor that allows multiple files to be edited > at once? > Please don't push for .po resources, for these are not better. As for improving the process, I doubt it'd repay the investment. After the initial translation effort, the further maintenance requires very little.

5 6

Regarding Smart Commits
by Colin Finck 15 Mar '17

15 Mar '17

Hi all! Some people have noticed that Smart Commits (#resolve, #comment, etc.) have stopped working after the JIRA/FishEye upgrade. This is due to the new per-user OAuth authentication between both systems, which means that every committer needs to authorize FishEye once to impersonate as your JIRA account. FishEye only tells you this and the URL to fix it after the first failed Smart Commit, but here it is: https://code.reactos.org/plugins/servlet/applinks/oauth/login-dance/authori… Click that, confirm and all subsequent Smart Commits should work. Make sure you are logged into JIRA and FishEye before. Cheers, Colin

1 0

Re: [ros-dev] New ideas added to GSoC Ideas list
by Alex Ionescu 13 Mar '17

13 Mar '17

I would like to see support for GPT partititioning :) Best regards, Alex Ionescu On Sun, Mar 12, 2017 at 3:51 PM, Javier Agustìn Fernàndez Arroyo < elhoir(a)gmail.com> wrote: > i dont think anyone has any problems on downloading a 100MB ISO file.... > but... what about any kind of minimal network install ISO file support? > > On Sun, Mar 12, 2017 at 11:34 PM, Thomas Mueller <mueller6723(a)twc.com> > wrote: > >> > Victor thought also about adding registry hive healing. >> > Hermès. >> >> > -----Message d'origine----- >> > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Colin >> Finck >> > Envoyé : dimanche 12 mars 2017 17:27 >> > À : 'ReactOS Development List' >> > Objet : [ros-dev] New ideas added to GSoC Ideas list >> >> > Hi all! >> >> > Daniel and me collected some additional ideas for GSoC today, which >> I've added to our Wiki Ideas list: >> > https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas >> >> > In particular: >> > * Fundamental WiFi components >> > * USBXHCI driver for supporting USB 3.x controllers >> > * Bluetooth Stack >> > * WebKit-based MSHTML implementation >> >> > I'm open for comments and suggestions! >> > We can still add ideas until March 20, so let's give students a large >> pool to draw from. >> >> > Cheers, >> >> > Colin >> >> Would GPT partitioning support for ReactOS be appropriate for GSoC? >> >> Also, the ability to build or cross-build ReactOS and install directory >> to a FAT32 partition, mounted on a directory, without having to burn to CD >> and boot/install from there: would that be appropriate? >> >> Tom >> >> >> >> >> _______________________________________________ >> 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 > >

2 1

Work on dxg.sys
by Sebastian Gąsiorek 10 Mar '17

10 Mar '17

Hi, Couple of days ago I have started dxg.sys functions implementation. There is some progress but it would be good to write tests for this api. Dxg mostly is just wrapper between driver and win32k, so win32k api tests should be enough. I saw some tests in rostests\dxtest\win32kdxtest but can't figure out how to enable them in build. Could some help me with this and add proper cmake files? :) Best regards, Sebastian

4 4

CLT, one seat left
by Daniel Reimer 09 Mar '17

09 Mar '17

After some strike related problems we lost one of our supporters @ Chemnitzer Linux Tage (https://chemnitzer.linux-tage.de/2017/de) SO if someone wants to join. Here we are, waiting for ya. Start is on THIS saturday and ending is THIS sunday evening. Yes, quite a bit early I ask here, but... sadly the problems showed up today. We might even have a hotel room left if our hotel does not cancel it that close to booking date. Otherwise we find a way, too. So, first come first served. Sell your soul/come to us ^^

1 0

Re: [ros-dev] [ros-diffs] [mjansen] 74063: [NTDLL] Fix RtlDecodeSystemPointer for usage inside ntdll. CORE-10368
by Michael Fritscher 06 Mar '17

06 Mar '17

Hi, I don't know - but this looks somehow ... surprising. Best regards, Michael > /* > * @implemented > + */ > +PVOID > +NTAPI > +RtlDecodeSystemPointer(IN PVOID Pointer) > +{ > + return RtlEncodeSystemPointer(Pointer); > +} > + > +/* > + * @implemented

2 2

Buildslave disk space problems fixed
by Colin Finck 05 Mar '17

05 Mar '17

Hi all! We have run out of space on our temporary universal Build and ISO machine HotelLux today. This is why TestCD creation has been failing. I'm currently moving files away from the main disk to a temporary storage. You should already be able to redo the failed builds. Within this month, Aleksey and me will move the ISO storage back to our actual storage server, upgraded with larger disks. This one should be sufficient for quite some time. Sorry for the inconveniences! Cheers, Colin

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 74068: [WS2_32] - Fix pointers verification in WSALookupServiceNextW and WSALookupServiceNextA; - In WSALookupServiceNextA: Perform extra checks to see whether we failed the first local ...
by Thomas Faber 05 Mar '17

05 Mar '17

On 2017-03-05 01:40, hbelusca(a)svn.reactos.org wrote: > + > + /* > + * Check whether we actually just retrieved the needed buffer size > + * because our previous local allocation did fail. If so, allocate > + * a new buffer and retry again. > + */ > + if ( (!UnicodeQuerySet) && (*lpdwBufferLength >= sizeof(WSAQUERYSETW)) && > + (ErrorCode == SOCKET_ERROR) && (GetLastError() == WSAEFAULT) ) Seems like you'd want to check WSAGetLastError when looking for WSA* error codes. > + { > + /* Allocate the buffer we'll use */ > + UnicodeQuerySet = HeapAlloc(WsSockHeap, 0, UnicodeQuerySetSize); > + if (UnicodeQuerySet) > + { > + /* Call the Unicode Function */ > + ErrorCode = WSALookupServiceNextW(hLookup, > + dwControlFlags, > + &UnicodeQuerySetSize, > + UnicodeQuerySet); > + } > + /* > + * Otherwise the allocation failed and we > + * fall back into the error checks below. > + */ > + } > + > if (ErrorCode == ERROR_SUCCESS) > { > - /* Not convert to ANSI */ > + /* Now convert back to ANSI */ > ErrorCode = MapUnicodeQuerySetToAnsi(UnicodeQuerySet, > lpdwBufferLength, > lpqsResults); > - if (ErrorCode != ERROR_SUCCESS) SetLastError(ErrorCode); > + if (ErrorCode != ERROR_SUCCESS) > + SetLastError(ErrorCode); > } > else > { > @@ -499,10 +542,11 @@ > } > > /* If we had a local buffer, free it */ > - if (UnicodeQuerySet) HeapFree(WsSockHeap, 0, UnicodeQuerySet); > + if (UnicodeQuerySet) > + HeapFree(WsSockHeap, 0, UnicodeQuerySet); HeapFree(NULL) is fine by the way. > > /* Return to caller */ > - return ErrorCode == ERROR_SUCCESS ? ErrorCode : SOCKET_ERROR; > + return (ErrorCode == ERROR_SUCCESS) ? ErrorCode : SOCKET_ERROR; > }

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 74054: [NTOS:OB] Create a custom security descriptor for the global DosDevices directory.
by Thomas Faber 04 Mar '17

04 Mar '17

On 2017-03-04 17:02, ekohl(a)svn.reactos.org wrote: > + Dacl = ExAllocatePool(PagedPool, AclLength); Would you mind using ExAllocatePoolWithTag for new code please, with no exceptions? (I want to #define ExAllocatePool do_not_use_this_function at some point) Thanks! -Thomas

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 73895: [NTGDI]: Few fixes & hacks for NtGdiGetGlyphIndicesW, see CORE-12825: - (Fix) Check for integer count overflow (per Thomas suggestion), - (Hack#1) Signal the particular calling ca...
by Thomas Faber 03 Mar '17

03 Mar '17

On 2017-02-24 02:52, hbelusca(a)svn.reactos.org wrote: > @@ -4419,12 +4422,31 @@ > LPCWSTR UnSafepwc = pwc; > LPWORD UnSafepgi = pgi; > > - if ((!UnSafepwc) && (!UnSafepgi)) return cwc; > - > - if ((UnSafepwc == NULL) || (UnSafepgi == NULL)) > + /* Check for integer overflow */ > + if (cwc & 0x80000000) // (INT_MAX + 1) == INT_MIN > + return GDI_ERROR; > + > + if (!UnSafepwc && !UnSafepgi) > + return cwc; > + > + if (!UnSafepwc || !UnSafepgi) > { > DPRINT1("UnSafepwc == %p, UnSafepgi = %p\n", UnSafepwc, UnSafepgi); > - return -1; > + return GDI_ERROR; > + } > + > + // TODO: Special undocumented case! > + if (!pwc && !pgi && (cwc == 0)) Why the sudden switch away from using the Unsafe version? > + { > + DPRINT1("ERR: NtGdiGetGlyphIndicesW with (!pwc && !pgi && (cwc == 0)) is UNIMPLEMENTED!\n"); > + return 0; > + } > + > + // FIXME: This is a hack!! (triggered by e.g. Word 2010). See CORE-12825 > + if (cwc == 0) > + { > + DPRINT1("ERR: NtGdiGetGlyphIndicesW with (cwc == 0) is UNIMPLEMENTED!\n"); > + return GDI_ERROR; > } > > dc = DC_LockDc(hdc); > >

3 2

Retiring rapps
by Mark Jansen 02 Mar '17

02 Mar '17

Hello, Soon (tm) we will be retiring rapps in favor of rapps_new. If you have any local patches in these regions, now is the time to step forward (and convert them to rapps_new!). regards, Mark Jansen

1 0

ReactOS is participating in Google Summer of Code 2017
by Colin Finck 27 Feb '17

27 Feb '17

Hi folks! We just got the good news: ReactOS has been accepted and will be participating in Google Summer of Code 2017!! :) Next step is finishing the Ideas list. Our current version is at https://reactos.org/wiki/Google_Summer_of_Code_2017_Ideas More information will also follow shortly on our website. Cheers, Colin

5 4

Re: [ros-dev] [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet:
by Ged Murphy 26 Feb '17

26 Feb '17

These are so much more useful to read now we have a changelog to explain the patch. Thanks Amine :) -----Original Message----- From: Ros-diffs [mailto:ros-diffs-bounces@reactos.org] On Behalf Of akhaldi(a)svn.reactos.org Sent: 26 February 2017 16:01 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [akhaldi] 73929: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet: Set index of folder in FDICopy callback. 1f7d144 cabinet: Make Extract fail on read-only files. af86bdc cabinet: ... Author: akhaldi Date: Sun Feb 26 16:00:58 2017 New Revision: 73929 URL: http://svn.reactos.org/svn/reactos?rev=73929&view=rev Log: [CABINET] Sync with Wine Staging 2.2. CORE-12823 a663fe94 cabinet: Set index of folder in FDICopy callback. 1f7d144 cabinet: Make Extract fail on read-only files. af86bdc cabinet: Make Extract overwrite existing files. 3273dff cabinet: Properly initialize internal fci structure (Valgrind). Modified: trunk/reactos/dll/win32/cabinet/cabinet_main.c trunk/reactos/dll/win32/cabinet/fci.c trunk/reactos/media/doc/README.WINE

1 0

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 25 Feb '17

25 Feb '17

I think I'm going to upload two PDF files to prove my point. On Thu, Feb 16, 2017 at 11:25 PM Hermès BÉLUSCA-MAÏTO <hermes.belusca(a)sfr.fr> wrote: > Hi ! Here are some thoughts as an answer to Ziliang's mail: > > > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Zachary > Gorden > > Envoyé : jeudi 16 février 2017 23:03 > > À : ReactOS Development List > > Objet : Re: [ros-dev] Microsoft switched to Git > > > The fact that git has problems maintain a large history is ONE of the > limitations that prompted them to develop GVFS. There are several comments > on the first page in the discussion of the ars technica article on GVFS > that talk about git's issues with long histories: > > > https://arstechnica.com/information-technology/2017/02/microsoft-hosts-the-… > > I can't link directly to the comments, but if you search by user name > you jump right to them. Two especially relevant ones are by smengler and > zaqzlea. The one by zaqzlea is also rather interesting if Linux itself has > truncated its own commit history, which is more than a bit disturbing from > > my perspective. > > I guess that this 'truncated history' story happened when Linus switched > to his newly-created Git the 16. April, 2005 : > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=… > because, if one believes what's written inside > https://git.wiki.kernel.org/index.php/GraftPoint , "When Linus started > using git for maintaining his kernel tree there didn't exist any tools to > convert the old kernel history." Later on, when new features have been > added to Git, people were able to create Git repositories of Linux' code > before the 16/04/2005 Git transition, and then, to be able to see the whole > Linux history, you need to use the so-called graft points. Examples are > given here: > > http://stackoverflow.com/questions/3264283/linux-kernel-historical-git-repo… > https://archive.org/details/git-history-of-linux > > > > We also see a few remarks by a guy calling himself scuttle22 who claims > that truncating history and dropping it is "common practice" and > acceptable. His original posts have all been downvoted to oblivion, > presumably because others take a less lackadaisical perspective > > on preserving history for purposes of documentation and accountability. > > This is possibly "common practice", maybe in order to reduce the git > repos... In there: > http://stackoverflow.com/questions/4515580/how-do-i-remove-the-old-history-… > , someone ask for example how to trim the history before a certain date, > while the complete copy of history is kept in an archive repository.... > > > I also take the occasion to mention the peculiar possibility, with Git, to > have a repository having multiple roots ("initial commits"): for example, > someone did the error once in the linux kernel repo: > http://lkml.iu.edu/hypermail/linux/kernel/1603.2/01926.html . > > Best, > Hermès > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev -- Best regards, Alex Ionescu

2 1

freetype.c related
by katahiromz . 24 Feb '17

24 Feb '17

That patched result has "OUT OF PAGED POOL" errors. Is the cache too large? Or are there any leaks?

1 0

Status Meeting (February 2017)
by Aleksey Bragin 23 Feb '17

23 Feb '17

Hello, Let me invite you to the monthly status meeting taking place tomorrow, 23rd of February, 19:00 UTC. IRC service will only be started shortly before the meeting. Your participation passwords and server address will be emailed to you shortly before the meeting starts, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. Alternatively we'll do it in #reactos-meeting on Freenode, depending on our admins mood. Please send agenda proposals to me before the meeting so we don't waste time trying to setup the agenda directly during the meeting. Regards, Aleksey Bragin

2 1

Office (Excel, Word...) 2010 on ReactOS
by Hermès BÉLUSCA-MAÏTO 22 Feb '17

22 Feb '17

Hello everyone, Today I was finally able to finish the installation of Office 2010 in ReactOS, using as a temporary measure the Wines NTLM layer that calls into the ntlm_auth utility of Samba. This was done while Samuel is completing his NTLM implementation. As this wine layer is here running on ReactOS, few modifications were needed, and I also needed to find a Windows build of Samba. Ive found one, by chance, at http://smithii.com/samba . Then, using ReactOS revision 73868 (or later), and using this version of Samba, the Office installation finishes (reminder: the problem was due to the fact the installer needed NTLM to communicate with the Office Software Platform Service, OSPPSVC.EXE). We are now able to use Excel, Word, on ReactOS, as shown in this picture: http://i.imgur.com/fLEwoVI.png There are now 2 main problems: - NTLM should be correctly implemented; - There are an awful lot of drawing problems with Office 2010 applications (similar to those of Office 2007 apps): for example, dragging the graph downwards shows his frame going upwards; there are many black regions that show up, etc...: It seems we have problems in coordinate frames. And other problems too. Also, we have some mouse capture problems: if you try to redimension the windows the normal way (bring mouse cursor on top of the border, left-click-maintained, move mouse, release left button), and then move the mouse inside the window, it continues to be redimensioned... As a result, I took ~=15 minutes to make this simple trivial picture above, almost all the time taken to fight against window dimensioning & the drawing problems. But anyways, enjoy ! This will be part of my next blog report. Cheers, Hermès

7 15

[ros-diffs] [gadamopoulos] 73871: [COMCTL32]: Copy button.c from user32, make the needed changes to make it compile and register it. This is the beginning of the v6 button. Remove the subclassing of the builti...
by James Tabor 22 Feb '17

22 Feb '17

Added: trunk/reactos/dll/win32/comctl32/button.c - copied, changed from r73835, trunk/reactos/win32ss/user/user32/controls/button.c O---M---G!!!!! My head just exploded!

2 2

JIRA/FishEye upgrade this weekend
by Colin Finck 19 Feb '17

19 Feb '17

Hi all! Due to the current unstable situation with FishEye, which also badly affects JIRA, I will attempt an upgrade of both applications on a new server this weekend. As always I will do my best to keep the downtime low. But keep in mind that this involves migrating databases from one machine to another, so downtime may be longer than for a usual upgrade. In the end, you can expect/hope for a much better performing setup with all the new features that got added to JIRA and FishEye over time :) Cheers, Colin

4 5

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 16 Feb '17

16 Feb '17

.... which have nothing to do with history. And which have now been publically made available/fixed. Best regards, Alex Ionescu On Thu, Feb 16, 2017 at 12:14 PM, Zachary Gorden <drakekaizer666(a)gmail.com> wrote: > It was not zero problems. Their entire creation of the git virtual file > system was to overcome git's limitations. > > On Thu, Feb 16, 2017 at 2:07 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote: >> >> Sounds like a bug in their migration/etc tool. MS has history going >> back to 1984 and migrated everything to Git with zero problems. >> >> At some point you should apply Ionescu's Razor: "Hmmm, a company of >> 150,000 developers and the most complicated and oldest series of >> repositories in the world, was able to move to Git, including while >> employing people who have been there for 30 years and used to other, >> older systems.... but 30 open source developers can't make that change >> because X". It follows from this that X is bullshit. >> >> On the polluting history, again, just read commits that have [FOOBAR] >> in them, and ignore others. Write a post-commit hook to rewrite/squash >> them. >> Best regards, >> Alex Ionescu >> >> >> On Thu, Feb 16, 2017 at 9:41 AM, Zachary Gorden >> <drakekaizer666(a)gmail.com> wrote: >> > The project that I worked with using git has history going back to 1988. >> > They certainly didn't start with git, nor did they necessarily start >> > with >> > any revision control at the beginning, but after they migrated to it >> > they >> > discovered the history problem. >> > >> > On Thu, Feb 16, 2017 at 10:42 AM, Colin Finck <colin(a)reactos.org> wrote: >> >> >> >> Am 16.02.2017 um 14:40 schrieb Alex Ionescu: >> >> > That being said, that type of "dirty history" only happens if you >> >> > heavily work with branches. That's not how reactos developers work -- >> >> > we >> >> > don't open PRs and separate branches for every checkin. >> >> > >> >> > These ALL sound like manufactured problems or poor/strange use of >> >> > git. >> >> >> >> That merge hell is easily reproducible using my default Git setup: >> >> >> >> 1) Change something in your clone of master and do a "git commit". >> >> 2) Let someone else change something in his clone of master and let him >> >> "git commit" and "git push" it. >> >> 3) Try to "git push" your commit, won't work because of the commit of >> >> the other person. >> >> 4) Do a "git pull" to fix the problem in 3) -> Bam! Git will do an >> >> automatic merge of both masters and pollute your history. >> >> >> >> You see, not a single extra branch is involved and yet we get two >> >> parallel streams of history. >> >> >> >> Rafal's mentioned "pull.rebase" option sounds promising, but can we >> >> enforce that somehow? >> >> >> >> >> >> - Colin >> >> >> >> _______________________________________________ >> >> Ros-dev mailing list >> >> Ros-dev(a)reactos.org >> >> http://www.reactos.org/mailman/listinfo/ros-dev >> > >> > >> > >> > _______________________________________________ >> > Ros-dev mailing list >> > Ros-dev(a)reactos.org >> > http://www.reactos.org/mailman/listinfo/ros-dev >> > >> >> _______________________________________________ >> Ros-dev mailing list >> Ros-dev(a)reactos.org >> http://www.reactos.org/mailman/listinfo/ros-dev > > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev >

3 2

CLT 2017, we will join ^^
by Daniel Reimer 16 Feb '17

16 Feb '17

Haaaay guys, so, we will join the guys @ CLT that year, too. Booth will be maintained by Colin, Mr. [TheFlash] aka Mr. CrystalMath, Mr. Adamopoulos and me ^^ Hotel planning will be done by me, CDs too I guess (meeeeh). One thing is still missing. Do we need any stuff? https://www.thomas-krenn.com/de/unternehmen/kampagnen/thomas-krenn-award.ht… Seems like we can win some stuff and for that we have to send em shopping cart IDs for 1st 2nd and 3rd price limit. Winners will be informed @ CLT Any ideas? Greetings Daniel

1 0

Re: [ros-dev] Microsoft switched to Git
by Alex Ionescu 16 Feb '17

16 Feb '17

I too have no idea where this "history limit" comes into play. I work on and have repos spaning 50-100 developers working on dozens of thousands of branches over two dozen repos with almost 8 years of history. Some people rebase, but most people don't. It is extremely easy to have a clean history due to the fact we enforce the "[COMPONENT] Description" commit message (and can use a git hook to make sure it looks this way). It is then trivial to write a script that only looks for those commits. Heck you can even auto-squash/rebase anything that doesn't match. That being said, that type of "dirty history" only happens if you heavily work with branches. That's not how reactos developers work -- we don't open PRs and separate branches for every checkin. These ALL sound like manufactured problems or poor/strange use of git. On Thu, Feb 16, 2017 at 12:02 AM David Quintana (gigaherz) < gigaherz(a)gmail.com> wrote: > If git has an upper limit on history, it's the first time I hear about it, > and it would be an issue I was simply not aware of. So far as I was aware, > git just keeps a parent hash on each commit, and the GC just deletes > commits without any reference. In fact, we use Git at my current job, and > the history goes back many years, and it seems perfectly capable of > tracking it. And no, we don't rebase or squash, ever. We are not allowed to > do any operation that changes commit history. So it's quite a mess of merge > commits, but even then it's manageable. > > I disagree on needing a single person responsible for merges. The the PR > workflow we have at my current job is that the developer submits a PR for > review, and adds to the PR two other developers, who have to approve the > changes or request fixes. Once it's approved, the original developer can > click the merge button themselves. For external PRs done by contributors, > then one of the reviewers is the responsible for clicking the merge button. > > And even if you do choose to require a commit-master, with the way > github's merge button works, you can choose to have a merge commit, or to > squash & rebase implicitly, and the history ends up with one single commit > attributed to all the developers that were involved in the merge. As an > example, I have a hobby writing Minecraft mods, and they use Forge to work: > https://github.com/MinecraftForge/MinecraftForge/commits/1.11.x -- you'll > see many "<someone> commited with LexManos". That's because there's an > author, and a commiter, in the git info. > > I do agree, git history can get messy, and ugly, and hard to track -- if > you abuse merge commits. I, unlike Alex, am a fan of manual rebases, and > leaving a clean history before you submit the changes for review. But I > understand that constantly rewriting history means you end up with a > fabricated history at the end. So the policy choices should probably either > be no merges at all, or no rebasing at all. But that's where "git blame" > comes in. With a proper tool, you can see exactly who changed a file, and > when, and you can use it to track back the history of that file, or that > specific line of code. > > > > On 16 February 2017 at 03:45, Zachary Gorden <drakekaizer666(a)gmail.com> > wrote: > > I've used both git and svn in work environments. If all you do is git pull > and git push, you end up with lots of noise in the commit log with git > tracking every single merge because you don't rebase. Combined with the > fact that git has an upper limit on how much history it can track and the > solution literally being to purge history, I'm not exactly sure why all of > you are so enthused about it. Unless the team wants to adopt having a > single person being responsible for all commits going into the canonical > master repo to avoid all of the problems with how git tracks history, the > commit log is going to be next to useless for actual tracking of history. > If you don't care about the commit history, then sure, go ahead, but I > personally would like to be able to easily track changes back cleanly. We > get that basically for free with svn right now. With git, the usage > patterns that those of you pushing for git are promoting actively works > against keeping a clean history. > > On Wed, Feb 15, 2017 at 7:32 PM, Alex Ionescu <ionucu(a)videotron.ca> wrote: > > Sure, I didn't count git add because you can do it with git commit -a. > git status/log are the same as the svn equivalents. just like git > diff/svn diff. I was mainly referring to regular workflow. > > In fact, I think outside of stash (which is an optional, but awesome, > feature) fetch and rebase (which I refuse to learn), all commands map > 1:1 with svn. That's why I don't get this whole "it takes way more > commands/steps in git". > > git commit -a -m "[BOOTLIB] Fix yet another bug]" > git push > > Done. > > Best regards, > Alex Ionescu > > > On Wed, Feb 15, 2017 at 3:48 PM, David Quintana (gigaherz) > <gigaherz(a)gmail.com> wrote: > > My command set is a bit more extended: > > > > git clone -- similar to svn checkout into a new folder > > git checkout -- for changing the current branch > > git pull -- effectively the same as "svn update", xcept it gets the > entire > > change history, not just the latest commit data > > git push [--force] -- for sending changes into the repository > > git fetch -- downloads stuff but doesn't apply it to the checkout copy > > git merge -- can be used to merge the remote data (in which case it's > like > > svn update), or to merge from another branch > > git branch > > git add > > git commit > > git stash save/pop -- can be used to temporarily undo some changes, and > be > > able to recover them afterward > > git status, git log, ... -- for getting info about the state of the > > repository and the uncommited changes > > ... and more I that I use less often > > > > I do agree that it is a bit annoying that git has so much trouble pulling > > with local changes, and that is the one area where svn just simply works > > better. In every other aspect, I have come to like the "git way" more. > > > > That said, I avoid commandline git as much as possible. I prefer to use > > TortoiseGit (in Windows, at home), or SourceTree (at work, where I use a > > mac, and SourceTree is probably the least shitty frontend for git). > > > > I like to say, that for someone who knows Subversion, learning git > starts by > > realizing that all the usual svn concepts, apply to git, just NOT with > the > > remote repository. The svn-like commands work with the local repository > > clone, and then it has a separate command set for interacting with > remotes. > > Of course it's not a 1:1 match, but it's a good starting point. If you > are > > able to "catch" that, then learning how to work with git becomes a LOT > > easier. > > > > > > > > On 16 February 2017 at 00:31, Alex Ionescu <ionucu(a)videotron.ca> wrote: > >> > >> On Wed, Feb 15, 2017 at 9:01 AM, Zachary Gorden > >> <drakekaizer666(a)gmail.com> wrote: > >> > Why is there a need for anything beyond "git commit" or "git push" or > >> > "git > >> > pull" to do anything? > >> > >> Good question. I've never used any other git command other than those > >> (except git checkout). Oh, that's lie, I've also used "git branch", > >> just like on svn, to create a branch. > >> > >> Sounds like you've never actually used git? I've never rebased in my > >> life, and I don't know what other commands even exist. > >> > >> Best regards, > >> Alex Ionescu > >> > >> _______________________________________________ > >> 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 > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > -- Best regards, Alex Ionescu

4 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev