- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [akhaldi] 66623: [RTL] Partly sync actctx.c with Wine Staging 1.7.37. CORE-9246
by Aleksey Bragin 09 Mar '15

09 Mar '15

Hi Amine, thanks for syncing up ActCtx stuff! Is that DPRINT->DPRINT1 change intentional btw? Regards, Aleksey Bragin On 09.03.2015 21:08, akhaldi(a)svn.reactos.org wrote: > @@ -2920,7 +2975,7 @@ > HANDLE file; > DWORD len; > > - DPRINT( "looking for name=%S version=%u.%u.%u.%u arch=%S\n", > + DPRINT1( "looking for name=%S version=%u.%u.%u.%u arch=%S\n", > ai->name, ai->version.major, ai->version.minor, ai->version.build, ai->version.revision, ai->arch ); > > if ((status = lookup_winsxs(acl, ai)) != STATUS_NO_SUCH_FILE) return status; >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 66613: [WIN32K] Fix a typo
by Jerome Gardou 08 Mar '15

08 Mar '15

Hey Timo, Le 09/03/2015 00:36, tkreuzer(a)svn.reactos.org a écrit : > Author: tkreuzer > Date: Sun Mar 8 23:36:04 2015 > New Revision: 66613 > > URL: http://svn.reactos.org/svn/reactos?rev=66613&view=rev > Log: > [WIN32K] > Fix a typo > > Modified: > trunk/reactos/win32ss/gdi/eng/bitblt.c > > Modified: trunk/reactos/win32ss/gdi/eng/bitblt.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/eng/bitblt.c?r… > ============================================================================== > --- trunk/reactos/win32ss/gdi/eng/bitblt.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/eng/bitblt.c [iso-8859-1] Sun Mar 8 23:36:04 2015 > @@ -468,7 +468,7 @@ > if (psoMask == NULL) > { > /* We have no mask, assume the mask is all foreground */ > - rop4 &= (rop4 & 0xFF) || ((rop4 & 0xFF) << 8); > + rop4 = (rop4 & 0xFF) || ((rop4 & 0xFF) << 8); Looks dubious. Is equivalent to ((rop4 & 0xFF) != 0) > UsesMask = FALSE; > } > } > >

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
by daniel.reimer 06 Mar '15

06 Mar '15

Hii, Well... In theory the restructuring might be logical and maybe even a good idea to separate some of the DLL/win32 folder etc, but this can't be done as one man show. It breaks the patches in jira, breaks the stuff our devs might have locally and maybe someone has something to say to your plans.How to resolve this? Tbh, no clue. But a open discussion BEFORE commiting would be a start IMO. So guys, what now? Can we keep it or not? Greetings Daniel Von meinem Samsung Gerät gesendet. -------- Ursprüngliche Nachricht -------- Von: Hermès BÉLUSCA - MAÏTO <hermes.belusca(a)sfr.fr> Datum: 06.03.2015 12:03 (GMT+01:00) An: 'ReactOS Development List' <ros-dev(a)reactos.org> Betreff: Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM So... ... must I revert trunk pre-66575 ? Hermès. -----Message d'origine----- De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de Aleksey Bragin Envoyé : vendredi 6 mars 2015 10:48 À : ReactOS Development List Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM On 06.03.2015 2:58, Hermès BÉLUSCA - MAÏTO wrote: > Hi, > > So first, please receive my apologies for not having warned in ros-dev > about this (continuation of) tree restructure I did starting with > r66575. Indeed this was the first thing to do before doing anything, > even if I talked about that on IRC and JIRA! Wrong. You did not need to warn, you need to get majority of devs to support this change, to get comments from them, to make sure they continue to feel "at home" in ReactOS source code. Right now, for the sake of subjective beautification you just forced everyone but you to adapt their patches (myself included, I have many working copies) just because you feel the tree structure was wrong. This is just ridiculous. As Pierre said, we are a team here. And teamwork without big issues is what is making our project a good place to work in, to get pleasure and satisfaction from the work done. > In fact, the tree restructure discussion started 5 years ago, along > with the cmake bringup: see the big thread here: > http://www.reactos.org/pipermail/ros-dev/2010-July/013257.html . Imagine what, I was part of it. > At that > time the main argument was that we were also in the middle of changing > the old build system (rbuild) to a new one (cmake) so it was > problematic to do those two big changes at once. Also at that time, > seeing the argumentation of Ged, Timo, Jérôme and the few others > (active developers) who dared to participate to this discussion, it > was clear that a tree restructure was necessary anyway, sooner or later. This is called https://en.wikipedia.org/wiki/Post-purchase_rationalization . After you made the change you start explaining that everyone was supporting it, it was so much needed, and let's just forget about any side-effects it may have caused. > In 2012 some tree restructure happened (r56305) by moving around and > in a more logical manner some core components of win32. Yep. > What happens now in 2015, i.e. 5 years after ? We have CMake well > established, everything works, but only win32 core was reorganized. Sure, 5 years is a magic number which means you can safely ignore everyone else and just force your own change. > I made http://jira.reactos.org/browse/CORE-9111 , people started to > give proposals. You came back with the almost same argument, that is > to finish the existing things first (adapt that: at the time of CMake, > it was CMake, now, it's fix all ReactOS 0.4 bugs), and then improve > structure of source tree. Since not all the existing bugs will be > fixed by then, we can continue this way and wait another 5 years in order to have a real tree restructure? > I don't think so. > So I took that for granted and committed r66575. You know, users don't care about source code tree structure. Tree is for developers. Users (and hence, popularity and usability of ReactOS) like when ReactOS does not crash, when ReactOS runs their apps, when ReactOS loads native binary drivers. And my point is that internal changes (code refactorings, tree restructures, reformatting) must happen only when the advantage of that is more than the disadvantage/side effects. Are you going to say that ReactOS 0.4 is closer now because you restructured the tree according to your taste? Was there any urge to do the restructure? > Active developers really think (at least, myself) it's a pain in the > *** The key part: "myself". Let's face it: you silently ignored my opinion and decided not to ask anyone else. This is PITA, not the tree structure. > that when we code on some given module (example: shell), we need to > modify some bit of code in base/shell/whatever, some bit of code in > dll/win32/shell32, some bit of code here and there. All the code of > the shell should be tied together. This goes also for everything else: > the core of NT (kernel, ntdll, "base" drivers...), the win32 subsystem > (win32k; for it the change in r56305 started to make things more > logical: you would not have to modify code in some win32k/ directory > while also changing > dll/win32/gdi32 or dll/win32/user32 that were by the way amongst all > the rest of wine dlls, etc...) . It's not "more logical", it's just different logical approaches. > Because I didn't want to wait yet another 5 years I decided to start > something. Just remember, trunk is not your private branch. You have to take other devs opinion into account. And you are not always right. Sometimes even Alex Ionescu fails, though I must say it happens very rare. Get used to convince people. Remember Arwinss? Did I just delete the existing trunk win32ss back then? Imagine if I did? My reasoning was perfect, the subsystem was superior to trunk back then in many ways, and "I did not want to wait another 10 years for someone to finish trunk's win32ss". > OK my fault I would have to get a synthesis of the different proposals > of tree restructures I got, then put in ros-dev, then wait 1 month > until everybody starts to vote. Of course you would get people > thinking it's better to do à la Wine and sort the files by extension > type (that's what we almost have currently) and it was already > repeated that it is BAD because it doesn't translate the fact that > ROS/windows is built by modules; others would have thought it's nice > to have this piece of thing next to another one whereas this can be > postponed later on until the *obvious* parts of code have been properly packed together. Yes, unless I don't know something and suddenly all your ideas are absolutely true without the need for verification. Mine aren't, I always consult with other skilled people. > And because of that, here is my proposal: UNTIL details get fixed, I > propose > to: > - keep the /boot/, /include/, /lib/, /media/ and /tools/ directories > (as well as /cmake/ and the files in / ) untouched. > - ntoskrnl, ntdll and the drivers we have in /drivers/ (SAUF, the > multimedia > ones) go into some main "ntcore" directory (ntcore, ntos, call it > whatever you prefer. I'm inclined to the second name, but I'm ok with the first one). > - the keyboard layouts can be moved either to win32ss/ or to / (in > case we can give sense to keyboard layouts in "pure" NT, for example > when we run usetup, etc...) > - ok... my already-done (but revertable) modifs from 66575 (directory > renamings can be done, it's not set in stone). > - putting all printing support in some /win32/printsup (or > "printing"...) directory : that means: localspl, ntprint, printui, > spoolsv and spoolss, and winspool (so far...) Oh, now you shared your secret plan with us. Thank you so much! Actually, I would like to invent something better than just copying the NT source code tree layout. > That's what I'm 99.99% sure (and what I think is quite clear). > Concerning the rest (that can create discussion) I still keep it in old directories. ... > Regards, > Hermès. > > > > -----Message d'origine----- > De : Ros-dev [mailto:ros-dev-bounces@reactos.org] De la part de > Aleksey Bragin Envoyé : vendredi 6 mars 2015 00:15 À : > ros-dev(a)reactos.org Objet : Re: [ros-dev] [ros-diffs] [hbelusca] > 66575: Start source tree (final, I hope!) restructuration. Part 1/X > Win32, Shell, Services, MVDM > > Hermes, > > What the fuck, may I ask? > > I don't understand since when we started doing big changes in trunk > without talking (or listening) to anyone at all, just at your own discretion? > > Are you so sure the change is accepted by majority of our developers? > Did you get approval of those devs? Give them some respect which they > earned over years with their skills and commitment. > > I understand ReactOS is a very loosely managed project (to favor ease > of development), but totally ignoring everyone? > I checked CORE-9111 and I don't see any single comment from Timo, > Jerome, James, whoever else counts. > > Regards, > Aleksey Bragin > P.S. I'm not talking about actual changes, I'm talking about the > process and attitude. > > On 06.03.2015 2:03, hbelusca(a)svn.reactos.org wrote: >> Author: hbelusca >> Date: Thu Mar 5 23:03:33 2015 >> New Revision: 66575 >> >> URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev >> Log: >> Start source tree (final, I hope!) restructuration. Part 1/X Win32, >> Shell, Services, MVDM >> > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

7 7

GSoC :: application rejected
by Pierre Schweitzer 06 Mar '15

06 Mar '15

Dear all, The ReactOS Foundation application to GSoC has been rejected this year again. Statistics are not reliable after all. In any case, keep up the good work. We don't need Google to be the bests at what we do. Cheers, -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

8 10

Re: [ros-dev] [ros-diffs] [hbelusca] 66575: Start source tree (final, I hope!) restructuration. Part 1/X Win32, Shell, Services, MVDM
by Aleksey Bragin 06 Mar '15

06 Mar '15

Hermes, What the fuck, may I ask? I don't understand since when we started doing big changes in trunk without talking (or listening) to anyone at all, just at your own discretion? Are you so sure the change is accepted by majority of our developers? Did you get approval of those devs? Give them some respect which they earned over years with their skills and commitment. I understand ReactOS is a very loosely managed project (to favor ease of development), but totally ignoring everyone? I checked CORE-9111 and I don't see any single comment from Timo, Jerome, James, whoever else counts. Regards, Aleksey Bragin P.S. I'm not talking about actual changes, I'm talking about the process and attitude. On 06.03.2015 2:03, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Thu Mar 5 23:03:33 2015 > New Revision: 66575 > > URL: http://svn.reactos.org/svn/reactos?rev=66575&view=rev > Log: > Start source tree (final, I hope!) restructuration. Part 1/X > Win32, Shell, Services, MVDM >

6 7

Intel Edison + ReactOS
by Aleksey Bragin 06 Mar '15

06 Mar '15

Hi! I visited Intel's office in Moscow this week where I was given the brand new Intel Edison along with the Arduino-compatible prototype board. This story started by Alexander Rechitsky who brought all this to my attention, communicated with Novosibirsk's and Moscow's Intel staff and explained the ReactOS-on-Edison idea. Now I can get my hands on this board, and I invite everyone who's interested to play with it together. I am just getting started with it - the basics, like attaching serial output, etc. Some photos of this thing can be seen in my public Facebook album: https://www.facebook.com/media/set/?set=a.10204517582234470.1073741833.1080… Regards, Aleksey Bragin

5 4

Re: [ros-dev] [ros-diffs] [cwittich] 66547: [WLANAPI] add stubs for WlanQueryInterface and WlanGetInterfaceCapability
by Thomas Faber 03 Mar '15

03 Mar '15

On 2015-03-02 20:27, cwittich(a)svn.reactos.org wrote: > --- trunk/reactos/include/psdk/wlanapi.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/wlanapi.h [iso-8859-1] Mon Mar 2 19:27:45 2015 > @@ -24,7 +24,7 @@ > wlan_opcode_value_type_set_by_group_policy, > wlan_opcode_value_type_set_by_user, > wlan_opcode_value_type_invalid > -} WLAN_OPCODE_VALUE_TYPE; > +} WLAN_OPCODE_VALUE_TYPE; /* HACK: WIDL is broken , *PWLAN_OPCODE_VALUE_TYPE; */ > > typedef enum _WLAN_SECURABLE_OBJECT { > wlan_secure_permit_list = 0, What's broken, exactly? Let's see if we can get it fixed...

2 1

Re: [ros-dev] [ros-diffs] [akhaldi] 66551: [PSDK] Fix winternl.h version of SECTION_IMAGE_INFORMATION and add missing MEM_EXECUTE_OPTION_DISABLE_THUNK_EMULATION definition.
by Alex Ionescu 03 Mar '15

03 Mar '15

This is wintrnl.h which should match the Windows one. Make sure you're not accidentally adding fields that only NDK should have. Best regards, Alex Ionescu On Mon, Mar 2, 2015 at 3:38 PM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Mon Mar 2 23:38:49 2015 > New Revision: 66551 > > URL: http://svn.reactos.org/svn/reactos?rev=66551&view=rev > Log: > [PSDK] Fix winternl.h version of SECTION_IMAGE_INFORMATION and add missing > MEM_EXECUTE_OPTION_DISABLE_THUNK_EMULATION definition. > > Modified: > trunk/reactos/include/psdk/winternl.h > > Modified: trunk/reactos/include/psdk/winternl.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/winternl.h?re… > > ============================================================================== > --- trunk/reactos/include/psdk/winternl.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/winternl.h [iso-8859-1] Mon Mar 2 > 23:38:49 2015 > @@ -705,6 +705,7 @@ > > #define MEM_EXECUTE_OPTION_DISABLE 0x01 > #define MEM_EXECUTE_OPTION_ENABLE 0x02 > +#define MEM_EXECUTE_OPTION_DISABLE_THUNK_EMULATION 0x04 > #define MEM_EXECUTE_OPTION_PERMANENT 0x08 > > typedef enum _SECTION_INHERIT { > @@ -1685,23 +1686,28 @@ > } SECTION_INFORMATION_CLASS; > > typedef struct _SECTION_BASIC_INFORMATION { > - ULONG BaseAddress; > + PVOID BaseAddress; > ULONG Attributes; > LARGE_INTEGER Size; > } SECTION_BASIC_INFORMATION, *PSECTION_BASIC_INFORMATION; > > typedef struct _SECTION_IMAGE_INFORMATION { > - PVOID EntryPoint; > - ULONG StackZeroBits; > - ULONG StackReserved; > - ULONG StackCommit; > - ULONG ImageSubsystem; > + PVOID TransferAddress; > + ULONG ZeroBits; > + SIZE_T MaximumStackSize; > + SIZE_T CommittedStackSize; > + ULONG SubSystemType; > WORD SubsystemVersionLow; > WORD SubsystemVersionHigh; > - ULONG Unknown1; > + ULONG GpValue; > ULONG ImageCharacteristics; > - ULONG ImageMachineType; > - ULONG Unknown2[3]; > + USHORT DllCharacteristics; > + USHORT Machine; > + BOOLEAN ImageContainsCode; > + UCHAR ImageFlags; > + ULONG LoaderFlags; > + ULONG ImageFileSize; > + ULONG CheckSum; > } SECTION_IMAGE_INFORMATION, *PSECTION_IMAGE_INFORMATION; > > typedef struct _LPC_SECTION_WRITE { > > >

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 66511: [PCI] - Handle 64-bit PCI base address registers (BARs) - Fix maximum address in resource requirements for 20-bit resources - Fix flags on memory and I/O port resources [NTOS] - Fi...
by Alex Ionescu 03 Mar '15

03 Mar '15

Just make pcix work already Best regards, Alex Ionescu On Sat, Feb 28, 2015 at 11:52 PM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Sun Mar 1 07:52:32 2015 > New Revision: 66511 > > URL: http://svn.reactos.org/svn/reactos?rev=66511&view=rev > Log: > [PCI] > - Handle 64-bit PCI base address registers (BARs) > - Fix maximum address in resource requirements for 20-bit resources > - Fix flags on memory and I/O port resources > [NTOS] > - Fix handling of 64-bit resources > > Modified: > trunk/reactos/drivers/bus/pci/pdo.c > trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c > > Modified: trunk/reactos/drivers/bus/pci/pdo.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/bus/pci/pdo.c?rev=… > > ============================================================================== > --- trunk/reactos/drivers/bus/pci/pdo.c [iso-8859-1] (original) > +++ trunk/reactos/drivers/bus/pci/pdo.c [iso-8859-1] Sun Mar 1 07:52:32 > 2015 > @@ -21,6 +21,9 @@ > #define DBGPRINT(...) > #endif > > +#define PCI_ADDRESS_MEMORY_ADDRESS_MASK_64 0xfffffffffffffff0ull > +#define PCI_ADDRESS_IO_ADDRESS_MASK_64 0xfffffffffffffffcull > + > /*** PRIVATE > *****************************************************************/ > > static NTSTATUS > @@ -191,80 +194,159 @@ > return STATUS_SUCCESS; > } > > +static BOOLEAN > +PdoReadPciBar(PPDO_DEVICE_EXTENSION DeviceExtension, > + ULONG Offset, > + PULONG OriginalValue, > + PULONG NewValue) > +{ > + ULONG Size; > + ULONG AllOnes; > + > + /* Read the original value */ > + Size = HalGetBusDataByOffset(PCIConfiguration, > + DeviceExtension->PciDevice->BusNumber, > + > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > + OriginalValue, > + Offset, > + sizeof(ULONG)); > + if (Size != sizeof(ULONG)) > + { > + DPRINT1("Wrong size %lu\n", Size); > + return FALSE; > + } > + > + /* Write all ones to determine which bits are held to zero */ > + AllOnes = MAXULONG; > + Size = HalSetBusDataByOffset(PCIConfiguration, > + DeviceExtension->PciDevice->BusNumber, > + > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > + &AllOnes, > + Offset, > + sizeof(ULONG)); > + if (Size != sizeof(ULONG)) > + { > + DPRINT1("Wrong size %lu\n", Size); > + return FALSE; > + } > + > + /* Get the range length */ > + Size = HalGetBusDataByOffset(PCIConfiguration, > + DeviceExtension->PciDevice->BusNumber, > + > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > + NewValue, > + Offset, > + sizeof(ULONG)); > + if (Size != sizeof(ULONG)) > + { > + DPRINT1("Wrong size %lu\n", Size); > + return FALSE; > + } > + > + /* Restore original value */ > + Size = HalSetBusDataByOffset(PCIConfiguration, > + DeviceExtension->PciDevice->BusNumber, > + > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > + OriginalValue, > + Offset, > + sizeof(ULONG)); > + if (Size != sizeof(ULONG)) > + { > + DPRINT1("Wrong size %lu\n", Size); > + return FALSE; > + } > + > + return TRUE; > +} > > static BOOLEAN > PdoGetRangeLength(PPDO_DEVICE_EXTENSION DeviceExtension, > - ULONG Offset, > - PULONG Base, > - PULONG Length, > - PULONG Flags) > -{ > - ULONG OrigValue; > - ULONG BaseValue; > - ULONG NewValue; > - ULONG Size; > - ULONG XLength; > - > - /* Save original value */ > - Size= HalGetBusDataByOffset(PCIConfiguration, > - DeviceExtension->PciDevice->BusNumber, > - > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > - &OrigValue, > - Offset, > - sizeof(ULONG)); > - if (Size != sizeof(ULONG)) > - { > - DPRINT1("Wrong size %lu\n", Size); > + UCHAR Bar, > + PULONGLONG Base, > + PULONGLONG Length, > + PULONG Flags, > + PUCHAR NextBar, > + PULONGLONG MaximumAddress) > +{ > + union { > + struct { > + ULONG Bar0; > + ULONG Bar1; > + } Bars; > + ULONGLONG Bar; > + } OriginalValue; > + union { > + struct { > + ULONG Bar0; > + ULONG Bar1; > + } Bars; > + ULONGLONG Bar; > + } NewValue; > + ULONG Offset; > + > + /* Compute the offset of this BAR in PCI config space */ > + Offset = 0x10 + Bar * 4; > + > + /* Assume this is a 32-bit BAR until we find wrong */ > + *NextBar = Bar + 1; > + > + /* Initialize BAR values to zero */ > + OriginalValue.Bar = 0ULL; > + NewValue.Bar = 0ULL; > + > + /* Read the first BAR */ > + if (!PdoReadPciBar(DeviceExtension, Offset, > + &OriginalValue.Bars.Bar0, > + &NewValue.Bars.Bar0)) > + { > return FALSE; > } > - > - BaseValue = (OrigValue & PCI_ADDRESS_IO_SPACE) > - ? (OrigValue & PCI_ADDRESS_IO_ADDRESS_MASK) > - : (OrigValue & PCI_ADDRESS_MEMORY_ADDRESS_MASK); > - > - *Base = BaseValue; > - > - /* Set magic value */ > - NewValue = MAXULONG; > - Size= HalSetBusDataByOffset(PCIConfiguration, > - DeviceExtension->PciDevice->BusNumber, > - > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > - &NewValue, > - Offset, > - sizeof(ULONG)); > - if (Size != sizeof(ULONG)) > - { > - DPRINT1("Wrong size %lu\n", Size); > - return FALSE; > - } > - > - /* Get the range length */ > - Size= HalGetBusDataByOffset(PCIConfiguration, > - DeviceExtension->PciDevice->BusNumber, > - > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > - &NewValue, > - Offset, > - sizeof(ULONG)); > - if (Size != sizeof(ULONG)) > - { > - DPRINT1("Wrong size %lu\n", Size); > - return FALSE; > - } > - > - /* Restore original value */ > - Size= HalSetBusDataByOffset(PCIConfiguration, > - DeviceExtension->PciDevice->BusNumber, > - > DeviceExtension->PciDevice->SlotNumber.u.AsULONG, > - &OrigValue, > - Offset, > - sizeof(ULONG)); > - if (Size != sizeof(ULONG)) > - { > - DPRINT1("Wrong size %lu\n", Size); > - return FALSE; > - } > - > - if (NewValue == 0) > + > + /* Check if this is a memory BAR */ > + if (!(OriginalValue.Bars.Bar0 & PCI_ADDRESS_IO_SPACE)) > + { > + /* Write the maximum address if the caller asked for it */ > + if (MaximumAddress != NULL) > + { > + if ((OriginalValue.Bars.Bar0 & PCI_ADDRESS_MEMORY_TYPE_MASK) > == PCI_TYPE_32BIT) > + { > + *MaximumAddress = 0x00000000FFFFFFFFULL; > + } > + else if ((OriginalValue.Bars.Bar0 & > PCI_ADDRESS_MEMORY_TYPE_MASK) == PCI_TYPE_20BIT) > + { > + *MaximumAddress = 0x00000000000FFFFFULL; > + } > + else if ((OriginalValue.Bars.Bar0 & > PCI_ADDRESS_MEMORY_TYPE_MASK) == PCI_TYPE_64BIT) > + { > + *MaximumAddress = 0xFFFFFFFFFFFFFFFFULL; > + } > + } > + > + /* Check if this is a 64-bit BAR */ > + if ((OriginalValue.Bars.Bar0 & PCI_ADDRESS_MEMORY_TYPE_MASK) == > PCI_TYPE_64BIT) > + { > + /* We've now consumed the next BAR too */ > + *NextBar = Bar + 2; > + > + /* Read the next BAR */ > + if (!PdoReadPciBar(DeviceExtension, Offset + 4, > + &OriginalValue.Bars.Bar1, > + &NewValue.Bars.Bar1)) > + { > + return FALSE; > + } > + } > + } > + else > + { > + /* Write the maximum I/O port address */ > + if (MaximumAddress != NULL) > + { > + *MaximumAddress = 0x00000000FFFFFFFFULL; > + } > + } > + > + if (NewValue.Bar == 0) > { > DPRINT("Unused address register\n"); > *Base = 0; > @@ -272,48 +354,16 @@ > *Flags = 0; > return TRUE; > } > - > - XLength = ~((NewValue & PCI_ADDRESS_IO_SPACE) > - ? (NewValue & PCI_ADDRESS_IO_ADDRESS_MASK) > - : (NewValue & PCI_ADDRESS_MEMORY_ADDRESS_MASK)) + 1; > - > -#if 0 > - DbgPrint("BaseAddress 0x%08lx Length 0x%08lx", > - BaseValue, XLength); > - > - if (NewValue & PCI_ADDRESS_IO_SPACE) > - { > - DbgPrint(" IO range"); > - } > - else > - { > - DbgPrint(" Memory range"); > - if ((NewValue & PCI_ADDRESS_MEMORY_TYPE_MASK) == 0) > - { > - DbgPrint(" in 32-Bit address space"); > - } > - else if ((NewValue & PCI_ADDRESS_MEMORY_TYPE_MASK) == 2) > - { > - DbgPrint(" below 1BM "); > - } > - else if ((NewValue & PCI_ADDRESS_MEMORY_TYPE_MASK) == 4) > - { > - DbgPrint(" in 64-Bit address space"); > - } > - > - if (NewValue & PCI_ADDRESS_MEMORY_PREFETCHABLE) > - { > - DbgPrint(" prefetchable"); > - } > - } > - > - DbgPrint("\n"); > -#endif > - > - *Length = XLength; > - *Flags = (NewValue & PCI_ADDRESS_IO_SPACE) > - ? (NewValue & ~PCI_ADDRESS_IO_ADDRESS_MASK) > - : (NewValue & ~PCI_ADDRESS_MEMORY_ADDRESS_MASK); > + > + *Base = OriginalValue.Bar & PCI_ADDRESS_MEMORY_ADDRESS_MASK_64; > + > + *Length = ~((NewValue.Bar & PCI_ADDRESS_IO_SPACE) > + ? (NewValue.Bar & PCI_ADDRESS_IO_ADDRESS_MASK_64) > + : (NewValue.Bar & PCI_ADDRESS_MEMORY_ADDRESS_MASK_64)) + > 1; > + > + *Flags = (NewValue.Bar & PCI_ADDRESS_IO_SPACE) > + ? (NewValue.Bar & ~PCI_ADDRESS_IO_ADDRESS_MASK_64) > + : (NewValue.Bar & ~PCI_ADDRESS_MEMORY_ADDRESS_MASK_64); > > return TRUE; > } > @@ -332,10 +382,11 @@ > ULONG Size; > ULONG ResCount = 0; > ULONG ListSize; > - ULONG i; > - ULONG Base; > - ULONG Length; > + UCHAR Bar; > + ULONGLONG Base; > + ULONGLONG Length; > ULONG Flags; > + ULONGLONG MaximumAddress; > > UNREFERENCED_PARAMETER(IrpSp); > DPRINT("PdoQueryResourceRequirements() called\n"); > @@ -361,13 +412,15 @@ > ResCount = 0; > if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_DEVICE_TYPE) > { > - for (i = 0; i < PCI_TYPE0_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE0_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + NULL)) > break; > > if (Length != 0) > @@ -381,13 +434,15 @@ > } > else if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_BRIDGE_TYPE) > { > - for (i = 0; i < PCI_TYPE1_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE1_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + NULL)) > break; > > if (Length != 0) > @@ -442,13 +497,15 @@ > Descriptor = &ResourceList->List[0].Descriptors[0]; > if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_DEVICE_TYPE) > { > - for (i = 0; i < PCI_TYPE0_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE0_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + &MaximumAddress)) > { > DPRINT1("PdoGetRangeLength() failed\n"); > break; > @@ -472,19 +529,20 @@ > > Descriptor->u.Port.Length = Length; > Descriptor->u.Port.Alignment = 1; > - Descriptor->u.Port.MinimumAddress.QuadPart = > (ULONGLONG)Base; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)(Base + Length - 1); > + Descriptor->u.Port.MinimumAddress.QuadPart = Base; > + Descriptor->u.Port.MaximumAddress.QuadPart = Base + > Length - 1; > } > else > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > > Descriptor->u.Memory.Length = Length; > Descriptor->u.Memory.Alignment = 1; > - Descriptor->u.Memory.MinimumAddress.QuadPart = > (ULONGLONG)Base; > - Descriptor->u.Memory.MaximumAddress.QuadPart = > (ULONGLONG)(Base + Length - 1); > + Descriptor->u.Memory.MinimumAddress.QuadPart = Base; > + Descriptor->u.Memory.MaximumAddress.QuadPart = Base + > Length - 1; > } > Descriptor++; > > @@ -500,19 +558,20 @@ > > Descriptor->u.Port.Length = Length; > Descriptor->u.Port.Alignment = Length; > - Descriptor->u.Port.MinimumAddress.QuadPart = (ULONGLONG)0; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)0x00000000FFFFFFFF; > + Descriptor->u.Port.MinimumAddress.QuadPart = 0; > + Descriptor->u.Port.MaximumAddress.QuadPart = > MaximumAddress; > } > else > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > > Descriptor->u.Memory.Length = Length; > Descriptor->u.Memory.Alignment = Length; > - Descriptor->u.Port.MinimumAddress.QuadPart = (ULONGLONG)0; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)0x00000000FFFFFFFF; > + Descriptor->u.Port.MinimumAddress.QuadPart = 0; > + Descriptor->u.Port.MaximumAddress.QuadPart = > MaximumAddress; > } > Descriptor++; > } > @@ -532,13 +591,15 @@ > } > else if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_BRIDGE_TYPE) > { > - for (i = 0; i < PCI_TYPE1_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE1_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + &MaximumAddress)) > { > DPRINT1("PdoGetRangeLength() failed\n"); > break; > @@ -562,19 +623,20 @@ > > Descriptor->u.Port.Length = Length; > Descriptor->u.Port.Alignment = 1; > - Descriptor->u.Port.MinimumAddress.QuadPart = > (ULONGLONG)Base; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)(Base + Length - 1); > + Descriptor->u.Port.MinimumAddress.QuadPart = Base; > + Descriptor->u.Port.MaximumAddress.QuadPart = Base + > Length - 1; > } > else > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > > Descriptor->u.Memory.Length = Length; > Descriptor->u.Memory.Alignment = 1; > - Descriptor->u.Memory.MinimumAddress.QuadPart = > (ULONGLONG)Base; > - Descriptor->u.Memory.MaximumAddress.QuadPart = > (ULONGLONG)(Base + Length - 1); > + Descriptor->u.Memory.MinimumAddress.QuadPart = Base; > + Descriptor->u.Memory.MaximumAddress.QuadPart = Base + > Length - 1; > } > Descriptor++; > > @@ -590,19 +652,20 @@ > > Descriptor->u.Port.Length = Length; > Descriptor->u.Port.Alignment = Length; > - Descriptor->u.Port.MinimumAddress.QuadPart = (ULONGLONG)0; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)0x00000000FFFFFFFF; > + Descriptor->u.Port.MinimumAddress.QuadPart = 0; > + Descriptor->u.Port.MaximumAddress.QuadPart = > MaximumAddress; > } > else > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > > Descriptor->u.Memory.Length = Length; > Descriptor->u.Memory.Alignment = Length; > - Descriptor->u.Port.MinimumAddress.QuadPart = (ULONGLONG)0; > - Descriptor->u.Port.MaximumAddress.QuadPart = > (ULONGLONG)0x00000000FFFFFFFF; > + Descriptor->u.Port.MinimumAddress.QuadPart = 0; > + Descriptor->u.Port.MaximumAddress.QuadPart = > MaximumAddress; > } > Descriptor++; > } > @@ -645,9 +708,9 @@ > ULONG Size; > ULONG ResCount = 0; > ULONG ListSize; > - ULONG i; > - ULONG Base; > - ULONG Length; > + UCHAR Bar; > + ULONGLONG Base; > + ULONGLONG Length; > ULONG Flags; > > DPRINT("PdoQueryResources() called\n"); > @@ -674,13 +737,15 @@ > ResCount = 0; > if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_DEVICE_TYPE) > { > - for (i = 0; i < PCI_TYPE0_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE0_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + NULL)) > break; > > if (Length) > @@ -694,13 +759,15 @@ > } > else if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_BRIDGE_TYPE) > { > - for (i = 0; i < PCI_TYPE1_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE1_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > + &Flags, > + &Bar, > + NULL)) > break; > > if (Length != 0) > @@ -749,17 +816,16 @@ > Descriptor = &PartialList->PartialDescriptors[0]; > if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_DEVICE_TYPE) > { > - for (i = 0; i < PCI_TYPE0_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE0_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > - { > - DPRINT1("PdoGetRangeLength() failed\n"); > + &Flags, > + &Bar, > + NULL)) > break; > - } > > if (Length == 0) > { > @@ -771,7 +837,9 @@ > { > Descriptor->Type = CmResourceTypePort; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_PORT_IO; > + Descriptor->Flags = CM_RESOURCE_PORT_IO | > + CM_RESOURCE_PORT_16_BIT_DECODE | > + CM_RESOURCE_PORT_POSITIVE_DECODE; > Descriptor->u.Port.Start.QuadPart = (ULONGLONG)Base; > Descriptor->u.Port.Length = Length; > > @@ -782,7 +850,8 @@ > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > Descriptor->u.Memory.Start.QuadPart = (ULONGLONG)Base; > Descriptor->u.Memory.Length = Length; > > @@ -811,17 +880,16 @@ > } > else if (PCI_CONFIGURATION_TYPE(&PciConfig) == PCI_BRIDGE_TYPE) > { > - for (i = 0; i < PCI_TYPE1_ADDRESSES; i++) > + for (Bar = 0; Bar < PCI_TYPE1_ADDRESSES;) > { > if (!PdoGetRangeLength(DeviceExtension, > - 0x10 + i * 4, > + Bar, > &Base, > &Length, > - &Flags)) > - { > - DPRINT1("PdoGetRangeLength() failed\n"); > + &Flags, > + &Bar, > + NULL)) > break; > - } > > if (Length == 0) > { > @@ -833,7 +901,9 @@ > { > Descriptor->Type = CmResourceTypePort; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_PORT_IO; > + Descriptor->Flags = CM_RESOURCE_PORT_IO | > + CM_RESOURCE_PORT_16_BIT_DECODE | > + CM_RESOURCE_PORT_POSITIVE_DECODE; > Descriptor->u.Port.Start.QuadPart = (ULONGLONG)Base; > Descriptor->u.Port.Length = Length; > > @@ -844,7 +914,8 @@ > { > Descriptor->Type = CmResourceTypeMemory; > Descriptor->ShareDisposition = > CmResourceShareDeviceExclusive; > - Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE; > + Descriptor->Flags = CM_RESOURCE_MEMORY_READ_WRITE | > + (Flags & PCI_ADDRESS_MEMORY_PREFETCHABLE) ? > CM_RESOURCE_MEMORY_PREFETCHABLE : 0; > Descriptor->u.Memory.Start.QuadPart = (ULONGLONG)Base; > Descriptor->u.Memory.Length = Length; > > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpres.c [iso-8859-1] Sun Mar 1 > 07:52:32 2015 > @@ -73,7 +73,7 @@ > IN PIO_RESOURCE_DESCRIPTOR IoDesc, > OUT PCM_PARTIAL_RESOURCE_DESCRIPTOR CmDesc) > { > - LONGLONG Start; > + ULONGLONG Start; > CM_PARTIAL_RESOURCE_DESCRIPTOR ConflictingDesc; > > ASSERT(IoDesc->Type == CmDesc->Type); > @@ -82,16 +82,16 @@ > /* HACK */ > if (IoDesc->u.Memory.Alignment == 0) IoDesc->u.Memory.Alignment = 1; > > - for (Start = IoDesc->u.Memory.MinimumAddress.QuadPart; > - Start <= IoDesc->u.Memory.MaximumAddress.QuadPart - > IoDesc->u.Memory.Length + 1; > + for (Start = (ULONGLONG)IoDesc->u.Memory.MinimumAddress.QuadPart; > + Start <= (ULONGLONG)IoDesc->u.Memory.MaximumAddress.QuadPart - > IoDesc->u.Memory.Length + 1; > Start += IoDesc->u.Memory.Alignment) > { > CmDesc->u.Memory.Length = IoDesc->u.Memory.Length; > - CmDesc->u.Memory.Start.QuadPart = Start; > + CmDesc->u.Memory.Start.QuadPart = (LONGLONG)Start; > > if (IopCheckDescriptorForConflict(CmDesc, &ConflictingDesc)) > { > - Start += ConflictingDesc.u.Memory.Start.QuadPart + > + Start += (ULONGLONG)ConflictingDesc.u.Memory.Start.QuadPart + > ConflictingDesc.u.Memory.Length; > } > else > @@ -110,7 +110,7 @@ > IN PIO_RESOURCE_DESCRIPTOR IoDesc, > OUT PCM_PARTIAL_RESOURCE_DESCRIPTOR CmDesc) > { > - LONGLONG Start; > + ULONGLONG Start; > CM_PARTIAL_RESOURCE_DESCRIPTOR ConflictingDesc; > > ASSERT(IoDesc->Type == CmDesc->Type); > @@ -119,16 +119,16 @@ > /* HACK */ > if (IoDesc->u.Port.Alignment == 0) IoDesc->u.Port.Alignment = 1; > > - for (Start = IoDesc->u.Port.MinimumAddress.QuadPart; > - Start <= IoDesc->u.Port.MaximumAddress.QuadPart - > IoDesc->u.Port.Length + 1; > + for (Start = (ULONGLONG)IoDesc->u.Port.MinimumAddress.QuadPart; > + Start <= (ULONGLONG)IoDesc->u.Port.MaximumAddress.QuadPart - > IoDesc->u.Port.Length + 1; > Start += IoDesc->u.Port.Alignment) > { > CmDesc->u.Port.Length = IoDesc->u.Port.Length; > - CmDesc->u.Port.Start.QuadPart = Start; > + CmDesc->u.Port.Start.QuadPart = (LONGLONG)Start; > > if (IopCheckDescriptorForConflict(CmDesc, &ConflictingDesc)) > { > - Start += ConflictingDesc.u.Port.Start.QuadPart + > ConflictingDesc.u.Port.Length; > + Start += (ULONGLONG)ConflictingDesc.u.Port.Start.QuadPart + > ConflictingDesc.u.Port.Length; > } > else > { > @@ -300,8 +300,8 @@ > case CmResourceTypePort: > /* Make sure the length matches and it satisfies > our address range */ > if (CmDesc->u.Memory.Length == > IoDesc->u.Memory.Length && > - CmDesc->u.Memory.Start.QuadPart >= > IoDesc->u.Memory.MinimumAddress.QuadPart && > - CmDesc->u.Memory.Start.QuadPart + > CmDesc->u.Memory.Length - 1 <= IoDesc->u.Memory.MaximumAddress.QuadPart) > + (ULONGLONG)CmDesc->u.Memory.Start.QuadPart >= > (ULONGLONG)IoDesc->u.Memory.MinimumAddress.QuadPart && > + (ULONGLONG)CmDesc->u.Memory.Start.QuadPart + > CmDesc->u.Memory.Length - 1 <= > (ULONGLONG)IoDesc->u.Memory.MaximumAddress.QuadPart) > { > /* Found it */ > Matched = TRUE; > @@ -564,11 +564,11 @@ > switch (ResDesc->Type) > { > case CmResourceTypeMemory: > - if ((ResDesc->u.Memory.Start.QuadPart < > ResDesc2->u.Memory.Start.QuadPart && > - ResDesc->u.Memory.Start.QuadPart + > ResDesc->u.Memory.Length > > - ResDesc2->u.Memory.Start.QuadPart) || > (ResDesc2->u.Memory.Start.QuadPart < > - ResDesc->u.Memory.Start.QuadPart && > ResDesc2->u.Memory.Start.QuadPart + > - ResDesc2->u.Memory.Length > > ResDesc->u.Memory.Start.QuadPart)) > + if (((ULONGLONG)ResDesc->u.Memory.Start.QuadPart < > (ULONGLONG)ResDesc2->u.Memory.Start.QuadPart && > + (ULONGLONG)ResDesc->u.Memory.Start.QuadPart + > ResDesc->u.Memory.Length > > + (ULONGLONG)ResDesc2->u.Memory.Start.QuadPart) || > ((ULONGLONG)ResDesc2->u.Memory.Start.QuadPart < > + (ULONGLONG)ResDesc->u.Memory.Start.QuadPart && > (ULONGLONG)ResDesc2->u.Memory.Start.QuadPart + > + ResDesc2->u.Memory.Length > > (ULONGLONG)ResDesc->u.Memory.Start.QuadPart)) > { > if (!Silent) > { > @@ -585,11 +585,11 @@ > break; > > case CmResourceTypePort: > - if ((ResDesc->u.Port.Start.QuadPart < > ResDesc2->u.Port.Start.QuadPart && > - ResDesc->u.Port.Start.QuadPart + > ResDesc->u.Port.Length > > - ResDesc2->u.Port.Start.QuadPart) || > (ResDesc2->u.Port.Start.QuadPart < > - ResDesc->u.Port.Start.QuadPart && > ResDesc2->u.Port.Start.QuadPart + > - ResDesc2->u.Port.Length > > ResDesc->u.Port.Start.QuadPart)) > + if (((ULONGLONG)ResDesc->u.Port.Start.QuadPart < > (ULONGLONG)ResDesc2->u.Port.Start.QuadPart && > + (ULONGLONG)ResDesc->u.Port.Start.QuadPart + > ResDesc->u.Port.Length > > + (ULONGLONG)ResDesc2->u.Port.Start.QuadPart) || > ((ULONGLONG)ResDesc2->u.Port.Start.QuadPart < > + (ULONGLONG)ResDesc->u.Port.Start.QuadPart && > (ULONGLONG)ResDesc2->u.Port.Start.QuadPart + > + ResDesc2->u.Port.Length > > (ULONGLONG)ResDesc->u.Port.Start.QuadPart)) > { > if (!Silent) > { > > >

1 0

Windows Server 2003 Testbot is live!
by Colin Finck 02 Mar '15

02 Mar '15

Hi all, After a long, long time, we finally have a Testbot regularly running our Wine tests and API tests under our target platform Windows Server 2003. The VM is actually based on Windows Home Server, which is a cheap Windows Server 2003 SP2 edition. The first successful test results are here: https://reactos.org/sites/all/modules/reactos/testman/compare.php?ids=34839 Okay, I have to admit this already required manual intervention. Test msi:install reproducibly hangs with the error message "The process cannot access the file because another process has locked a portion of the file". I expect all of this to still need some tweaking here and there. Please reply to this mail with all your tweaking suggestions and I see what I can do. Have fun, Colin

3 3

Re: [ros-dev] [ros-diffs] [hbelusca] 66538: [SHLWAPI]: Remove some Wine madness. CORE-8936.
by Thomas Faber 02 Mar '15

02 Mar '15

Hmm what's the point of this? If it doesn't break anything, let's not create a ROS-diff? On 2015-03-02 02:15, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Mon Mar 2 01:15:00 2015 > New Revision: 66538 > > URL: http://svn.reactos.org/svn/reactos?rev=66538&view=rev > Log: > [SHLWAPI]: Remove some Wine madness. CORE-8936. > > Modified: > trunk/reactos/dll/win32/shlwapi/path.c > > Modified: trunk/reactos/dll/win32/shlwapi/path.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shlwapi/path.c?r… > ============================================================================== > --- trunk/reactos/dll/win32/shlwapi/path.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shlwapi/path.c [iso-8859-1] Mon Mar 2 01:15:00 2015 > @@ -21,22 +21,7 @@ > > #include "precomp.h" > > -/* Get a function pointer from a DLL handle */ > -#define GET_FUNC(func, module, name, fail) \ > - do { \ > - if (!func) { \ > - if (!SHLWAPI_h##module && !(SHLWAPI_h##module = LoadLibraryA(#module ".dll"))) return fail; \ > - func = (fn##func)GetProcAddress(SHLWAPI_h##module, name); \ > - if (!func) return fail; \ > - } \ > - } while (0) > - > -/* DLL handles for late bound calls */ > -static HMODULE SHLWAPI_hshell32; > - > -/* Function pointers for GET_FUNC macro; these need to be global because of gcc bug */ > -typedef BOOL (WINAPI *fnpIsNetDrive)(int); > -static fnpIsNetDrive pIsNetDrive; > +int WINAPI IsNetDrive(int drive); > > HRESULT WINAPI SHGetWebFolderFilePathW(LPCWSTR,LPWSTR,DWORD); > > @@ -3699,8 +3684,7 @@ > dwDriveNum = PathGetDriveNumberA(lpszPath); > if (dwDriveNum == -1) > return FALSE; > - GET_FUNC(pIsNetDrive, shell32, (LPCSTR)66, FALSE); /* ord 66 = shell32.IsNetDrive */ > - return pIsNetDrive(dwDriveNum); > + return IsNetDrive(dwDriveNum); > } > > /************************************************************************* > @@ -3721,8 +3705,7 @@ > dwDriveNum = PathGetDriveNumberW(lpszPath); > if (dwDriveNum == -1) > return FALSE; > - GET_FUNC(pIsNetDrive, shell32, (LPCSTR)66, FALSE); /* ord 66 = shell32.IsNetDrive */ > - return pIsNetDrive(dwDriveNum); > + return IsNetDrive(dwDriveNum); > } > > /************************************************************************* > >

1 0

Cant log in jira
by Alexander Rechitskiy 01 Mar '15

01 Mar '15

3 2

Re: [ros-dev] [ros-diffs] [akhaldi] 66500: [KERNEL32_VISTA] Add and export InitOnceExecuteOnce(). CORE-9246
by Alex Ionescu 28 Feb '15

28 Feb '15

Why are we adding Wineisms to core binaries like kernel32? These functions should be in NTDLL and not in kernel32, and they are badly written anyway. Best regards, Alex Ionescu On Sat, Feb 28, 2015 at 10:46 AM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Sat Feb 28 15:46:43 2015 > New Revision: 66500 > > URL: http://svn.reactos.org/svn/reactos?rev=66500&view=rev > Log: > [KERNEL32_VISTA] Add and export InitOnceExecuteOnce(). CORE-9246 > > Added: > trunk/reactos/dll/win32/kernel32_vista/InitOnceExecuteOnce.c (with > props) > Modified: > trunk/reactos/dll/win32/kernel32_vista/CMakeLists.txt > trunk/reactos/dll/win32/kernel32_vista/kernel32_vista.spec > > Modified: trunk/reactos/dll/win32/kernel32_vista/CMakeLists.txt > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32_vista/C… > > ============================================================================== > --- trunk/reactos/dll/win32/kernel32_vista/CMakeLists.txt > [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32_vista/CMakeLists.txt > [iso-8859-1] Sat Feb 28 15:46:43 2015 > @@ -8,15 +8,11 @@ > list(APPEND SOURCE > DllMain.c > GetTickCount64.c > + InitOnceExecuteOnce.c > ${CMAKE_CURRENT_BINARY_DIR}/kernel32_vista.def) > > add_library(kernel32_vista SHARED ${SOURCE}) > set_module_type(kernel32_vista win32dll HOTPATCHABLE ENTRYPOINT DllMain > 12) > -add_importlibs(kernel32_vista kernel32) > - > -if(MSVC) > - add_importlibs(kernel32_vista ntdll) > -endif() > - > +add_importlibs(kernel32_vista kernel32 ntdll) > add_dependencies(kernel32_vista psdk) > add_cd_file(TARGET kernel32_vista DESTINATION reactos/system32 FOR all) > > Added: trunk/reactos/dll/win32/kernel32_vista/InitOnceExecuteOnce.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32_vista/I… > > ============================================================================== > --- trunk/reactos/dll/win32/kernel32_vista/InitOnceExecuteOnce.c > (added) > +++ trunk/reactos/dll/win32/kernel32_vista/InitOnceExecuteOnce.c > [iso-8859-1] Sat Feb 28 15:46:43 2015 > @@ -0,0 +1,118 @@ > + > +#include "k32_vista.h" > + > +#include <ndk/exfuncs.h> > +#include <wine/config.h> > +#include <wine/port.h> > + > +/* Taken from Wine ntdll/sync.c */ > + > +HANDLE keyed_event = NULL; > + > +static DWORD WINAPI RtlRunOnceBeginInitialize( RTL_RUN_ONCE *once, ULONG > flags, void **context ) > +{ > + if (flags & RTL_RUN_ONCE_CHECK_ONLY) > + { > + ULONG_PTR val = (ULONG_PTR)once->Ptr; > + > + if (flags & RTL_RUN_ONCE_ASYNC) return STATUS_INVALID_PARAMETER; > + if ((val & 3) != 2) return STATUS_UNSUCCESSFUL; > + if (context) *context = (void *)(val & ~3); > + return STATUS_SUCCESS; > + } > + > + for (;;) > + { > + ULONG_PTR next, val = (ULONG_PTR)once->Ptr; > + > + switch (val & 3) > + { > + case 0: /* first time */ > + if (!interlocked_cmpxchg_ptr( &once->Ptr, > + (flags & RTL_RUN_ONCE_ASYNC) ? > (void *)3 : (void *)1, 0 )) > + return STATUS_PENDING; > + break; > + > + case 1: /* in progress, wait */ > + if (flags & RTL_RUN_ONCE_ASYNC) return > STATUS_INVALID_PARAMETER; > + next = val & ~3; > + if (interlocked_cmpxchg_ptr( &once->Ptr, (void > *)((ULONG_PTR)&next | 1), > + (void *)val ) == (void *)val) > + NtWaitForKeyedEvent( keyed_event, &next, FALSE, NULL ); > + break; > + > + case 2: /* done */ > + if (context) *context = (void *)(val & ~3); > + return STATUS_SUCCESS; > + > + case 3: /* in progress, async */ > + if (!(flags & RTL_RUN_ONCE_ASYNC)) return > STATUS_INVALID_PARAMETER; > + return STATUS_PENDING; > + } > + } > +} > + > +static DWORD WINAPI RtlpRunOnceComplete( RTL_RUN_ONCE *once, ULONG flags, > void *context ) > +{ > + if ((ULONG_PTR)context & 3) return STATUS_INVALID_PARAMETER; > + > + if (flags & RTL_RUN_ONCE_INIT_FAILED) > + { > + if (context) return STATUS_INVALID_PARAMETER; > + if (flags & RTL_RUN_ONCE_ASYNC) return STATUS_INVALID_PARAMETER; > + } > + else context = (void *)((ULONG_PTR)context | 2); > + > + for (;;) > + { > + ULONG_PTR val = (ULONG_PTR)once->Ptr; > + > + switch (val & 3) > + { > + case 1: /* in progress */ > + if (interlocked_cmpxchg_ptr( &once->Ptr, context, (void *)val > ) != (void *)val) break; > + val &= ~3; > + while (val) > + { > + ULONG_PTR next = *(ULONG_PTR *)val; > + NtReleaseKeyedEvent( keyed_event, (void *)val, FALSE, > NULL ); > + val = next; > + } > + return STATUS_SUCCESS; > + > + case 3: /* in progress, async */ > + if (!(flags & RTL_RUN_ONCE_ASYNC)) return > STATUS_INVALID_PARAMETER; > + if (interlocked_cmpxchg_ptr( &once->Ptr, context, (void *)val > ) != (void *)val) break; > + return STATUS_SUCCESS; > + > + default: > + return STATUS_UNSUCCESSFUL; > + } > + } > +} > + > +static DWORD WINAPI RtlpRunOnceExecuteOnce( RTL_RUN_ONCE *once, > PRTL_RUN_ONCE_INIT_FN func, > + void *param, void **context ) > +{ > + DWORD ret = RtlRunOnceBeginInitialize( once, 0, context ); > + > + if (ret != STATUS_PENDING) return ret; > + > + if (!func( once, param, context )) > + { > + RtlpRunOnceComplete( once, RTL_RUN_ONCE_INIT_FAILED, NULL ); > + return STATUS_UNSUCCESSFUL; > + } > + > + return RtlpRunOnceComplete( once, 0, context ? *context : NULL ); > +} > + > +/* Taken from Wine kernel32/sync.c */ > + > +/* > + * @implemented > + */ > +BOOL NTAPI InitOnceExecuteOnce( INIT_ONCE *once, PINIT_ONCE_FN func, void > *param, void **context ) > +{ > + return !RtlpRunOnceExecuteOnce( once, (PRTL_RUN_ONCE_INIT_FN)func, > param, context ); > +} > > Propchange: trunk/reactos/dll/win32/kernel32_vista/InitOnceExecuteOnce.c > > ------------------------------------------------------------------------------ > svn:eol-style = native > > Modified: trunk/reactos/dll/win32/kernel32_vista/kernel32_vista.spec > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32_vista/k… > > ============================================================================== > --- trunk/reactos/dll/win32/kernel32_vista/kernel32_vista.spec > [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32_vista/kernel32_vista.spec > [iso-8859-1] Sat Feb 28 15:46:43 2015 > @@ -1,2 +1,3 @@ > > @ stdcall -ret64 GetTickCount64() > +@ stdcall InitOnceExecuteOnce(ptr ptr ptr ptr) > > >

3 3

New Patchbot
by Colin Finck 27 Feb '15

27 Feb '15

Hi all, Based on Hermès' suggestion, I've transformed our Debug-Buildbot "Trunk_x86_GCCLin Debug" into a Patchbot. That means, it will continue to build each SVN revision as usual, but you can also force a build and enter a patch ID. Your build will then be patched accordingly. After building and testing, you will have: * The patched regtest ISO at http://iso.reactos.org/regtestcd/ * A test result in Testman with source "Patched Trunk_x86_GCCLin (KVM)" These changes will be applied to the other Buildslaves too once our servers are all back up. Cheers, Colin

3 2

Re: [ros-dev] [ros-diffs] [gadamopoulos] 66457: [USER32] - button.c: Use NtUserAlterWindowStyle where wine uses WIN_SetStyle (usage and parameters were confirmed with windbg) [NTUSER] - Implement NtUserAlterWindowStyle. Fix...
by Timo Kreuzer 26 Feb '15

26 Feb '15

Why don't we use a macro or wrapper function, unstead of hacking shared code everywhere? Am 25.02.2015 um 21:02 schrieb gadamopoulos(a)svn.reactos.org: > Author: gadamopoulos > Date: Wed Feb 25 20:02:10 2015 > New Revision: 66457 > > URL: http://svn.reactos.org/svn/reactos?rev=66457&view=rev > Log: > [USER32] > - button.c: Use NtUserAlterWindowStyle where wine uses WIN_SetStyle (usage and parameters were confirmed with windbg) > > [NTUSER] > - Implement NtUserAlterWindowStyle. > > Fixes remaining failures in user32:msg_controls test. > > Modified: > trunk/reactos/win32ss/user/ntuser/ntstubs.c > trunk/reactos/win32ss/user/ntuser/window.c > trunk/reactos/win32ss/user/user32/controls/button.c > > Modified: trunk/reactos/win32ss/user/ntuser/ntstubs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/ntstub… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/ntstubs.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/ntstubs.c [iso-8859-1] Wed Feb 25 20:02:10 2015 > @@ -1157,19 +1157,6 @@ > return 0; > } > > -/* > - * @unimplemented > - */ > -DWORD APIENTRY > -NtUserAlterWindowStyle(DWORD Unknown0, > - DWORD Unknown1, > - DWORD Unknown2) > -{ > - STUB > - > - return(0); > -} > - > BOOL APIENTRY NtUserAddClipboardFormatListener( > HWND hwnd > ) > > Modified: trunk/reactos/win32ss/user/ntuser/window.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/window… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/window.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/window.c [iso-8859-1] Wed Feb 25 20:02:10 2015 > @@ -3537,8 +3537,8 @@ > return FALSE; > } > > -LONG FASTCALL > -co_UserSetWindowLong(HWND hWnd, DWORD Index, LONG NewValue, BOOL Ansi) > +static LONG > +co_IntSetWindowLong(HWND hWnd, DWORD Index, LONG NewValue, BOOL Ansi, BOOL bAlter) > { > PWND Window, Parent; > PWINSTATION_OBJECT WindowStation; > @@ -3597,6 +3597,7 @@ > Style.styleNew &= ~WS_EX_WINDOWEDGE; > > Window->ExStyle = (DWORD)Style.styleNew; > + > co_IntSendMessage(hWnd, WM_STYLECHANGED, GWL_EXSTYLE, (LPARAM) &Style); > break; > > @@ -3604,7 +3605,9 @@ > OldValue = (LONG) Window->style; > Style.styleOld = OldValue; > Style.styleNew = NewValue; > - co_IntSendMessage(hWnd, WM_STYLECHANGING, GWL_STYLE, (LPARAM) &Style); > + > + if (!bAlter) > + co_IntSendMessage(hWnd, WM_STYLECHANGING, GWL_STYLE, (LPARAM) &Style); > > /* WS_CLIPSIBLINGS can't be reset on top-level windows */ > if (Window->spwndParent == UserGetDesktopWindow()) Style.styleNew |= WS_CLIPSIBLINGS; > @@ -3621,7 +3624,9 @@ > DceResetActiveDCEs( Window ); > } > Window->style = (DWORD)Style.styleNew; > - co_IntSendMessage(hWnd, WM_STYLECHANGED, GWL_STYLE, (LPARAM) &Style); > + > + if (!bAlter) > + co_IntSendMessage(hWnd, WM_STYLECHANGED, GWL_STYLE, (LPARAM) &Style); > break; > > case GWL_WNDPROC: > @@ -3672,6 +3677,13 @@ > return( OldValue); > } > > + > +LONG FASTCALL > +co_UserSetWindowLong(HWND hWnd, DWORD Index, LONG NewValue, BOOL Ansi) > +{ > + return co_IntSetWindowLong(hWnd, Index, NewValue, Ansi, FALSE); > +} > + > /* > * NtUserSetWindowLong > * > @@ -3686,24 +3698,45 @@ > LONG APIENTRY > NtUserSetWindowLong(HWND hWnd, DWORD Index, LONG NewValue, BOOL Ansi) > { > - DECLARE_RETURN(LONG); > - > - TRACE("Enter NtUserSetWindowLong\n"); > + LONG ret; > + > UserEnterExclusive(); > > if (hWnd == IntGetDesktopWindow()) > { > EngSetLastError(STATUS_ACCESS_DENIED); > - RETURN( 0); > - } > - > - RETURN( co_UserSetWindowLong(hWnd, Index, NewValue, Ansi)); > - > -CLEANUP: > - TRACE("Leave NtUserSetWindowLong, ret=%i\n",_ret_); > + UserLeave(); > + return 0; > + } > + > + ret = co_IntSetWindowLong(hWnd, Index, NewValue, Ansi, FALSE); > + > UserLeave(); > - END_CLEANUP; > -} > + > + return ret; > +} > + > +DWORD APIENTRY > +NtUserAlterWindowStyle(HWND hWnd, DWORD Index, LONG NewValue) > +{ > + LONG ret; > + > + UserEnterExclusive(); > + > + if (hWnd == IntGetDesktopWindow()) > + { > + EngSetLastError(STATUS_ACCESS_DENIED); > + UserLeave(); > + return 0; > + } > + > + ret = co_IntSetWindowLong(hWnd, Index, NewValue, FALSE, TRUE); > + > + UserLeave(); > + > + return ret; > +} > + > > /* > * NtUserSetWindowWord > > Modified: trunk/reactos/win32ss/user/user32/controls/button.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/user32/contro… > ============================================================================== > --- trunk/reactos/win32ss/user/user32/controls/button.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/user32/controls/button.c [iso-8859-1] Wed Feb 25 20:02:10 2015 > @@ -298,11 +298,10 @@ > /* XP turns a BS_USERBUTTON into BS_PUSHBUTTON */ > if (btn_type == BS_USERBUTTON ) > { > + style = (style & ~BS_TYPEMASK) | BS_PUSHBUTTON; > #ifdef __REACTOS__ > - style = (style & ~BS_TYPEMASK) | BS_PUSHBUTTON; > - SetWindowLongPtrW( hWnd, GWL_STYLE, style ); > + NtUserAlterWindowStyle(hWnd, GWL_STYLE, style ); > #else > - style = (style & ~BS_TYPEMASK) | BS_PUSHBUTTON; > WIN_SetStyle( hWnd, style, BS_TYPEMASK & ~style ); > #endif > } > @@ -508,8 +507,11 @@ > if ((wParam & BS_TYPEMASK) >= MAX_BTN_TYPE) break; > btn_type = wParam & BS_TYPEMASK; > style = (style & ~BS_TYPEMASK) | btn_type; > - SetWindowLongPtrW( hWnd, GWL_STYLE, style ); > - //WIN_SetStyle( hWnd, style, BS_TYPEMASK & ~style ); > +#ifdef __REACTOS__ > + NtUserAlterWindowStyle(hWnd, GWL_STYLE, style ); > +#else > + WIN_SetStyle( hWnd, style, BS_TYPEMASK & ~style ); > +#endif > > /* Only redraw if lParam flag is set.*/ > if (lParam) > @@ -565,7 +567,7 @@ > #ifdef __REACTOS__ > if (wParam) style |= WS_TABSTOP; > else style &= ~WS_TABSTOP; > - SetWindowLongPtrW( hWnd, GWL_STYLE, style ); > + NtUserAlterWindowStyle(hWnd, GWL_STYLE, style ); > #else > if (wParam) WIN_SetStyle( hWnd, WS_TABSTOP, 0 ); > else WIN_SetStyle( hWnd, 0, WS_TABSTOP ); > > >

1 0

Status Meeting (February 2015)
by Aleksey Bragin 26 Feb '15

26 Feb '15

Hello, Let me invite you to the monthly status meeting taking place 26th 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. If someone still is not getting passwords sent before a meeting - please email Pierre before the meeting started to get one. Please send agenda proposals to me before the meeting, so that we can start with a proposed agenda. And join Mumble! :-) Regards, Aleksey Bragin

