- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [cgutman] 54418: [HALX86] - Do not allow software interrupts to preempt code running with interrupts disabled during KfLowerIrql
by Aleksey Bragin 21 Nov '11

21 Nov '11

I would like to ask our kernel gurus if this one is correct. WBR, Aleksey Bragin. On 18.11.2011 22:53, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Fri Nov 18 18:53:41 2011 > New Revision: 54418 > > URL: http://svn.reactos.org/svn/reactos?rev=54418&view=rev > Log: > [HALX86] > - Do not allow software interrupts to preempt code running with interrupts disabled during KfLowerIrql > > Modified: > trunk/reactos/hal/halx86/up/pic.c > > Modified: trunk/reactos/hal/halx86/up/pic.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/hal/halx86/up/pic.c?rev=54… > ============================================================================== > --- trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] (original) > +++ trunk/reactos/hal/halx86/up/pic.c [iso-8859-1] Fri Nov 18 18:53:41 2011 > @@ -665,26 +665,30 @@ > > /* Set old IRQL */ > Pcr->Irql = OldIrql; > - > - /* Check for pending software interrupts and compare with current IRQL */ > - PendingIrqlMask = Pcr->IRR& FindHigherIrqlMask[OldIrql]; > - if (PendingIrqlMask) > - { > - /* Check if pending IRQL affects hardware state */ > - BitScanReverse(&PendingIrql, PendingIrqlMask); > - if (PendingIrql> DISPATCH_LEVEL) > + > + /* Make sure interrupts were enabled */ > + if (EFlags& EFLAGS_INTERRUPT_MASK) > + { > + /* Check for pending software interrupts and compare with current IRQL */ > + PendingIrqlMask = Pcr->IRR& FindHigherIrqlMask[OldIrql]; > + if (PendingIrqlMask) > { > - /* Set new PIC mask */ > - Mask.Both = Pcr->IDR; > - __outbyte(PIC1_DATA_PORT, Mask.Master); > - __outbyte(PIC2_DATA_PORT, Mask.Slave); > - > - /* Clear IRR bit */ > - Pcr->IRR ^= (1<< PendingIrql); > + /* Check if pending IRQL affects hardware state */ > + BitScanReverse(&PendingIrql, PendingIrqlMask); > + if (PendingIrql> DISPATCH_LEVEL) > + { > + /* Set new PIC mask */ > + Mask.Both = Pcr->IDR; > + __outbyte(PIC1_DATA_PORT, Mask.Master); > + __outbyte(PIC2_DATA_PORT, Mask.Slave); > + > + /* Clear IRR bit */ > + Pcr->IRR ^= (1<< PendingIrql); > + } > + > + /* Now handle pending interrupt */ > + SWInterruptHandlerTable[PendingIrql](); > } > - > - /* Now handle pending interrupt */ > - SWInterruptHandlerTable[PendingIrql](); > } > > /* Restore interrupt state */ > >

3 3

Re: [ros-dev] [ros-diffs] [cgutman] 54415: [I8042PRT] - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) - Fixes bug 1395
by Johannnes Anderwald 21 Nov '11

21 Nov '11

Am 18.11.2011 00:41, schrieb cgutman(a)svn.reactos.org: > Author: cgutman > Date: Thu Nov 17 23:41:18 2011 > New Revision: 54415 > > URL: http://svn.reactos.org/svn/reactos?rev=54415&view=rev > Log: > [I8042PRT] > - Implement support for hot plugging PS/2 mice if one was present at boot (same requirement as Windows) > - Fixes bug 1395 > > Exellent! -- Johannes Anderwald

7 6

Looking for new maintainers
by Colin Finck 20 Nov '11

20 Nov '11

Hi all, As some of you know, I have started university about a month ago. Due to the amount of time I have to spend on university tasks these days, I can no longer fulfil all my project obligations. Therefore, I'm looking for new maintainers in the following areas: * RosBE-Unix * My Web tools (especially Testman and the rest of the regression testing system, but also GetBuilds/People Map/Subsystem integration) * Release Engineering (unless Ziliang can fully takeover my position) Provided that I find time, I'll introduce the new maintainers into these tasks as good as possible. I try to stay available for infrastructure and foundation tasks, but my time for these will definitely be limited as well. Best regards, Colin

3 3

Testing sound
by Igor Paliychuk 19 Nov '11

19 Nov '11

Debug log from testing cmake soundchip in KSStudio. http://www.reactos.org/paste/index.php/9568/ Btw i'm getting crash in cmuda.sys on two different PCs (though i didn't notiv=ce if chips are the same) To get your attention, Johannes ;)

1 1

Qemu Recoverable Assertion when Loading Gecko
by James Tabor 18 Nov '11

18 Nov '11

Head up on this one. It's recoverable by just typing "cont" and it goes on. (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\oleaut32.dll WARNING: MmFlushVirtualMemory at ntoskrnl/mm/ARM3/virtual.c:1044 is UNIMPLEMENTED! fixme:(dll/win32/wintrust/register.c:1161) stub (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name C:\ReactOS\system32\mshtml.dll (76650000 -> 014C0000) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\System32\setupapi.dll (ntoskrnl/se/semgr.c:299) SidInToken Calls: 40000 Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb:> bt Eip: <NTOSKRNL.EXE:104eff (lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:c283d (ntoskrnl/mm/freelist.c:127 (MmRemoveLRUUserPage@4))> <NTOSKRNL.EXE:c18de (ntoskrnl/mm/balance.c:134 (MmReleasePageMemoryConsumer@8))> <NTOSKRNL.EXE:cbf6a (ntoskrnl/mm/section.c:2365 (MmPageOutSectionView@16))> <NTOSKRNL.EXE:c822c (ntoskrnl/mm/rmap.c:143 (MmPageOutPhysicalAddress@4))> <NTOSKRNL.EXE:c17a9 (ntoskrnl/mm/balance.c:177 (MmTrimUserMemory))> <NTOSKRNL.EXE:c141c (ntoskrnl/mm/balance.c:366 (MiBalancerThread@4))> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <fcdebd80> <NTOSKRNL.EXE:152e5 (ntoskrnl/ke/wait.c:527 (KeWaitForSingleObject@20))> <NTOSKRNL.EXE:c524e (ntoskrnl/mm/mminit.c:292 (MmMpwThreadMain@4))> <NTOSKRNL.EXE:f2972 (ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:5a6a (ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f290e (ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <fce4fab0> <00000001> kdb:> cont Assertion 'RtlCheckBit(&MiUserPfnBitMap, (ULONG)Page)' failed at ntoskrnl/mm/freelist.c line 127 Entered debugger on embedded INT3 at 0x0008:0x80904efe. kdb:> cont (subsystems/win32/win32k/ntuser/keyboard.c:1066) err: No Window for Translate. (dll/ntdll/ldr/ldrutils.c:1138) LDR: LdrpMapDll Relocating Image Name xul.dll (10000000 -> 01DB0000) (dll/ntdll/ldr/ldrutils.c:1177) Overlapping DLL: C:\ReactOS\system32\ \1.0.0\wine_gecko\xpcom.dll

6 11

Re: [ros-dev] [ros-diffs] [tfaber] 54401: [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474) [NDK] - Remove meaningless const attribute from pointer rvalues to make Coverity's life easier
by Timo Kreuzer 17 Nov '11

17 Nov '11

Am 16.11.2011 22:17, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Wed Nov 16 21:17:38 2011 > New Revision: 54401 > > URL: http://svn.reactos.org/svn/reactos?rev=54401&view=rev > Log: > [ATL] - Fix buffer overflow in CComDynamicUnkArray::Add. Found by Coverity (CID 2474) > [NDK] - Remove meaningless const attribute from pointer rvalues to make Coverity's life easier > -#define SharedUserData ((KUSER_SHARED_DATA *CONST)USER_SHARED_DATA) > +#define SharedUserData ((KUSER_SHARED_DATA *)USER_SHARED_DATA) It is like this (with the const) in wdm.h #define SharedUserData ((KUSER_SHARED_DATA * const) KI_USER_SHARED_DATA) maybe its supposed to express that "SharedUserData" is a constant and not a variable... although that doesn't make much sense

3 2

SendMessageW doubt/bug with ANSI LPARAM.
by victor martinez 17 Nov '11

17 Nov '11

>The Total Commander comboboxes for the left and right drive list >are Unicode. However, Total Commander calls >SendMessage(handle,CB_ADDSTRING,0,(LPARAM)ansitext); >to add items as ANSI text. This seems to work, but it's adding some >extra text at the end. If I understand correctly, Total Commander is calling SendMessage, which in this case is translated to SendMessageW (as the comboboxes are Unicode). So TC is calling SendMessageW to append an ANSI string to a Combobox. Let's give a look to SendMessageW implementation thanks to Doxygen: http://doxygen.reactos.org/da/d64/winuser_8h_a18e5b961d742150a18d3039b5dd88… 02161 Result = NtUserMessageCall( Wnd, 02162 KMMsg.message, 02163 KMMsg.wParam, 02164 KMMsg.lParam, 02165 (ULONG_PTR)&Result, 02166 FNID_SENDMESSAGE, 02167 FALSE); Line 2167 FALSE is the BOOL ANSI param of NtUserMessageCall. But in this case the BOOL ANSI should be TRUE as the string is really ANSI. So since this moment we are treating TC call ( SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)ansitext); ) in the same way as we would be treating SendMessageW(handle,CB_ADDSTRING,0,(LPARAM)unicodetext); This seems a bug for me. Feel free to correct me, but seems that SendMessageW is able to set both kind of strings ANSI and UNICODE in Windows, while we are forcing to our SendMessageW implementation to treat them as UNICODE always. Am I wrong? This could be a big potential issue as this could affect to all the SendmessageW calls. This is all just a guess, so please feed me with your knowledge. Thanks a lot!

4 5

1000 EUR for ReactOS - We have made it!
by Colin Finck 15 Nov '11

15 Nov '11

Hi all, Looking at https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev, we have scored the 810th place in the tough competition and just won 1000 EUR for the foundation! :-) Even if we lost our position in the top of the list, comparable German Open-Source foundations like KDE e.V. or Free Software Foundation Europe are both out of the game. I'd like to use this opportunity to thank every voter for the great support towards the project! Over 8000 votes in four weeks really shows that we still have a huge fan base. Best regards, Colin

9 9

Re: [ros-dev] [ion] 54323: [KERNEL32]: Move the "curdir.c" APIs into path.c as well, as they are Path APIs. No code changes (just formatting and moving to DPRINTs).
by Aleksey Bragin 15 Nov '11

15 Nov '11

I'm getting questions, if it's "just formatting and no code changes", why author names are removed for good and not readded in the new file? WBR, Aleksey Bragin. On 07.11.2011 3:01, ion(a)svn.reactos.org wrote: > Author: ion > Date: Sun Nov 6 23:01:04 2011 > New Revision: 54323 > > URL: http://svn.reactos.org/svn/reactos?rev=54323&view=rev > Log: > [KERNEL32]: Move the "curdir.c" APIs into path.c as well, as they are Path APIs. No code changes (just formatting and moving to DPRINTs). > Removed: trunk/reactos/dll/win32/kernel32/client/file/curdir.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/kernel32/client/… > ============================================================================== > --- trunk/reactos/dll/win32/kernel32/client/file/curdir.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/kernel32/client/file/curdir.c (removed) > @@ -1,388 +1,0 @@ > -/* $Id$ > - * > - * COPYRIGHT: See COPYING in the top level directory > - * PROJECT: ReactOS system libraries > - * FILE: lib/kernel32/file/curdir.c > - * PURPOSE: Current directory functions > - * PROGRAMMER: Eric Kohl > - * Filip Navara > - * Steven Edwards > - * Thomas Weidenmueller > - * Gunnar Andre' Dalsnes > - * UPDATE HISTORY: > - * Created 30/09/98 > - */ >

2 2

Send Messages
by James Tabor 05 Nov '11

05 Nov '11

Hi! What I have run across in regards of ReactOS send message subsystem, ros is not packing before co_MsqSendMessage and unpacking after co_IntCallWindowProc! Instead packing before co_IntCallWindowProc with send message. Does that not raise any questions? co_IntSendMessageWithCallBack seems to do it almost right, but IntCallWndProc/Ret should be called when calling the client via co_IntCallWindowProc and should pack before the call to MsqWakeQueue and then unpack after the call to co_IntCallWindowProc. Confused? Basing this on IntCallLowLevelEvent and co_IntCallLowLevelHook when the lParam is used to save information that could get lost in a stack switch or release. Setting up the pattern; Pack before co_MsqSendMessage or related friends and Unpack after calling co_IntCallWindowProc to client. Have co_MsqDispatchOneSentMessage call something other than co_IntSendMessage so the Packed data can be handled correctly when calling to the client via co_IntCallWindowProc. I'm sure Michael Martin has brought this up to me on many occasions. Let's see where this goes! Thanks, James

2 2

Linux debug build slave relocated
by Pierre Schweitzer 02 Nov '11

02 Nov '11

Hi, the Linux build slave will be relocated (changing data center & country) starting tomorrow. It will, obviously, be offline during the meantime. So, you will not have any Linux builds nor KVM tests. We will do our best to get it back online as soon as possible. Regards, The ReactOS Sysadmins.

1 1

Minutes from 10.27.2011
by Claudiu Mihail 30 Oct '11

30 Oct '11

Hello all, Here are the minutes from the last ReactOS meeting on the 27th of October 2011: 20:20 Aleksey Bragin called the meeting to order - Aleksey Bragin shared a video interview about ReactOS at http://alenapopova.ru/egov/react-os-kraudsorsing-pri-sozdanii-operacionnoj-… - Aleksey Bragin stated the meeting agenda as being: 1. Website revamp status 2. CMake adoption 3. Release status 1. Website Revamp ----------------- - Amine Khaldi started on the Website revamp status and stated that unfortunately nothing has progressed since the last meeting because of aross, superdog and nisky being extremely busy. - He also stated that Aleksey has yet to commit the bridges needed and that the actual milestone is the theme (ie design/layout that matches the current website), after which devs will need to investigate phpbb issue. - Aleksey Bragin added that almost the only thing left is the theme and with it progress could be made fast to the website engine and have a test run with real data. - He also stated that all details could be provided to anyone motivated enough with HTML/CSS. - Matthias Kupfer said he could support HTML/CSS around Christmas, but not earlier. - Aleksey Bragin asked Maciej Bialas if he could assist in theming. - Maciej Bialas said he could, and added that he tried to create a simple theme first resembling the current one, and that aross said he could have done better by using some Drupal modules Maciej was not aware of. - Aleksey Bragin stated that a simple theme would suffice for now and a better one can always be done later. - Ziliang Guo asked about user and forum transfer status. - Aleksey Bragin replied that the forum is phpbb and therefore easily transferable - Ziliang Guo asked about the reason for sticking with phpbb. - Amine Khaldi and Aleksey Bragin stated that it was for the sake of easier migration (ie migrate one thing at a time not everything at once) - Maciej Bialas stated that one downside to this was tedious integration with phpbb. - Aleksey Bragin pointed out that playground.reactos.org (with its intact database) will be what the new main site looks like when the switch is made. - Ziliang Guo said he can start trying to add content the coming weekend. - Amine Khaldi asked Ziliang Guo to keep everything minimalistic. - Aleksey Bragin moved the meeting on to the CMake adoption topic on the agenda. 2. CMake adoption -------------------- - Aleksey Bragin took this chance to welcome Alex Ionescu back to the ReactOS project. - Amine Khaldi stated that Alex Ionescu stumbled upon a way to separate debug info from binaries, in a pdb similar way, using objcopy. He also mentioned that Alex helped by fixing two bugs in windmc and windres. - He went on to say that Alex suggested that we go back to using dwarf-2, only this time with pdb style debug, and with an improved, out of the kernel, symbols handling. He mentioned that Thomas Faber was kind enough to sketch a batch script that takes a debug log and translates the addresses inside it. - Amine Khaldi further stated that with the script + the CMake changes to take account of windres and objcopy, we'll be able to reduce the iso size, reduce the memory footprint, reduce the disk space needed to compile, use windres alone and get rid of handling symbols in the kernel (something "no other OS does" as Alex describes it). - He then explained that, on the RosBE level, this will only require updating binutils (gcc will stay at 4.4.3) with the patched windres and windmc, and it will also require the translating script to be part of RosBE. A discussion ensued about testing the new RosBE and the following conclusions where reached: - Have a new Build Environment Release Candidate (2.0) which is an update to binutils (ld, windres, windmc, addr2line... etc) until the next meeting. - Keep the 4.4.3 version of gcc until the next meeting. - Alex Ionescu suggested having the new RosBE ready by the time of the next release. He also noted that this does not mean the new BE will be released along with the next version of ReactOS, but that it must be ready by then. - Cameron Gutman then brought up the issue of switching to gcc 4.6, but it was decided to keep gcc 4.4.3 until after the next release. - Thomas Faber then suggested an outlined step by step plan: 1) Update BE 2) Release new version of ReactOS (0.3.14) 3) Get rid of wrc 4) Get rid of rbuild 5) Switch to dwarf 6) Adopt new compiler (gcc 4.6) After some deliberating it was agreed upon that Thomas Faber's proposed course of action is the best way to go, and his proposal was accepted. - Amine Khaldi then moved the meeting to the next topic 3. Release status -------------------- - Cameron Gutman inquired about the progress on the heap regression issue. - Thomas Faber stated that although he himself hasn't made much progress because he is very busy during the week, Jerome has been tracking it down pretty well and that it is apparently caused by resource loading. - Amine Khaldi took this chance too thank everyone for the awesome bugfixing phase, and stated that a lot of bugs has been fixed and a lot of regression has been addressed. He also went on to thank testers, and outlined the importance they have, and stated that he hopes this will be the mentality of the ReactOS project team, as thanks to it ReactOS is improving a lot. - He went on to say that as far as the remaining blockers are concerned, more team work on fixing them is needed, as this has proved very effective in the past. He also added that Jim Tabor did a good one man job on the jre issue, but that the other issues could use some teaming up. - Aleksey Bragin further added to this that ReactOS is on the way to possibly one of the best releases, and that after years have passed everyone is working towards the same goal, which, he added, is fantastic. - Cameron Gutman agreed that ReactOS is indeed very stable now, especially in kernel mode. - Olaf Siejka went on to sum up that entering the release stage would require at the very least fixing mshtml bug and fixing ldr regressions. - Aleksey Bragin agreed with Olaf Siejka on that point. - Kamil Hornicek inquired about the official stance about hackfixing certain bugs. - Aleksey Bragin and Amine Khaldi both explained that while hackfixing should be avoided, there are some bugs which cannot be resolved in a timely fashion. But hackfixing these should clearly be reflected in the commit message and comments in the code. - Amine Khaldi went on to ask for a more visible teaming up, for example on IRC and through bug reports, and to also request marking bugs as assigned when devs take them. He mentioned that since the release blockers remained unassigned for a while, it was difficult at times to keep track of who is working on what. - Cameron Gutman inquired if anybody objects to modifying the default color depth from 16-bit to 32-bit. - Olaf Siejka raised some concerns about this as it will affect QEMU since it does not support 32bpp. - Cameron Cutman further inquired about the possibility of falling back more gracefully as far as color depth is concerned when a video card does not support a certain resolution (right now it falls back directly to 8bpp). He went further to ask Timo Kreuzer if this is standard windows behavior. - Timo Kreuzer said he would need to investigate this issue. - Aleksey Bragin formally ended the meeting, thanking everyone for their time and information. Minutes by Claudiu Mihail.

