- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [ekohl] 53469: [WIDL] Revert parts of r53171: Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the range attribute and others....
by Jérôme Gardou 28 Aug '11

28 Aug '11

HI Eric! I'm not sure about what you mean for range attribute, but I notice that typedef [context_handle] PVOID my_handle; makes widl thinks that any value of the my_handle type is passed by pointer, whereas midl considers it is passed by value. Could you be more precise about "range attributes and others?" please. Regards. Jérôme. Le 27/08/2011 18:24, ekohl(a)svn.reactos.org a écrit : > Author: ekohl > Date: Sat Aug 27 16:24:40 2011 > New Revision: 53469 > > URL: http://svn.reactos.org/svn/reactos?rev=53469&view=rev > Log: > [WIDL] > Revert parts of r53171: > Remove the -Oif flag for WIDL because the NT4 stub code generated by the current WIDL is heavily broken with respect to the range attribute and others. Please enable the -Oif feature only after these bugs are fixed in WIDL! > > Modified: > trunk/reactos/cmake/idl-support.cmake > trunk/reactos/tools/rbuild/backend/mingw/rules.mak > > Modified: trunk/reactos/cmake/idl-support.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/idl-support.cmake?re… > ============================================================================== > --- trunk/reactos/cmake/idl-support.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/idl-support.cmake [iso-8859-1] Sat Aug 27 16:24:40 2011 > @@ -22,8 +22,8 @@ > set(IDL_HEADER_ARG -h -o) #.h > set(IDL_HEADER_ARG2 -h -H) #.h > set(IDL_TYPELIB_ARG -t -o) #.tlb > - set(IDL_SERVER_ARG -Oif -s -o) #.c for server library > - set(IDL_CLIENT_ARG -Oif -c -o) #.c for stub client library > + set(IDL_SERVER_ARG -s -o) #.c for server library > + set(IDL_CLIENT_ARG -c -o) #.c for stub client library > set(IDL_PROXY_ARG -p -o) > set(IDL_INTERFACE_ARG -u -o) > if(ARCH MATCHES i386) > @@ -169,6 +169,6 @@ > list(APPEND IID_SOURCES ${NAME}_i.c) > endforeach() > add_library(${TARGET} ${IID_SOURCES}) > - add_dependencies(${TARGET} psdk) > + add_dependencies(${TARGET} psdk) > set_target_properties(${TARGET} PROPERTIES EXCLUDE_FROM_ALL TRUE) > endfunction() > > Modified: trunk/reactos/tools/rbuild/backend/mingw/rules.mak > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/rbuild/backend/mingw… > ============================================================================== > --- trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] (original) > +++ trunk/reactos/tools/rbuild/backend/mingw/rules.mak [iso-8859-1] Sat Aug 27 16:24:40 2011 > @@ -264,7 +264,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_c: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_c.h -c -C ${call RBUILD_intermediate_path_noext,$(2)}_c.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_c.c,,,${call RBUILD_intermediate_path_noext,$(2)}_c.o} > @@ -280,7 +280,7 @@ > > ${call RBUILD_intermediate_path_noext,$(2)}_s: $(2) $(3) $$(widl_TARGET) | ${call RBUILD_intermediate_dir,$(2)} > $$(ECHO_WIDL) > - $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -Oif -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > + $$(Q)$$(widl_TARGET) ${call RBUILD_midlflags,$(1),$(4),-I${call RBUILD_dir,$(2)}} -h -H ${call RBUILD_intermediate_path_noext,$(2)}_s.h -s -S ${call RBUILD_intermediate_path_noext,$(2)}_s.c $(2) > $${checkpoint} $$@>$(NUL) > > ${call RBUILD_CC,$(1),${call RBUILD_intermediate_path_noext,$(2)}_s.c,,,${call RBUILD_intermediate_path_noext,$(2)}_s.o} > >

3 5

Sugetao
by Dimas FranK 27 Aug '11

27 Aug '11

I obeservado that companies have made the opening of perfius on social sites like orkte, face buk to have a closer contacts with its customers Suggestions Taves Foce the time to develop a page-pink similar to orkut only for pelomenos emvolvidos list of ros-dev communicate mellhor we take for example the option orkut This allows you to replaying a message to the entire group or just for some or open a profile but it would be the maintainer of the profile to select some options has some social networks that desacoselho to be very open but partially open orkut and where he has partial control of where and where does the information would be very nice to have something in ros.org or maybe opening a profile on some these social networks a method would be to discuss and APREDE programs in a more dynamic

2 1

Uma Questao
by Dimas FranK 27 Aug '11

27 Aug '11

A Matter discursoes saw some about the future of Roses A sugentao as a powerful gaming machine MaxiVista server and at the same time continue the development of financial markets and earn some cash to the developers and everyone involved in the project we will take as examples the maximum this game is notable that the projects do not get for the day for the night

2 1

Re: [ros-dev] Ros-dev Digest, Vol 84, Issue 22
by Dimas FranK 27 Aug '11

27 Aug '11