4 8

VirtualBox Testslave
by Colin Finck 26 Feb '15

26 Feb '15

Hi all, As tests have shown that VirtualBox doesn't work properly inside an already virtualized environment, ReactOS Deutschland e.V. has just ordered a tiny Intel NUC that will serve as a VirtualBox Testslave. We plan to set it up right next to our Buildslaves, so that every ISO could possibly be regression-tested under VirtualBox. As a start, we plan to test the builds of the new MSVC Builder. The machine is powerful enough though to eventually test multiple ISOs simultaneously. I don't know about the current state of sysreg2 regarding VirtualBox support. To let this all happen as soon as possible, please ensure sysreg2 can fully handle VirtualBox once I set up the machine. Cheers, Colin

2 2

Re: [ros-dev] [ros-diffs] [jimtabor] 66464: [User32_WINETEST] - Move test_SetFocus first as it is done originally. Refer to read past wine CVS logs for the reason.
by Thomas Faber 26 Feb '15

26 Feb '15

I don't care about the reason. Tests that fail on Windows are broken, period. In this order the tests fail on Windows. On 2015-02-26 09:38, jimtabor(a)svn.reactos.org wrote: > Author: jimtabor > Date: Thu Feb 26 08:38:00 2015 > New Revision: 66464 > > URL: http://svn.reactos.org/svn/reactos?rev=66464&view=rev > Log: > [User32_WINETEST] > - Move test_SetFocus first as it is done originally. Refer to read past wine CVS logs for the reason. > > Modified: > trunk/rostests/winetests/user32/msg.c > > Modified: trunk/rostests/winetests/user32/msg.c > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/winetests/user32/msg.c?re… > ============================================================================== > --- trunk/rostests/winetests/user32/msg.c [iso-8859-1] (original) > +++ trunk/rostests/winetests/user32/msg.c [iso-8859-1] Thu Feb 26 08:38:00 2015 > @@ -14717,8 +14717,8 @@ > START_TEST(msg_focus) > { > init_tests(); > + test_SetFocus(); > test_SetActiveWindow(); > - test_SetFocus(); > > /* HACK: For some reason test_SetForegroundWindow fails on Windows unless > * we do this */