2 1

Monthly status meeting
by Aleksey Bragin 28 Oct '11

28 Oct '11

Hello, Let me invite you to the monthly status meeting taking place last thursday of this month (hint: today), 27th of October, 19:00 UTC. The meeting will be atirc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting. Note that the IRC service will only be started shortly before the meeting. Everyone is invited to listen, and active community members have their passwords so that they can participate in the discussion. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. Proposed agenda for the meeting: 1. Release status 2. CMake adoption status 3. Website revamp status More suggestions are welcome. With the best regards, Aleksey Bragin.

5 5

Regressions / release status
by Aleksey Bragin 27 Oct '11

27 Oct '11

Hello! Time flies fast, and soon we are going to face the deadline (next status meeting) by which we decided to create a RC of the upcoming release. And, there are some problems. I will start from good stuff. Since the last meeting took place, quite a few regressions were fixed, and interesting bugs have also been closed. This is very good and I appreciate your efforts. However some problems remains, and here is where your help is urgently needed! For the current milestone (0.3.14), there are 3 blocker regressions and 2 big buckets of issues - ldr rewrite regressions and shell32 rewrite regressions. From blocker stuff, the most important is the heap-related one. Mephisto provided a good explanation here (http://www.reactos.org/bugzilla/show_bug.cgi?id=5857), and we need someone with a fresh eye to look into this problem. N.B. Please don't go into "let's fix some unrelated stuff in the heap code just to make it better". Look strictly into the specified bug and try to spot the place where the heap lists are getting corrupted. Anyone volunteers to have a look? LDR regressions: there are relatively many of them, but all are more-or-less nicely fixable because of the new, good LDR code. Alex - maybe you could please devote a bit of your time to check the code and see if that fixes some of the regressions? shell32 regressions: I already see some improvements being committed, please continue this way. We can make a good 0.3.14 release only if we act as a team now. It's not someone, it's YOUR help which matters. Testers are already doing as much as they can, retesting issues, providing newer debug logs, and other other things. Now it's time to act and fix regressions before moving further. It's just stupid to move further, if a rewrite introduces new bugs instead of fixing existing. I know how hard it is, but let's finish smaller steps and hence move forward. There is no way forward at all if old bugs are stacked and new regressions are introduced all the time. We can't bring in new good changes (wine syncs, 3rd party code syncs, arwinss, whatever else) until 0.3.14 is ready, and 0.3.14 is not ready until blocking regressions are fixed. As simple as it is. Thanks for reading and I hope you understand. With the best regards, Aleksey Bragin.

4 3

Two petitions
by caemyr＠myopera.com 23 Oct '11

23 Oct '11

Hiya Its still at least two weeks until next meeting, hence i suppose ros-dev could be used in decision making even before that. I have two things i would like to push, things that i discussed a bit with varioius team memebers on IRC and got positive feedback. I would like you guys to comment on those and if you feel that one of both of them are wrong/unnecessary/not needed, please voice it out here. If there is no opposition for them, i`ll consider those two accepted and push for them to be finialised. Here we go: 1. Adding a default theme to ReactOS. We need at least one to test Themes service in trunk ootb and avoid copying it to ros install each time, which is really important in regression testing. Also, a theme is a must for our upcoming release. Since its not a big file usually, it should be present in trunk, not only in release ISO. 2. Moving Starfield screensaver from rosapps to trunk. Rosapps, no matter how much cheered, is a wasteland, a museum, a forgotten place. It will not be even buildable when we move away from rbuild. Old and unneeded code should land there, but not a new creation Carlo has been working on. Apart from that, Starfield is using OpenGL, which is also a handy ootb test tool for 3d acceleration, also important in regression testing. If you think that two screensavers are the top amount you can accept, then lets replace one of the trunk screensavers with Starfield. -- With best regards Caemyr

10 17

Would you donate just 3 minutes to the project?
by The ReactOS Team 21 Oct '11

21 Oct '11

Dear ReactOS Community Member, We contact you today, because you have signed up for a myReactOS account some time ago. And we need your help! A German bank is currently running a sponsoring campaign for all kinds of foundations. The 1000 foundations with the most votes receive 1000 EUR each by the 15th November. You can easily increase our chances by voting on the following website: https://verein.ing-diba.de/sonstiges/33378/reactos-deutschland-ev Here is the complete voting procedure: * Open the link above * Click on the orange button "Stimme abgeben" (= Vote) * Enter your E-Mail address and solve the captcha, then hit the button "Absenden" (= Send) * You will receive a confirmation E-Mail where you have to click the first link. Finally click on "Stimme abgeben" again and you're done. Note that you can vote UP TO 3 TIMES with a single E-Mail address, and you can even cast all votes to the same foundation. You may also share this, so that we can get as many people as possible to vote for us. Let's get ReactOS among the top 1000! Cheers and thanks for your support, Aleksey Bragin and Colin Finck in the name of the ReactOS Team and ReactOS Deutschland e.V.

7 10

Livecd video regression
by Timo Kreuzer 19 Oct '11

19 Oct '11

Hi, Since one of my recent video driver loading changes, livecd video is vga mode. The reson is: When installing bootcd, there will be only 1 video driver installed: based on 1st stage selection, either vbe or vga will be installed the other one is deactivated (start mode = manual). When installing a 3rd party driver, that one used to be installed and loaded prior to VBE and thus became Device/Video0, which win32k happily used as primary adapter. This behaviour changed with ACPI hal and VBE is loaded first, resulting is non functional VBox driver. I fixed this, by having win32k decide which driver to use, by looking if its a vga compatible driver and use that one only as fallback, if no other is present. additionally the VBE was marked as VgaCompatible. Now livecd behaves differently and simply installs both VGA and VBE. and since both are now marked as VgaCompatible, win32k doesn't know which one to use and currently uses VGA. Now how does this work in Windows? Windows has only one Adapter installed for VGA and VBE (vga.sys + vga.dll/vga256.dll/vga64k.dll/framebuf.dll) This service is always loaded and marked as "VgaCompatible". It is also used when a 3rd party driver is installed, when you switch to fullscreen console mode. This adapter is only replaced by a 3rd party adapter if that one is also vga compatible. This way its easy for win32k to decide which one to use: based on whether /BASEVIDEO is passed, either the vga compatible one or the other one can be selected. Possible solutions: 1) Add another workaround to win32k, checking if 2 VGA adapters are installed and then using the first one, instead of the second one as currently (because 1st is VGA, simply the second is used), but thats not a real solution. 2) Fix whatever is neccessary to have VBE be replaced by a 3rd party driver that is installed. (Cameron said it was related to VBE not being PNP ready.) This way we can stop marking it as VgaCompatible. 3) Combine VGA and VBE miniport into one vga compatible driver, like it's in windows. Alex mentioned that eVb has more or less finished that. Question is: whats missing to have the code comitted? Comments and feedback appreciated, Timo

3 5

Re: [ros-dev] [ros-diffs] [jgardou] 54179: [WinMM] - avoid buffer overrun. - do not try to unload uninitialized driver. See issue #6343 for more details.
by Timo Kreuzer 17 Oct '11

17 Oct '11

I think that will not unload the last driver. Looking at MMDRV_Install, MMDrvsHi is the index of the first free array field and its incremented each time MMDRV_Install is called. The assert in line 465 is wrong. It should be "<". The for () loop in line 432 is also wrong Your change starts with MMDrvsHi - 1, the last used index, then decrements i by one before doing anything else. Am 17.10.2011 18:35, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Oct 17 16:35:10 2011 > New Revision: 54179 > > URL: http://svn.reactos.org/svn/reactos?rev=54179&view=rev > Log: > [WinMM] > - avoid buffer overrun. > - do not try to unload uninitialized driver. > See issue #6343 for more details. > > Modified: > trunk/reactos/dll/win32/winmm/lolvldrv.c > > Modified: trunk/reactos/dll/win32/winmm/lolvldrv.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/winmm/lolvldrv.c… > ============================================================================== > --- trunk/reactos/dll/win32/winmm/lolvldrv.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/winmm/lolvldrv.c [iso-8859-1] Mon Oct 17 16:35:10 2011 > @@ -634,7 +634,7 @@ > } > > /* unload driver, in reverse order of loading */ > - i = sizeof(MMDrvs) / sizeof(MMDrvs[0]); > + i = MMDrvsHi - 1; > while (i--> 0) > { > MMDRV_ExitPerType(&MMDrvs[i], MMDRV_AUX); > > >

1 0

CMake migration of Trunk_x86_GCCLin Debug Buildslave
by Colin Finck 16 Oct '11

16 Oct '11

Hello all, The "Trunk_x86_GCCLin Debug" Buildslave has been migrated to RosBE-Unix 2.0-RC1. All builds starting with r53983 are now created using a CMake environment. Unfortunately, the CMake builds don't boot under KVM on the same machine, but apparently for everybody else. To give you an idea what I mean by "don't boot": http://img830.imageshack.us/img830/5145/image1iz.png If nobody has an idea how to debug or fix this, I'm afraid I have to revert everything back to the rbuild scripts until a proper solution is found. - Colin

6 19

Problems linking msxml3.dll
by Alex Ionescu 16 Oct '11

16 Oct '11

This is the original command-line: mingw32-ld --entry=_DllMain@12 --image-base=0x74ae0000 @obj-i386/dll/win32/msxml3/msxml3_objs.rsp --start-group "/usr/local/new/RosBE/i386/lib/gcc/mingw32/4.4.3/libgcc.a" obj-i386/lib/3rdparty/libxml2/libxml2.a output-i386/dll/3rdparty/libxslt/libxslt.dll obj-i386/lib/3rdparty/libwine/wine.a obj-i386/lib/3rdparty/libwine/wineldr.a obj-i386/dll/win32/urlmon/liburlmon.a obj-i386/dll/win32/wininet/libwininet.a obj-i386/dll/win32/ws2_32/libws2_32.a obj-i386/dll/win32/comctl32/libcomctl32.a obj-i386/dll/win32/shell32/libshell32.a obj-i386/dll/win32/shlwapi/libshlwapi.a obj-i386/dll/win32/cabinet/libcabinet.a obj-i386/dll/win32/oleaut32/liboleaut32.a obj-i386/dll/win32/ole32/libole32.a obj-i386/dll/win32/version/libversion.a obj-i386/dll/win32/user32/libuser32.a obj-i386/dll/win32/gdi32/libgdi32.a obj-i386/dll/win32/advapi32/libadvapi32.a obj-i386/lib/sdk/uuid/uuid.a obj-i386/dll/ntdll/libntdll.a obj-i386/lib/3rdparty/mingw/mingw_common.a obj-i386/lib/3rdparty/mingw/oldnames.a obj-i386/dll/ntdll/libntdll.a obj-i386/dll/win32/kernel32/libkernel32.a obj-i386/dll/win32/msvcrt/libmsvcrt.a obj-i386/lib/debugsup/debugsup_ntdll.a --end-group -disable-stdcall-fixup -file-alignment=0x1000 -section-alignment=0x1000 --shared --exclude-all-symbols -o output-i386/dll/win32/msxml3/msxml3.dll This is on RosBE 2.0 with RBUILD. Note that it's trying to link with libxslt.dll, which obviously won-t work on a non-Windows host. Removing that broken linkage makes the link work fine if I do it by hand. Can anyone fix? -- Best regards, Alex Ionescu

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 54136: [CMD] * Reduce the scope of some variables.
by Alex Ionescu 14 Oct '11

14 Oct '11

Why? It doesn't change anything...and... This is not our coding standard. Best regards, Alex Ionescu On Fri, Oct 14, 2011 at 1:50 PM, <akhaldi(a)svn.reactos.org> wrote: > Author: akhaldi > Date: Fri Oct 14 17:50:16 2011 > New Revision: 54136 > > URL: http://svn.reactos.org/svn/reactos?rev=54136&view=rev > Log: > [CMD] > * Reduce the scope of some variables. > > Modified: > trunk/reactos/base/shell/cmd/assoc.c > trunk/reactos/base/shell/cmd/dir.c > trunk/reactos/base/shell/cmd/filecomp.c > trunk/reactos/base/shell/cmd/start.c > trunk/reactos/base/shell/cmd/ver.c > > Modified: trunk/reactos/base/shell/cmd/assoc.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/assoc.c?rev… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/assoc.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -206,8 +206,6 @@ > INT CommandAssoc (LPTSTR param) > { > > - LPTSTR lpEqualSign = NULL; > - > /* print help */ > if (!_tcsncmp (param, _T("/?"), 2)) > { > @@ -221,7 +219,7 @@ > PrintAllAssociations(); > else > { > - lpEqualSign = _tcschr(param, _T('=')); > + LPTSTR lpEqualSign = _tcschr(param, _T('=')); > if(lpEqualSign != NULL) > { > LPTSTR fileType = lpEqualSign + 1; > > Modified: trunk/reactos/base/shell/cmd/dir.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/dir.c?rev=5… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/dir.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -1260,13 +1260,11 @@ > LPDIRSWITCHFLAGS lpFlags) /* [IN] The flags that > we will use to sort */ > { > LPWIN32_FIND_DATA lpTemp; /* A temporary pointer */ > - int First, Last, Temp; > BOOL Way; > > if (i < j) > { > - First = i; > - Last = j; > + int First = i, Last = j, Temp; > Way = TRUE; > while (i != j) > { > > Modified: trunk/reactos/base/shell/cmd/filecomp.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/filecomp.c?… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/filecomp.c [iso-8859-1] Fri Oct 14 > 17:50:16 2011 > @@ -209,7 +209,6 @@ > TCHAR path[MAX_PATH]; > TCHAR fname[MAX_PATH]; > TCHAR directory[MAX_PATH]; > - UINT longestfname = 0; > SHORT screenwidth; > > /* expand current file name */ > @@ -277,6 +276,7 @@ > hFile = FindFirstFile (path, &file); > if (hFile != INVALID_HANDLE_VALUE) > { > + UINT longestfname = 0; > /* Get the size of longest filename first. */ > do > { > > Modified: trunk/reactos/base/shell/cmd/start.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/start.c?rev… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/start.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/start.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -48,7 +48,6 @@ > TCHAR szFullCmdLine [CMDLINE_LENGTH]; > PROCESS_INFORMATION prci; > STARTUPINFO stui; > - INT i = 0; > #ifdef UNICODE > DWORD dwCreationFlags = CREATE_NEW_CONSOLE | > CREATE_UNICODE_ENVIRONMENT; > #else > @@ -213,7 +212,7 @@ > /* Parsing the command that gets called by start, and it's > parameters */ > { > BOOL bInside = FALSE; > - > + INT i; > /* find the end of the command and put the arguments in > param */ > for (i = 0; Rest[i]; i++) > { > > Modified: trunk/reactos/base/shell/cmd/ver.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/base/shell/cmd/ver.c?rev=5… > > ============================================================================== > --- trunk/reactos/base/shell/cmd/ver.c [iso-8859-1] (original) > +++ trunk/reactos/base/shell/cmd/ver.c [iso-8859-1] Fri Oct 14 17:50:16 > 2011 > @@ -28,8 +28,6 @@ > VOID ShortVersion (VOID) > { > OSVERSIONINFO VersionInfo; > - unsigned RosVersionLen; > - LPTSTR RosVersion; > > ConOutResPrintf(STRING_CMD_SHELLINFO, _T(KERNEL_RELEASE_STR), > _T(KERNEL_VERSION_BUILD_STR)); > VersionInfo.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); > @@ -37,6 +35,9 @@ > memset(VersionInfo.szCSDVersion, 0, > sizeof(VersionInfo.szCSDVersion)); > if (GetVersionEx(&VersionInfo)) > { > + LPTSTR RosVersion; > + unsigned RosVersionLen; > + > RosVersion = VersionInfo.szCSDVersion + > _tcslen(VersionInfo.szCSDVersion) + 1; > RosVersionLen = sizeof(VersionInfo.szCSDVersion) / > sizeof(VersionInfo.szCSDVersion[0]) - > (RosVersion - VersionInfo.szCSDVersion); > > >

2 1

RosBE-Unix 2.0-RC1
by Colin Finck 13 Oct '11

13 Oct '11

Hi all, A first release candidate of RosBE-Unix 2.0 is now available on http://svn.reactos.org/RosBE-Temp/. Compared to 1.5, it finally includes CMake 2.8.5 (with Jerome's patches), an updated GNU Make and new GMP and MPFR libraries. For the latter ones, I've added a patch to fix building under Mac OS X 10.7. Please try it out and tell me about your results. If there's anything that needs to be fixed before the release, please tell me in a reply to this mail. For the reference, the current CMake building commands in a ReactOS checkout are as follows: - ./configure.sh - cd output-i386-MinGW/host-tools - makex - cd ../reactos - makex bootcd I'll also set up this Build Environment on the Debug Buildslave as soon as possible. Happy building, Colin

5 6

Bugfixing mode
by Aleksey Bragin 11 Oct '11

11 Oct '11

Hello! As per discussion during the last status meeting, I proposed to set up a deadline for having a 0.3.14 Release Candidate available by the time of the next meeting. Olaf, Amine and others were kind enough to make an up-to-date list of critical bugs and regressions to be fixed. It's available here: http://www.reactos.org/wiki/Buglist (indeed this page should be in your web browser's Favorites!) . I want to ask all of you to concentrate on fixing regressions and critical/blocker bugs first, before going into fancy features or implementing something else. It's really important, we need to make 0.3.14 as the last release before switching to 0.4. We have all necessary prerequisites, and just need to sit down and fix regressions. I personally put off all of my ReactOS-related "fancy" projects because I want a solid trunk first, and I am working only on stuff which is urgently needed - fixing remaining LDR rewrite regressions, special pool to catch pool corruptions, etc. It's meaningless to work on something else now if regressions aren't fixed. Hopefully you will follow my advice and we will have a wonderful bugfixing week(s)! Thank you! WBR, Aleksey Bragin.

3 4

freeldr.ini now is overwritten by newly generated (livecd)
by Minas Abrahamyan 11 Oct '11

11 Oct '11

Hi all, Previously I used edited version of freeldr.ini to build livecd ISOs, it is in \output-i386\livecd\ Now freeldr.ini is becoming overwritten in make process by newly generated "standard" one, and it is overwriting my manually edited version. So 1) what is now the correct way is to have custom freeldr.ini in iso image? 2) For what are these new automagical erase-and-newly-generate scripts? Although I can now manually edit (in iso image) what has been done earlier automatically, replace the file, but, at my PoV something goes wrong. -- Best Regards, M.A.

1 1

[ros-diffs] [rharabien] 54006: [WIN32K] - Rewrite keyboard input processing to match windows behavior -
by James Tabor 11 Oct '11

11 Oct '11

Hi! Well if anyone cares! This commit message is a lie! In IntKeyboardInput I added support for KF_DLGMODE and KF_MENUMODE ! BTW is used! In Dialog.c DF_DIALOGACTIVE! So someone will fix it right? Okay, James

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev