- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [cgutman] 56043: [NEWCC] - Turn NewCC on temporarily for some testing - Patchbot is broken so I had to do it this way :(‏
by Pierre Schweitzer 05 Mar '12

05 Mar '12

Nice try! However it failed on KVM: http://build.reactos.org/builders/Linux_AMD64_1% 20KVM-CMake-Test/builds/255/steps/test/logs/stdio Regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

3 2

Fwd: buildbot failure in ReactOS on CMake_x86_GCCWin Debug
by caemyr＠myopera.com 04 Mar '12

04 Mar '12

Could it be a ccache miss? Failed to read source file: 0 mingw32-make.exe[3]: *** [boot/freeldr/freeldr/frldr16.bin] Error -4 [ 98%] [ 98%] mingw32-make.exe[2]: *** [boot/freeldr/freeldr/CMakeFiles/freeldr.dir/all] Error 2 mingw32-make.exe[2]: *** Waiting for unfinished jobs.... ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Date: Sun, 04 Mar 2012 20:03:52 +0000 Subject: buildbot failure in ReactOS on CMake_x86_GCCWin Debug The Buildbot has finished a build on builder CMake_x86_GCCWin Debug while building ReactOS. Full details are available at: http://build.reactos.org/builders/CMake_x86_GCCWin%20Debug/builds/2966 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_1 Build Reason: scheduler Build Source Stamp: 56010 Blamelist: sir_richard BUILD FAILED: failed building bootcd sincerely, -The Buildbot -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [cgutman] 55978: [STORAGE] - Back by popular demand, the storage driver to end all storage drivers, uniata! - I had forgotten how many issues atapi had itself and the hardware compatibility improve...‏
by Pierre Schweitzer 04 Mar '12

04 Mar '12

Hi, this revision actually fixed KVM testbot (ie r55980 was not mandatory). But this has been hidden by two things: - sysreg regression: this has been kicked out by now; - trunk regression: introduced by r55977, it is still present. And results couldn't be sent to testman since rosautotest got messed up and ran same tests several times; Sorry for the issues caused by sysreg regression. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] buildbot failure in ReactOS on CMake_x86_MSVCWin Debug
by caemyr＠myopera.com 03 Mar '12

03 Mar '12

Cabman error, build was restarted and went fine On Sat, Mar 3, 2012, at 08:26 PM, buildbot(a)reactos.org wrote: > The Buildbot has finished a build on builder CMake_x86_MSVCWin Debug > while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/596 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_1a > > Build Reason: scheduler > Build Source Stamp: 55970 > Blamelist: tkreuzer > > BUILD FAILED: failed building bootcd > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-builds] Linux_AMD64_1 KVM-CMake-Test: build failed
by Pierre Schweitzer 03 Mar '12

03 Mar '12

This is due to an issue within both ReactOS and sysreg. ReactOS appears not to boot any longer with r55879 on KVM, and crashing during ntoskrnl init on CD. Sysreg is also not catching the crash, nor hitting the timeout and so is not killing the VM. And then, buildbot is unable to start any new test due to the frozen VM. I have killed the frozen VM and restarted HEAD (ie, r55886 testing). If the fix has been really committed with r55880, it should work properly. Will investigate the issue ASAP, to ensure it doesn't happen any more. Le lundi 27 février 2012 à 17:40 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Linux_AMD64_1 KVM-CMake-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Linux_AMD64_1%20KVM-CMake-Test/builds/76 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: Triggerable(Linux_AMD64_1 KVM-CMake-Test Trigger) > Build Source Stamp: 55886 > Blamelist: ion > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 1

Re: [ros-dev] buildbot failure in ReactOS on CMake_x86_MSVCWin Debug
by caemyr＠myopera.com 02 Mar '12

02 Mar '12

Cabman failure. Repeated. On Fri, Mar 2, 2012, at 10:24 PM, buildbot(a)reactos.org wrote: > The Buildbot has finished a build on builder CMake_x86_MSVCWin Debug > while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/566 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_1a > > Build Reason: scheduler > Build Source Stamp: 55939 > Blamelist: khornicek > > BUILD FAILED: failed building bootcd > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Cmake result differences
by Bernd Blaauw 01 Mar '12

01 Mar '12

I was wondering why the Cmake results are different between the Windows/ReactOS and Unix/Linux platforms. The compressed trunk CD images available for download differ by about 6MB. Expecting identical output (checksums, file sizes) on different platforms even with the same compiler isn't realistic ofcourse but above mentioned 6MB is a bit much. Creating dbgwin-builds makes sense, but if the Unix builder builds faster and smaller builds, and makes them earlier available for download, what's the point in making the Windows build available publicly? Would it make more sense to offer MSVC builds if license-technical allowed? Or automated builds of CLT-type (combined installCD + liveCD) ? Bernd

5 8

Re: [ros-dev] [ros-diffs] [tkreuzer] 55943: Party revert r55722: "[CSRSRV]: Some misc cleanup of dead code. No functional change.", which caused MSVC builds to hang on 2nd stage
by Alex Ionescu 01 Mar '12

01 Mar '12

Uhhh.... While I'm happy you have MSVC working again.... it's kind of weird this is fixing it for you? Does the DPRINT1 show up? -- Best regards, Alex Ionescu On 2012-03-01, at 6:17 AM, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Mar 1 14:17:23 2012 > New Revision: 55943 > > URL: http://svn.reactos.org/svn/reactos?rev=55943&view=rev > Log: > Party revert r55722: "[CSRSRV]: Some misc cleanup of dead code. No functional change.", which caused MSVC builds to hang on 2nd stage > > Modified: > trunk/reactos/subsystems/win32/csrss/csrss.c > > Modified: trunk/reactos/subsystems/win32/csrss/csrss.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/csrss/csr… > ============================================================================== > --- trunk/reactos/subsystems/win32/csrss/csrss.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/win32/csrss/csrss.c [iso-8859-1] Thu Mar 1 14:17:23 2012 > @@ -41,7 +41,7 @@ > { > KPRIORITY BasePriority = (8 + 1) + 4; > NTSTATUS Status; > - ULONG Response; > + //ULONG Response; > UNREFERENCED_PARAMETER(envp); > UNREFERENCED_PARAMETER(DebugFlag); > > @@ -60,12 +60,14 @@ > { > /* Raise a hard error */ > DPRINT1("CSRSS: Could not raise IOPL: %x\n", Status); > +#if 0 > Status = NtRaiseHardError(STATUS_IO_PRIVILEGE_FAILED, > 0, > 0, > NULL, > OptionOk, > &Response); > +#endif > } > > /* Initialize CSR through CSRSRV */ > >

1 0

Rasberry Pi
by Ged Murphy 29 Feb '12

29 Feb '12

It looks like the model B boards are now in manufacture. http://www.raspberrypi.org/archives/509 There are only 10k being made being made in this batch and demand is really high, so I doubt they'll last longer than a few minutes. With only 256MB RAM available, I doubt Windows 8 will ever run on it although Windows Embedded Compact 7 might. I know the reactos arm port is still a way off, but this could be a golden opportunity for reactos. At $25 per computer, they're gonna sell hundreds of thousands of these things and most buyers will be enthusiasts/developers. Ged.

18 38

KVM regtest CDs available
by Pierre Schweitzer 29 Feb '12

29 Feb '12

Hi, to address an increasing ReactOS developers demand, you'll be able to find regtest CDs used by KVM testbot at the URL: http://iso.reactos.org/regtestcd/ I think I'll probably put the KVM testbot machine specifications on the wiki to help as well. Regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-builds] CMake_x86_GCCLin Debug: build failed
by Pierre Schweitzer 28 Feb '12

28 Feb '12

This is due to the new way test CDs are handled on the builder. I'm on it to get it back to working state. Le mardi 28 février 2012 à 22:22 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder CMake_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_GCCLin%20Debug/builds/96 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 55909 > Blamelist: janderwald > > BUILD FAILED: failed compile_5 > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

mikeos
by mikey sibert 27 Feb '12

27 Feb '12

can you send me a copy of mikeos 4.3 because it is blocked for me and i cant download it i am going to base a 16 bit os off of it

2 1

February 2012 Meeting Minutes
by Amine Khaldi 27 Feb '12

27 Feb '12

February 2012 Meeting Minutes 2012-02-23 19:45 UTC Fezile, #meeting Proceedings =========== * Meeting started at 19:45 UTC by Aleksey Bragin. * Point 1: Release status: 0.3.15 --------------------------------- * Aleksey Bragin proposed that we prepare trunk and release 0.3.15, as it is now, before anything major happens. Several members then wondered about the status of USB and the "mshtml bug". Jerome Gardou explained a bit about how the mshtml bug is far from completely being fixed, because if you look at testbot's results, there are still some problems with ASSERTs hit and some bad pagefaults happening when paging out. * A lengthy discussion occurred, about how ready trunk is, whether it's in a better state than 0.3.14, the state of the theme to be bundled with ros, the plan for CLT, whether we should go 0.4<something> or 0.3.15... This was settled through a voting: "Do you agree to release 0.3.15 with current trunk features, before CLT?". * The total number of votes was 21, with 11 votes as Yes, 5 as No, and 5 abstentions. As a result, we will be having a 0.3.15 release with CLT being the deadline. * Point 2: New website status and migration plans ------------------------------------------------- * Amine Khaldi gave a quick summary on the state of the website revamp: - Quite some progress has been made in the theming department, and it's visible from the playground. It's starting to look a lot like the current one, which means it's almost done (only some issues are left). - Maciej Bialas has been investigating how to import users from the RosCMS. We will most likely need to compromise: members will have to reenter passwords when we migrate, but we'll see. - Amine Khaldi then mentioned that we need help from web devs familiar with Drupal. Alexander Rechitskiy mentioned that he has a guy that wants to be part of the web team, and he passes his info to Amine to establish the contact. - He also mentioned that Maciej is very busy, so the progress will slow down, and that the current short term plan is to continue the theming work, provide a way to import users, import the rest of data from wiki/bugzilla...etc and finally add the phpbb bridge. * He then summarized the summary by saying: We needs skillful drupal guys, we're almost there, and that's it. * Point 3: CMake migration and finally abandoning RBuild -------------------------------------------------------- * Amine Khaldi suggested that it's time to ditch rbuild, as he suspects most of our members have migrated already. Agreement on that, from ours members, was unprecedented as *everyone* were on favor of this :) * We agreed on doing the necessary commits/infrastructure changes ASAP, ie "tonight" (relative to the meeting of course), but that didn't happen just yet so it's just a matter of time. Amine Khaldi wants to do the honors (the commit that will remove rbuild and its related files). * Amine Khaldi also mentioned that he's preparing a nice little surprise for major build performance boost, on many levels, so stay tuned guys ;) * Jerome Gardou explained that he'll be handling the PCH support to get it to a much better state than it is right now. * Point 4: Added per Amine Khaldi's request: GSoC preparations -------------------------------------------------------------- * Amine Khaldi explained that he created a Google Doc and invited the interested members. He asked the members to collaborate and shape up an excellent ideas list, projects that fit in GSoC at both the time and complexity levels. * Colin suggested building up on the last year in terms of informative content (wiki pages from last year), covering questions about how we deal with students, our application form... etc. * Meeting closed at 21:45 UTC by Aleksey Bragin. * Minutes written by Amine Khaldi.

13 19

Re: [ros-dev] [ros-diffs] [pschweitzer] 55861: [USER32] Correct user32 japanese translation (and fix build as well)
by Amine Khaldi 25 Feb '12

25 Feb '12

> [USER32] > Correct user32 japanese translation (and fix build as well) For the record, this doesn't fix build because: 1) It was not broken (hint: r55860). 2) The module that broke build back then was shell32, not user32. Regards, Amine.

2 1

Re: [ros-dev] [ros-diffs] [dgorbachev] 55835: [FREELDR][NTOSKRNL] Update linker scripts.
by Timo Kreuzer 24 Feb '12

24 Feb '12

Hi, Can we rename linker scripts to .lds or something? It's annoying to see the shortcut overlay instead of tsvn overlay on the .lnk files. Regards, Timo Am 23.02.2012 19:59, schrieb dgorbachev(a)svn.reactos.org: > Author: dgorbachev > Date: Thu Feb 23 18:59:24 2012 > New Revision: 55835 > > URL: http://svn.reactos.org/svn/reactos?rev=55835&view=rev > Log: > [FREELDR][NTOSKRNL] > Update linker scripts. > > Modified: > trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk > trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk > > Modified: trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/freel… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/freeldr_i386.lnk [iso-8859-1] Thu Feb 23 18:59:24 2012 > @@ -23,6 +23,15 @@ > __bss_end__ = . ; > } > > + .stab BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.stab) > + } > + .stabstr BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.stabstr) > + } > + > /* DWARF debug sections. > Symbols in the DWARF debugging sections are relative to the beginning > of the section. Unlike other targets that fake this by putting the > @@ -43,7 +52,7 @@ > /* DWARF 2. */ > .debug_info BLOCK(__section_alignment__) (NOLOAD) : > { > - *(.debug_info) *(.gnu.linkonce.wi.*) > + *(.debug_info .gnu.linkonce.wi.*) > } > .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > { > @@ -98,7 +107,7 @@ > /* DWARF 4. */ > .debug_types BLOCK(__section_alignment__) (NOLOAD) : > { > - *(.debug_types) *(.gnu.linkonce.wt.*) > + *(.debug_types .gnu.linkonce.wt.*) > } > > /DISCARD/ : > > Modified: trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk… > ============================================================================== > --- trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ntoskrnl_i386.lnk [iso-8859-1] Thu Feb 23 18:59:24 2012 > @@ -1,105 +1,150 @@ > -OUTPUT_FORMAT(pei-i386) > -ENTRY(_mainCRTStartup) > SECTIONS > { > - .text __image_base__ + __section_alignment__ : > + .text __image_base__ + __section_alignment__ : > { > - __text_start__ = .; > - *(.init) > *(.text) > - *(SORT(.text$*)) > - *(.glue_7t) > - *(.glue_7) > - ___CTOR_LIST__ = .; __CTOR_LIST__ = . ; > - LONG (-1); *(.ctors); *(.ctor); LONG (0); > - ___DTOR_LIST__ = .; __DTOR_LIST__ = . ; > - LONG (-1); *(.dtors); *(.dtor); LONG (0); > - *(.fini) > - /* ??? Why is .gcc_exc here? */ > - *(.gcc_exc) > - __text_end__ = .; > - *(.gcc_except_table) > + *(SORT(.text*)) > } > - /* The Cygwin32 library uses a section to avoid copying certain data > - on fork. This used to be named ".data". The linker used > - to include this between __data_start__ and __data_end__, but that > - breaks building the cygwin32 dll. Instead, we name the section > - ".data_cygwin_nocopy" and explictly include it after __data_end__. */ > - .data BLOCK(__section_alignment__) : > + > + .data BLOCK(__section_alignment__) : > { > - __data_start__ = . ; > *(.data) > - *(.data2) > - *(SORT(.data$*)) > - __data_end__ = . ; > - *(.data_cygwin_nocopy) > + *(SORT(.data*)) > } > + > .rdata BLOCK(__section_alignment__) : > { > *(.rdata) > - *(SORT(.rdata$*)) > + *(SORT(.rdata*)) > *(.eh_frame) > } > + > .edata BLOCK(__section_alignment__) : > { > *(.edata) > } > + > /DISCARD/ : > { > - *(.debug$S) > - *(.debug$T) > - *(.debug$F) > *(.drectve) > + *(.gnu.lto_*) > } > > .idata BLOCK(__section_alignment__) : > { > /* This cannot currently be handled with grouped sections. > - See pe.em:sort_sections. */ > + See pe.em:sort_sections. */ > SORT(*)(.idata$2) > SORT(*)(.idata$3) > /* These zeroes mark the end of the import list. */ > LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); > - SORT(*)(.idata$4) > + SORT(*)(.idata$4) > SORT(*)(.idata$5) > SORT(*)(.idata$6) > SORT(*)(.idata$7) > } > - .CRT BLOCK(__section_alignment__) : > - { > - *(SORT(.CRT$*)) > - } > + > .rsrc BLOCK(__section_alignment__) : > - { > + { > *(.rsrc) > *(SORT(.rsrc$*)) > } > + > .bss BLOCK(__section_alignment__) : > { > - __bss_start__ = . ; > *(.bss) > *(COMMON) > - __bss_end__ = . ; > } > + > .reloc BLOCK(__section_alignment__) : > - { > + { > *(.reloc) > - /* These zeroes mark the end of the reloc section. */ > - LONG (0); LONG (0); LONG (0); LONG (0); LONG (0); > } > + > .stab BLOCK(__section_alignment__) (NOLOAD) : > { > - [ .stab ] > + *(.stab) > } > .stabstr BLOCK(__section_alignment__) (NOLOAD) : > { > - [ .stabstr ] > + *(.stabstr) > } > - INIT BLOCK(__section_alignment__) : > + > + /* DWARF debug sections. > + Symbols in the DWARF debugging sections are relative to the beginning > + of the section. Unlike other targets that fake this by putting the > + section VMA at 0, the PE format will not allow it. */ > + /* DWARF 1.1 and DWARF 2. */ > + .debug_aranges BLOCK(__section_alignment__) (NOLOAD) : > { > - __init_start__ = . ; > - *(INIT) > - __init_end__ = . ; > + *(.debug_aranges) > + } > + .debug_pubnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_pubnames) > + } > + .debug_pubtypes BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_pubtypes) > + } > + /* DWARF 2. */ > + .debug_info BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_info .gnu.linkonce.wi.*) > + } > + .debug_abbrev BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_abbrev) > + } > + .debug_line BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_line) > + } > + .debug_frame BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_frame*) > + } > + .debug_str BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_str) > + } > + .debug_loc BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_loc) > + } > + .debug_macinfo BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_macinfo) > + } > + /* SGI/MIPS DWARF 2 extensions. */ > + .debug_weaknames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_weaknames) > + } > + .debug_funcnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_funcnames) > + } > + .debug_typenames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_typenames) > + } > + .debug_varnames BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_varnames) > + } > + .debug_macro BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_macro) > + } > + /* DWARF 3. */ > + .debug_ranges BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_ranges) > + } > + /* DWARF 4. */ > + .debug_types BLOCK(__section_alignment__) (NOLOAD) : > + { > + *(.debug_types .gnu.linkonce.wt.*) > } > } > - > > >

1 0

Developer meeting
by mikey sibert 24 Feb '12

24 Feb '12

I won't be able to go to the meeting maybe I will get some new drivers tested but I lost my usb card and need to find it.

2 3

Re: [ros-dev] [ros-builds] Windows_AMD64_1 VBox-Test: build failed
by caemyr＠myopera.com 23 Feb '12

23 Feb '12

0x19 bugcheck with CM corruption. Test reran. On Wed, Feb 22, 2012, at 10:30 PM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Windows_AMD64_1 > VBox-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/4897 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) > Build Source Stamp: 55816 > Blamelist: sginsberg > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [sginsberg] 55813: Some misc fixes to Prefast. [DDK] - ndis.h Don't use local variables with the same name as function parameters. [PSDK] - access.idl Remove incorrect annotation - usbioctl.h Not r...
by Timo Kreuzer 23 Feb '12

23 Feb '12

These are not correct. Am 22.02.2012 21:58, schrieb sginsberg(a)svn.reactos.org: > Author: sginsberg > Date: Wed Feb 22 20:58:20 2012 > New Revision: 55813 > > > > Modified: trunk/reactos/include/psdk/usbioctl.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/psdk/usbioctl.h?re… > ============================================================================== > --- trunk/reactos/include/psdk/usbioctl.h [iso-8859-1] (original) > +++ trunk/reactos/include/psdk/usbioctl.h [iso-8859-1] Wed Feb 22 20:58:20 2012 > @@ -295,34 +295,34 @@ > USHORT DeviceAddress; > ULONG NumberOfOpenPipes; > USB_CONNECTION_STATUS ConnectionStatus; > - USB_PIPE_INFO PipeList[0]; > + USB_PIPE_INFO PipeList[ANYSIZE_ARRAY]; > } USB_NODE_CONNECTION_INFORMATION, *PUSB_NODE_CONNECTION_INFORMATION; > > > typedef struct _USB_DESCRIPTOR_REQUEST { > @@ -334,7 +334,7 @@ > USHORT wIndex; > USHORT wLength; > } SetupPacket; > - UCHAR Data[0]; > + UCHAR Data[ANYSIZE_ARRAY]; > } USB_DESCRIPTOR_REQUEST, *PUSB_DESCRIPTOR_REQUEST; > > #if (_WIN32_WINNT>= 0x0501) > @@ -358,7 +358,7 @@ > USHORT DeviceAddress; > ULONG NumberOfOpenPipes; > USB_CONNECTION_STATUS ConnectionStatus; > - USB_PIPE_INFO PipeList[0]; > + USB_PIPE_INFO PipeList[ANYSIZE_ARRAY]; > } USB_NODE_CONNECTION_INFORMATION_EX, *PUSB_NODE_CONNECTION_INFORMATION_EX; > > C_ASSERT(sizeof(USB_NODE_CONNECTION_INFORMATION_EX) == sizeof(USB_NODE_CONNECTION_INFORMATION));

1 0

Monthly meeting - February
by Aleksey Bragin 23 Feb '12

23 Feb '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 23rd of February, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Your participation passwords will be emailed to you shortly before the meeting starts. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. In order to save time, let's choose who is going to be the minute taker on the upcoming meeting. Volunteers welcome. Proposed agenda for the meeting: 1. Release status: 0.3.15 2. New website status and migration plans. 3. CMake migration and finally abandoning RBuild. 4. 0.3.14 release party. More suggestions are welcome as usual. With the best regards, Aleksey Bragin.

4 3

change in email
by mikey sibert 23 Feb '12

23 Feb '12

i changed email to this one microsoft windows live is better than google. now i saved the best part for last, go her for a list of win32 api functions: http://j00ru.vexillium.org/w32k_syscalls/ it will help a lot in the development of reactos and make a lot mor programs run on then system

5 6

http://j00ru.vexillium.org/ntapi/
by mikey sibert 23 Feb '12

23 Feb '12

go here it might work i don't know it all runs on my pc.

1 0

system call list
by mikey sibert 23 Feb '12

23 Feb '12

can you send i list of the ones you have implemented

1 0

Re: [ros-dev] [ros-builds] Windows_AMD64_1 VBox-Test: build failed
by caemyr＠myopera.com 22 Feb '12

22 Feb '12

2nd stage pool corruption at the end, CM assert at subsequent reboots. I restarted the test and it worked fine the second time. On Wed, Feb 22, 2012, at 05:28 PM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Windows_AMD64_1 > VBox-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/4888 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: Triggerable(Windows_AMD64_1 VBox-Test Trigger) > Build Source Stamp: 55808 > Blamelist: sginsberg > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-builds] Windows_AMD64_1 VBox-Test: build failed
by caemyr＠myopera.com 22 Feb '12

22 Feb '12

VBox was locked up. Usurp: could you look into it? VBox window is stuck with Stopping status. Perhaps sysreg should kill the whole process and restart it, just to be safe? Best regards On Wed, Feb 22, 2012, at 12:15 PM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Windows_AMD64_1 > VBox-Test while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/4882 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: The web-page 'force build' button was pressed by 'osiejka': > > Build Source Stamp: 55804 > Blamelist: > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 55770: [NTOSKRNL/MM] - finally, release user shared data at process address space cleanup. - release PDE pages that might not be freed at process end. - Let the caller handle PDE release ...
by Jérôme Gardou 22 Feb '12

22 Feb '12

Le 21/02/2012 01:32, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Tue Feb 21 00:32:24 2012 > New Revision: 55770 > > URL: http://svn.reactos.org/svn/reactos?rev=55770&view=rev > Log: > [NTOSKRNL/MM] > - finally, release user shared data at process address space cleanup. > - release PDE pages that might not be freed at process end. > - Let the caller handle PDE release when deleting a PTE > - restore Richard's ASSERT : All user PDE pages are now freed! Addendum to log : When a page maps a Prototype PTE, we can't know if it must be deleted before dropping shared reference. Modify ASSERT accordingly. Restore the ASSERTion that only page fault should provocate the creation of the PDE and modify PDE refcounting in pageout code accordingly.

2 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