2 2

[ros-diffs] [gadamopoulos] 66454: [USER32_WINETEST] and [ros-diffs] [gadamopoulos] 66457: [USER32] - button.c: Use NtUserAlterWindowStyle
by James Tabor 26 Feb '15

26 Feb '15

Hi! The message testing, LOL just made more work for Amine... Okay AlterWindowStyle, could it be better to place it in WIN_SetStyle as a wrapper, maybe? WIN_SetStyle is just glue code for ReactOS. James

2 1

[ros-diffs] [tkreuzer] 66444: [USER32_APITEST] Add some test for GetDCEx that highlight the ridiculous implementation of owned and class DCs.
by James Tabor 25 Feb '15

25 Feb '15

Author: tkreuzer Date: Tue Feb 24 23:15:08 2015 New Revision: 66444 [USER32_APITEST] Add some test for GetDCEx that highlight the ridiculous implementation of owned and class DCs. Hello All! What is ridiculous is the attitude of our smart A__ developers! James

2 3

win32k C++ suggestion
by Timo Kreuzer 22 Feb '15

22 Feb '15

Hi I'd like to propose introducing C++ to win32k. Don't worry, this is not a suggestion to rewrite everything from scratch in C++, but to gradually introduce C++. The reason is not "That's what Windows does", but the fact that especially GDI would heavily benefit in terms of code simplicity, clarily and quality from using C++. A lot of the interfaces are already in a C++ object style way, but still code can bypass interfaces and directly modify structure members, even if it is not supposed to be done that way. Unless there are strong objections, I'd post a design / style / roadmap suggestion soon. If people feel strongly about it, we can defer this to after a 0.4.0 release. Regards, Timo

4 3

Re: [ros-dev] [ros-diffs] [jgardou] 66334: [NTOSKRNL/MM] - MiIsEntireRangeCommitted: Ensure the PTE we are checking is really faulted in. - Prefer MiPteToPde and MiPdeToPte (which should really be called MiFirstPteInPde) in...
by Alex Ionescu 21 Feb '15

21 Feb '15

it might fix an assert but the patch is incorrect. will this also take 6 months to revert? Best regards, Alex Ionescu On Tue, Feb 17, 2015 at 6:19 AM, <jgardou(a)svn.reactos.org> wrote: > Author: jgardou > Date: Tue Feb 17 14:19:05 2015 > New Revision: 66334 > > URL: http://svn.reactos.org/svn/reactos?rev=66334&view=rev > Log: > [NTOSKRNL/MM] > - MiIsEntireRangeCommitted: Ensure the PTE we are checking is really > faulted in. > - Prefer MiPteToPde and MiPdeToPte (which should really be called > MiFirstPteInPde) instead of MiAddressToPte and MiPteToAddress > Fixes weird failed ASSERT in page fault handler when using DPH. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Tue Feb 17 > 14:19:05 2015 > @@ -1994,14 +1994,13 @@ > if (OnBoundary) > { > /* Is this PDE demand zero? */ > - PointerPde = MiAddressToPte(PointerPte); > + PointerPde = MiPteToPde(PointerPte); > if (PointerPde->u.Long != 0) > { > /* It isn't -- is it valid? */ > if (PointerPde->u.Hard.Valid == 0) > { > /* Nope, fault it in */ > - PointerPte = MiPteToAddress(PointerPde); > MiMakeSystemAddressValid(PointerPte, Process); > } > } > @@ -2009,13 +2008,13 @@ > { > /* The PTE was already valid, so move to the next one */ > PointerPde++; > - PointerPte = MiPteToAddress(PointerPde); > + PointerPte = MiPdeToPte(PointerPde); > > /* Is the entire VAD committed? If not, fail */ > if (!Vad->u.VadFlags.MemCommit) return FALSE; > > - /* Everything is committed so far past the range, return > true */ > - if (PointerPte > LastPte) return TRUE; > + /* New loop iteration with our new, on-boundary PTE. */ > + continue; > } > } > > > >

4 4

Re: [ros-dev] [ros-diffs] [tfaber] 66365: [KERNEL32] - Make BaseSetLastNTError return the converted Win32 error code. This will determine the upper 24 bits of EAX in functions that return BOOLEAN FALSE right after calling B...
by Timo Kreuzer 21 Feb '15

21 Feb '15

For me this looks like a hack. It might "do what Windows does", but the result is more based on luck / random compiler behaviour rather than deterministic behavior. We should think about returning a full ULONG in all functions that rely on this (like Wow64EnableWow64FsRedirection), containing the correct value, rather than relying on random stuff. Am 20.02.2015 um 08:03 schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Fri Feb 20 07:03:00 2015 > New Revision: 66365 > > URL: http://svn.reactos.org/svn/reactos?rev=66365&view=rev > Log: > [KERNEL32] > - Make BaseSetLastNTError return the converted Win32 error code. This will determine the upper 24 bits of EAX in functions that return BOOLEAN FALSE right after calling BaseSetLastNTError, e.g. Wow64EnableWow64FsRedirection. Fixes installers using WiX Toolset (e.g. VS2012 redist) on MSVC builds. > See http://wixtoolset.org/issues/4681/ for the WiX bug that causes this. > CORE-8010 > > Modified: > trunk/reactos/dll/win32/kernel32/client/except.c > trunk/reactos/dll/win32/kernel32/include/kernel32.h > > Modified: trunk/reactos/dll/win32/kernel32/client/except.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/except.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/except.c [iso-8859-1] Fri Feb 20 07:03:00 2015 > @@ -682,12 +682,16 @@ > /* > * @implemented > */ > -VOID > +DWORD > WINAPI > BaseSetLastNTError(IN NTSTATUS Status) > { > + DWORD dwErrCode; > + > /* Convert from NT to Win32, then set */ > - SetLastError(RtlNtStatusToDosError(Status)); > + dwErrCode = RtlNtStatusToDosError(Status); > + SetLastError(dwErrCode); > + return dwErrCode; > } > > /* > > Modified: trunk/reactos/dll/win32/kernel32/include/kernel32.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/include… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/include/kernel32.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/include/kernel32.h [iso-8859-1] Fri Feb 20 07:03:00 2015 > @@ -353,7 +353,7 @@ > WINAPI > InitCommandLines(VOID); > > -VOID > +DWORD > WINAPI > BaseSetLastNTError(IN NTSTATUS Status); > > > >

2 1

Re: [ros-dev] [ros-diffs] [gadamopoulos] 66383: [SHELL32] - Implement progress dialogs for SHFileOperation - Patch by Hwu Davies CORE-4476
by Pierre Schweitzer 21 Feb '15

21 Feb '15

In such situations, please update all the langages files and not only English. This makes work easier for translators to track changes. On 21/02/2015 13:52, gadamopoulos(a)svn.reactos.org wrote: > Author: gadamopoulos > Date: Sat Feb 21 12:52:58 2015 > New Revision: 66383 > > URL: http://svn.reactos.org/svn/reactos?rev=66383&view=rev > Log: > [SHELL32] > - Implement progress dialogs for SHFileOperation > - Patch by Hwu Davies > CORE-4476 > > Modified: > trunk/reactos/dll/win32/shell32/lang/en-US.rc > > Modified: trunk/reactos/dll/win32/shell32/lang/en-US.rc > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/lang/en-… > ============================================================================== > --- trunk/reactos/dll/win32/shell32/lang/en-US.rc [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/lang/en-US.rc [iso-8859-1] Sat Feb 21 12:52:58 2015 > @@ -693,6 +693,13 @@ > IDS_OVERWRITEFILE_CAPTION "Confirm file overwrite" > IDS_OVERWRITEFOLDER_TEXT "This folder already contains a folder named '%1'.\n\nIf the files in the destination folder have the same names as files in the\nselected folder they will be replaced. Do you still want to move or copy\nthe folder?" > > + IDS_FILEOOP_COPYING "Copying" > + IDS_FILEOOP_MOVING "Moving" > + IDS_FILEOOP_DELETING "Deleting" > + IDS_FILEOOP_FROM_TO "From %1 to %2" > + IDS_FILEOOP_FROM "From %1" > + IDS_FILEOOP_PREFLIGHT "Preflight" > + > /* message box strings */ > IDS_RESTART_TITLE "Restart" > IDS_RESTART_PROMPT "Do you want to restart the system?" > -- Pierre Schweitzer <pierre at reactos.org> System & Network Administrator Senior Kernel Developer ReactOS Deutschland e.V.

1 0

Where is the Patchbot??
by Hermès BÉLUSCA - MAÏTO 21 Feb '15

21 Feb '15

Hi guys ! Where is the Patchbot?? Dont you think its still needed? Thanks, Hermès.

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev