- Ros-dev - ReactOS.org

Re: [ros-dev] [ros-diffs] [akhaldi] 56311: * Reorganize the whole ReactOS codebase into a new layout. Discussing it will only waste time, so we better have it then talk about it after. * Put ntoskrnl and ntdll in the same f...
by Aleksey Bragin 06 Apr '12

06 Apr '12

02.04.2012 0:42, akhaldi(a)svn.reactos.org пишет: > Author: akhaldi > Date: Sun Apr 1 20:42:43 2012 > New Revision: 56311 > > URL: http://svn.reactos.org/svn/reactos?rev=56311&view=rev > Log: > * Discussing it will only waste time, so we better have it then talk about it after. I was thinking it's some of my old commits, until I read the line about april fools day :) > * I'm just kidding, you know, April's fool and all ;) > WBR, Aleksey.

1 0

Re: [ros-dev] [ros-diffs] [sginsberg] 56333: - Even while I love having the trap/fpu/context code in C, the bugs this switch introduced continue to amaze me. This time, fix a bug from 45156 when KiFlushNPXState was rewritte...
by Aleksey Bragin 06 Apr '12

06 Apr '12

That was a nice catch! 07.04.2012 0:13, sginsberg(a)svn.reactos.org пишет: > Author: sginsberg > Date: Fri Apr 6 20:13:33 2012 > New Revision: 56333 > > URL: http://svn.reactos.org/svn/reactos?rev=56333&view=rev > Log: > - Even while I love having the trap/fpu/context code in C, the bugs this switch introduced continue to amaze me. This time, fix a bug from 45156 when KiFlushNPXState was rewritten in C. The C version could miss to restore the interrupt state, which would lead to interrupts being disabled when it was not expected. This "interrupt leak" was seen in the page fault handler if a page fault occurred after interrupts had been disabled (which had sometimes been observed to occur on the test server during exception handling and thread creation when KiFlushNPXState had been called). This didn't completely hang the system because during thread creation (and other system calls where this may have happened) interrupts would be re-enabled when returning to user mode when restoring eflags, and the exception handling would result in a system call which would enable interrupts again (it appears exception handler would have run with interrupts disabled, though!). This is now fixed, as well as any other issues this might have caused. The hack in the page fault handler remains until another issue has been fixed. > > Modified: > trunk/reactos/ntoskrnl/ke/i386/cpu.c > > Modified: trunk/reactos/ntoskrnl/ke/i386/cpu.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ke/i386/cpu.c?rev… > ============================================================================== > --- trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ke/i386/cpu.c [iso-8859-1] Fri Apr 6 20:13:33 2012 > @@ -1323,7 +1323,12 @@ > if (Thread->NpxState != NPX_STATE_LOADED) > { > /* If there's nothing to load, quit */ > - if (!SaveArea) return; > + if (!SaveArea) > + { > + /* Restore interrupt state and return */ > + __writeeflags(EFlags); > + return; > + } > > /* Need FXSR support for this */ > ASSERT(KeI386FxsrPresent == TRUE); > >

1 0

March 2012 Meeting Minutes
by Colin Finck 30 Mar '12

30 Mar '12

March 2012 Meeting Minutes 2012-03-29 19:00 UTC Fezile, #meeting Proceedings =========== * Meeting started at 19:00 UTC by Aleksey Bragin. * Point 1: The state of Trunk ----------------------------- * Cameron Gutman gave some examples how badly Trunk has regressed since 0.3.14: - Frequent bugchecks and assertions in the console - Broken Unicode in the console - Several key apps such as Firefox, Ping, Dwnl and Notepad being broken or rarely working He opened a discussion about improving the quality of Trunk. * Timo Kreuzer favorized a stricter revert-on-regressions policy. By employing the Patchbot buildslave, "evil" changes should be detected in advance before committing them. According to Giannis Adamopoulos, the Patchbot currently needs 20 minutes in total for building and testing a patch. * Colin Finck asked whether the current regressions were visible in the automated regression tests. Aleksey Bragin denied this for most of them as these were usability problems not detected by our regression tests. * Various people suggested frameworks such as AutoIt and AutoHotKey to automate application testing as well. * To also automate real hardware testing, Jan Blomqvist Kinander has set up another server. He reported that he could successfully perform a remote ReactOS installation on it and just needs some scripts to automate the procedures now. * Aleksey Bragin illustrated his plan to move more towards loosely managed development. In particular, he wants to introduce Atlassian tools such as FishEye and JIRA to plan activity and actually do stuff. * Cameron Gutman wanted a firm decision about dealing with regressions first. Aleksey Bragin responded that the current rules still apply: A commit shall be reverted after one day if it breaks booting or installation. Other regressions shall be reported in Bugzilla using the REGRESSION prefix. * Olaf Siejka criticized the way bugs are currently handled. The list at http://www.reactos.org/wiki/Bug_Filters#Patch_review_list is getting bigger and bigger while developers don't take responsibility for it. He added that a decision was taken to release early last month, although no progress towards implementing it was visible. * Alex Ionescu joined the meeting later and reopened the discussion about using Atlassian tools. In his opinion, JIRA and FishEye can support our development along with Bamboo as a build and continuous integration system. Later on, these systems could be set up to only accept a commit if it can be successfully built by Bamboo. - Olaf Siejka wants to set up a Bamboo test system to evaluate the tool. - Alex Ionescu will send out an E-Mail as soon as our setup is ready for testing. * Point 2: Plan for the next month ---------------------------------- * The previous discussion about improving development using new tools continued here. While Aleksey Bragin outlined that he wants to finish the setup in April, Alex Ionescu gave more examples about what needs to be changed when moving to JIRA: - A dynamic component maintainer list should be added to establish a clear chain of responsibility for all parts of ReactOS. - User privileges should be changed to let only component maintainers classify their bugs. * Furthermore, the list at http://www.reactos.org/wiki/Bug_Filters#Patch_review_list has been discussed again. Alex Ionescu and Timo Kreuzer agreed that such general lists are pointless and the following approach was suggested instead: - Developers owning bugs and being mailed about them - Release not being made until all important bugs are fixed - Someone to prioritize which bugs are blocking a release * Alex Ionescu outlined more ideas about improving the release process. He suggested to create a roadmap for each release and picking several specific bugs as goals for this release. Only fixes for these bugs should go into a release, new features could be prepared in branches. * The branches idea was picked up by Amine Khaldi who questioned that SVN was able to properly handle more branches for new features, release preparation, etc. due to its limited branching capabilities. * Alex Ionescu did not agree with this, because people can merge just subdirectories of a branch into Trunk or even bundle all changes in .patch files and simply apply them. * Timo Kreuzer called for a feature freeze in Trunk before the discussion on point 2 ended, but Aleksey Bragin stated that this would prevent further work on fixing Mm. * Aleksey Bragin finally repeated that he is going to finish the setup of the new tools in April and wants to get everybody used to them. The idea of having modules owners shall get more developer responsibility towards issues and patches. * Point 3: Next release discussion ---------------------------------- * Aleksey Bragin postponed this discussion to the next meeting as most of the topics have already been covered in the discussion about Trunk. No objections were raised. * Point 4: New website status ----------------------------- * Maciej Bialas reported that he is at the point of applying small fixes now as well as importing the user database into Drupal. He stated that every user needs to change his password after the migration because of different hashing algorithms used in Drupal and RosCMS. * Pierre Schweitzer noted that we should prevent another mass mailing of all registered users due to the problems caused by the last one. * Ziliang Guo proposed to just create a sticky forum post and write a mail to a ReactOS mailing list about the password changes. There were no objections. * The participants agreed to continue discussions about website content on the mailing lists. * Point 5: Miscellaneous ------------------------ * Giannis Adamopoulos picked up the new subsystem layout for Win32k, which had already been discussed a year ago and was postponed. He outlined it at http://pastie.org/3694259. Aleksey Bragin, James Tabor and Timo Kreuzer agreed on it, so it will be committed within the next 4 days. * Art Yerkes reported about his work on NewCC. In particular, he is currently looking at a bug not existing in a non-NewCC build. He expects other issues afterwards, but thinks that the entire work is progressing well. * Meeting closed at 21:55 UTC by Aleksey Bragin. * Minutes written by Colin Finck.

3 2

Facebook fanpage
by Ged Murphy 29 Mar '12

29 Mar '12

All Facebook fanpages will be to switch to the new timeline layout this weekend. This means we need a cover picture for our reactos fan page. If artistic guys out there wanna put something together, we'll upload it to our fanpage. Maybe someone could start a thread in the forum to gather some interest? Cheers, Ged.

2 1

Monthly meeting - March 2012
by Aleksey Bragin 29 Mar '12

29 Mar '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 29th of March, 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 will be posted to this list tomorrow. Please email me your suggestions. With the best regards, Aleksey Bragin.

4 5

PBD parser.
by Svyatoslav Kuzmich 24 Mar '12

24 Mar '12

Hello dear React OS mailing list! I've found that ReactOS dbghelp.dll includes PDB file parser. Does anyone know where I can find documentation of PDB internal structure? Thanks, Svyatoslav Kuzmich

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 56192: [SHELL32] - Fix another local vs member variable issue.
by Timo Kreuzer 20 Mar '12

20 Mar '12

Am 19.03.2012 17:21, schrieb tfaber(a)svn.reactos.org: > } > } > - uState = uState; > + this->uState = uState; > TRACE("--\n"); > } LOL! Thats another reason why I love C++, it makes people write very funny code :D

2 1

New set of potential(?) bugs and its fixes(?)
by victor martinez 19 Mar '12

19 Mar '12

This is a new set of potential bugs found via Viva64: Example 1. ReactOS project. Incorrect printing of a WCHAR-character( regproc.c 293) . static void REGPROC_unescape_string(WCHAR* str) { ... default: fprintf(stderr, "Warning! Unrecognized escape sequence: \\%c'\n", str[str_idx]); ... }Reason: To fix the code, we should replace '%c' with '%C' in the format string. Example 2. ReactOS project. Assignment error. (menu.c 4347) BOOL WINAPI GetMenuItemInfoA(...) { ... mii->cch = mii->cch; ... } Example 16. ReactOS project. Misprint in a macro.( win32k gradient.c 343 ) #define SWAP(a,b,c) c = a;\ a = b;\ a = c Example 8. ReactOS object. Choosing a wrong object. void CardButton::DrawRect(HDC hdc, RECT *rect, bool fNormal) { ... HPEN hhi = CreatePen(0, 0, MAKE_PALETTERGB(crHighlight)); HPEN hsh = CreatePen(0, 0, MAKE_PALETTERGB(crShadow)); ... if(fNormal) hOld = SelectObject(hdc, hhi); else hOld = SelectObject(hdc, hhi); ... } The 'then' statement is equivalent to the 'else' statement. cardlib cardbutton.cpp 83 The 'hsh' object is not used, while 'hhi' is used twice. This is the correct code: if(fNormal) hOld = SelectObject(hdc, hhi); else hOld = SelectObject(hdc, hsh); Example 10. ReactOS project. Mistake in a variable name. BOOL APIENTRY GreStretchBltMask(...) { ... MaskPoint.x += DCMask->ptlDCOrig.x; MaskPoint.y += DCMask->ptlDCOrig.x; ... } Consider reviewing the correctness of 'x' item's usage. win32k bitblt.c 670 Example 4. ReactOS project. Incorrect calculation of a string length ( vbe.c 57 ) static const PCHAR Nv11Board = "NV11 (GeForce2) Board"; static const PCHAR Nv11Chip = "Chip Rev B2"; static const PCHAR Nv11Vendor = "NVidia Corporation"; BOOLEAN IsVesaBiosOk(...) { ... if (!(strncmp(Vendor, Nv11Vendor, sizeof(Nv11Vendor))) && !(strncmp(Product, Nv11Board, sizeof(Nv11Board))) && !(strncmp(Revision, Nv11Chip, sizeof(Nv11Chip))) && (OemRevision == 0x311)) ... }Reason: The error here is this: the sizeof() operator, absolutely inappropriate in this situation, is used to calculate string lengths. The sizeof() operator actually calculates the pointer size instead of the number of bytes in a string. In this case Abragin said this is not a bug. I'm sending here to discuss about them ;).Are they valid? Link: http://www.viva64.com/en/a/0079/

6 7

Kdserial use in first stage
by Sylvain Petreolle 19 Mar '12

19 Mar '12

Automatic Continue in kdb has been implemented and improves the debugging on the test bots. However, the KVM bot can't use it in the first stage because it is controlled by keyboard entries at this time. I propose to switch the first stage to kdserial as well. Any objections ? Kind regards, Sylvain Petreolle

1 0

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

15 Mar '12

..\..\dll\win32\avifil32\avifile_Hu.rc(32) : error RC2101 : invalid directive in preprocessed RC file Still broken, since winesync Best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Date: Thu, 15 Mar 2012 23:12:01 +0000 Subject: buildbot failure in ReactOS on CMake_x86_MSVCWin Debug 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/808 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_1 Build Reason: scheduler Build Source Stamp: 56167 Blamelist: rharabien BUILD FAILED: failed building bootcd sincerely, -The Buildbot -- With best regards Caemyr

1 0

Commit by tfaber :: r56146 / (2 files in 2 dirs): (link) [CLT2012] Done here. Tag the release.
by Javier Agustìn Fernàndez Arroyo 14 Mar '12

14 Mar '12

Shouldn´t have you done this in the CTL2012 branch instead of trunk?

3 3

Re: [ros-dev] [ros-diffs] [rharabien] 56132: [COMCTL32] - When installing dll copy manifest to winsxs\manifests directory as comctl32 before sync did. Fixes Firefox 10 regression. See issue #6910 for more details.
by Timo Kreuzer 13 Mar '12

13 Mar '12

I would prefer if ros specific code would be seperated as much as possible to avoid huge diff files. The bigger the diff file, the more likely it will cause issues in the next sync. Am 12.03.2012 15:16, schrieb rharabien(a)svn.reactos.org: > Author: rharabien > Date: Mon Mar 12 14:16:58 2012 > New Revision: 56132 > > URL: http://svn.reactos.org/svn/reactos?rev=56132&view=rev > Log: > [COMCTL32] > - When installing dll copy manifest to winsxs\manifests directory as comctl32 before sync did. Fixes Firefox 10 regression. > See issue #6910 for more details. > > Modified: > trunk/reactos/dll/win32/comctl32/commctrl.c > > Modified: trunk/reactos/dll/win32/comctl32/commctrl.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/comctl32/commctr… > ============================================================================== > --- trunk/reactos/dll/win32/comctl32/commctrl.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/comctl32/commctrl.c [iso-8859-1] Mon Mar 12 14:16:58 2012 > @@ -71,6 +71,19 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(commctrl); > > +#define NAME L"microsoft.windows.common-controls" > +#define VERSION L"6.0.2600.2982" > +#define PUBLIC_KEY L"6595b64144ccf1df" > + > +#ifdef __i386__ > +#define ARCH L"x86" > +#elif defined __x86_64__ > +#define ARCH L"amd64" > +#else > +#define ARCH L"none" > +#endif > + > +static const WCHAR manifest_filename[] = ARCH L"_" NAME L"_" PUBLIC_KEY L"_" VERSION L"_none_deadbeef.manifest"; > > static LRESULT WINAPI COMCTL32_SubclassProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam); > > @@ -91,6 +104,67 @@ > static const WCHAR strCC32SubclassInfo[] = { > 'C','C','3','2','S','u','b','c','l','a','s','s','I','n','f','o',0 > }; > + > +static BOOL create_manifest(BOOL install) > +{ > + WCHAR *pwszBuf; > + HRSRC hResInfo; > + HGLOBAL hResData; > + PVOID pManifest; > + DWORD cchBuf, cbManifest, cbWritten; > + HANDLE hFile; > + BOOL bRet = FALSE; > + > + hResInfo = FindResourceW(COMCTL32_hModule, L"WINE_MANIFEST", RT_MANIFEST); > + if (!hResInfo) > + return FALSE; > + > + cbManifest = SizeofResource(COMCTL32_hModule, hResInfo); > + if (!cbManifest) > + return FALSE; > + > + hResData = LoadResource(COMCTL32_hModule, hResInfo); > + if (!hResData) > + return FALSE; > + > + pManifest = LockResource(hResData); > + if (!pManifest) > + return FALSE; > + > + cchBuf = GetWindowsDirectoryW(NULL, 0) * sizeof(WCHAR) + sizeof(L"\\winsxs\\manifests\\") + sizeof(manifest_filename); > + pwszBuf = (WCHAR*)HeapAlloc(GetProcessHeap(), 0, cchBuf * sizeof(WCHAR)); > + if (!pwszBuf) > + return FALSE; > + > + GetWindowsDirectoryW(pwszBuf, cchBuf); > + lstrcatW(pwszBuf, L"\\winsxs"); > + CreateDirectoryW(pwszBuf, NULL); > + lstrcatW(pwszBuf, L"\\manifests\\"); > + CreateDirectoryW(pwszBuf, NULL); > + lstrcatW(pwszBuf, manifest_filename); > + if (install) > + { > + hFile = CreateFileW(pwszBuf, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > + if (hFile != INVALID_HANDLE_VALUE) > + { > + if (WriteFile(hFile, pManifest, cbManifest,&cbWritten, NULL)&& cbWritten == cbManifest) > + bRet = TRUE; > + > + CloseHandle(hFile); > + > + if (!bRet) > + DeleteFileW(pwszBuf); > + else > + TRACE("created %s\n", debugstr_w(pwszBuf)); > + } > + } > + else > + bRet = DeleteFileW(pwszBuf); > + > + HeapFree(GetProcessHeap(), 0, pwszBuf); > + > + return bRet; > +} > > > /*********************************************************************** > @@ -930,6 +1004,12 @@ > HRESULT WINAPI DllInstall(BOOL bInstall, LPCWSTR cmdline) > { > TRACE("(%u, %s): stub\n", bInstall, debugstr_w(cmdline)); > + if (!create_manifest(bInstall)) > + { > + ERR("create_manifest failed!\n"); > + return HRESULT_FROM_WIN32(GetLastError()); > + } > + > return S_OK; > } > > > >

3 2

Re: [ros-dev] [ros-diffs] [cgutman] 56113: [HIVESYS] - Merge back many old changes from i386 to AMD64
by Cameron Gutman 12 Mar '12

12 Mar '12

On Mar 11, 2012, at 7:13 AM, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Mar 11 11:13:15 2012 > New Revision: 56113 > > URL: http://svn.reactos.org/svn/reactos?rev=56113&view=rev > Log: > [HIVESYS] > - Merge back many old changes from i386 to AMD64 The way we do hive INFs is very far from ideal right now. I propose to create a base INF that is used to construct each hive and turning the hivexxx_arch.inf into an additional section like livecd.inf is now. This way every architecture inherits a base configuration and turning on/off services or changing certain settings can be done in the arch-specific inf. This would eliminate having to do these merge backs and also prevent tons of breakages and lost time in the future from having to merge the same change 3+ times. Regards, Cameron

3 2

INI editor for Reactos
by Aleksey Bragin 11 Mar '12

11 Mar '12

FYI -------- Original Message -------- Hi there, Someone recommended that I point out my open-source INI editor for Reactos... Here it is: http://code.google.com/p/ini-settings-editor/ It opens INI files into a pretty tab-based view for editing. Let me know if you have any comments about it.

5 7

Re: [ros-dev] [ros-diffs] [akhaldi] 56104: [CMAKE] * Fix a typo.
by Jérôme Gardou 10 Mar '12

10 Mar '12

Le 10/03/2012 19:02, akhaldi(a)svn.reactos.org a écrit : > Author: akhaldi > Date: Sat Mar 10 18:02:40 2012 > New Revision: 56104 > > URL: http://svn.reactos.org/svn/reactos?rev=56104&view=rev > Log: > [CMAKE] > * Fix a typo. > > Modified: > trunk/reactos/cmake/msvc.cmake > > Modified: trunk/reactos/cmake/msvc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/msvc.cmake?rev=56104… > ============================================================================== > --- trunk/reactos/cmake/msvc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/msvc.cmake [iso-8859-1] Sat Mar 10 18:02:40 2012 > @@ -178,7 +178,7 @@ > > # add our library > # NOTE: as stub file and def file are generated in one pass, depending on one is like depending on the other > - _add_library(lib${_file} STATIC EXCLUDE_FROM_ALL > + add_library(lib${_file} STATIC EXCLUDE_FROM_ALL > ${CMAKE_CURRENT_BINARY_DIR}/lib${_file}_stubs.asm) > > # set correct "link rule" > > it wasn't a typo :-)

1 0

Re: [ros-dev] buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 10 Mar '12

10 Mar '12

Added yet another check, this time for all builders, which will stop any run passed without revision number. On Sat, Mar 10, 2012, at 05:34 AM, buildbot(a)reactos.org wrote: > The Buildbot has finished a 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/5238 > > 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: 56097 > Blamelist: > > BUILD FAILED: failed Initial preparations > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Re: [ros-dev] buildbot exception in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 10 Mar '12

10 Mar '12

Strange vbox lockup at the end of 2nd stage. Build restarted, went fine this time. On Sat, Mar 10, 2012, at 01:24 AM, buildbot(a)reactos.org wrote: > The Buildbot has finished a 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/5236 > > 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: 56096 > Blamelist: spetreolle > > BUILD FAILED: exception test > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 56082: [DAMN_IT] - addendum to r56081
by Jérôme Gardou 08 Mar '12

08 Mar '12

Hey! Can't we add tests to the regular tree, and disable them with a onig flag or something. This is getting retarded, and we must be the only project separating tests and runtime in their tree. Every tester should just build them (not speaking about developers...), and we include them in nightly builds. For me this separation is just pointless... regards. Jérôme Le 07/03/2012 22:46, jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Wed Mar 7 21:46:15 2012 > New Revision: 56082 > > URL: http://svn.reactos.org/svn/reactos?rev=56082&view=rev > Log: > [DAMN_IT] > - addendum to r56081 > > Modified: > trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt > trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt > trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt > trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt > > Modified: trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_… > ============================================================================== > --- trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/rostests/apitests/w32kdll/w32kdll_2k3sp2/CMakeLists.txt [iso-8859-1] Wed Mar 7 21:46:15 2012 > @@ -1,5 +1,5 @@ > > -spec2def(w32kdll_2k3sp2.dll w32kdll_2k3sp2.spec) > +spec2def(w32kdll_2k3sp2.dll w32kdll_2k3sp2.spec ADD_IMPORTLIB) > > add_library(w32kdll_2k3sp2 SHARED > main.c > @@ -9,4 +9,3 @@ > set_entrypoint(w32kdll_2k3sp2 0) > > add_dependencies(w32kdll_2k3sp2 psdk ) > -add_importlib_target(w32kdll_2k3sp2.spec w32kdll_2k3sp2.dll) > > Modified: trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_… > ============================================================================== > --- trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/rostests/apitests/w32kdll/w32kdll_ros/CMakeLists.txt [iso-8859-1] Wed Mar 7 21:46:15 2012 > @@ -1,5 +1,5 @@ > > -spec2def(w32kdll_ros.dll w32kdll_ros.spec) > +spec2def(w32kdll_ros.dll w32kdll_ros.spec ADD_IMPORTLIB) > > add_library(w32kdll_ros SHARED > main.c > @@ -10,4 +10,3 @@ > target_link_libraries(w32kdll_ros win32ksys) > > add_dependencies(w32kdll_ros psdk) > -add_importlib_target(w32kdll_ros.spec w32kdll_ros.dll) > > Modified: trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_… > ============================================================================== > --- trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/rostests/apitests/w32kdll/w32kdll_vista/CMakeLists.txt [iso-8859-1] Wed Mar 7 21:46:15 2012 > @@ -1,5 +1,5 @@ > > -spec2def(w32kdll_dll.spec w32kdll_vista.spec) > +spec2def(w32kdll_vista.spec w32kdll_vista.spec ADD_IMPORTLIB) > > add_library(w32kdll_vista SHARED > main.c > @@ -8,4 +8,3 @@ > set_entrypoint(w32kdll_vista 0) > > add_dependencies(w32kdll_vista psdk ) > -add_importlib_target(w32kdll_vista.spec w32kdll_dll.spec) > > Modified: trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/rostests/apitests/w32kdll/w32kdll_… > ============================================================================== > --- trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/rostests/apitests/w32kdll/w32kdll_xpsp2/CMakeLists.txt [iso-8859-1] Wed Mar 7 21:46:15 2012 > @@ -1,4 +1,4 @@ > -spec2def(w32kdll_xpsp2.dll w32kdll_xpsp2.spec) > +spec2def(w32kdll_xpsp2.dll w32kdll_xpsp2.spec ADD_IMPORTLIB) > > add_library(w32kdll_xpsp2 SHARED > main.c > @@ -6,5 +6,4 @@ > ${CMAKE_CURRENT_BINARY_DIR}/w32kdll_xpsp2.def) > set_entrypoint(w32kdll_xpsp2 0) > > -add_dependencies(w32kdll_xpsp2 psdk ) > -add_importlib_target(w32kdll_xpsp2.spec w32kdll_xpsp2.dll) > +add_dependencies(w32kdll_xpsp2 psdk) > >

