Ros-dev

ros-dev@reactos.org

5790 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev