Ros-dev March 2015

ros-dev@reactos.org

25 participants
34 discussions

Re: [ros-dev] [ros-diffs] [tkreuzer] 66636: [DDK/XDK] - Fix some prototypes in wdm.h (PMDLX -> PMDL) - Fix annotations for ExFreePool(WithTag)
by Thomas Faber 10 Mar '15

10 Mar '15

On 2015-03-10 01:09, tkreuzer(a)svn.reactos.org wrote: > --- trunk/reactos/include/xdk/exfuncs.h [iso-8859-1] (original) > +++ trunk/reactos/include/xdk/exfuncs.h [iso-8859-1] Tue Mar 10 00:09:20 2015 > @@ -606,14 +606,14 @@ > VOID > NTAPI > ExFreePool( > - _In_ __drv_freesMem(Mem) PVOID P); > + _Pre_not __drv_freesMem(Mem) PVOID P); > > _IRQL_requires_max_(DISPATCH_LEVEL) > NTKERNELAPI > VOID > NTAPI > ExFreePoolWithTag( > - _In_ __drv_freesMem(Mem) PVOID P, > + _Pre_not __drv_freesMem(Mem) PVOID P, > _In_ ULONG Tag); > > _IRQL_requires_max_(DISPATCH_LEVEL) Are these typos (missing "null_")?

1 0

Undocumented interesting WinDBG commands
by Hermès BÉLUSCA - MAÏTO 09 Mar '15

09 Mar '15

Hi ! For your information, here are some undocumented but nevertheless interesting WinDBG commands: http://blogs.msdn.com/b/reiley/archive/2011/10/30/undocumented-windbg.aspx Cheers, Hermès.

1 0

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

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