10 18

Re: [ros-dev] [ros-diffs] [jgardou] 56083: Branch for C++. Amine will be proud.
by Aleksey Bragin 08 Mar '12

08 Mar '12

On 08.03.2012 2:27, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Wed Mar 7 22:27:48 2012 > New Revision: 56083 > > URL: http://svn.reactos.org/svn/reactos?rev=56083&view=rev > Log: > Branch for C++. > Amine will be proud. > Me too ;)

3 2

Re: [ros-dev] [ros-diffs] [pschweitzer] 56077: [DDK] Fix release build?
by Timo Kreuzer 08 Mar '12

08 Mar '12

This belongs into ntdef.h Am 07.03.2012 20:46, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Wed Mar 7 19:46:16 2012 > New Revision: 56077 > > URL: http://svn.reactos.org/svn/reactos?rev=56077&view=rev > Log: > [DDK] > Fix release build? > > Modified: > trunk/reactos/include/ddk/wdm.h > > Modified: trunk/reactos/include/ddk/wdm.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/ddk/wdm.h?rev=5607… > ============================================================================== > --- trunk/reactos/include/ddk/wdm.h [iso-8859-1] (original) > +++ trunk/reactos/include/ddk/wdm.h [iso-8859-1] Wed Mar 7 19:46:16 2012 > @@ -128,6 +128,16 @@ > #define ALLOC_DATA_PRAGMA 1 > #endif > > +/* Add NOP_FUNCTION support */ > +#ifndef NOP_FUNCTION&& (_MSC_VER>= 1210) > +#define NOP_FUNCTION __noop > +#else > +#define NOP_FUNCTION (void)0 > +#endif > +#else > +#ifndef NOP_FUNCTION > +#define NOP_FUNCTION (void)0 > +#endif > #endif > > #if defined(_WIN64) > > >

1 0

Re: [ros-dev] buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 07 Mar '12

07 Mar '12

One last bug squashed (hopefully) - now testbot should detect missing ISO and break up runtime at prepare stage. On Wed, Mar 7, 2012, at 11:30 AM, buildbot(a)reactos.org wrote: > The Buildbot has finished a 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/5220 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: The web-page 'rebuild' button was pressed by 'osiejka': > > Build Source Stamp: 56072 > Blamelist: > > BUILD FAILED: failed Initial preparations > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [cgutman] 56069: [NTOSKRNL] - Fix the unload path - This does expose some bugs: 2 cont-able assertions in ARM3 after unplugging a USB storage device (during usbstor unload), HID unload doesn't seem...
by Cameron Gutman 06 Mar '12

06 Mar '12

[NTOSKRNL] - Fix the unload path - This does expose some bugs: 2 cont-able assertions in ARM3 after unplugging a USB storage device (during usbstor unload), HID unload doesn't seem to work correctly (somebody still has references to the devices), other issues may pop up too I've tracked this issue down to using loader heap to allocate the LDR data entry (which gets freed by the kernel during init). This makes it invalid when we go to read the module object when we unload it, causing a crash. I'm not sure how to move forward from here but the changes needed are in FreeLoader's peloader.c. After fixing that, I'm running into another issue where it appears that LdrEntry->LoadedImports is no longer valid (set for boot drivers during kernel init) so it results in a null pointer dereference. I've confirmed that this crash only occurs when boot loaded drivers are unloaded; any other PnP driver loaded after boot unloads perfectly. Richard (or someone else knowledgeable in the area), if you could take a few minutes to figure this out for me that would be fantastic. Here is the log and backtrace after I fixed the LDR data entry allocation type: (C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\device.c:447) Unloading driver '\Driver\usbstor' (automatic) (C:\Users\Cam\reactos\trunk\ntoskrnl\io\iomgr\driver.c:61) Deleting driver object '\Driver\usbstor' (C:\Users\Cam\reactos\trunk\ntoskrnl\mm\ARM3\sysldr.c:935) Leaking driver: usbstor.sys Entered debugger on first-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x00000000 could not be read: Page not present. kdb:> bt Eip: <NTOSKRNL.EXE:b0c71 (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:389 (MiDereferenceImports@4))> Frames: <NTOSKRNL.EXE:b0a7f (ReactOS/ntoskrnl/mm/ARM3/sysldr.c:947 (MmUnloadSystemImage@4))> <NTOSKRNL.EXE:5ce2c (ReactOS/ntoskrnl/io/iomgr/driver.c:80 (IopDeleteDriver@4))> <NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237 (@ObfDereferenceObject@4))> <NTOSKRNL.EXE:59c24 (ReactOS/ntoskrnl/io/iomgr/device.c:61 (IopDeleteDevice@4))> <NTOSKRNL.EXE:d63f5 (ReactOS/ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da790 (ReactOS/ntoskrnl/ob/obref.c:237 (@ObfDereferenceObject@4))> <NTOSKRNL.EXE:73adc (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:1286 (IopSynchronousCall@12))> <NTOSKRNL.EXE:73b23 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:585 (IopSendRemoveDevice@4))> <NTOSKRNL.EXE:7532a (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:2214 (IopEnumerateDevice))> <NTOSKRNL.EXE:7550c (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:4672 (IoSynchronousInvalidateDeviceRelations@8))> <NTOSKRNL.EXE:75530 (ReactOS/ntoskrnl/io/pnpmgr/pnpmgr.c:889 (IopAsynchronousInvalidateDeviceRelations@8))> <NTOSKRNL.EXE:6a737 (ReactOS/ntoskrnl/io/iomgr/iowork.c:27 (IopWorkItemCallback@4))> <NTOSKRNL.EXE:42056 (ReactOS/ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:efaca (ReactOS/ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:100d63 (ReactOS/ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:efa66 (ReactOS/ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> Regards, Cameron

1 0

Problems with patchbot/newcc/rosbe
by caemyr＠myopera.com 06 Mar '12

06 Mar '12

After a quick look into your problems with patchbot it seems that vbox scripts were missing some errorlevel checks, which should bail out the test run at prepare stage when ISO was not present (which is the situation when you dont pass the proper revision/id number. Same thing was with newcc1 tests. I added some debug prints so if my current solution wont do its job, i`ll at least know bit more about the problem. By that occasion i found out a problem with current ROSBE - its not emitting proper ERRORLEVEL at the end of the build, due to tee/buildtime/flash/sound playback or any of similar crap that is getting the final ERRORLEVEL value. For main building step i hacked around this issue by simply checking for ISO file at the end and erroring out if its not there. For host building part, this is more complicated. I tried removing the stuff mentioned above, but it still doesnt work. Dreimer: it would be of help if you could fix this problem. -- With best regards Caemyr

4 5

Fwd: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test
by caemyr＠myopera.com 06 Mar '12

06 Mar '12

Sorry for the error spam, had to fix one erroneous check (that forced exiting with errorlevel 0 instead of the proper one). ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Date: Tue, 06 Mar 2012 21:18:43 +0000 Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test The Buildbot has finished a 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/5204 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_2 Build Reason: The web-page 'rebuild' button was pressed by 'osiejka': Build Source Stamp: 56063 Blamelist: cgutman BUILD FAILED: failed Initial preparations sincerely, -The Buildbot -- With best regards Caemyr

1 0

Release builds are back
by Pierre Schweitzer 06 Mar '12

06 Mar '12

Hi, release builds will finally be available again. Those will be daily built against most recent head. They will be findable at usual place. For the moment, no new release build is available since release build its broken (cf: http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/1/steps…). With my best regards, -- Pierre Schweitzer<pierre(a)reactos.org> System Administrator ReactOS Foundation

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