When complete the installation of the driver placa GF8200A shipeset 8200 Through the message that the dll not found Wow32.dll MainFrameBase::OpenShellFolders():parent_pidl=C:\Documents and Settgs\Administrator\Desktop MainFrameBase::OpenShellFolders(): pidl_abs=(null) (drivers\filesystems\cdfs\create.c:148) Status c0000013 (drivers\filesystems\cdfs\create.c:148) Status c0000013 (drivers\flesystems\cdfs\common.c:196) STATUS_VERIFY_REQUIRED (drivers\filesystems\cdfs\fsctl.c:590) CDFS: IRP_MN_VERIFY_VOLUME (drivers\filesystems\cdfs\fsctl.c:467) CdfsVerifyVolume() called (drivers\filesystems\cdfs\fsctl.c:494) Deviceobject B1285A48 Device to verify B1285A48 (drivers\filesystems\cdfs\devctrl.c:34) FIXME: CdfsDevieControl called without FileObjec! (drivers\filesystems\cdfs\fsct.c:511) Different volume! (drives\filesystems\cdfs\fsctl.c:518) OenFile \ RefCount 1 (drivers\fiesystems\cdfs\fsctl.c:518) OpenFie \loader RefCount 0 (drivers\flesystems\cdfs\fsctl.c:518) OpenFile \reactos RefCount 0 (drivers\filesystems\cdfs\fsctl.c:518) OenFile \reactos\system32 RefCoun 0 (drivers\filesystems\cdfs\common.c203) IoVerifyVolume() returned (Status c0000012) (drivers\filesysems\cdfs\create.c:148) Status 8000016 MainFrameBase::OpenShellFolders():parent_pidl=(null) MainFrameBase:OpenShellFolders(): pidl_abs=D:\ MDIMainFrame PM_OPEN_WINDOW: pat=D:\ MainFrameBase::OpenShellFolders():rent_pidl=D:\ (lib\rtl\path.c:256) don't keep the directory handl open on removable media (dll\ntdll\ldr\utils.c:2301) Faile to create or open dll section of'WOW32.DLL' (Status c0000135) (d\ntdll\ldr\utils.c:1512) failed tload WOW32.DLL (subsystems\win32csrss\csrsrv\api\wapi.c:115) CSR:received hard error c0000135 WARNING: MmLockPageableDataSectio at ntoskrnl\mm\ARM3\drvmgmt.c:62s UNIMPLEMENTED! WARNING: MmUnlockPageableImageSecon at ntoskrnl\mm\ARM3\drvmgmt.c: is UNIMPLEMENTED! (ntoskrnl\se\semgr.c:299) SidInTok Calls: 30000 2011/8/26, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Debug Buildslave Maintenance (caemyr(a)myopera.com) > 2. Re: Debug Buildslave Maintenance (Eric Kohl) > 3. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Ged Murphy) > 4. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Aleksey Bragin) > 5. Re: Debug Buildslave Maintenance (Aleksey Bragin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Aug 2011 23:29:55 +0200 > From: caemyr(a)myopera.com > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: "ReactOS Development List" <ros-dev(a)reactos.org> > Message-ID: > <1314307795.18690.140258133790149(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="us-ascii" > > @Eric > > http://reactos.org/testman/compare.php?ids=7429,7579 > http://reactos.org/testman/detail.php?id=2639952 > > Please find that the crash is not CMake related, and CMake build is not > inherently broken. > > On Thu, 25 Aug 2011 23:03 +0200, "Pierre Schweitzer" > <pierre.schweitzer(a)reactos.org> wrote: >> Hi, >> >> finally. >> Colin and I are pleased to announce you that ReactOS Linux KVM tests are >> back online and working. You can find the first tests results (on r53383) >> sent tonight by the testbot on testman: http://www.reactos.org/testman/. >> >> Regards, >> Pierre. >> >> ReactOS Development List <ros-dev(a)reactos.org> wrote on Sat, August 20th, >> 2011, 4:24 PM: >> > Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >> > > What about fixing release buildbot first? >> > >> > It's still a private machine owned and administered solely by Christoph. >> > >> > As long as I can't even reach him by phone, we can only wait. >> > >> > >> > > And is there a chance, maybe in the future, to switch buildbots more >> > > easily, to have a backup solution running? >> > >> > First of all, we hope that we can get the same reliability as our other >> > servers after reinstalling the server OS, giving more ReactOS admins >> > access to the machine and adding monitoring. >> > The current OS was meant to be reinstalled for quite a long time, but up >> > >> > to now, nobody with physical access to the machine had any time to do >> > it. >> > >> > If such problems continue to exist afterwards, we can try to set up a >> > fallback system, but this would require an equally configured and >> > powerful Linux machine first. >> > >> > >> > > One week without debug builds is a serious thing. >> > >> > I hope you're aware that builds are still properly uploaded, it's only >> > the testing step which fails. >> > >> > >> > - 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 >> > With best regards > Caemyr > > > > ------------------------------ > > Message: 2 > Date: Fri, 26 Aug 2011 01:01:40 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4E56D454.6060606(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Olaf, > > I am already investigating the services test issues. One of my first > findings is that the current widl seems to mess up value ranges in some > cases. This is the cause of the following errors: > err:(dll/win32/rpcrt4/ndr_marshall.c:6496) value exceeded bounds: 918, > low: 0, high: 514 > > <rant> > It is pretty annoying that jgardou updated rpcrt4, widl and other > components without proper testing. At least he should have posted a bug > list BEFORE he comitted the new stuff. > </rant> > > Regards > Eric > >> @Eric >> >> http://reactos.org/testman/compare.php?ids=7429,7579 >> http://reactos.org/testman/detail.php?id=2639952 >> >> Please find that the crash is not CMake related, and CMake build is not >> inherently broken. >> > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Aug 2011 09:05:21 +0100 > From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: <ros-dev(a)reactos.org> > Message-ID: <004201cc63c6$e7a44a40$b6ecdec0$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > fireball(a)svn.reactos.org wrote: > >> - Use Zw* functions instead of Nt* where necessary in >> LdrQueryImageFileKeyOption(). > > 'where necessary'm I don't understand this change. > People prefer (and Microsoft recommend) that Nt* is used in usermode. > Nt and Zw APIs point to the same address in usermode, so why is it > necessary? > > Ged. > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Aug 2011 12:13:26 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <7766A32C-3CB0-446A-96F4-4EDC73BC3A29(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 12:05 PM, Ged Murphy wrote: > >> fireball(a)svn.reactos.org wrote: >> >>> - Use Zw* functions instead of Nt* where necessary in >>> LdrQueryImageFileKeyOption(). >> >> 'where necessary'm I don't understand this change. >> People prefer (and Microsoft recommend) that Nt* is used in usermode. >> Nt and Zw APIs point to the same address in usermode, so why is it >> necessary? > > This was a test for attention, and so far I got a few notices in IRC > and one in ros-dev. Good! > > Seriously, the change slipped through because I was editing source > code of both RTL (which works both at umode and kmode) and NTDLL/LDR > (which is only umode) a while ago. Of course, Nt is "preferable" in > usermode because there is just no reason to use Zw there. > > > WBR, > Aleksey Bragin. > > > > > ------------------------------ > > Message: 5 > Date: Fri, 26 Aug 2011 12:15:24 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <1F3FEE77-59BC-4D24-83A9-5D280FB45966(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 3:01 AM, Eric Kohl wrote: > >> <rant> >> It is pretty annoying that jgardou updated rpcrt4, widl and other >> components without proper testing. At least he should have posted a >> bug list BEFORE he comitted the new stuff. >> </rant> > I also ranted about that. In fact that's why I stopped syncing rpcrt4 > some time ago - because new version always gave problems. So I wanted > to solve problems first and only then commit. > > But, OK, as Olaf said - if something needs to be done, let's simply > do that and fix everything which broke ;). > > WBR, > Aleksey. > > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 84, Issue 22 > *************************************** >

1 1

Re: [ros-dev] Ros-dev Digest, Vol 84, Issue 22
by Dimas FranK 26 Aug '11

26 Aug '11

When complete the installation of the driver placa GF8200A shipeset 8200 Through the message that the dll not found Wow32.dll 2011/8/26, ros-dev-request(a)reactos.org <ros-dev-request(a)reactos.org>: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Debug Buildslave Maintenance (caemyr(a)myopera.com) > 2. Re: Debug Buildslave Maintenance (Eric Kohl) > 3. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Ged Murphy) > 4. Re: [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong > loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... (Aleksey Bragin) > 5. Re: Debug Buildslave Maintenance (Aleksey Bragin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Aug 2011 23:29:55 +0200 > From: caemyr(a)myopera.com > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: "ReactOS Development List" <ros-dev(a)reactos.org> > Message-ID: > <1314307795.18690.140258133790149(a)webmail.messagingengine.com> > Content-Type: text/plain; charset="us-ascii" > > @Eric > > http://reactos.org/testman/compare.php?ids=7429,7579 > http://reactos.org/testman/detail.php?id=2639952 > > Please find that the crash is not CMake related, and CMake build is not > inherently broken. > > On Thu, 25 Aug 2011 23:03 +0200, "Pierre Schweitzer" > <pierre.schweitzer(a)reactos.org> wrote: >> Hi, >> >> finally. >> Colin and I are pleased to announce you that ReactOS Linux KVM tests are >> back online and working. You can find the first tests results (on r53383) >> sent tonight by the testbot on testman: http://www.reactos.org/testman/. >> >> Regards, >> Pierre. >> >> ReactOS Development List <ros-dev(a)reactos.org> wrote on Sat, August 20th, >> 2011, 4:24 PM: >> > Timo Kreuzer <timo.kreuzer(a)web.de> wrote: >> > > What about fixing release buildbot first? >> > >> > It's still a private machine owned and administered solely by Christoph. >> > >> > As long as I can't even reach him by phone, we can only wait. >> > >> > >> > > And is there a chance, maybe in the future, to switch buildbots more >> > > easily, to have a backup solution running? >> > >> > First of all, we hope that we can get the same reliability as our other >> > servers after reinstalling the server OS, giving more ReactOS admins >> > access to the machine and adding monitoring. >> > The current OS was meant to be reinstalled for quite a long time, but up >> > >> > to now, nobody with physical access to the machine had any time to do >> > it. >> > >> > If such problems continue to exist afterwards, we can try to set up a >> > fallback system, but this would require an equally configured and >> > powerful Linux machine first. >> > >> > >> > > One week without debug builds is a serious thing. >> > >> > I hope you're aware that builds are still properly uploaded, it's only >> > the testing step which fails. >> > >> > >> > - 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 >> > With best regards > Caemyr > > > > ------------------------------ > > Message: 2 > Date: Fri, 26 Aug 2011 01:01:40 +0200 > From: Eric Kohl <eric.kohl(a)t-online.de> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <4E56D454.6060606(a)t-online.de> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi Olaf, > > I am already investigating the services test issues. One of my first > findings is that the current widl seems to mess up value ranges in some > cases. This is the cause of the following errors: > err:(dll/win32/rpcrt4/ndr_marshall.c:6496) value exceeded bounds: 918, > low: 0, high: 514 > > <rant> > It is pretty annoying that jgardou updated rpcrt4, widl and other > components without proper testing. At least he should have posted a bug > list BEFORE he comitted the new stuff. > </rant> > > Regards > Eric > >> @Eric >> >> http://reactos.org/testman/compare.php?ids=7429,7579 >> http://reactos.org/testman/detail.php?id=2639952 >> >> Please find that the crash is not CMake related, and CMake build is not >> inherently broken. >> > > > > ------------------------------ > > Message: 3 > Date: Fri, 26 Aug 2011 09:05:21 +0100 > From: "Ged Murphy" <gedmurphy.maillists(a)gmail.com> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: <ros-dev(a)reactos.org> > Message-ID: <004201cc63c6$e7a44a40$b6ecdec0$(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > fireball(a)svn.reactos.org wrote: > >> - Use Zw* functions instead of Nt* where necessary in >> LdrQueryImageFileKeyOption(). > > 'where necessary'm I don't understand this change. > People prefer (and Microsoft recommend) that Nt* is used in usermode. > Nt and Zw APIs point to the same address in usermode, so why is it > necessary? > > Ged. > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 26 Aug 2011 12:13:26 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix > wrong loop condition which would often lead to heap underread. - Fix > wrong subkey string length calculation, which would result in an > incorrect string being used... > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <7766A32C-3CB0-446A-96F4-4EDC73BC3A29(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 12:05 PM, Ged Murphy wrote: > >> fireball(a)svn.reactos.org wrote: >> >>> - Use Zw* functions instead of Nt* where necessary in >>> LdrQueryImageFileKeyOption(). >> >> 'where necessary'm I don't understand this change. >> People prefer (and Microsoft recommend) that Nt* is used in usermode. >> Nt and Zw APIs point to the same address in usermode, so why is it >> necessary? > > This was a test for attention, and so far I got a few notices in IRC > and one in ros-dev. Good! > > Seriously, the change slipped through because I was editing source > code of both RTL (which works both at umode and kmode) and NTDLL/LDR > (which is only umode) a while ago. Of course, Nt is "preferable" in > usermode because there is just no reason to use Zw there. > > > WBR, > Aleksey Bragin. > > > > > ------------------------------ > > Message: 5 > Date: Fri, 26 Aug 2011 12:15:24 +0400 > From: Aleksey Bragin <aleksey(a)reactos.org> > Subject: Re: [ros-dev] Debug Buildslave Maintenance > To: ReactOS Development List <ros-dev(a)reactos.org> > Message-ID: <1F3FEE77-59BC-4D24-83A9-5D280FB45966(a)reactos.org> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > > On Aug 26, 2011, at 3:01 AM, Eric Kohl wrote: > >> <rant> >> It is pretty annoying that jgardou updated rpcrt4, widl and other >> components without proper testing. At least he should have posted a >> bug list BEFORE he comitted the new stuff. >> </rant> > I also ranted about that. In fact that's why I stopped syncing rpcrt4 > some time ago - because new version always gave problems. So I wanted > to solve problems first and only then commit. > > But, OK, as Olaf said - if something needs to be done, let's simply > do that and fix everything which broke ;). > > WBR, > Aleksey. > > > > > ------------------------------ > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > > End of Ros-dev Digest, Vol 84, Issue 22 > *************************************** >

1 0

Debug Buildslave Maintenance
by Colin Finck 26 Aug '11

26 Aug '11

Hello all, The Debug Buildslave will be down for maintenance throughout the next week. We hope to have it fully working again by next weekend. In the process of this maintenance, the OS will be reinstalled to match the one we already use on our other servers. Besides, more of our administrators will get access to the machine, so that further problems can be debugged more easily. - Colin

6 9

Re: [ros-dev] [ros-diffs] [fireball] 53446: [NTDLL/LDR] - Fix wrong loop condition which would often lead to heap underread. - Fix wrong subkey string length calculation, which would result in an incorrect string being used...
by Ged Murphy 26 Aug '11

26 Aug '11

fireball(a)svn.reactos.org wrote: > - Use Zw* functions instead of Nt* where necessary in LdrQueryImageFileKeyOption(). 'where necessary'm I don't understand this change. People prefer (and Microsoft recommend) that Nt* is used in usermode. Nt and Zw APIs point to the same address in usermode, so why is it necessary? Ged.

2 1

August meeting
by Aleksey Bragin 25 Aug '11

25 Aug '11

Hi, this is a reminder about the Status meeting, which is to happen tomorrow, 25th of August at 19:00 UTC. Please don't miss it. Proposed agenda for the meeting: 1. Arwinss adoption voting. 2. CMake adoption voting. 3. Release preparation status report, deciding on the next release date. 4. Driver signing. Discussing possible threats and deciding on an official position wrt driver signing in future. 4. Party related to GSoC results. I propose to move individual devs status reports to ros-dev mailing list, because there is no reason to just sit in the irc channel and listen to them for hours. List of participants: - Giannis Adamopoulos (smiley1_) - Johannes Anderwald (janderwald) - Javier Agustìn Fernàndez Arroyo (elhoir) - Maciej Bialas (niski) - Jan Blomqvist-Kinander (JaixBly) - Aleksey Bragin (abragin) - Thomas Faber (ThFabba) - Colin Finck (Colin_Finck) - Jérôme Gardou (zefklop) - Danny Götte (dangerground) - Cameron Gutman (aicom) - Ziliang Guo (ZWabbit) - Rafal Harabien (rafalh) - Andrew Hill (ash77) - Kamil Hornicek (Pigglesworth) - Gabriel Ilardi (gabriel_it) - Alex Ionescu (Alex_Ionescu) - Amine Khaldi (AmineKhaldi) - Igor Koshpaev (tower) - Timo Kreuzer (tkreuzer) - Matthias Kupfer (Collibri) - Michael Martin (mjmartin) - Victor Martinez (vicmarcal) - Roel Messiant (Mephisto) - Claudiu Mihail (KlausM) - Andrew Munger (WaxDragon) - Ged Murphy (GedMurphy) - Igor Paliychuk (igorko) - Sylvain Petreolle (Usurp) - Hervé Poussineau (hpoussin) - Daniel Reimer (dreimer) - Pierre Schweitzer (HeisSpiter) - Samuel Serapion (encoded) - Olaf Siejka (Caemyr) - James Tabor (jimtabor) - Christoph von Wittich (Christoph_vW) - Art Yerkes (arty) WBR, Aleksey Bragin.

7 9

[53425] ekohl: [HAL] Add PCI_HAL device for non-ACPI machines. Code taken from the ACPI-HAL. This is just a quick hack and needs some more improvements.
by caemyr＠myopera.com 24 Aug '11

24 Aug '11

r53425 broke CMake build. To make the things worse, this is our only working test\iso provider at the moment. I would reckon fixing it a priority. CMakeFiles/hal.dir/generic/halinit.c.obj: In function `HalInitSystem@8': P:/Trunk_slave/x86_CMake/build/hal/halx86/generic/halinit.c:116: undefined reference to `HaliInitPnpDriver@0' collect2: ld returned 1 exit status -- With best regards Caemyr

1 0

Another regression
by caemyr＠myopera.com 24 Aug '11

24 Aug '11

Revision 53257 breaks Vbox test runtime at 2nd stage booting. http://svn.reactos.org/svn/reactos?view=rev&revision=53257 -- With best regards Caemyr

8 12

Re: [ros-dev] [ros-diffs] [akhaldi] 53405: [EVENTLOG] * Fix a bad sizeof().‏
by Pierre Schweitzer 24 Aug '11

24 Aug '11

Hi, same thing that for r53402, but with structure: RPC_SID. Cf: http://doxygen.reactos.org/d5/df6/structRPC__SID.html Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 53402: [HAL] * Fix a couple bad sizeof().‏
by Pierre Schweitzer 24 Aug '11

24 Aug '11

Hi, this is wrong and does actually change nothing regarding previous code. You need to copy data (structure) length, not pointer length. Structure is: CM_PARTIAL_RESOURCE_DESCRIPTOR. Cf: http://doxygen.reactos.org/db/d22/structCM__PARTIAL__RESOURCE__DESCRIPTOR.h… Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 53404: [VIDEOPRT] * Fix a bad sizeof() that's been with us since r12860 (more than 6 years ago).
by Dmitry Gorbachev 24 Aug '11

24 Aug '11

Hi Amine! > - RtlCopyMemory(AgpServices, &Interface.AgpReservePhysical, sizeof(AgpServices)); > + RtlCopyMemory(AgpServices, &Interface.AgpReservePhysical, sizeof(PVIDEO_PORT_AGP_SERVICES)); You mean sizeof(VIDEO_PORT_AGP_SERVICES), right?

1 0

Suspicious Bill
by arkoprovomukherjee＠gmail.com 18 Aug '11

18 Aug '11

2 1

lwIP testing request
by Cameron Gutman 18 Aug '11

18 Aug '11

LwIP is in the final stage of testing, pending one bug fix before all known bugs are fixed. I would greatly appreciate everyone to try it and reply to this email with the results of your tests. I've already tried many apps including telnetd, chargen, and abyss web server, samba tng, and Opera 9.6. During my testing, the lwIP implementation performed flawlessly. It handled several chargen sessions while serving web pages and servicing open telnet sessions plus being probed by nmap. The only thing that finally killed the server was a pool leak that caused a win32k assert failure. I also ran a BitTorrent download and it peaked at 2.3 MB/s down. Web browsing is an absolute pleasure on lwIP. It really feels like I'm browsing on the host system directly. There are no more stutters like oskit had. I'd encourage everyone to try it. It's surprising how well it works especially since I thought oskit was fairly good. My testing on lwIP has been perfect and I hope everyone else has a similar experience. Please only report bugs that don't also happen with oskit. Happy testing! LwIP ISO Link: http://www.mediafire.com/?d6j4qwz8vgabj9i Thanks in advance, Cameron

7 9

Faça parte da minha rede no LinkedIn
by dimas francisco 15 Aug '11

15 Aug '11

LinkedIn ------------ Eu gostaria de adicioná-lo à minha rede profissional no LinkedIn. -dimas dimas francisco Profissional de Serviços da informação São Paulo e redondezas, Brasil Confirme que você conhece dimas francisco https://www.linkedin.com/e/-w5xu2x-gre1loc3-34/isd/3867275872/u_LdDFjC/ -- (c) 2011, LinkedIn Corporation

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53249: [NTOSKRNL] - Rewrite IopIsAcpiComputer (and rename to IopIsFirmwareMapperDisabled) to eliminate the need for the ENABLE_ACPI define - IopIsFirmwareMapperDisabled now reads the regi...
by Alex Ionescu 15 Aug '11

15 Aug '11

At some point after initializing RAWFS you need to call HalInitPnpDriver -- which through the HAL private dispatch table should call into the HAL's PNP driver (either ACPI or PCAT). Richard and I got that far with Gopher. Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 10:15 PM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Mon Aug 15 02:15:18 2011 > New Revision: 53249 > > URL: http://svn.reactos.org/svn/reactos?rev=53249&view=rev > Log: > [NTOSKRNL] > - Rewrite IopIsAcpiComputer (and rename to IopIsFirmwareMapperDisabled) to > eliminate the need for the ENABLE_ACPI define > - IopIsFirmwareMapperDisabled now reads the registry entry that HAL sets to > indicate that the firmware mapper should be disabled > - Partially rewrite IopUpdateRootKey so it does not interfere with HAL's > PnP driver > - ACPI is automatically enabled when the ACPI HAL is loaded and disabled > when the standard HAL is loaded > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] Mon Aug 15 > 02:15:18 2011 > @@ -12,8 +12,6 @@ > #include <ntoskrnl.h> > #define NDEBUG > #include <debug.h> > - > -//#define ENABLE_ACPI > > /* GLOBALS > *******************************************************************/ > > @@ -2693,143 +2691,73 @@ > } > > static BOOLEAN INIT_FUNCTION > -IopIsAcpiComputer(VOID) > -{ > -#ifndef ENABLE_ACPI > - return FALSE; > -#else > - UNICODE_STRING MultiKeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter"); > - UNICODE_STRING IdentifierU = RTL_CONSTANT_STRING(L"Identifier"); > - UNICODE_STRING AcpiBiosIdentifier = RTL_CONSTANT_STRING(L"ACPI BIOS"); > +IopIsFirmwareMapperDisabled(VOID) > +{ > + UNICODE_STRING KeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\SYSTEM\\CURRENTCONTROLSET\\Control\\Pnp"); > + UNICODE_STRING KeyNameU = > RTL_CONSTANT_STRING(L"DisableFirmwareMapper"); > OBJECT_ATTRIBUTES ObjectAttributes; > - PKEY_BASIC_INFORMATION pDeviceInformation = NULL; > - ULONG DeviceInfoLength = sizeof(KEY_BASIC_INFORMATION) + 50 * > sizeof(WCHAR); > - PKEY_VALUE_PARTIAL_INFORMATION pValueInformation = NULL; > - ULONG ValueInfoLength = sizeof(KEY_VALUE_PARTIAL_INFORMATION) + 50 * > sizeof(WCHAR); > - ULONG RequiredSize; > - ULONG IndexDevice = 0; > - UNICODE_STRING DeviceName, ValueName; > - HANDLE hDevicesKey = NULL; > - HANDLE hDeviceKey = NULL; > + HANDLE hPnpKey; > + PKEY_VALUE_PARTIAL_INFORMATION KeyInformation; > + ULONG DesiredLength, Length, KeyValue; > NTSTATUS Status; > - BOOLEAN ret = FALSE; > - > - InitializeObjectAttributes(&ObjectAttributes, &MultiKeyPathU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL); > - Status = ZwOpenKey(&hDevicesKey, KEY_ENUMERATE_SUB_KEYS, > &ObjectAttributes); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwOpenKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - > - pDeviceInformation = ExAllocatePool(PagedPool, DeviceInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - > - pValueInformation = ExAllocatePool(PagedPool, ValueInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - > - while (TRUE) > - { > - Status = ZwEnumerateKey(hDevicesKey, IndexDevice, > KeyBasicInformation, pDeviceInformation, DeviceInfoLength, &RequiredSize); > - if (Status == STATUS_NO_MORE_ENTRIES) > - break; > - else if (Status == STATUS_BUFFER_OVERFLOW || Status == > STATUS_BUFFER_TOO_SMALL) > - { > - ExFreePool(pDeviceInformation); > - DeviceInfoLength = RequiredSize; > - pDeviceInformation = ExAllocatePool(PagedPool, DeviceInfoLength); > - if (!pDeviceInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - Status = ZwEnumerateKey(hDevicesKey, IndexDevice, > KeyBasicInformation, pDeviceInformation, DeviceInfoLength, &RequiredSize); > - } > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwEnumerateKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - IndexDevice++; > - > - /* Open device key */ > - DeviceName.Length = DeviceName.MaximumLength = > pDeviceInformation->NameLength; > - DeviceName.Buffer = pDeviceInformation->Name; > - InitializeObjectAttributes(&ObjectAttributes, &DeviceName, > OBJ_KERNEL_HANDLE, hDevicesKey, NULL); > - Status = ZwOpenKey( > - &hDeviceKey, > - KEY_QUERY_VALUE, > - &ObjectAttributes); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwOpenKey() failed with status 0x%08lx\n", Status); > - goto cleanup; > - } > - > - /* Read identifier */ > - Status = ZwQueryValueKey(hDeviceKey, &IdentifierU, > KeyValuePartialInformation, pValueInformation, ValueInfoLength, > &RequiredSize); > - if (Status == STATUS_BUFFER_OVERFLOW || Status == > STATUS_BUFFER_TOO_SMALL) > - { > - ExFreePool(pValueInformation); > - ValueInfoLength = RequiredSize; > - pValueInformation = ExAllocatePool(PagedPool, ValueInfoLength); > - if (!pValueInformation) > - { > - DPRINT("ExAllocatePool() failed\n"); > - Status = STATUS_NO_MEMORY; > - goto cleanup; > - } > - Status = ZwQueryValueKey(hDeviceKey, &IdentifierU, > KeyValuePartialInformation, pValueInformation, ValueInfoLength, > &RequiredSize); > - } > - if (!NT_SUCCESS(Status)) > - { > - DPRINT("ZwQueryValueKey() failed with status 0x%08lx\n", Status); > - goto nextdevice; > - } > - else if (pValueInformation->Type != REG_SZ) > - { > - DPRINT("Wrong registry type: got 0x%lx, expected 0x%lx\n", > pValueInformation->Type, REG_SZ); > - goto nextdevice; > - } > - > - ValueName.Length = ValueName.MaximumLength = > pValueInformation->DataLength; > - ValueName.Buffer = (PWCHAR)pValueInformation->Data; > - if (ValueName.Length >= sizeof(WCHAR) && > ValueName.Buffer[ValueName.Length / sizeof(WCHAR) - 1] == UNICODE_NULL) > - ValueName.Length -= sizeof(WCHAR); > - if (RtlCompareUnicodeString(&ValueName, &AcpiBiosIdentifier, FALSE) > == 0) > - { > - DPRINT("Found ACPI BIOS\n"); > - ret = TRUE; > - goto cleanup; > - } > - > -nextdevice: > - ZwClose(hDeviceKey); > - hDeviceKey = NULL; > - } > - > -cleanup: > - if (pDeviceInformation) > - ExFreePool(pDeviceInformation); > - if (pValueInformation) > - ExFreePool(pValueInformation); > - if (hDevicesKey) > - ZwClose(hDevicesKey); > - if (hDeviceKey) > - ZwClose(hDeviceKey); > - return ret; > -#endif > + > + InitializeObjectAttributes(&ObjectAttributes, &KeyPathU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, NULL, NULL); > + Status = ZwOpenKey(&hPnpKey, KEY_QUERY_VALUE, &ObjectAttributes); > + if (NT_SUCCESS(Status)) > + { > + Status = ZwQueryValueKey(hPnpKey, > + &KeyNameU, > + KeyValuePartialInformation, > + NULL, > + 0, > + &DesiredLength); > + if ((Status == STATUS_BUFFER_TOO_SMALL) || > + (Status == STATUS_BUFFER_OVERFLOW)) > + { > + Length = DesiredLength; > + KeyInformation = ExAllocatePool(PagedPool, Length); > + if (KeyInformation) > + { > + Status = ZwQueryValueKey(hPnpKey, > + &KeyNameU, > + KeyValuePartialInformation, > + KeyInformation, > + Length, > + &DesiredLength); > + if (NT_SUCCESS(Status) && KeyInformation->DataLength == > sizeof(ULONG)) > + { > + KeyValue = (ULONG)(*KeyInformation->Data); > + } > + else > + { > + DPRINT1("ZwQueryValueKey(%wZ%wZ) failed\n", &KeyPathU, > &KeyNameU); > + KeyValue = 0; > + } > + > + ExFreePool(KeyInformation); > + } > + else > + { > + DPRINT1("Failed to allocate memory for registry query\n"); > + KeyValue = 0; > + } > + } > + else > + { > + DPRINT1("ZwQueryValueKey(%wZ%wZ) failed with status 0x%08lx\n", > &KeyPathU, &KeyNameU, Status); > + KeyValue = 0; > + } > + > + ZwClose(hPnpKey); > + } > + else > + { > + DPRINT1("ZwOpenKey(%wZ) failed with status 0x%08lx\n", &KeyPathU, > Status); > + } > + > + DPRINT1("Firmware mapper is %s\n", KeyValue != 0 ? "disabled" : > "enabled"); > + > + return (KeyValue != 0) ? TRUE : FALSE; > } > > NTSTATUS > @@ -2840,17 +2768,9 @@ > UNICODE_STRING EnumU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\SYSTEM\\CurrentControlSet\\Enum"); > UNICODE_STRING RootPathU = RTL_CONSTANT_STRING(L"Root"); > UNICODE_STRING MultiKeyPathU = > RTL_CONSTANT_STRING(L"\\Registry\\Machine\\HARDWARE\\DESCRIPTION\\System\\MultifunctionAdapter"); > - UNICODE_STRING DeviceDescU = RTL_CONSTANT_STRING(L"DeviceDesc"); > - UNICODE_STRING HardwareIDU = RTL_CONSTANT_STRING(L"HardwareID"); > - UNICODE_STRING LogConfU = RTL_CONSTANT_STRING(L"LogConf"); > - UNICODE_STRING HalAcpiDevice = RTL_CONSTANT_STRING(L"ACPI_HAL"); > - UNICODE_STRING HalAcpiId = RTL_CONSTANT_STRING(L"0000"); > - UNICODE_STRING HalAcpiDeviceDesc = RTL_CONSTANT_STRING(L"HAL ACPI"); > - UNICODE_STRING HalAcpiHardwareID = RTL_CONSTANT_STRING(L"*PNP0C08\0"); > OBJECT_ATTRIBUTES ObjectAttributes; > - HANDLE hEnum, hRoot, hHalAcpiDevice, hHalAcpiId, hLogConf; > + HANDLE hEnum, hRoot; > NTSTATUS Status; > - ULONG Disposition; > > InitializeObjectAttributes(&ObjectAttributes, &EnumU, OBJ_KERNEL_HANDLE > | OBJ_CASE_INSENSITIVE, NULL, NULL); > Status = ZwCreateKey(&hEnum, KEY_CREATE_SUB_KEY, &ObjectAttributes, 0, > NULL, 0, NULL); > @@ -2869,35 +2789,7 @@ > return Status; > } > > - if (IopIsAcpiComputer()) > - { > - InitializeObjectAttributes(&ObjectAttributes, &HalAcpiDevice, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hRoot, NULL); > - Status = ZwCreateKey(&hHalAcpiDevice, KEY_CREATE_SUB_KEY, > &ObjectAttributes, 0, NULL, 0, NULL); > - ZwClose(hRoot); > - if (!NT_SUCCESS(Status)) > - return Status; > - InitializeObjectAttributes(&ObjectAttributes, &HalAcpiId, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hHalAcpiDevice, NULL); > - Status = ZwCreateKey(&hHalAcpiId, KEY_CREATE_SUB_KEY | > KEY_SET_VALUE, &ObjectAttributes, 0, NULL, 0, &Disposition); > - ZwClose(hHalAcpiDevice); > - if (!NT_SUCCESS(Status)) > - return Status; > - if (Disposition == REG_CREATED_NEW_KEY) > - { > - Status = ZwSetValueKey(hHalAcpiId, &DeviceDescU, 0, REG_SZ, > HalAcpiDeviceDesc.Buffer, HalAcpiDeviceDesc.MaximumLength); > - if (NT_SUCCESS(Status)) > - Status = ZwSetValueKey(hHalAcpiId, &HardwareIDU, 0, > REG_MULTI_SZ, HalAcpiHardwareID.Buffer, HalAcpiHardwareID.MaximumLength); > - } > - if (NT_SUCCESS(Status)) > - { > - InitializeObjectAttributes(&ObjectAttributes, &LogConfU, > OBJ_KERNEL_HANDLE | OBJ_CASE_INSENSITIVE, hHalAcpiId, NULL); > - Status = ZwCreateKey(&hLogConf, 0, &ObjectAttributes, 0, NULL, > REG_OPTION_VOLATILE, NULL); > - if (NT_SUCCESS(Status)) > - ZwClose(hLogConf); > - } > - ZwClose(hHalAcpiId); > - return Status; > - } > - else > + if (!IopIsFirmwareMapperDisabled()) > { > Status = IopOpenRegistryKeyEx(&hEnum, NULL, &MultiKeyPathU, > KEY_ENUMERATE_SUB_KEYS); > if (!NT_SUCCESS(Status)) > @@ -2915,9 +2807,16 @@ > NULL, > 0); > ZwClose(hEnum); > - ZwClose(hRoot); > - return Status; > - } > + } > + else > + { > + /* Enumeration is disabled */ > + Status = STATUS_SUCCESS; > + } > + > + ZwClose(hRoot); > + > + return Status; > } > > NTSTATUS > > >

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53232: [NTOSKRNL] - Fix NULL termination of strings in IoGetDeviceProperty - Fixes garbage displayed in the Enumerator field of the device manager property page
by caemyr＠myopera.com 15 Aug '11

15 Aug '11

This revision breaks up MSVC iso booting: http://www.reactos.org/paste/index.php/9231/ -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 53232: [NTOSKRNL] - Fix NULL termination of strings in IoGetDeviceProperty - Fixes garbage displayed in the Enumerator field of the device manager property page
by Alex Ionescu 14 Aug '11

14 Aug '11

And, you have, of course, confirmed that this piece of kernel code is wrong, and that DevMgr/Cfgapi/SetupApi are doing the right thing, right? So if I was to reverse engineer ntoskrnl I wouldn't discover that it was actually doing the same thing as the un-"fixed" code, right? Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 10:44 AM, <cgutman(a)svn.reactos.org> wrote: > Author: cgutman > Date: Sun Aug 14 14:44:34 2011 > New Revision: 53232 > > URL: http://svn.reactos.org/svn/reactos?rev=53232&view=rev > Log: > [NTOSKRNL] > - Fix NULL termination of strings in IoGetDeviceProperty > - Fixes garbage displayed in the Enumerator field of the device manager > property page > > Modified: > trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > > Modified: trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.… > > ============================================================================== > --- trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/io/pnpmgr/pnpmgr.c [iso-8859-1] Sun Aug 14 > 14:44:34 2011 > @@ -3467,6 +3467,8 @@ > NTSTATUS Status = STATUS_BUFFER_TOO_SMALL; > GUID BusTypeGuid; > POBJECT_NAME_INFORMATION ObjectNameInfo = NULL; > + BOOLEAN NullTerminate = FALSE; > + > DPRINT("IoGetDeviceProperty(0x%p %d)\n", DeviceObject, DeviceProperty); > > /* Assume failure */ > @@ -3517,7 +3519,10 @@ > /* Get the name from the path */ > EnumeratorNameEnd = wcschr(DeviceInstanceName, > OBJ_NAME_PATH_SEPARATOR); > ASSERT(EnumeratorNameEnd); > - > + > + /* This string needs to be NULL-terminated */ > + NullTerminate = TRUE; > + > /* This is the format of the returned data */ > PIP_RETURN_DATA((EnumeratorNameEnd - DeviceInstanceName) * > sizeof(WCHAR), > DeviceInstanceName); > @@ -3567,7 +3572,10 @@ > /* It's up to the caller to try again */ > Status = STATUS_BUFFER_TOO_SMALL; > } > - > + > + /* This string needs to be NULL-terminated */ > + NullTerminate = TRUE; > + > /* Return if successful */ > if (NT_SUCCESS(Status)) > PIP_RETURN_DATA(ObjectNameInfo->Name.Length, > > ObjectNameInfo->Name.Buffer); > @@ -3633,15 +3641,14 @@ > else if (NT_SUCCESS(Status)) > { > /* We know up-front how much data to expect, check the caller's > buffer */ > - *ResultLength = ReturnLength; > - if (ReturnLength <= BufferLength) > + *ResultLength = ReturnLength + (NullTerminate ? > sizeof(UNICODE_NULL) : 0); > + if (*ResultLength <= BufferLength) > { > /* Buffer is all good, copy the data */ > RtlCopyMemory(PropertyBuffer, Data, ReturnLength); > > - /* Check for properties that require a null-terminated string > */ > - if ((DeviceProperty == DevicePropertyEnumeratorName) || > - (DeviceProperty == > DevicePropertyPhysicalDeviceObjectName)) > + /* Check if we need to NULL-terminate the string */ > + if (NullTerminate) > { > /* Terminate the string */ > ((PWCHAR)PropertyBuffer)[ReturnLength / sizeof(WCHAR)] = > UNICODE_NULL; > > >

3 2

Re: [ros-dev] [ros-diffs] [akhaldi] 53230: [AUTOCHK][CMD][TASKMGR] * Exclude some indirectly included headers.
by Alex Ionescu 14 Aug '11

14 Aug '11

Never depend on this! Depending on funcs.h including types.h of the same module is fine, but you should not depend on rtlfuncs dependong on pstypes. Best regards, Alex Ionescu On Sun, Aug 14, 2011 at 8:57 AM, <akhaldi(a)svn.reactos.org> wrote: > #define NTOS_MODE_USER > -#include <ndk/pstypes.h> > #include <ndk/rtlfuncs.h> >

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 53201: [ADVAPI32] Fix EnumServicesStatusEx[A/W]: - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer to REnumSe...
by Jérôme Gardou 14 Aug '11

14 Aug '11

Passing [in] and [unique] to RQueryServiceonfigW is not a solution either. It was a quick and dirty hack to get things working. I'm working on a proper solution right now, unless you already have something in your hat :-) Le 13/08/2011 12:53, ekohl(a)svn.reactos.org a écrit : > Author: ekohl > Date: Sat Aug 13 10:53:15 2011 > New Revision: 53201 > > URL: http://svn.reactos.org/svn/reactos?rev=53201&view=rev > Log: > [ADVAPI32] > Fix EnumServicesStatusEx[A/W]: > - If lpServices is NULL or cbBufSize is less than sizeof(ENUM_SERVICE_STATUS_PROCESS) pass a pointer to an internal status buffer to REnumServicesStatusExA/W. Adding 'in' and 'unique' attributes in the idl file is NOT an option because this is not compatible with Windows. > - Check the InfoLevel. > > Modified: > trunk/reactos/dll/win32/advapi32/service/scm.c > > Modified: trunk/reactos/dll/win32/advapi32/service/scm.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/advapi32/service… > ============================================================================== > --- trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/advapi32/service/scm.c [iso-8859-1] Sat Aug 13 10:53:15 2011 > @@ -1150,7 +1150,9 @@ > LPDWORD lpResumeHandle, > LPCSTR pszGroupName) > { > + ENUM_SERVICE_STATUS_PROCESSA ServiceStatus; > LPENUM_SERVICE_STATUS_PROCESSA lpStatusPtr; > + DWORD dwBufferSize; > DWORD dwError; > DWORD dwCount; > > @@ -1166,6 +1168,18 @@ > { > SetLastError(ERROR_INVALID_HANDLE); > return FALSE; > + } > + > + if (lpServices == NULL || > + cbBufSize< sizeof(ENUM_SERVICE_STATUS_PROCESSA)) > + { > + lpStatusPtr =&ServiceStatus; > + dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSA); > + } > + else > + { > + lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices; > + dwBufferSize = cbBufSize; > } > > RpcTryExcept > @@ -1174,8 +1188,8 @@ > InfoLevel, > dwServiceType, > dwServiceState, > - (LPBYTE)lpServices, > - cbBufSize, > + (LPBYTE)lpStatusPtr, > + dwBufferSize, > pcbBytesNeeded, > lpServicesReturned, > lpResumeHandle, > @@ -1189,18 +1203,20 @@ > > if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA) > { > - lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSA)lpServices; > - for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + if (InfoLevel == SC_ENUM_PROCESS_INFO) > { > - if (lpStatusPtr->lpServiceName) > - lpStatusPtr->lpServiceName = > - (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > - > - if (lpStatusPtr->lpDisplayName) > - lpStatusPtr->lpDisplayName = > - (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > - > - lpStatusPtr++; > + for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + { > + if (lpStatusPtr->lpServiceName) > + lpStatusPtr->lpServiceName = > + (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > + > + if (lpStatusPtr->lpDisplayName) > + lpStatusPtr->lpDisplayName = > + (LPSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > + > + lpStatusPtr++; > + } > } > } > > @@ -1234,11 +1250,31 @@ > LPDWORD lpResumeHandle, > LPCWSTR pszGroupName) > { > + ENUM_SERVICE_STATUS_PROCESSW ServiceStatus; > LPENUM_SERVICE_STATUS_PROCESSW lpStatusPtr; > + DWORD dwBufferSize; > DWORD dwError; > DWORD dwCount; > > TRACE("EnumServicesStatusExW() called\n"); > + > + if (InfoLevel != SC_ENUM_PROCESS_INFO) > + { > + SetLastError(ERROR_INVALID_LEVEL); > + return FALSE; > + } > + > + if (lpServices == NULL || > + cbBufSize< sizeof(ENUM_SERVICE_STATUS_PROCESSW)) > + { > + lpStatusPtr =&ServiceStatus; > + dwBufferSize = sizeof(ENUM_SERVICE_STATUS_PROCESSW); > + } > + else > + { > + lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices; > + dwBufferSize = cbBufSize; > + } > > RpcTryExcept > { > @@ -1246,8 +1282,8 @@ > InfoLevel, > dwServiceType, > dwServiceState, > - (LPBYTE)lpServices, > - cbBufSize, > + (LPBYTE)lpStatusPtr, > + dwBufferSize, > pcbBytesNeeded, > lpServicesReturned, > lpResumeHandle, > @@ -1261,18 +1297,20 @@ > > if (dwError == ERROR_SUCCESS || dwError == ERROR_MORE_DATA) > { > - lpStatusPtr = (LPENUM_SERVICE_STATUS_PROCESSW)lpServices; > - for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + if (InfoLevel == SC_ENUM_PROCESS_INFO) > { > - if (lpStatusPtr->lpServiceName) > - lpStatusPtr->lpServiceName = > - (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > - > - if (lpStatusPtr->lpDisplayName) > - lpStatusPtr->lpDisplayName = > - (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > - > - lpStatusPtr++; > + for (dwCount = 0; dwCount< *lpServicesReturned; dwCount++) > + { > + if (lpStatusPtr->lpServiceName) > + lpStatusPtr->lpServiceName = > + (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpServiceName); > + > + if (lpStatusPtr->lpDisplayName) > + lpStatusPtr->lpDisplayName = > + (LPWSTR)((ULONG_PTR)lpServices + (ULONG_PTR)lpStatusPtr->lpDisplayName); > + > + lpStatusPtr++; > + } > } > } > > >

3 3

Re: [ros-dev] [ros-diffs] [jgardou] 53158: [TOOLS] - sync wpp, widl and wrc with wine 1.3.26
by Jérôme Gardou 09 Aug '11

09 Aug '11

CMake users : please don't forget to rebuild your host tools :-) Non cmake user : don't worry, this user unfriendly-ness is being worked on. Le 10/08/2011 00:51, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Tue Aug 9 22:51:55 2011 > New Revision: 53158 > > URL: http://svn.reactos.org/svn/reactos?rev=53158&view=rev > Log: > [TOOLS] > - sync wpp, widl and wrc with wine 1.3.26 > > Added: > trunk/reactos/tools/wrc/po.c (with props) > Modified: > trunk/reactos/include/host/nls.h > trunk/reactos/include/host/wine/wpp.h > trunk/reactos/tools/widl/client.c > trunk/reactos/tools/widl/expr.c > trunk/reactos/tools/widl/hash.c > trunk/reactos/tools/widl/header.c > trunk/reactos/tools/widl/header.h > trunk/reactos/tools/widl/parser.l > trunk/reactos/tools/widl/parser.tab.c > trunk/reactos/tools/widl/parser.tab.h > trunk/reactos/tools/widl/parser.y > trunk/reactos/tools/widl/parser.yy.c > trunk/reactos/tools/widl/proxy.c > trunk/reactos/tools/widl/register.c > trunk/reactos/tools/widl/server.c > trunk/reactos/tools/widl/typegen.c > trunk/reactos/tools/widl/typegen.h > trunk/reactos/tools/widl/typelib.c > trunk/reactos/tools/widl/typelib_struct.h > trunk/reactos/tools/widl/utils.c > trunk/reactos/tools/widl/utils.h > trunk/reactos/tools/widl/widl.c > trunk/reactos/tools/widl/widl.h > trunk/reactos/tools/widl/widl.rbuild > trunk/reactos/tools/widl/widltypes.h > trunk/reactos/tools/widl/write_msft.c > trunk/reactos/tools/wpp/lex.yy.c > trunk/reactos/tools/wpp/ppl.l > trunk/reactos/tools/wpp/ppy.tab.c > trunk/reactos/tools/wpp/ppy.tab.h > trunk/reactos/tools/wpp/ppy.y > trunk/reactos/tools/wpp/preproc.c > trunk/reactos/tools/wpp/wpp.c > trunk/reactos/tools/wpp/wpp_private.h > trunk/reactos/tools/wrc/CMakeLists.txt > trunk/reactos/tools/wrc/dumpres.c > trunk/reactos/tools/wrc/genres.c > trunk/reactos/tools/wrc/lex.yy.c > trunk/reactos/tools/wrc/newstruc.c > trunk/reactos/tools/wrc/newstruc.h > trunk/reactos/tools/wrc/parser.h > trunk/reactos/tools/wrc/parser.l > trunk/reactos/tools/wrc/parser.tab.c > trunk/reactos/tools/wrc/parser.tab.h > trunk/reactos/tools/wrc/parser.y > trunk/reactos/tools/wrc/translation.c > trunk/reactos/tools/wrc/utils.c > trunk/reactos/tools/wrc/utils.h > trunk/reactos/tools/wrc/wrc.c > trunk/reactos/tools/wrc/wrc.h > trunk/reactos/tools/wrc/wrc.rbuild > trunk/reactos/tools/wrc/wrcrostypes.h > trunk/reactos/tools/wrc/wrctypes.h > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/include/host/nls.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/nls.h?rev=531… > > Modified: trunk/reactos/include/host/wine/wpp.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/host/wine/wpp.h?re… > > Modified: trunk/reactos/tools/widl/client.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/client.c?rev=53… > > Modified: trunk/reactos/tools/widl/expr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/expr.c?rev=5315… > > Modified: trunk/reactos/tools/widl/hash.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/hash.c?rev=5315… > > Modified: trunk/reactos/tools/widl/header.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.c?rev=53… > > Modified: trunk/reactos/tools/widl/header.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/header.h?rev=53… > > Modified: trunk/reactos/tools/widl/parser.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.l?rev=53… > > Modified: trunk/reactos/tools/widl/parser.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.c?re… > > Modified: trunk/reactos/tools/widl/parser.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.tab.h?re… > > Modified: trunk/reactos/tools/widl/parser.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.y?rev=53… > > Modified: trunk/reactos/tools/widl/parser.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/parser.yy.c?rev… > > Modified: trunk/reactos/tools/widl/proxy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/proxy.c?rev=531… > > Modified: trunk/reactos/tools/widl/register.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/register.c?rev=… > > Modified: trunk/reactos/tools/widl/server.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/server.c?rev=53… > > Modified: trunk/reactos/tools/widl/typegen.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typegen.c?rev=5… > > Modified: trunk/reactos/tools/widl/typegen.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typegen.h?rev=5… > > Modified: trunk/reactos/tools/widl/typelib.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typelib.c?rev=5… > > Modified: trunk/reactos/tools/widl/typelib_struct.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/typelib_struct.… > > Modified: trunk/reactos/tools/widl/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/utils.c?rev=531… > > Modified: trunk/reactos/tools/widl/utils.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/utils.h?rev=531… > > Modified: trunk/reactos/tools/widl/widl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.c?rev=5315… > > Modified: trunk/reactos/tools/widl/widl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.h?rev=5315… > > Modified: trunk/reactos/tools/widl/widl.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widl.rbuild?rev… > > Modified: trunk/reactos/tools/widl/widltypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/widltypes.h?rev… > > Modified: trunk/reactos/tools/widl/write_msft.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/widl/write_msft.c?re… > > Modified: trunk/reactos/tools/wpp/lex.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/lex.yy.c?rev=531… > > Modified: trunk/reactos/tools/wpp/ppl.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppl.l?rev=53158&… > > Modified: trunk/reactos/tools/wpp/ppy.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.tab.c?rev=53… > > Modified: trunk/reactos/tools/wpp/ppy.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.tab.h?rev=53… > > Modified: trunk/reactos/tools/wpp/ppy.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/ppy.y?rev=53158&… > > Modified: trunk/reactos/tools/wpp/preproc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/preproc.c?rev=53… > > Modified: trunk/reactos/tools/wpp/wpp.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/wpp.c?rev=53158&… > > Modified: trunk/reactos/tools/wpp/wpp_private.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wpp/wpp_private.h?re… > > Modified: trunk/reactos/tools/wrc/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/CMakeLists.txt?r… > > Modified: trunk/reactos/tools/wrc/dumpres.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/dumpres.c?rev=53… > > Modified: trunk/reactos/tools/wrc/genres.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/genres.c?rev=531… > > Modified: trunk/reactos/tools/wrc/lex.yy.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/lex.yy.c?rev=531… > > Modified: trunk/reactos/tools/wrc/newstruc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/newstruc.c?rev=5… > > Modified: trunk/reactos/tools/wrc/newstruc.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/newstruc.h?rev=5… > > Modified: trunk/reactos/tools/wrc/parser.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.h?rev=531… > > Modified: trunk/reactos/tools/wrc/parser.l > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.l?rev=531… > > Modified: trunk/reactos/tools/wrc/parser.tab.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.tab.c?rev… > > Modified: trunk/reactos/tools/wrc/parser.tab.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.tab.h?rev… > > Modified: trunk/reactos/tools/wrc/parser.y > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/parser.y?rev=531… > > Added: trunk/reactos/tools/wrc/po.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/po.c?rev=53158&v… > > Modified: trunk/reactos/tools/wrc/translation.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/translation.c?re… > > Modified: trunk/reactos/tools/wrc/utils.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/utils.c?rev=5315… > > Modified: trunk/reactos/tools/wrc/utils.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/utils.h?rev=5315… > > Modified: trunk/reactos/tools/wrc/wrc.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.c?rev=53158&… > > Modified: trunk/reactos/tools/wrc/wrc.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.h?rev=53158&… > > Modified: trunk/reactos/tools/wrc/wrc.rbuild > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrc.rbuild?rev=5… > > Modified: trunk/reactos/tools/wrc/wrcrostypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrcrostypes.h?re… > > Modified: trunk/reactos/tools/wrc/wrctypes.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/tools/wrc/wrctypes.h?rev=5… > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.
by Ged Murphy 09 Aug '11

09 Aug '11

Maybe you could add all the other changes with checkin comments such as "this should be sent upstream to wine" to that plan too :) That practice has become quite common these days. Ged. Sent from my Windows Phone From: Jérôme Gardou Sent: 09 August 2011 22:32 To: ros-dev(a)reactos.org Subject: Re: [ros-dev] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic. Don't worry, it's part of the plan! Le 09/08/2011 23:29, Ged Murphy a écrit : > Call me nuts, but why don't you add a ros_diff patch so it doesn't get > lost again??? > From: jgardou(a)svn.reactos.org > Sent: 09 August 2011 18:43 > To: ros-diffs(a)reactos.org > Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros > specific change. Thanks Vic. > Author: jgardou > Date: Tue Aug 9 17:43:37 2011 > New Revision: 53152 > > URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev > Log: > [RPCRT4] > - restore lost ros specific change. > Thanks Vic. > > Modified: > trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > > Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh… > ============================================================================== > --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug > 9 17:43:37 2011 > @@ -6159,6 +6159,7 @@ > case RPC_FC_WCHAR: > case RPC_FC_SHORT: > case RPC_FC_USHORT: > + case RPC_FC_ENUM16: > { > USHORT d; > align_pointer(&pStubMsg->Buffer, sizeof(USHORT)); > > _______________________________________________ > 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] [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic.
by Ged Murphy 09 Aug '11

09 Aug '11

Call me nuts, but why don't you add a ros_diff patch so it doesn't get lost again??? From: jgardou(a)svn.reactos.org Sent: 09 August 2011 18:43 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [jgardou] 53152: [RPCRT4] - restore lost ros specific change. Thanks Vic. Author: jgardou Date: Tue Aug 9 17:43:37 2011 New Revision: 53152 URL: http://svn.reactos.org/svn/reactos?rev=53152&view=rev Log: [RPCRT4] - restore lost ros specific change. Thanks Vic. Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c Modified: trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/rpcrt4/ndr_marsh… ============================================================================== --- trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] (original) +++ trunk/reactos/dll/win32/rpcrt4/ndr_marshall.c [iso-8859-1] Tue Aug 9 17:43:37 2011 @@ -6159,6 +6159,7 @@ case RPC_FC_WCHAR: case RPC_FC_SHORT: case RPC_FC_USHORT: + case RPC_FC_ENUM16: { USHORT d; align_pointer(&pStubMsg->Buffer, sizeof(USHORT));

2 1

BuildBot ISOs
by Colin Finck 07 Aug '11

07 Aug '11

Hello everybody, Due to a mistake from my side, the uploaded BuildBot 7zipped ISO files in the revision range from 53120 to 53127 as created by the Debug Buildslave contained the very same ISO of revision 53119. This has been fixed in the meantime, the faulty files have been removed from the server and at least the 7-Zip archive of revision 53127 has been recreated. On the other hand, Olaf and I have finally enabled his server to upload ISOs to http://iso.reactos.org. These ISOs are built by his Buildslave running under Windows, already using the new CMake buildsystem and incorporating our regression tests and the Gecko CAB file. I might have time to add another filter to http://reactos.org/getbuilds soon, so that everybody can download the new ISOs easily. - Colin

1 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev