- Ros-dev - ReactOS.org

Status of ARM Development
by J. C. Jones 19 Jan '13

19 Jan '13

Hi All, Newbie here (2 days). I would like to know the who-is-doing-what for the ARM port. It seems that, with the current lock-down of all three major mobile platforms (iOS/Android/Windows Phone 8), as well as the impending surge in 2013 of ultra-cheap mobile devices like tablets based on ARM, and of course, the loveable Raspberry Pi, a truly open Windows-oriented platform is more needed than ever. J.C.

5 6

Notice Of Intent - Visual Studio Build of ReactOS - Take III
by J. C. Jones 13 Jan '13

13 Jan '13

Hi All, I had quick chat with Amine and others, and for the time being, I will pick up where I let off in creating a Visual Studio ReactOS.sln with the following features: 1. A single ReactOS.sln file that is interchangeable between Visual Studio 2010 and Visual Studio 2012. 2. A single ReactOS.sln file that incorporates all 800+ .vcxproj files and allows all 800+ project to be viewable within a single session of Visual Studio. 3. No (serious) performance problems with load of the ReactOS.sln file or .vcxproj files. 4. An arrangement in the Solution Workspace that mirrors the structure of the ReactOS repository on disk. 5. The ability to build all applications or drivers by right-clicking, within Solution Workspace, on the folder named applications or drivers and doing clicking Build. 6. Visibility of the lang directories in the Solution Workspace. 7. Visibility of all SVN files in the Solution Workspace, including CMakeLists.txt files. 8. Support for Debug and Release project configurations. 9. Support for x86_32, x86_64, ARM platform configurations. 10. Self-relative paths for all .h's and .libs's so that solution can be moved by the developer on his/her local hard disk without consequence. 11. No need to download any extraneous tools. User should be able to type in SVN URL, either from within Visual Studio, or with Windows Explorer, pull ReactOS repository, load ReactOS.sln, and start editing/compiling/linking, debugging. With the CMakeLists.txt files, the information needed is already present. With Amine's latest work of actually generating the .vcxproj files, things become even easier. However, as I have two other moderate projects going concurrently, one of which I just started, this will take some time. I will provide updates as I go along. Cheers, -John

2 2

Notice Of Intent - Visual Studio Build of ReactOS
by J. C. Jones 13 Jan '13

13 Jan '13

Hi All, Some of you might have seen my recent on the post regarding the build process: http://www.reactos.org/forum/viewtopic.php?f=9&t=12240&start=15 As I mentioned, it would help greatly to lower the barrier-to-entry to less-experienced developers, as well as more experienced developers who might have limited time budgets [Who among us does not have a limited time budget?]. I wanted to send out this message to let everyone know that I intend to use what bit of time that I available right now, at the beginning of January, to tackle this issue head-on. Again, my purpose here is not to step on anyone's toes, but make certain that we never turn away a potentially-valuable contributor simply because they are unnecessarily removed from their development comfort zone. I do realize that there is already on-going work on the build process, and I have no intention of interfering with that. I will wait 24-hours for any objections/reservations from now before making a hard commitment, but frankly, we really to get this done, like right now. Happy New Year. :) -JC

8 33

Notice Of Intent - Visual Studio Build of ReactOS - Take II
by J. C. Jones 12 Jan '13

12 Jan '13

Hi All, I wanted to start fresh since there are several emails/chats going around regarding Visual Studio builds of ReactOS. First, I would like to state something clearly, since there seems to be implicit thoughts to the contrary: Visual Studio is capable of handling a project the size of ReactOS in its entirety in one .sln without any major performance problems, if it is configured correctly. The key phrase is "if it is configured correctly". For example: 1. The performance problem during loading occurs because IntelliSense is being unnecessarily taxed (quite heavily in fact). This is fixed by adding #define WIN32_LEAN_AND_MEAN as appropriate to the IDE settings. 2. The lack of x86_64 and ARM support is occurring because there is a lack of x86_64 and ARM support. :D 3. Some people might look at the Solution Workspace window, see 800 projects, and think, "Wow. That's a lot of projects. I will be scrolling all day long." There is a solution (no pun intended) for that: Don't put 800 projects linearly in the Solution Workspace. Put them in a hierarchy that matches, exactly, the hierarchy of the ReactOS project. 4. That build paths will be broken if the user decides to move his/her ReactOS hierarchy to a different directory after the .sln and .vcxproj files have been generated by cmake, is easily fixed: Use relative paths in the IDE project settings instead. 5. The fact that it is not possible to build, say, just applications, or just drivers, without hunting-and-pecking projects in the Solution Workspace, is related to problem #3: The projects are not yet placed into a hierarchy that mirrors the ReactOS repository. If the projects were placed into a hierarchy that mirrors the ReactOS repository, it would be possible to select, say, drivers, right-click, select Build, and all the drivers will be built depends on what was done in the code, as well as setting proper paths in the IDE. The use would be able to toggle between Debug/Release, x86_32/ARM, and perform the same operation, with expected results. I could go on, but you get the point. It is trivial to set up Visual Studio so that it "behaves properly". I started this effort, and was 10% into the 800 projects, at least setting up the structure, for x86_32, x86_64, and ARM; but I throttled-back because I do not like redundancy of effort, and Amine was already well on his way doing something that was essentially similar. I am confident that, over time, he will solve these problems. In the meantime, I would hope that we keep in mind that the problem is not the tool. The problem is that the tool has not been given a chance to be configured properly. If we configure it properly, these problems go away, and most importantly, when a new developer comes and sees ReactOS in Visual Studio for the first time, what they see makes sense. Let me repeat that: The measure of success here, is not whether it is possible to get Visual Studio to compile ReactOS, although I read some writings about how some wanted the Microsoft compiler over GCC. The measure of success is whether a heavily experience user of Visual Studio sees the IDE for the first time with ReactOS in it, and not start mumbling things like.."Ok.uh... why did they do that.???" By contrast we want them to say: "Wow.800-project solution. Let's see, x86_32, x86_64, ARM support..nice.both Debug and Release present.good good.looks like Solution Workspace mirrors what is on disk..cool.#include paths in IDE project settings are relative to root of solution so I can move solution to another disk if I like.appreciate that.IntelliSense seems to be working correctly.and this livecd thing.I guess right-clicking on that and doing Build does minimum operations necessary to generate a live CD. I wonder what happens when I try to execute the livecd project after built. Wow.that is too awesome!!! Ok. Everything makes sense. I can handle myself from here. Thanks." IMO, we should give Amine time to get the ReactOS repository into this state.. I am re-attaching an image I sent last week about what I would have done for the structure of the Solution Workspace. As you can see from this structure, there is nothing intimidating or inefficient about this structure, and it mirrors what ReactOS veterans see on disk every day. Cheers. -John cid:image001.png@01CDEA11.FFD64AF0

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 58154: [REACTOS] Fix the debugging macros introduced in r58132 (for the _FATAL case): do not use exceptions but instead a breakpoint followed by a process termination procedure (or a bug...
by Timo Kreuzer 12 Jan '13

12 Jan '13

Why not use NtTerminateProcess() for non-native apps? Am 10.01.2013 02:45, schrieb hbelusca(a)svn.reactos.org: > +/* > + * Declare a target-dependent process termination procedure. > + */ > +#ifndef_NTDDK_ /* User-Mode */ > + #ifndef NTOS_MODE_USER /* Should be Win32 */ > + #ifndef _WIN32 > + #error "Unsupported target." > + #else > + #define TerminateCurrentProcess(Status) TerminateProcess(GetCurrentProcess(), (Status)) > + #endif > + #else /* Native */ > + #ifndef _PSFUNCS_H > + NTSYSCALLAPI > + NTSTATUS > + NTAPI > + NtTerminateProcess( > + IN HANDLE ProcessHandle, > + IN NTSTATUS ExitStatus > + ); > + #endif > + #ifndef NtCurrentProcess > + #define NtCurrentProcess() ((HANDLE)(LONG_PTR)-1) > + #endif > + #define TerminateCurrentProcess(Status) NtTerminateProcess(NtCurrentProcess(), (Status)) > + #endif > +#else /* Kernel-Mode */ > + #include <bugcodes.h> > + #define TerminateCurrentProcess(Status) KeBugCheckEx(CRITICAL_SERVICE_FAILED, (Status), 0, 0, 0) > +#endif > +

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 58135: [REACTOS] - Fix the debugging macros I've introduced in r58132; in particular do not use while(true); for forbidding the user to continue execution, but instead raise an exception...
by Timo Kreuzer 08 Jan '13

08 Jan '13

I see a problem with this change. A debug breakpoint will always break into the debugger exactly where it is. Like an ASSERT does. But an exception will usually end up in the installed exception handler. This does not really help with figuring out what went wrong. Am 07.01.2013 00:29, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sun Jan 6 23:29:05 2013 > New Revision: 58135 > > URL: http://svn.reactos.org/svn/reactos?rev=58135&view=rev > Log: > [REACTOS] > - Fix the debugging macros I've introduced in r58132; in particular do not use while(true); for forbidding the user to continue execution, but instead raise an exception with EXCEPTION_NONCONTINUABLE flag (included when called RtlRaiseStatus). > - Adjust the definition of RtlRaiseStatus (in kernel-mode it is ExRaiseStatus which is used). > > Modified: > trunk/reactos/include/reactos/debug.h > > Modified: trunk/reactos/include/reactos/debug.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/debug.h?re… > ============================================================================== > --- trunk/reactos/include/reactos/debug.h [iso-8859-1] (original) > +++ trunk/reactos/include/reactos/debug.h [iso-8859-1] Sun Jan 6 23:29:05 2013 > @@ -15,7 +15,7 @@ > #ifndef __INTERNAL_DEBUG > #define __INTERNAL_DEBUG > > -/* Define DbgPrint/DbgPrintEx/RtlAssert unless the NDK is used */ > +/* Define DbgPrint/DbgPrintEx/RtlAssert/RtlRaiseStatus unless the NDK is used */ > #if !defined(_RTLFUNCS_H) && !defined(_NTDDK_) > > /* Make sure we have basic types (some people include us *before* SDK)... */ > @@ -51,7 +51,27 @@ > PCHAR Message > ); > > +#ifndef _NTDEF_ /* Guard against redefinition from ntdef.h */ > + typedef _Return_type_success_(return >= 0) LONG NTSTATUS; > +#endif > +__analysis_noreturn > +NTSYSAPI > +VOID > +NTAPI > +RtlRaiseStatus( > + _In_ NTSTATUS Status > +); > + > #endif /* !defined(_RTLFUNCS_H) && !defined(_NTDDK_) */ > + > + > +/* Fix usage of RtlRaiseStatus */ > +#if !defined(_RTLFUNCS_H) && defined(_NTDDK_) > + #define RaiseStatus ExRaiseStatus > +#else > + #define RaiseStatus RtlRaiseStatus > +#endif /* !defined(_RTLFUNCS_H) && defined(_NTDDK_) */ > + > > #ifndef assert > #ifndef NASSERT > @@ -136,11 +156,7 @@ > > #endif /* not DBG */ > > -/* > - * These macros are designed to display an optional printf-like > - * user-defined message and to break into the debugger. > - * After that they allow to continue the program execution. > - */ > +/******************************************************************************/ > /* For internal purposes only */ > #define __ERROR_DBGBREAK(...) \ > do { \ > @@ -148,6 +164,18 @@ > DbgBreakPoint(); \ > } while (0) > > +/* For internal purposes only */ > +#define __ERROR_FATAL(Status, ...) \ > +do { \ > + DbgPrint("" __VA_ARGS__); \ > + RaiseStatus((Status)); \ > +} while (0) > + > +/* > + * These macros are designed to display an optional printf-like > + * user-defined message and to break into the debugger. > + * After that they allow to continue the program execution. > + */ > #define ERROR_DBGBREAK(...) \ > do { \ > __NOTICE(ERROR, "\n"); \ > @@ -165,19 +193,18 @@ > * user-defined message and to break into the debugger. > * After that they halt the execution of the current thread. > */ > -#define ERROR_FATAL(...) \ > -do { \ > - __NOTICE(UNRECOVERABLE ERROR, "\n"); \ > - __ERROR_DBGBREAK(__VA_ARGS__); \ > - while (TRUE); \ > +#define ERROR_FATAL(...) \ > +do { \ > + __NOTICE(UNRECOVERABLE ERROR, "\n"); \ > + __ERROR_FATAL(STATUS_ASSERTION_FAILURE, __VA_ARGS__); \ > } while (0) > > #define UNIMPLEMENTED_FATAL(...) \ > do { \ > __NOTICE(UNRECOVERABLE ERROR, "is UNIMPLEMENTED!\n"); \ > - __ERROR_DBGBREAK(__VA_ARGS__); \ > - while (TRUE); \ > -} while (0) > + __ERROR_FATAL(STATUS_NOT_IMPLEMENTED, __VA_ARGS__); \ > +} while (0) > +/******************************************************************************/ > > #define ASSERT_IRQL_LESS_OR_EQUAL(x) ASSERT(KeGetCurrentIrql()<=(x)) > #define ASSERT_IRQL_EQUAL(x) ASSERT(KeGetCurrentIrql()==(x)) > > >

2 4

Re: [ros-dev] [ros-diffs] [hbelusca] 58110: while (TRUE); (when something is unimplemented) ---> ASSERT(FALSE); // while (TRUE); (unless we deal with a 'noreturn' function), and in some cases, return an adequate value. Part...
by Aleksey Bragin 05 Jan '13

05 Jan '13

With all respect, I don't understand many of these changes. Answering between the lines. On 04.01.2013 15:47, hbelusca(a)svn.reactos.org wrote: > NTSTATUS > @@ -643,7 +643,8 @@ > /* FIXME: TODO */ > DPRINT1("You have implemented the KD routines for searching PCI debugger" > "devices, but you have forgotten to implement this routine\n"); > - while (TRUE); > + UNIMPLEMENTED; > + ASSERT(FALSE); // while (TRUE); > } It already prints a mandatory log message that this part is unimplemented. And execution is supposed to stop after printing this message, because it's meaningless to continue (that's why while(TRUE); was put there in the first place). > > static ULONG NTAPI > @@ -678,7 +679,7 @@ > { > /* /PCILOCK is not yet supported */ > UNIMPLEMENTED; > - while (TRUE); > + ASSERT(FALSE); // while (TRUE); > } > #endif > /* Now create the correct resource list based on the supported bus ranges */ It already has UNIMPLEMENTED; and now you added an ASSERT(FALSE); which essentially is the same thing. And if continuation is possible, then just UNIMPLEMENTED would be enough. I'd like some general solution to this. Like, UNIMPLEMENTED_FATAL() or something like that. Any thoughts? Regards, Aleksey Bragin

5 6

Monthly meeting December 2012 rescheduled
by Aleksey Bragin 04 Jan '13

04 Jan '13

Hello! Due to Christmas and New Year holidays this month's status meeting makes little sense. Preliminary it's rescheduled to January, exact dates will be proposed after speaking to our team members. Thank you all for your work in 2012, and bright future awaits us in 2013, I'm sure. Best regards, Aleksey Bragin

5 8

IPv6 link down
by Pierre Schweitzer 04 Jan '13

04 Jan '13

Hi, due to a server move, one IPv6 link is currently down waiting for its replacing link (and for DNS update). Affected services are mainly Jira, Fisheye & Drupal website. We are working on it. Sorry for the inconvenience. IPv4 is all fine on those servers. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

2 4

Re: [ros-dev] [ros-diffs] [tkreuzer] 58101: [WIN32K] Revert the revert from r58091 and apply a correct fix (passed parameters to RECTL_vSetRect() in wrong order)
by Jérôme Gardou 02 Jan '13

02 Jan '13

Thank you for looking into this, I am not really available for coding in reactos at the moment. Greetings. Jérôme tkreuzer(a)svn.reactos.org a écrit : > Author: tkreuzer > Date: Wed Jan 2 14:52:34 2013 > New Revision: 58101 > > URL: http://svn.reactos.org/svn/reactos?rev=58101&view=rev > Log: > [WIN32K] > Revert the revert from r58091 and apply a correct fix (passed parameters to RECTL_vSetRect() in wrong order) > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/dib.h > trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > trunk/reactos/win32ss/user/ntuser/clipboard.c > trunk/reactos/win32ss/user/ntuser/misc/file.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dib.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dib.h?re… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dib.h [iso-8859-1] Wed Jan 2 14:52:34 2013 > @@ -7,8 +7,11 @@ > INT APIENTRY DIB_GetDIBImageBytes (INT width, INT height, INT depth); > HPALETTE FASTCALL DIB_MapPaletteColors(PPALETTE ppal, CONST BITMAPINFO* lpbmi); > HPALETTE FASTCALL BuildDIBPalette (CONST BITMAPINFO *bmi); > + > +/* Those functions permit to tranparently work with a BITMAPCOREINFO structure */ > BITMAPINFO* FASTCALL DIB_ConvertBitmapInfo(CONST BITMAPINFO* bmi, DWORD Usage); > -VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* orig); > +/* Pass Usage = -1 if you don't want to convert the BITMAPINFO back to BITMAPCOREINFO */ > +VOID FASTCALL DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* orig, DWORD Usage); > > INT > APIENTRY > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Jan 2 14:52:34 2013 > @@ -584,7 +584,6 @@ > DWORD compr, size ; > USHORT i; > int bitmap_type; > - RGBTRIPLE* rgbTriples; > RGBQUAD* rgbQuads; > VOID* colorPtr; > > @@ -594,7 +593,6 @@ > return 0; > > colorPtr = (LPBYTE)Info + Info->bmiHeader.biSize; > - rgbTriples = colorPtr; > rgbQuads = colorPtr; > > bitmap_type = DIB_GetBitmapInfo(&Info->bmiHeader, > @@ -643,15 +641,6 @@ > switch(bpp) > { > case 0: /* Only info */ > - if(pbmci) > - { > - pbmci->bmciHeader.bcWidth = (WORD)psurf->SurfObj.sizlBitmap.cx; > - pbmci->bmciHeader.bcHeight = (WORD)((psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > - -psurf->SurfObj.sizlBitmap.cy : > - psurf->SurfObj.sizlBitmap.cy); > - pbmci->bmciHeader.bcPlanes = 1; > - pbmci->bmciHeader.bcBitCount = BitsPerFormat(psurf->SurfObj.iBitmapFormat); > - } > Info->bmiHeader.biWidth = psurf->SurfObj.sizlBitmap.cx; > Info->bmiHeader.biHeight = (psurf->SurfObj.fjBitmap & BMF_TOPDOWN) ? > -psurf->SurfObj.sizlBitmap.cy : > @@ -702,16 +691,6 @@ > if(Usage == DIB_RGB_COLORS) > { > ULONG colors = min(psurf->ppal->NumColors, 256); > - > - if(pbmci) > - { > - for(i = 0; i < colors; i++) > - { > - rgbTriples[i].rgbtRed = psurf->ppal->IndexedColors[i].peRed; > - rgbTriples[i].rgbtGreen = psurf->ppal->IndexedColors[i].peGreen; > - rgbTriples[i].rgbtBlue = psurf->ppal->IndexedColors[i].peBlue; > - } > - } > if(colors != 256) Info->bmiHeader.biClrUsed = colors; > for(i = 0; i < colors; i++) > { > @@ -724,10 +703,7 @@ > else > { > for(i = 0; i < 256; i++) > - { > - if(pbmci) ((WORD*)rgbTriples)[i] = i; > ((WORD*)rgbQuads)[i] = i; > - } > } > } > else > @@ -736,7 +712,6 @@ > { > for(i = 0; i < 256; i++) > { > - if(pbmci) ((WORD*)rgbTriples)[i] = i; > ((WORD*)rgbQuads)[i] = i; > } > } > @@ -753,13 +728,6 @@ > } > for (i = 0; i < pDcPal->NumColors; i++) > { > - if (pbmci) > - { > - rgbTriples[i].rgbtRed = pDcPal->IndexedColors[i].peRed; > - rgbTriples[i].rgbtGreen = pDcPal->IndexedColors[i].peGreen; > - rgbTriples[i].rgbtBlue = pDcPal->IndexedColors[i].peBlue; > - } > - > rgbQuads[i].rgbRed = pDcPal->IndexedColors[i].peRed; > rgbQuads[i].rgbGreen = pDcPal->IndexedColors[i].peGreen; > rgbQuads[i].rgbBlue = pDcPal->IndexedColors[i].peBlue; > @@ -772,55 +740,20 @@ > switch (bpp) > { > case 1: > - if (pbmci) > - { > - rgbTriples[0].rgbtRed = rgbTriples[0].rgbtGreen = > - rgbTriples[0].rgbtBlue = 0; > - rgbTriples[1].rgbtRed = rgbTriples[1].rgbtGreen = > - rgbTriples[1].rgbtBlue = 0xff; > - } > - rgbQuads[0].rgbRed = rgbQuads[0].rgbGreen = > - rgbQuads[0].rgbBlue = 0; > + rgbQuads[0].rgbRed = rgbQuads[0].rgbGreen = rgbQuads[0].rgbBlue = 0; > rgbQuads[0].rgbReserved = 0; > - rgbQuads[1].rgbRed = rgbQuads[1].rgbGreen = > - rgbQuads[1].rgbBlue = 0xff; > + rgbQuads[1].rgbRed = rgbQuads[1].rgbGreen = rgbQuads[1].rgbBlue = 0xff; > rgbQuads[1].rgbReserved = 0; > break; > > case 4: > - if (pbmci) > - RtlCopyMemory(rgbTriples, EGAColorsTriples, sizeof(EGAColorsTriples)); > RtlCopyMemory(rgbQuads, EGAColorsQuads, sizeof(EGAColorsQuads)); > - > break; > > case 8: > { > INT r, g, b; > RGBQUAD *color; > - if (pbmci) > - { > - RGBTRIPLE *colorTriple; > - > - RtlCopyMemory(rgbTriples, DefLogPaletteTriples, > - 10 * sizeof(RGBTRIPLE)); > - RtlCopyMemory(rgbTriples + 246, DefLogPaletteTriples + 10, > - 10 * sizeof(RGBTRIPLE)); > - colorTriple = rgbTriples + 10; > - for(r = 0; r <= 5; r++) /* FIXME */ > - { > - for(g = 0; g <= 5; g++) > - { > - for(b = 0; b <= 5; b++) > - { > - colorTriple->rgbtRed = (r * 0xff) / 5; > - colorTriple->rgbtGreen = (g * 0xff) / 5; > - colorTriple->rgbtBlue = (b * 0xff) / 5; > - colorTriple++; > - } > - } > - } > - } > memcpy(rgbQuads, DefLogPaletteQuads, > 10 * sizeof(RGBQUAD)); > memcpy(rgbQuads + 246, DefLogPaletteQuads + 10, > @@ -935,12 +868,7 @@ > > psurfDest = SURFACE_ShareLockSurface(hBmpDest); > > - RECTL_vSetRect(&rcDest, 0, 0, ScanLines, psurf->SurfObj.sizlBitmap.cx); > - > - rcDest.left = 0; > - rcDest.top = 0; > - rcDest.bottom = ScanLines; > - rcDest.right = psurf->SurfObj.sizlBitmap.cx; > + RECTL_vSetRect(&rcDest, 0, 0, psurf->SurfObj.sizlBitmap.cx, ScanLines); > > srcPoint.x = 0; > > @@ -990,7 +918,7 @@ > > if(pDC) DC_UnlockDc(pDC); > if(psurf) SURFACE_ShareUnlockSurface(psurf); > - if(pbmci) DIB_FreeConvertedBitmapInfo(Info, (BITMAPINFO*)pbmci); > + if(pbmci) DIB_FreeConvertedBitmapInfo(Info, (BITMAPINFO*)pbmci, Usage); > > return ScanLines; > } > @@ -1929,10 +1857,51 @@ > /* Frees a BITMAPINFO created with DIB_ConvertBitmapInfo */ > VOID > FASTCALL > -DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* orig) > -{ > - if(converted != orig) > +DIB_FreeConvertedBitmapInfo(BITMAPINFO* converted, BITMAPINFO* orig, DWORD usage) > +{ > + BITMAPCOREINFO* pbmci; > + if(converted == orig) > + return; > + > + if(usage == -1) > + { > + /* Caller don't want any conversion */ > ExFreePoolWithTag(converted, TAG_DIB); > + return; > + } > + > + /* Perform inverse conversion */ > + pbmci = (BITMAPCOREINFO*)orig; > + > + ASSERT(pbmci->bmciHeader.bcSize == sizeof(BITMAPCOREHEADER)); > + pbmci->bmciHeader.bcBitCount = converted->bmiHeader.biBitCount; > + pbmci->bmciHeader.bcWidth = converted->bmiHeader.biWidth; > + pbmci->bmciHeader.bcHeight = converted->bmiHeader.biHeight; > + pbmci->bmciHeader.bcPlanes = converted->bmiHeader.biPlanes; > + > + if(pbmci->bmciHeader.bcBitCount <= 8) > + { > + UINT numColors = converted->bmiHeader.biClrUsed; > + if(!numColors) numColors = 1 << pbmci->bmciHeader.bcBitCount; > + if(usage == DIB_PAL_COLORS) > + { > + RtlZeroMemory(pbmci->bmciColors, (1 << pbmci->bmciHeader.bcBitCount) * sizeof(WORD)); > + RtlCopyMemory(pbmci->bmciColors, converted->bmiColors, numColors * sizeof(WORD)); > + } > + else > + { > + UINT i; > + RtlZeroMemory(pbmci->bmciColors, (1 << pbmci->bmciHeader.bcBitCount) * sizeof(RGBTRIPLE)); > + for(i=0; i<numColors; i++) > + { > + pbmci->bmciColors[i].rgbtRed = converted->bmiColors[i].rgbRed; > + pbmci->bmciColors[i].rgbtGreen = converted->bmiColors[i].rgbGreen; > + pbmci->bmciColors[i].rgbtBlue = converted->bmiColors[i].rgbBlue; > + } > + } > + } > + /* Now free it, it's not needed anymore */ > + ExFreePoolWithTag(converted, TAG_DIB); > } > > /* EOF */ > > Modified: trunk/reactos/win32ss/user/ntuser/clipboard.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/clipbo… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/clipboard.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/clipboard.c [iso-8859-1] Wed Jan 2 14:52:34 2013 > @@ -276,7 +276,7 @@ > UserReleaseDC(NULL, hdc, FALSE); > > if (pConvertedBmi) > - DIB_FreeConvertedBitmapInfo(pConvertedBmi, pBmi); > + DIB_FreeConvertedBitmapInfo(pConvertedBmi, pBmi, -1); > } > > VOID static NTAPI > > Modified: trunk/reactos/win32ss/user/ntuser/misc/file.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/misc/f… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/misc/file.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/misc/file.c [iso-8859-1] Wed Jan 2 14:52:34 2013 > @@ -233,7 +233,7 @@ > 0); > > NtGdiDeleteObjectApp(hdc); > - DIB_FreeConvertedBitmapInfo(pConvertedInfo, pbmi); > + DIB_FreeConvertedBitmapInfo(pConvertedInfo, pbmi, -1); > } > else > { > >

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 58016: [MSVCRT] Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, int srclen, wcha...
by Jérôme Gardou 30 Dec '12

30 Dec '12

I think that in the spec files semantics, destination strings are just buffers and should be considered as pointers. hbelusca(a)svn.reactos.org a écrit : > Author: hbelusca > Date: Wed Dec 26 19:26:08 2012 > New Revision: 58016 > > URL: http://svn.reactos.org/svn/reactos?rev=58016&view=rev > Log: > [MSVCRT] > Export __crtLCMapStringW and correct __crtLCMapStringA: their prototypes are : > > int CDECL __crtLCMapStringW(LCID lcid, DWORD mapflags, const wchar_t *src, > int srclen, wchar_t *dst, int dstlen, unsigned int codepage, int xflag) > > and > > int CDECL __crtLCMapStringA(LCID lcid, DWORD mapflags, const char* src, > int srclen, char* dst, int dstlen, unsigned int codepage, int xflag) > > Needed by SVN. > > Modified: > trunk/reactos/dll/win32/msvcrt/msvcrt.spec > > Modified: trunk/reactos/dll/win32/msvcrt/msvcrt.spec > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/msvcrt/msvcrt.sp… > ============================================================================== > --- trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/msvcrt/msvcrt.spec [iso-8859-1] Wed Dec 26 19:26:08 2012 > @@ -143,8 +143,8 @@ > @ cdecl __crtCompareStringW(long long wstr long wstr long) kernel32.CompareStringW > @ cdecl __crtGetLocaleInfoW(long long ptr long) kernel32.GetLocaleInfoW > @ cdecl __crtGetStringTypeW(long long wstr long ptr) > -@ cdecl __crtLCMapStringA(long long str long ptr long long long) > -# stub __crtLCMapStringW > +@ cdecl __crtLCMapStringA(long long str long str long long long) > +@ cdecl __crtLCMapStringW(long long wstr long wstr long long long) > @ cdecl __daylight() __p__daylight > @ cdecl __dllonexit(ptr ptr ptr) > @ cdecl __doserrno() > >

2 2

New testbot slave
by Pierre Schweitzer 29 Dec '12

29 Dec '12

Hello, starting now a new debug testbot slave is available. It is running VMware Player 5.0.1 under Linux x64. It will run all the ISOs built by the Linux builder. Its results are available at the usual place: http://www.reactos.org/testman with the name: CMake_x86_GCCLin (VMPlayer). With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

2 1

Universities collaboration
by Aleksey Bragin 26 Dec '12

26 Dec '12

Hello and Merry Christmas! I know there are people from various technical universities around the world subscribed to this list. If you work there, please reply to me, as I'm looking for some collaboration related to Operating Systems theory course and ReactOS. Thank you, Aleksey Bragin P.S. Crossposting to both ros-dev and ros-general is a bad idea, but I'm doing this to reach out all our subscribers. Sorry for inconvinience.

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 57976: [EXPLORER_NEW] - Add a manifest file to support theming - Formatting fixes - Based on Andrew Green's GSoC branch
by Ged Murphy 23 Dec '12

23 Dec '12

Are you planning on resurrecting this branch Thomas? On 23/12/2012 10:25, "tfaber(a)svn.reactos.org" <tfaber(a)svn.reactos.org> wrote: >Author: tfaber >Date: Sun Dec 23 10:25:19 2012 >New Revision: 57976 > >URL: http://svn.reactos.org/svn/reactos?rev=57976&view=rev >Log: >[EXPLORER_NEW] >- Add a manifest file to support theming >- Formatting fixes >- Based on Andrew Green's GSoC branch > >Added: > trunk/reactos/base/shell/explorer-new/explorer.exe.manifest (with >props) >Modified: > trunk/reactos/base/shell/explorer-new/explorer.rc > trunk/reactos/base/shell/explorer-new/taskswnd.c > trunk/reactos/base/shell/explorer-new/trayntfy.c

2 1

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Release: build failed
by Pierre Schweitzer 15 Dec '12

15 Dec '12

Fixed as well. Forgot that one, sorry. Le samedi 15 décembre 2012 à 12:48 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/289 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1B > > Build Reason: The Periodic scheduler named 'release' triggered this build > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed compile_1 > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 57909: [INCLUDE/CRT] - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us.
by Timo Kreuzer 14 Dec '12

14 Dec '12

The reason for this define is to allow swprintf etc., wich is then an alias for _swprintf, which we do implement. I don't see why this should be disabled. Am 13.12.2012 20:21, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Thu Dec 13 19:21:30 2012 > New Revision: 57909 > > URL: http://svn.reactos.org/svn/reactos?rev=57909&view=rev > Log: > [INCLUDE/CRT] > - _CRT_NON_CONFORMING_SWPRINTFS is not relevant for us. > > Modified: > trunk/reactos/include/crt/stdio.h > trunk/reactos/include/crt/wchar.h > > Modified: trunk/reactos/include/crt/stdio.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/stdio.h?rev=57… > ============================================================================== > --- trunk/reactos/include/crt/stdio.h [iso-8859-1] (original) > +++ trunk/reactos/include/crt/stdio.h [iso-8859-1] Thu Dec 13 19:21:30 2012 > @@ -322,12 +322,14 @@ > #include <vadefs.h> > #endif > > +#if 0 //this is for MSVCRT80 and higher, which we don't use nor implement > #ifdef _CRT_NON_CONFORMING_SWPRINTFS > #ifndef __cplusplus > #define swprintf _swprintf > #define vswprintf _vswprintf > #define _swprintf_l __swprintf_l > #define _vswprintf_l __vswprintf_l > +#endif > #endif > #endif > > > Modified: trunk/reactos/include/crt/wchar.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/crt/wchar.h?rev=57… > ============================================================================== > --- trunk/reactos/include/crt/wchar.h [iso-8859-1] (original) > +++ trunk/reactos/include/crt/wchar.h [iso-8859-1] Thu Dec 13 19:21:30 2012 > @@ -561,12 +561,14 @@ > _CRTIMP int __cdecl __swprintf_l(wchar_t *_Dest,const wchar_t *_Format,_locale_t _Plocinfo,...); > _CRTIMP int __cdecl __vswprintf_l(wchar_t *_Dest,const wchar_t *_Format,_locale_t _Plocinfo,va_list _Args); > > +#if 0 //this is for MSVCRT80 and higher, which we don't use nor implement > #ifdef _CRT_NON_CONFORMING_SWPRINTFS > #ifndef __cplusplus > #define swprintf _swprintf > #define vswprintf _vswprintf > #define _swprintf_l __swprintf_l > #define _vswprintf_l __vswprintf_l > +#endif > #endif > #endif > > > >

2 1

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 14 Dec '12

14 Dec '12

Fixed. The needed env variable is now exported. Le vendredi 14 décembre 2012 à 21:56 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/2066 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 57913 > Blamelist: akhaldi > > BUILD FAILED: failed compile_1 > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 57815: [SPIDER] - Only dissolve a stack of cards if they're of the same color - Allow easier recognition of suit in concealed cards - Patch by Marcel Leyendeckers, m dot leyendeckers at gm...
by Timo Kreuzer 14 Dec '12

14 Dec '12

YAY! Finally this is fixed! Am 07.12.2012 19:00, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Fri Dec 7 18:00:30 2012 > New Revision: 57815 > > URL: http://svn.reactos.org/svn/reactos?rev=57815&view=rev > Log: > [SPIDER] > - Only dissolve a stack of cards if they're of the same color > - Allow easier recognition of suit in concealed cards > - Patch by Marcel Leyendeckers, m dot leyendeckers at gmx dot de > CORE-6808 #resolve #comment Committed. Thanks! > > Modified: > trunk/reactos/base/applications/games/spider/spigame.cpp > > Modified: trunk/reactos/base/applications/games/spider/spigame.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/games/sp… > ============================================================================== > --- trunk/reactos/base/applications/games/spider/spigame.cpp [iso-8859-1] (original) > +++ trunk/reactos/base/applications/games/spider/spigame.cpp [iso-8859-1] Fri Dec 7 18:00:30 2012 > @@ -249,7 +249,8 @@ > int i, max = NUM_ONECOLOR_CARDS - dragcards.NumCards() - 1; > > /* Dragged cards have been checked to be in order, check stack cards */ > - if (stackLookingGood(mystack, max)) > + if (mystack[0].Suit() == dragcard.Suit() && > + stackLookingGood(mystack, max)) > { > CardStack s = stackobj.GetCardStack(); > CardStack f; > @@ -279,8 +280,8 @@ > { > int i, pos; > > - /* Compute the value for yRowStackCardOffset based on the height of the card, so the card number isn't hidden on larger cards */ > - yRowStackCardOffset = (int)(__cardheight / 6.7); > + /* Compute the value for yRowStackCardOffset based on the height of the card, so the card number and suite isn't hidden on larger cards except Ace */ > + yRowStackCardOffset = (int)(__cardheight / 6.4); > > pDeck = SpiderWnd.CreateRegion(0, true, 0, 0, -15, 0); > pDeck->SetFaceDirection(CS_FACE_DOWN, 0); > > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 57899: [FREELDR] - Use a list of possible operating system method loading to load ReactOS / ROS-Setup / Windows / Linux or booting from a disk / partition ..., instead of using a (huge) ...
by Aleksey Bragin 14 Dec '12

14 Dec '12

Great, that if/elseif was really lame and I wanted to fix that since the moment I added Windows boot support. Regards, Aleksey Bragin On 13.12.2012 4:46, hbelusca(a)svn.reactos.org wrote: > Author: hbelusca > Date: Thu Dec 13 00:46:55 2012 > New Revision: 57899 > > URL: http://svn.reactos.org/svn/reactos?rev=57899&view=rev > Log: > [FREELDR] > - Use a list of possible operating system method loading to load ReactOS / ROS-Setup / Windows / Linux or booting from a disk / partition ..., instead of using a (huge) if () else if () ... instruction. > - Modify the corresponding functions to take into account for this new functionality. > - Allow having a live + boot cd if needed, in a elegant way. > > Modified: > trunk/reactos/boot/freeldr/freeldr/arch/i386/custom.c > trunk/reactos/boot/freeldr/freeldr/arch/i386/miscboot.c > trunk/reactos/boot/freeldr/freeldr/bootmgr.c > trunk/reactos/boot/freeldr/freeldr/include/arch/i386/miscboot.h > trunk/reactos/boot/freeldr/freeldr/include/linux.h > trunk/reactos/boot/freeldr/freeldr/include/winldr.h > trunk/reactos/boot/freeldr/freeldr/linuxboot.c > trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/custom.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/custom.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/custom.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -40,8 +40,8 @@ > "ReactOS", > "Linux" > }; > - ULONG CustomBootMenuCount = sizeof(CustomBootMenuList) / sizeof(CustomBootMenuList[0]); > - ULONG SelectedMenuItem; > + ULONG CustomBootMenuCount = sizeof(CustomBootMenuList) / sizeof(CustomBootMenuList[0]); > + ULONG SelectedMenuItem; > > if (!UiDisplayMenu("Please choose a boot method:", > CustomBootMenuList, > @@ -74,10 +74,11 @@ > > VOID OptionMenuCustomBootDisk(VOID) > { > - CHAR SectionName[100]; > - CHAR BootDriveString[20]; > - ULONG SectionId; > + ULONG_PTR SectionId; > + CHAR SectionName[100]; > + CHAR BootDriveString[20]; > TIMEINFO* TimeInfo; > + OperatingSystemItem OperatingSystem; > > RtlZeroMemory(SectionName, sizeof(SectionName)); > RtlZeroMemory(BootDriveString, sizeof(BootDriveString)); > @@ -111,16 +112,21 @@ > > UiMessageBox(CustomBootPrompt); > > - LoadAndBootDrive(SectionName); > + OperatingSystem.SystemPartition = SectionName; > + OperatingSystem.LoadIdentifier = NULL; > + OperatingSystem.OsLoadOptions = NULL; > + > + LoadAndBootDrive(&OperatingSystem, 0); > } > > VOID OptionMenuCustomBootPartition(VOID) > { > - CHAR SectionName[100]; > - CHAR BootDriveString[20]; > - CHAR BootPartitionString[20]; > - ULONG SectionId; > + ULONG_PTR SectionId; > + CHAR SectionName[100]; > + CHAR BootDriveString[20]; > + CHAR BootPartitionString[20]; > TIMEINFO* TimeInfo; > + OperatingSystemItem OperatingSystem; > > RtlZeroMemory(SectionName, sizeof(SectionName)); > RtlZeroMemory(BootDriveString, sizeof(BootDriveString)); > @@ -166,17 +172,22 @@ > > UiMessageBox(CustomBootPrompt); > > - LoadAndBootPartition(SectionName); > + OperatingSystem.SystemPartition = SectionName; > + OperatingSystem.LoadIdentifier = NULL; > + OperatingSystem.OsLoadOptions = NULL; > + > + LoadAndBootPartition(&OperatingSystem, 0); > } > > VOID OptionMenuCustomBootBootSectorFile(VOID) > { > - CHAR SectionName[100]; > - CHAR BootDriveString[20]; > - CHAR BootPartitionString[20]; > - CHAR BootSectorFileString[200]; > - ULONG SectionId; > + ULONG_PTR SectionId; > + CHAR SectionName[100]; > + CHAR BootDriveString[20]; > + CHAR BootPartitionString[20]; > + CHAR BootSectorFileString[200]; > TIMEINFO* TimeInfo; > + OperatingSystemItem OperatingSystem; > > RtlZeroMemory(SectionName, sizeof(SectionName)); > RtlZeroMemory(BootDriveString, sizeof(BootDriveString)); > @@ -234,19 +245,24 @@ > > UiMessageBox(CustomBootPrompt); > > - LoadAndBootBootSector(SectionName); > + OperatingSystem.SystemPartition = SectionName; > + OperatingSystem.LoadIdentifier = NULL; > + OperatingSystem.OsLoadOptions = NULL; > + > + LoadAndBootBootSector(&OperatingSystem, 0); > } > > VOID OptionMenuCustomBootLinux(VOID) > { > - CHAR SectionName[100]; > - CHAR BootDriveString[20]; > - CHAR BootPartitionString[20]; > - CHAR LinuxKernelString[200]; > - CHAR LinuxInitrdString[200]; > - CHAR LinuxCommandLineString[200]; > - ULONG SectionId; > + ULONG_PTR SectionId; > + CHAR SectionName[100]; > + CHAR BootDriveString[20]; > + CHAR BootPartitionString[20]; > + CHAR LinuxKernelString[200]; > + CHAR LinuxInitrdString[200]; > + CHAR LinuxCommandLineString[200]; > TIMEINFO* TimeInfo; > + OperatingSystemItem OperatingSystem; > > RtlZeroMemory(SectionName, sizeof(SectionName)); > RtlZeroMemory(BootDriveString, sizeof(BootDriveString)); > @@ -331,7 +347,11 @@ > > UiMessageBox(CustomBootPrompt); > > - LoadAndBootLinux(SectionName, "Custom Linux Setup"); > + OperatingSystem.SystemPartition = SectionName; > + OperatingSystem.LoadIdentifier = "Custom Linux Setup"; > + OperatingSystem.OsLoadOptions = NULL; > + > + LoadAndBootLinux(&OperatingSystem, 0); > } > > VOID OptionMenuReboot(VOID) > > Modified: trunk/reactos/boot/freeldr/freeldr/arch/i386/miscboot.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/arch/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/arch/i386/miscboot.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/arch/i386/miscboot.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -19,21 +19,24 @@ > > #include <freeldr.h> > > -VOID LoadAndBootBootSector(PCSTR OperatingSystemName) > +VOID > +LoadAndBootBootSector(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > { > + ULONG_PTR SectionId; > + PCSTR SectionName = OperatingSystem->SystemPartition; > + CHAR FileName[260]; > PFILE FilePointer; > + ULONG BytesRead; > CHAR SettingName[80]; > - ULONG SectionId; > - CHAR FileName[260]; > - ULONG BytesRead; > > // Find all the message box settings and run them > - UiShowMessageBoxesInSection(OperatingSystemName); > + UiShowMessageBoxesInSection(SectionName); > > // Try to open the operating system section in the .ini file > - if (!IniOpenSection(OperatingSystemName, &SectionId)) > - { > - sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", OperatingSystemName); > + if (!IniOpenSection(SectionName, &SectionId)) > + { > + sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", SectionName); > UiMessageBox(SettingName); > return; > } > @@ -79,22 +82,25 @@ > ChainLoadBiosBootSectorCode(); > } > > -VOID LoadAndBootPartition(PCSTR OperatingSystemName) > +VOID > +LoadAndBootPartition(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > { > + ULONG_PTR SectionId; > + PCSTR SectionName = OperatingSystem->SystemPartition; > CHAR SettingName[80]; > CHAR SettingValue[80]; > - ULONG SectionId; > PARTITION_TABLE_ENTRY PartitionTableEntry; > UCHAR DriveNumber; > ULONG PartitionNumber; > > // Find all the message box settings and run them > - UiShowMessageBoxesInSection(OperatingSystemName); > + UiShowMessageBoxesInSection(SectionName); > > // Try to open the operating system section in the .ini file > - if (!IniOpenSection(OperatingSystemName, &SectionId)) > - { > - sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", OperatingSystemName); > + if (!IniOpenSection(SectionName, &SectionId)) > + { > + sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", SectionName); > UiMessageBox(SettingName); > return; > } > @@ -151,20 +157,23 @@ > ChainLoadBiosBootSectorCode(); > } > > -VOID LoadAndBootDrive(PCSTR OperatingSystemName) > +VOID > +LoadAndBootDrive(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > { > + ULONG_PTR SectionId; > + PCSTR SectionName = OperatingSystem->SystemPartition; > CHAR SettingName[80]; > CHAR SettingValue[80]; > - ULONG SectionId; > UCHAR DriveNumber; > > // Find all the message box settings and run them > - UiShowMessageBoxesInSection(OperatingSystemName); > + UiShowMessageBoxesInSection(SectionName); > > // Try to open the operating system section in the .ini file > - if (!IniOpenSection(OperatingSystemName, &SectionId)) > - { > - sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", OperatingSystemName); > + if (!IniOpenSection(SectionName, &SectionId)) > + { > + sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", SectionName); > UiMessageBox(SettingName); > return; > } > > Modified: trunk/reactos/boot/freeldr/freeldr/bootmgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/bootm… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/bootmgr.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/bootmgr.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -24,7 +24,90 @@ > CHAR reactos_arc_hardware_data[HW_MAX_ARC_HEAP_SIZE] = {0}; > CHAR reactos_arc_strings[32][256]; > > -ULONG GetDefaultOperatingSystem(OperatingSystemItem* OperatingSystemList, ULONG OperatingSystemCount) > +typedef > +VOID > +(*OS_LOADING_METHOD)(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > + > +struct > +{ > + CHAR BootType[80]; > + USHORT OperatingSystemVersion; > + OS_LOADING_METHOD Load; > +} OSLoadingMethods[] = > +{ > +#ifdef FREELDR_REACTOS_SETUP > + {"ReactOSSetup", 0 , LoadReactOSSetup }, > +#endif > + > +#ifdef _M_IX86 > + {"BootSector" , 0 , LoadAndBootBootSector}, > + {"Drive" , 0 , LoadAndBootDrive }, > + {"Partition" , 0 , LoadAndBootPartition }, > + > + {"Linux" , 0 , LoadAndBootLinux }, > + > + {"Windows" , 0 , LoadAndBootWindows }, > + {"WindowsNT40" , _WIN32_WINNT_NT4 , LoadAndBootWindows }, > +#endif > + {"Windows2003" , _WIN32_WINNT_WS03, LoadAndBootWindows }, > + > +// {"Not found" , 0 , NULL } > +}; > + > +VOID LoadOperatingSystem(IN OperatingSystemItem* OperatingSystem) > +{ > + ULONG_PTR SectionId; > + PCSTR SectionName = OperatingSystem->SystemPartition; > + CHAR BootType[80]; > + ULONG i; > + > + // Try to open the operating system section in the .ini file > + if (IniOpenSection(SectionName, &SectionId)) > + { > + // Try to read the boot type > + IniReadSettingByName(SectionId, "BootType", BootType, sizeof(BootType)); > + } > + else > + { > + BootType[0] = ANSI_NULL; > + } > + > + if (BootType[0] == ANSI_NULL && SectionName[0] != ANSI_NULL) > + { > + // Try to infere the boot type value > +#ifdef _M_IX86 > + ULONG FileId; > + if (ArcOpen((PSTR)SectionName, OpenReadOnly, &FileId) == ESUCCESS) > + { > + ArcClose(FileId); > + strcpy(BootType, "BootSector"); > + } > + else > +#endif > + { > + strcpy(BootType, "Windows"); > + } > + } > + > + // Install the drive mapper according to this section drive mappings > +#if defined(_M_IX86) && !defined(_MSC_VER) > + DriveMapMapDrivesInSection(SectionName); > +#endif > + > + // Loop through the OS loading method table and find a suitable OS to boot > + for (i = 0; i < sizeof(OSLoadingMethods) / sizeof(OSLoadingMethods[0]); ++i) > + { > + if (_stricmp(BootType, OSLoadingMethods[i].BootType) == 0) > + { > + OSLoadingMethods[i].Load(OperatingSystem, > + OSLoadingMethods[i].OperatingSystemVersion); > + return; > + } > + } > +} > + > +ULONG GetDefaultOperatingSystem(OperatingSystemItem* OperatingSystemList, ULONG OperatingSystemCount) > { > CHAR DefaultOSText[80]; > PCSTR DefaultOSName; > @@ -105,17 +188,14 @@ > > VOID RunLoader(VOID) > { > - CHAR SettingValue[80]; > - CHAR BootType[80]; > ULONG_PTR SectionId; > ULONG OperatingSystemCount; > OperatingSystemItem* OperatingSystemList; > - PCSTR *OperatingSystemDisplayNames; > - PCSTR SectionName; > - ULONG i; > + PCSTR* OperatingSystemDisplayNames; > ULONG DefaultOperatingSystem; > LONG TimeOut; > ULONG SelectedOperatingSystem; > + ULONG i; > > // FIXME: if possible, only detect and register ARC devices... > if (!MachHwDetect()) > @@ -206,78 +286,8 @@ > > TimeOut = -1; > > - // Try to open the operating system section in the .ini file > - SettingValue[0] = ANSI_NULL; > - SectionName = OperatingSystemList[SelectedOperatingSystem].SystemPartition; > - if (IniOpenSection(SectionName, &SectionId)) > - { > - // Try to read the boot type > - IniReadSettingByName(SectionId, "BootType", BootType, sizeof(BootType)); > - } > - else > - BootType[0] = ANSI_NULL; > - > - if (BootType[0] == ANSI_NULL && SectionName[0] != ANSI_NULL) > - { > - // Try to infere boot type value > -#ifdef _M_IX86 > - ULONG FileId; > - if (ArcOpen((CHAR*)SectionName, OpenReadOnly, &FileId) == ESUCCESS) > - { > - ArcClose(FileId); > - strcpy(BootType, "BootSector"); > - } > - else > -#endif > - { > - strcpy(BootType, "Windows"); > - } > - } > - > - // Get OS setting value > - IniOpenSection("Operating Systems", &SectionId); > - IniReadSettingByName(SectionId, SectionName, SettingValue, sizeof(SettingValue)); > - > - // Install the drive mapper according to this sections drive mappings > -#if defined(_M_IX86) && !defined(_MSC_VER) > - DriveMapMapDrivesInSection(SectionName); > -#endif > - > -#ifdef FREELDR_REACTOS_SETUP > - // WinLdr-style boot > - LoadReactOSSetup(); > -#elif defined(_M_IX86) > - if (_stricmp(BootType, "Windows") == 0) > - { > - LoadAndBootWindows(SectionName, SettingValue, 0); > - } > - else if (_stricmp(BootType, "WindowsNT40") == 0) > - { > - LoadAndBootWindows(SectionName, SettingValue, _WIN32_WINNT_NT4); > - } > - else if (_stricmp(BootType, "Windows2003") == 0) > - { > - LoadAndBootWindows(SectionName, SettingValue, _WIN32_WINNT_WS03); > - } > - else if (_stricmp(BootType, "Linux") == 0) > - { > - LoadAndBootLinux(SectionName, OperatingSystemDisplayNames[SelectedOperatingSystem]); > - } > - else if (_stricmp(BootType, "BootSector") == 0) > - { > - LoadAndBootBootSector(SectionName); > - } > - else if (_stricmp(BootType, "Partition") == 0) > - { > - LoadAndBootPartition(SectionName); > - } > - else if (_stricmp(BootType, "Drive") == 0) > - { > - LoadAndBootDrive(SectionName); > - } > -#else > - LoadAndBootWindows(SectionName, SettingValue, _WIN32_WINNT_WS03); > -#endif > + // Load the chosen operating system > + LoadOperatingSystem(&OperatingSystemList[SelectedOperatingSystem]); > } > > reboot: > > Modified: trunk/reactos/boot/freeldr/freeldr/include/arch/i386/miscboot.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inclu… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/include/arch/i386/miscboot.h [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/include/arch/i386/miscboot.h [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -19,6 +19,12 @@ > > #pragma once > > -VOID LoadAndBootBootSector(PCSTR OperatingSystemName); > -VOID LoadAndBootPartition(PCSTR OperatingSystemName); > -VOID LoadAndBootDrive(PCSTR OperatingSystemName); > +VOID > +LoadAndBootBootSector(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > +VOID > +LoadAndBootPartition(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > +VOID > +LoadAndBootDrive(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > > Modified: trunk/reactos/boot/freeldr/freeldr/include/linux.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inclu… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/include/linux.h [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/include/linux.h [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -18,6 +18,7 @@ > */ > > #include <fs.h> > +#include <oslist.h> > > #ifndef __LINUX_H > #define __LINUX_H > @@ -129,7 +130,9 @@ > VOID BootNewLinuxKernel(VOID); // Implemented in linux.S > VOID BootOldLinuxKernel(ULONG KernelSize); // Implemented in linux.S > > -VOID LoadAndBootLinux(PCSTR OperatingSystemName, PCSTR Description); > +VOID > +LoadAndBootLinux(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > > BOOLEAN LinuxParseIniSection(PCSTR OperatingSystemName); > BOOLEAN LinuxReadBootSector(PFILE LinuxKernelFile); > > Modified: trunk/reactos/boot/freeldr/freeldr/include/winldr.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/inclu… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/include/winldr.h [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/include/winldr.h [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -80,9 +80,8 @@ > // ReactOS Loading Functions > // > /////////////////////////////////////////////////////////////////////////////////////// > -VOID LoadAndBootWindows(PCSTR OperatingSystemName, > - PSTR SettingsValue, > - USHORT OperatingSystemVersion); > +VOID LoadAndBootWindows(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > > // conversion.c > PVOID VaToPa(PVOID Va); > @@ -179,7 +178,9 @@ > LPCSTR BootPath, > BOOLEAN Setup); > > -VOID LoadReactOSSetup(VOID); > +VOID > +LoadReactOSSetup(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion); > > VOID > WinLdrSetupMachineDependent(PLOADER_PARAMETER_BLOCK LoaderBlock); > > Modified: trunk/reactos/boot/freeldr/freeldr/linuxboot.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/linux… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/linuxboot.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/linuxboot.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -72,8 +72,12 @@ > return TRUE; > } > > -VOID LoadAndBootLinux(PCSTR OperatingSystemName, PCSTR Description) > -{ > +VOID > +LoadAndBootLinux(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > +{ > + PCSTR SectionName = OperatingSystem->SystemPartition; > + PCSTR Description = OperatingSystem->LoadIdentifier; > PFILE LinuxKernel = 0; > PFILE LinuxInitrdFile = 0; > CHAR TempString[260]; > @@ -93,7 +97,7 @@ > UiDrawProgressBarCenter(0, 100, LinuxBootDescription); > > // Parse the .ini file section > - if (!LinuxParseIniSection(OperatingSystemName)) > + if (!LinuxParseIniSection(SectionName)) > { > goto LinuxBootFailed; > } > @@ -235,18 +239,18 @@ > LinuxCommandLineSize = 0; > } > > -BOOLEAN LinuxParseIniSection(PCSTR OperatingSystemName) > -{ > - CHAR SettingName[260]; > - ULONG SectionId; > +BOOLEAN LinuxParseIniSection(PCSTR SectionName) > +{ > + ULONG_PTR SectionId; > + CHAR SettingName[260]; > > // Find all the message box settings and run them > - UiShowMessageBoxesInSection(OperatingSystemName); > + UiShowMessageBoxesInSection(SectionName); > > // Try to open the operating system section in the .ini file > - if (!IniOpenSection(OperatingSystemName, &SectionId)) > - { > - sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", OperatingSystemName); > + if (!IniOpenSection(SectionName, &SectionId)) > + { > + sprintf(SettingName, "Section [%s] not found in freeldr.ini.\n", SectionName); > UiMessageBox(SettingName); > return FALSE; > } > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/setupldr.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -133,7 +133,9 @@ > } while (InfFindNextLine(&InfContext, &InfContext)); > } > > -VOID LoadReactOSSetup(VOID) > +VOID > +LoadReactOSSetup(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > { > CHAR FileName[512]; > CHAR BootPath[512]; > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/winldr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/windows/winldr.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/winldr.c [iso-8859-1] Thu Dec 13 00:46:55 2012 > @@ -456,22 +456,28 @@ > } > > VOID > -LoadAndBootWindows(PCSTR OperatingSystemName, > - PSTR SettingsValue, > - USHORT OperatingSystemVersion) > -{ > +LoadAndBootWindows(IN OperatingSystemItem* OperatingSystem, > + IN USHORT OperatingSystemVersion) > +{ > + ULONG_PTR SectionId; > + PCSTR SectionName = OperatingSystem->SystemPartition; > + CHAR SettingsValue[80]; > BOOLEAN HasSection; > - char BootPath[MAX_PATH]; > + CHAR BootPath[MAX_PATH]; > CHAR FileName[MAX_PATH]; > CHAR BootOptions[256]; > PCHAR File; > BOOLEAN Status; > - ULONG_PTR SectionId; > PLOADER_PARAMETER_BLOCK LoaderBlock; > + > + // Get OS setting value > + SettingsValue[0] = ANSI_NULL; > + IniOpenSection("Operating Systems", &SectionId); > + IniReadSettingByName(SectionId, SectionName, SettingsValue, sizeof(SettingsValue)); > > // Open the operating system section > // specified in the .ini file > - HasSection = IniOpenSection(OperatingSystemName, &SectionId); > + HasSection = IniOpenSection(SectionName, &SectionId); > > UiDrawBackdrop(); > UiDrawProgressBarCenter(1, 100, "Loading NT..."); > @@ -480,7 +486,7 @@ > if (!HasSection || > !IniReadSettingByName(SectionId, "SystemPath", BootPath, sizeof(BootPath))) > { > - strcpy(BootPath, OperatingSystemName); > + strcpy(BootPath, SectionName); > } > > /* Special case for LiveCD */ > @@ -499,7 +505,7 @@ > if (!HasSection || !IniReadSettingByName(SectionId, "Options", BootOptions, sizeof(BootOptions))) > { > /* Get options after the title */ > - const CHAR*p = SettingsValue; > + PCSTR p = SettingsValue; > while (*p == ' ' || *p == '"') > p++; > while (*p != '\0' && *p != '"') > >

1 0

Re: [ros-dev] [ros-diffs] [pschweitzer] 57792: [NTOSKRNL] ExFreePool -> ExFreePoolWithTag
by Aleksey Bragin 04 Dec '12

04 Dec '12

On 04.12.2012 2:15, pschweitzer(a)svn.reactos.org wrote: > - ExFreePool(SharedRange); > + ExFreePoolWithTag(SharedRange, 'FSRA'); > /* We need to rebuild the list of shared ranges. */ > DPRINT("Removing the lock entry %wZ (%08x%08x:%08x%08x)\n", > &FileObject->FileName, > @@ -1287,7 +1287,7 @@ > SharedRange = CONTAINING_RECORD(SharedEntry, LOCK_SHARED_RANGE, Entry); > SharedEntry = SharedEntry->Flink; > RemoveEntryList(SharedEntry); > - ExFreePool(SharedRange); > + ExFreePoolWithTag(SharedRange, 'FSRA'); > } > while ((Entry = RtlGetElementGenericTable(&InternalInfo->RangeTable, 0)) != NULL) > { > > It would be a good idea to add this to TAG_ list of defines.

1 0

24pullrequests.com
by Александр 02 Dec '12

02 Dec '12

3 2

Re: [ros-dev] [ros-diffs] [hbelusca] 57780: [CPORTLIB/FREELDR] GetByte --> Wait for data (with timeout) and get it if available. PollByte --> Check for data, get it if available, and return immediately.
by Timo Kreuzer 30 Nov '12

30 Nov '12

You are aware that this changes the behavior? Polling previously only checked, if data is available, but didn't read it from the port. But afaics it's only relvenat for WinLdrPortPollOnly, which seems to be unused anyway. Am 29.11.2012 00:16, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Wed Nov 28 23:16:01 2012 > New Revision: 57780 > > URL: http://svn.reactos.org/svn/reactos?rev=57780&view=rev > Log: > [CPORTLIB/FREELDR] > GetByte --> Wait for data (with timeout) and get it if available. > PollByte --> Check for data, get it if available, and return immediately. > > Modified: > trunk/reactos/boot/freeldr/freeldr/comm/rs232.c > trunk/reactos/boot/freeldr/freeldr/windows/headless.c > trunk/reactos/include/reactos/libs/cportlib/cportlib.h > trunk/reactos/lib/cportlib/cport.c > > Modified: trunk/reactos/boot/freeldr/freeldr/comm/rs232.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/comm/… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/comm/rs232.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/comm/rs232.c [iso-8859-1] Wed Nov 28 23:16:01 2012 > @@ -100,7 +100,7 @@ > if (PortInitialized == FALSE) > return FALSE; > > - return (CpGetByte(&Rs232ComPort, ByteReceived, FALSE, FALSE) == CP_GET_SUCCESS); > + return (CpGetByte(&Rs232ComPort, ByteReceived, TRUE) == CP_GET_SUCCESS); > } > > /* > @@ -109,12 +109,7 @@ > if (PortInitialized == FALSE) > return FALSE; > > - while ((READ_PORT_UCHAR (SER_LSR(Rs232PortBase)) & SR_LSR_DR) == 0) > - ; > - > - *ByteReceived = READ_PORT_UCHAR (SER_RBR(Rs232PortBase)); > - > - return TRUE; > + return (CpGetByte(&Rs232ComPort, ByteReceived, FALSE) == CP_GET_SUCCESS); > } > */ > > > Modified: trunk/reactos/boot/freeldr/freeldr/windows/headless.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/windo… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/windows/headless.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/windows/headless.c [iso-8859-1] Wed Nov 28 23:16:01 2012 > @@ -143,7 +143,7 @@ > WinLdrPortGetByte(IN ULONG PortId, > OUT PUCHAR Data) > { > - return CpGetByte(&Port[PortId], Data, TRUE, FALSE) == CP_GET_SUCCESS; > + return CpGetByte(&Port[PortId], Data, TRUE) == CP_GET_SUCCESS; > } > > BOOLEAN > @@ -151,7 +151,7 @@ > { > UCHAR Dummy; > > - return CpGetByte(&Port[PortId], &Dummy, FALSE, TRUE) == CP_GET_SUCCESS; > + return CpGetByte(&Port[PortId], &Dummy, FALSE) == CP_GET_SUCCESS; > } > > VOID > > Modified: trunk/reactos/include/reactos/libs/cportlib/cportlib.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/libs/cport… > ============================================================================== > --- trunk/reactos/include/reactos/libs/cportlib/cportlib.h [iso-8859-1] (original) > +++ trunk/reactos/include/reactos/libs/cportlib/cportlib.h [iso-8859-1] Wed Nov 28 23:16:01 2012 > @@ -69,8 +69,7 @@ > CpGetByte( > IN PCPPORT Port, > OUT PUCHAR Byte, > - IN BOOLEAN Wait, > - IN BOOLEAN Poll > + IN BOOLEAN Wait > ); > > VOID > > Modified: trunk/reactos/lib/cportlib/cport.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/cportlib/cport.c?rev=5… > ============================================================================== > --- trunk/reactos/lib/cportlib/cport.c [iso-8859-1] (original) > +++ trunk/reactos/lib/cportlib/cport.c [iso-8859-1] Wed Nov 28 23:16:01 2012 > @@ -255,8 +255,7 @@ > NTAPI > CpGetByte(IN PCPPORT Port, > OUT PUCHAR Byte, > - IN BOOLEAN Wait, > - IN BOOLEAN Poll) > + IN BOOLEAN Wait) > { > UCHAR Lsr; > ULONG LimitCount = Wait ? TIMEOUT_COUNT : 1; > @@ -278,9 +277,6 @@ > return CP_GET_ERROR; > } > > - /* If only polling was requested by caller, return now */ > - if (Poll) return CP_GET_SUCCESS; > - > /* Otherwise read the byte and return it */ > *Byte = READ_PORT_UCHAR(Port->Address + RECEIVE_BUFFER_REGISTER); > > > >

2 1

November Status Meeting Tomorrow
by Aleksey Bragin 29 Nov '12

29 Nov '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 29th of November, 19:00 UTC. The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the channel #meeting, or as Pierre/Colin say. 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, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. If someone still is not getting passwords sent before a meeting - please email Colin or Pierre before the meeting started to get one. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). Hot topics would include progress made during this month, contracts updates, release plans (if any), web site progress (if any). With the best regards, Aleksey Bragin

4 4

Re: [ros-dev] [ros-general] Services downtime
by Colin Finck 16 Nov '12

16 Nov '12

Hi all, Pierre Schweitzer <pierre(a)reactos.org> wrote: > due to a hardware migration ongoing on one of our hypervisors, the > following services are currently down: The server upgrade went successfully and everything is back to normal now. Cheers, Colin

1 0

Server upgrade next Friday
by Colin Finck 15 Nov '12

15 Nov '12

Hi all, Several ReactOS services will be moved to a new server next Friday. As this migration highly depends on our hosting provider, the downtime may be up to 24 hours. Affected services include: - ns1.reactos.org - playground.reactos.org - jira.reactos.org The upgrade will improve reliability and adds resources for additional services in the future. Of course, you will be informed once the migration is over. Cheers, Colin

2 3

Re: [ros-dev] [ros-diffs] [hbelusca] 57701: [CSRSRV] - Use a variable ServerDll instead of using each time CsrLoadedServerDll[i], as it is done in some other places. - Clean the code (remove extra-parentheses). - Zero-out t...
by Alex Ionescu 15 Nov '12

15 Nov '12

Would you mind not "cleaning up formatting" by going against our coding style and doing the very thing I even taught you not to do during your initial patches/code reviews? Thanks. Best regards, Alex Ionescu On Tue, Nov 13, 2012 at 1:08 PM, <hbelusca(a)svn.reactos.org> wrote: > - if ((ServerDll) && (ServerDll->HardErrorCallback)) > + if (ServerDll && ServerDll->HardErrorCallback) >

4 5

Re: [ros-dev] [ros-diffs] [pschweitzer] 57674: [DOXYGEN] ReactOS is not C only. Enable support builtin STL.
by Timo Kreuzer 07 Nov '12

07 Nov '12

We have 90 % C. So disabling OPTIMIZE_OUTPUT_FOR_C will probably result in worse readable output for 90% of the code. Am 05.11.2012 12:14, schrieb pschweitzer(a)svn.reactos.org: > Author: pschweitzer > Date: Mon Nov 5 11:13:59 2012 > New Revision: 57674 > > URL: http://svn.reactos.org/svn/reactos?rev=57674&view=rev > Log: > [DOXYGEN] > ReactOS is not C only. > Enable support builtin STL. > > Modified: > trunk/reactos/Doxyfile > > Modified: trunk/reactos/Doxyfile > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/Doxyfile?rev=57674&r1=5767… > ============================================================================== > --- trunk/reactos/Doxyfile [iso-8859-1] (original) > +++ trunk/reactos/Doxyfile [iso-8859-1] Mon Nov 5 11:13:59 2012 > @@ -196,7 +196,7 @@ > # For instance, some of the names that are used will be different. The list > # of all members will be omitted, etc. > > -OPTIMIZE_OUTPUT_FOR_C = YES > +OPTIMIZE_OUTPUT_FOR_C = NO > > # Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java > # sources only. Doxygen will then generate output that is more tailored for > @@ -236,7 +236,7 @@ > # func(std::string) {}). This also make the inheritance and collaboration > # diagrams that involve STL classes more complete and accurate. > > -BUILTIN_STL_SUPPORT = NO > +BUILTIN_STL_SUPPORT = YES > > # If you use Microsoft's C++/CLI language, you should set this option to YES to > # enable parsing support. > > >

3 3

[ros-diffs] [jgardou] 57679: [USER32] - Avoid more rounding issues and hopefully fix MSC build
by James Tabor 06 Nov '12

06 Nov '12

Hi, BE AWARE this is port synced from wine and please notate changes so it will not get lost on the next sync! James

1 0

Meeting rescheduled!
by Aleksey Bragin 30 Oct '12

30 Oct '12

Hello, the meeting is rescheduled to 1st of November, as I don't see a point to do a meeting if zwabbit, caemyr and other can not attend. 1st of November will also be thursday, just one week late. Sorry for inconvenience. And it's time for agenda proposals already, please send them in to my email address as usual. Thanks. Best regards, Aleksey Bragin.

4 7

Re: [ros-dev] [ros-diffs] [hbelusca] 57526: [BOOTDATA-CMAKE] Add a bin\data directory for holding data files which can be used for tests.
by Hermès BÉLUSCA - MAÏTO 10 Oct '12

10 Oct '12

OK, I didn't know that ! I will revert this modification as soon as possible. Regards, Hermès BÉLUSCA - MAÏTO -----Message d'origine----- De : ros-dev-bounces(a)reactos.org [mailto:ros-dev-bounces@reactos.org] De la part de Sylvain Petreolle Envoyé : mercredi 10 octobre 2012 18:10 À : ReactOS Development List Objet : Re: [ros-dev] [ros-diffs] [hbelusca] 57526: [BOOTDATA-CMAKE] Add a bin\data directory for holding data files which can be used for tests. +1. You don't need to add the directory in PATH even if the helper is into bin\data. Kind regards, Sylvain Petreolle ----- Mail original ----- > De : Timo Kreuzer <timo.kreuzer(a)web.de> À : ros-dev(a)reactos.org Cc : > Envoyé le : Mercredi 10 octobre 2012 9h52 Objet : Re: [ros-dev] > [ros-diffs] [hbelusca] 57526: [BOOTDATA-CMAKE] Add a bin\data directory for holding data files which can be used for tests. > > > Why is it in the PATH variable? > Why not just put the test data in the bin folder? > > Am 10.10.2012 00:00, schrieb hbelusca(a)svn.reactos.org: >> Author: hbelusca >> Date: Tue Oct 9 22:00:47 2012 >> New Revision: 57526 >> >> URL: http://svn.reactos.org/svn/reactos?rev=57526&view=rev >> Log: >> [BOOTDATA-CMAKE] >> Add a bin\data directory for holding data files which can be used >> for > tests. >> >> Modified: >> trunk/reactos/boot/bootdata/hivesys_amd64.inf >> trunk/reactos/boot/bootdata/hivesys_arm.inf >> trunk/reactos/boot/bootdata/hivesys_i386.inf >> trunk/reactos/boot/bootdata/packages/reactos.dff.in >> trunk/reactos/cmake/CMakeMacros.cmake >> >> Modified: trunk/reactos/boot/bootdata/hivesys_amd64.inf >> URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys > _amd64.inf?rev=57526&r1=57525&r2=57526&view=diff >> > ====================================================================== > ======== >> --- trunk/reactos/boot/bootdata/hivesys_amd64.inf [iso-8859-1] >> (original) +++ trunk/reactos/boot/bootdata/hivesys_amd64.inf >> [iso-8859-1] Tue Oct 9 > 22:00:47 2012 >> @@ -1200,7 +1200,7 @@ >> ; System environment settings >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" >> -HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system 32;%SystemRoot%;%SystemRoot%\system32\wbem" >> +HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\da ta;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","windir",0x00020000,"%SystemRoot%" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" >> >> Modified: trunk/reactos/boot/bootdata/hivesys_arm.inf >> URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys > _arm.inf?rev=57526&r1=57525&r2=57526&view=diff >> > ====================================================================== > ======== >> --- trunk/reactos/boot/bootdata/hivesys_arm.inf [iso-8859-1] >> (original) +++ trunk/reactos/boot/bootdata/hivesys_arm.inf >> [iso-8859-1] Tue Oct 9 > 22:00:47 2012 >> @@ -755,7 +755,7 @@ >> ; System environment settings >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" >> -HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system 32;%SystemRoot%;%SystemRoot%\system32\wbem" >> +HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\da ta;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","windir",0x00020000,"%SystemRoot%" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" >> >> Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf >> URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys > _i386.inf?rev=57526&r1=57525&r2=57526&view=diff >> > ====================================================================== > ======== >> --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] >> (original) +++ trunk/reactos/boot/bootdata/hivesys_i386.inf >> [iso-8859-1] Tue Oct 9 > 22:00:47 2012 >> @@ -1200,7 +1200,7 @@ >> ; System environment settings >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" >> -HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system 32;%SystemRoot%;%SystemRoot%\system32\wbem" >> +HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\da ta;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","windir",0x00020000,"%SystemRoot%" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" >> HKLM,"SYSTEM\CurrentControlSet\Control\Session > Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" >> >> Modified: trunk/reactos/boot/bootdata/packages/reactos.dff.in >> URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/package > s/reactos.dff.in?rev=57526&r1=57525&r2=57526&view=diff >> > ====================================================================== > ======== >> --- trunk/reactos/boot/bootdata/packages/reactos.dff.in [iso-8859-1] > (original) >> +++ trunk/reactos/boot/bootdata/packages/reactos.dff.in [iso-8859-1] >> Tue > Oct 9 22:00:47 2012 >> @@ -21,12 +21,13 @@ >> 5 = system32\drivers\etc >> 6 = inf >> 7 = bin >> -8 = media >> -9 = Microsoft.NET >> -10 = Microsoft.NET\Framework >> -11 = Microsoft.NET\Framework\v1.0.3705 >> -12 = Microsoft.NET\Framework\v1.1.4322 >> -13 = Microsoft.NET\Framework\v2.0.50727 >> +8 = bin\data >> +9 = media >> +10 = Microsoft.NET >> +11 = Microsoft.NET\Framework >> +12 = Microsoft.NET\Framework\v1.0.3705 >> +13 = Microsoft.NET\Framework\v1.1.4322 >> +14 = Microsoft.NET\Framework\v2.0.50727 >> .InfEnd >> @@ -59,4 +60,4 @@ >> modules\optional\wine_gecko-1.0.0-x86.cab 4 optional >> boot\bootdata\bootcdregtest\AHKAppTests.cmd 7 > optional >> -modules\wallpaper\Angelus_02_ROSWP.bmp > 4 optional >> +modules\wallpaper\Angelus_02_ROSWP.bmp 4 optional >> >> Modified: trunk/reactos/cmake/CMakeMacros.cmake >> URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/CMakeMacros.cma > ke?rev=57526&r1=57525&r2=57526&view=diff >> > ====================================================================== > ======== >> --- trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] (original) >> +++ trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] Tue Oct 9 >> 22:00:47 > 2012 >> @@ -97,18 +97,20 @@ >> set(${var} 6) >> elseif(${dir} STREQUAL reactos/bin) >> set(${var} 7) >> + elseif(${dir} STREQUAL reactos/bin/data) + set(${var} >> 8) >> elseif(${dir} STREQUAL reactos/media) >> - set(${var} 8) >> + set(${var} 9) >> elseif(${dir} STREQUAL reactos/Microsoft.NET) >> - set(${var} 9) >> + set(${var} 10) >> elseif(${dir} STREQUAL reactos/Microsoft.NET/Framework) >> - set(${var} 10) >> + set(${var} 11) >> elseif(${dir} STREQUAL >> reactos/Microsoft.NET/Framework/v1.0.3705) >> - set(${var} 11) >> + set(${var} 12) >> elseif(${dir} STREQUAL >> reactos/Microsoft.NET/Framework/v1.1.4322) >> - set(${var} 12) >> + set(${var} 13) >> elseif(${dir} STREQUAL >> reactos/Microsoft.NET/Framework/v2.0.50727) >> - set(${var} 13) >> + set(${var} 14) >> else() >> message(ERROR "Wrong destination: ${dir}") >> endif() >> >> >> > > > _______________________________________________ > Ros-dev mailing list > Ros-dev(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-dev > _______________________________________________ Ros-dev mailing list Ros-dev(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-dev

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 57526: [BOOTDATA-CMAKE] Add a bin\data directory for holding data files which can be used for tests.
by Timo Kreuzer 10 Oct '12

10 Oct '12

Why is it in the PATH variable? Why not just put the test data in the bin folder? Am 10.10.2012 00:00, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Tue Oct 9 22:00:47 2012 > New Revision: 57526 > > URL: http://svn.reactos.org/svn/reactos?rev=57526&view=rev > Log: > [BOOTDATA-CMAKE] > Add a bin\data directory for holding data files which can be used for tests. > > Modified: > trunk/reactos/boot/bootdata/hivesys_amd64.inf > trunk/reactos/boot/bootdata/hivesys_arm.inf > trunk/reactos/boot/bootdata/hivesys_i386.inf > trunk/reactos/boot/bootdata/packages/reactos.dff.in > trunk/reactos/cmake/CMakeMacros.cmake > > Modified: trunk/reactos/boot/bootdata/hivesys_amd64.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_amd6… > ============================================================================== > --- trunk/reactos/boot/bootdata/hivesys_amd64.inf [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/hivesys_amd64.inf [iso-8859-1] Tue Oct 9 22:00:47 2012 > @@ -1200,7 +1200,7 @@ > > ; System environment settings > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" > -HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","windir",0x00020000,"%SystemRoot%" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" > > Modified: trunk/reactos/boot/bootdata/hivesys_arm.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_arm.… > ============================================================================== > --- trunk/reactos/boot/bootdata/hivesys_arm.inf [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/hivesys_arm.inf [iso-8859-1] Tue Oct 9 22:00:47 2012 > @@ -755,7 +755,7 @@ > > ; System environment settings > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" > -HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","windir",0x00020000,"%SystemRoot%" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" > > Modified: trunk/reactos/boot/bootdata/hivesys_i386.inf > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/hivesys_i386… > ============================================================================== > --- trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/hivesys_i386.inf [iso-8859-1] Tue Oct 9 22:00:47 2012 > @@ -1200,7 +1200,7 @@ > > ; System environment settings > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","ComSpec",0x00020000,"%SystemRoot%\system32\cmd.exe" > -HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > +HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","Path",0x00020000,"%SystemRoot%\bin;%SystemRoot%\bin\data;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\system32\wbem" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","windir",0x00020000,"%SystemRoot%" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TEMP",0x00020000,"%SystemDrive%\TEMP" > HKLM,"SYSTEM\CurrentControlSet\Control\Session Manager\Environment","TMP",0x00020000,"%SystemDrive%\TEMP" > > Modified: trunk/reactos/boot/bootdata/packages/reactos.dff.in > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/packages/rea… > ============================================================================== > --- trunk/reactos/boot/bootdata/packages/reactos.dff.in [iso-8859-1] (original) > +++ trunk/reactos/boot/bootdata/packages/reactos.dff.in [iso-8859-1] Tue Oct 9 22:00:47 2012 > @@ -21,12 +21,13 @@ > 5 = system32\drivers\etc > 6 = inf > 7 = bin > -8 = media > -9 = Microsoft.NET > -10 = Microsoft.NET\Framework > -11 = Microsoft.NET\Framework\v1.0.3705 > -12 = Microsoft.NET\Framework\v1.1.4322 > -13 = Microsoft.NET\Framework\v2.0.50727 > +8 = bin\data > +9 = media > +10 = Microsoft.NET > +11 = Microsoft.NET\Framework > +12 = Microsoft.NET\Framework\v1.0.3705 > +13 = Microsoft.NET\Framework\v1.1.4322 > +14 = Microsoft.NET\Framework\v2.0.50727 > > .InfEnd > > @@ -59,4 +60,4 @@ > modules\optional\wine_gecko-1.0.0-x86.cab 4 optional > boot\bootdata\bootcdregtest\AHKAppTests.cmd 7 optional > > -modules\wallpaper\Angelus_02_ROSWP.bmp 4 optional > +modules\wallpaper\Angelus_02_ROSWP.bmp 4 optional > > Modified: trunk/reactos/cmake/CMakeMacros.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/CMakeMacros.cmake?re… > ============================================================================== > --- trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/CMakeMacros.cmake [iso-8859-1] Tue Oct 9 22:00:47 2012 > @@ -97,18 +97,20 @@ > set(${var} 6) > elseif(${dir} STREQUAL reactos/bin) > set(${var} 7) > + elseif(${dir} STREQUAL reactos/bin/data) > + set(${var} 8) > elseif(${dir} STREQUAL reactos/media) > - set(${var} 8) > + set(${var} 9) > elseif(${dir} STREQUAL reactos/Microsoft.NET) > - set(${var} 9) > + set(${var} 10) > elseif(${dir} STREQUAL reactos/Microsoft.NET/Framework) > - set(${var} 10) > + set(${var} 11) > elseif(${dir} STREQUAL reactos/Microsoft.NET/Framework/v1.0.3705) > - set(${var} 11) > + set(${var} 12) > elseif(${dir} STREQUAL reactos/Microsoft.NET/Framework/v1.1.4322) > - set(${var} 12) > + set(${var} 13) > elseif(${dir} STREQUAL reactos/Microsoft.NET/Framework/v2.0.50727) > - set(${var} 13) > + set(${var} 14) > else() > message(ERROR "Wrong destination: ${dir}") > endif() > > >

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 57517: [LSASRV] Implement lookup of accounts in the account domain of the SAM database. The advapi32 security winetest shows proper domain and account names for the administrator and guest ...
by Alex Ionescu 08 Oct '12

08 Oct '12

Eric, with my rewrite, you can call RtlEqualPrefixSid instead of using LsapIsPrefixSid. The code should be the same Best regards, Alex Ionescu On Sun, Oct 7, 2012 at 7:33 PM, <ekohl(a)svn.reactos.org> wrote: > LsapIsPrefixSid

2 1

Re: [ros-dev] [ros-diffs] [ekohl] 57503: [LSASRV] - Make LsarLookupNames, LsarLookupNames2 and LsarLookupNames4 call LsapLookupNames and convert the results where this is needed. - Split the lookup code in LsapLookupSids in...
by Timo Kreuzer 08 Oct '12

08 Oct '12

Looks like this revision breaks advapi32:security test (crash) and iphlpapi:iphlpapi (cancelled) http://reactos.org/testman/compare.php?ids=13887,13888 Am 06.10.2012 21:37, schrieb ekohl(a)svn.reactos.org: > Author: ekohl > Date: Sat Oct 6 19:37:10 2012 > New Revision: 57503 > > URL:http://svn.reactos.org/svn/reactos?rev=57503&view=rev > Log: > [LSASRV] > - Make LsarLookupNames, LsarLookupNames2 and LsarLookupNames4 call LsapLookupNames and convert the results where this is needed. > - Split the lookup code in LsapLookupSids into separate functions. > > Modified: > trunk/reactos/dll/win32/lsasrv/lsarpc.c > trunk/reactos/dll/win32/lsasrv/lsasrv.h > trunk/reactos/dll/win32/lsasrv/sids.c > > Modified: trunk/reactos/dll/win32/lsasrv/lsarpc.c > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/lsarp… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/lsarpc.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/lsarpc.c [iso-8859-1] Sat Oct 6 19:37:10 2012 > @@ -550,89 +550,53 @@ > LSAP_LOOKUP_LEVEL LookupLevel, > DWORD *MappedCount) > { > - SID_IDENTIFIER_AUTHORITY IdentifierAuthority = {SECURITY_NT_AUTHORITY}; > - static const UNICODE_STRING DomainName = RTL_CONSTANT_STRING(L"DOMAIN"); > - PLSAPR_REFERENCED_DOMAIN_LIST OutputDomains = NULL; > - PLSA_TRANSLATED_SID OutputSids = NULL; > - ULONG OutputSidsLength; > + LSAPR_TRANSLATED_SIDS_EX2 TranslatedSidsEx2; > ULONG i; > - PSID Sid; > - ULONG SidLength; > NTSTATUS Status; > > - TRACE("LsarLookupNames(%p, %lu, %p, %p, %p, %d, %p)\n", > + TRACE("(%p %lu %p %p %p %d %p)\n", > PolicyHandle, Count, Names, ReferencedDomains, TranslatedSids, > LookupLevel, MappedCount); > > - TranslatedSids->Entries = Count; > + TranslatedSids->Entries = 0; > TranslatedSids->Sids = NULL; > *ReferencedDomains = NULL; > > - OutputSidsLength = Count * sizeof(LSA_TRANSLATED_SID); > - OutputSids = MIDL_user_allocate(OutputSidsLength); > - if (OutputSids == NULL) > - { > + if (Count == 0) > + return STATUS_NONE_MAPPED; > + > + TranslatedSidsEx2.Entries = 0; > + TranslatedSidsEx2.Sids = NULL; > + > + Status = LsapLookupNames(Count, > + Names, > + ReferencedDomains, > + &TranslatedSidsEx2, > + LookupLevel, > + MappedCount, > + 0, > + 0); > + if (!NT_SUCCESS(Status)) > + return Status; > + > + TranslatedSids->Entries = TranslatedSidsEx2.Entries; > + TranslatedSids->Sids = MIDL_user_allocate(TranslatedSids->Entries * sizeof(LSA_TRANSLATED_SID)); > + if (TranslatedSids->Sids == NULL) > + { > + MIDL_user_free(TranslatedSidsEx2.Sids); > + MIDL_user_free(*ReferencedDomains); > + *ReferencedDomains = NULL; > return STATUS_INSUFFICIENT_RESOURCES; > } > > - RtlZeroMemory(OutputSids, OutputSidsLength); > - > - OutputDomains = MIDL_user_allocate(sizeof(LSAPR_REFERENCED_DOMAIN_LIST)); > - if (OutputDomains == NULL) > - { > - MIDL_user_free(OutputSids); > - return STATUS_INSUFFICIENT_RESOURCES; > - } > - > - OutputDomains->Entries = Count; > - OutputDomains->Domains = MIDL_user_allocate(Count * sizeof(LSA_TRUST_INFORMATION)); > - if (OutputDomains->Domains == NULL) > - { > - MIDL_user_free(OutputDomains); > - MIDL_user_free(OutputSids); > - return STATUS_INSUFFICIENT_RESOURCES; > - } > - > - Status = RtlAllocateAndInitializeSid(&IdentifierAuthority, > - 2, > - SECURITY_BUILTIN_DOMAIN_RID, > - DOMAIN_ALIAS_RID_ADMINS, > - 0, 0, 0, 0, 0, 0, > - &Sid); > - if (!NT_SUCCESS(Status)) > - { > - MIDL_user_free(OutputDomains->Domains); > - MIDL_user_free(OutputDomains); > - MIDL_user_free(OutputSids); > - return Status; > - } > - > - SidLength = RtlLengthSid(Sid); > - > - for (i = 0; i < Count; i++) > - { > - OutputDomains->Domains[i].Sid = MIDL_user_allocate(SidLength); > - RtlCopyMemory(OutputDomains->Domains[i].Sid, Sid, SidLength); > - > - OutputDomains->Domains[i].Name.Buffer = MIDL_user_allocate(DomainName.MaximumLength); > - OutputDomains->Domains[i].Name.Length = DomainName.Length; > - OutputDomains->Domains[i].Name.MaximumLength = DomainName.MaximumLength; > - RtlCopyMemory(OutputDomains->Domains[i].Name.Buffer, DomainName.Buffer, DomainName.MaximumLength); > - } > - > - for (i = 0; i < Count; i++) > - { > - OutputSids[i].Use = SidTypeWellKnownGroup; > - OutputSids[i].RelativeId = DOMAIN_USER_RID_ADMIN; //DOMAIN_ALIAS_RID_ADMINS; > - OutputSids[i].DomainIndex = i; > - } > - > - *ReferencedDomains = OutputDomains; > - > - *MappedCount = Count; > - > - TranslatedSids->Entries = Count; > - TranslatedSids->Sids = OutputSids; > + for (i = 0; i < TranslatedSidsEx2.Entries; i++) > + { > + TranslatedSids->Sids[i].Use = TranslatedSidsEx2.Sids[i].Use; > + TranslatedSids->Sids[i].RelativeId = LsapGetRelativeIdFromSid(TranslatedSidsEx2.Sids[i].Sid); > + TranslatedSids->Sids[i].DomainIndex = TranslatedSidsEx2.Sids[i].DomainIndex; > + } > + > + MIDL_user_free(TranslatedSidsEx2.Sids); > > return STATUS_SUCCESS; > } > @@ -658,14 +622,11 @@ > /* FIXME: Fail, if there is an invalid SID in the SidEnumBuffer */ > > TranslatedNames->Entries = SidEnumBuffer->Entries; > - TranslatedNames->Names = MIDL_user_allocate(SidEnumBuffer->Entries * sizeof(LSAPR_TRANSLATED_NAME)); > - if (TranslatedNames->Names == NULL) > - return STATUS_INSUFFICIENT_RESOURCES; > - > + TranslatedNames->Names = NULL; > *ReferencedDomains = NULL; > > TranslatedNamesEx.Entries = SidEnumBuffer->Entries; > - TranslatedNamesEx.Names = NULL;; > + TranslatedNamesEx.Names = NULL; > > Status = LsapLookupSids(SidEnumBuffer, > ReferencedDomains, > @@ -675,9 +636,16 @@ > 0, > 0); > if (!NT_SUCCESS(Status)) > + return Status; > + > + TranslatedNames->Entries = SidEnumBuffer->Entries; > + TranslatedNames->Names = MIDL_user_allocate(SidEnumBuffer->Entries * sizeof(LSAPR_TRANSLATED_NAME)); > + if (TranslatedNames->Names == NULL) > { > MIDL_user_free(TranslatedNamesEx.Names); > - return Status; > + MIDL_user_free(*ReferencedDomains); > + *ReferencedDomains = NULL; > + return STATUS_INSUFFICIENT_RESOURCES; > } > > for (i = 0; i < TranslatedNamesEx.Entries; i++) > @@ -1977,8 +1945,56 @@ > DWORD LookupOptions, > DWORD ClientRevision) > { > - UNIMPLEMENTED; > - return STATUS_NOT_IMPLEMENTED; > + LSAPR_TRANSLATED_SIDS_EX2 TranslatedSidsEx2; > + ULONG i; > + NTSTATUS Status; > + > + TRACE("(%p %lu %p %p %p %d %p %lu %lu)\n", > + PolicyHandle, Count, Names, ReferencedDomains, TranslatedSids, > + LookupLevel, MappedCount, LookupOptions, ClientRevision); > + > + TranslatedSids->Entries = 0; > + TranslatedSids->Sids = NULL; > + *ReferencedDomains = NULL; > + > + if (Count == 0) > + return STATUS_NONE_MAPPED; > + > + TranslatedSidsEx2.Entries = 0; > + TranslatedSidsEx2.Sids = NULL; > + > + Status = LsapLookupNames(Count, > + Names, > + ReferencedDomains, > + &TranslatedSidsEx2, > + LookupLevel, > + MappedCount, > + LookupOptions, > + ClientRevision); > + if (!NT_SUCCESS(Status)) > + return Status; > + > + TranslatedSids->Entries = TranslatedSidsEx2.Entries; > + TranslatedSids->Sids = MIDL_user_allocate(TranslatedSids->Entries * sizeof(LSA_TRANSLATED_SID)); > + if (TranslatedSids->Sids == NULL) > + { > + MIDL_user_free(TranslatedSidsEx2.Sids); > + MIDL_user_free(*ReferencedDomains); > + *ReferencedDomains = NULL; > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + for (i = 0; i < TranslatedSidsEx2.Entries; i++) > + { > + TranslatedSids->Sids[i].Use = TranslatedSidsEx2.Sids[i].Use; > + TranslatedSids->Sids[i].RelativeId = LsapGetRelativeIdFromSid(TranslatedSidsEx2.Sids[i].Sid); > + TranslatedSids->Sids[i].DomainIndex = TranslatedSidsEx2.Sids[i].DomainIndex; > + TranslatedSids->Sids[i].Flags = TranslatedSidsEx2.Sids[i].Flags; > + } > + > + MIDL_user_free(TranslatedSidsEx2.Sids); > + > + return STATUS_SUCCESS; > } > > > @@ -2081,7 +2097,7 @@ > { > NTSTATUS Status; > > - TRACE("LsarLookupNames3(%p, %lu, %p, %p, %p, %d, %p, %lu, %lu)\n", > + TRACE("(%p %lu %p %p %p %d %p %lu %lu)\n", > PolicyHandle, Count, Names, ReferencedDomains, TranslatedSids, > LookupLevel, MappedCount, LookupOptions, ClientRevision); > > @@ -2223,8 +2239,29 @@ > DWORD LookupOptions, > DWORD ClientRevision) > { > - UNIMPLEMENTED; > - return STATUS_NOT_IMPLEMENTED; > + NTSTATUS Status; > + > + TRACE("(%p %lu %p %p %p %d %p %lu %lu)\n", > + RpcHandle, Count, Names, ReferencedDomains, TranslatedSids, > + LookupLevel, MappedCount, LookupOptions, ClientRevision); > + > + TranslatedSids->Entries = 0; > + TranslatedSids->Sids = NULL; > + *ReferencedDomains = NULL; > + > + if (Count == 0) > + return STATUS_NONE_MAPPED; > + > + Status = LsapLookupNames(Count, > + Names, > + ReferencedDomains, > + TranslatedSids, > + LookupLevel, > + MappedCount, > + LookupOptions, > + ClientRevision); > + > + return Status; > } > > > > Modified: trunk/reactos/dll/win32/lsasrv/lsasrv.h > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/lsasr… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/lsasrv.h [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/lsasrv.h [iso-8859-1] Sat Oct 6 19:37:10 2012 > @@ -192,6 +192,9 @@ > NTSTATUS > LsapInitSids(VOID); > > +ULONG > +LsapGetRelativeIdFromSid(PSID Sid); > + > NTSTATUS > LsapLookupNames(DWORD Count, > PRPC_UNICODE_STRING Names, > > Modified: trunk/reactos/dll/win32/lsasrv/sids.c > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/lsasrv/sids.… > ============================================================================== > --- trunk/reactos/dll/win32/lsasrv/sids.c [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/lsasrv/sids.c [iso-8859-1] Sat Oct 6 19:37:10 2012 > @@ -808,6 +808,18 @@ > } > > > +ULONG > +LsapGetRelativeIdFromSid(PSID Sid_) > +{ > + PISID Sid = Sid_; > + > + if (Sid->SubAuthorityCount != 0) > + return Sid->SubAuthority[Sid->SubAuthorityCount - 1]; > + > + return 0; > +} > + > + > NTSTATUS > LsapLookupNames(DWORD Count, > PRPC_UNICODE_STRING Names, > @@ -824,10 +836,6 @@ > PRPC_UNICODE_STRING AccountNames = NULL; > ULONG SidsBufferLength; > ULONG DomainIndex; > -// ULONG DomainSidLength; > -// ULONG AccountSidLength; > -// PSID DomainSid; > -// PSID AccountSid; > ULONG i; > ULONG Mapped = 0; > NTSTATUS Status = STATUS_SUCCESS; > @@ -1006,84 +1014,29 @@ > } > > > -NTSTATUS > -LsapLookupSids(PLSAPR_SID_ENUM_BUFFER SidEnumBuffer, > - PLSAPR_REFERENCED_DOMAIN_LIST *ReferencedDomains, > - PLSAPR_TRANSLATED_NAMES_EX TranslatedNames, > - LSAP_LOOKUP_LEVEL LookupLevel, > - DWORD *MappedCount, > - DWORD LookupOptions, > - DWORD ClientRevision) > -{ > - PLSAPR_REFERENCED_DOMAIN_LIST DomainsBuffer = NULL; > - PLSAPR_TRANSLATED_NAME_EX NamesBuffer = NULL; > - ULONG NamesBufferLength; > +static NTSTATUS > +LsapLookupWellKnownSids(PLSAPR_SID_ENUM_BUFFER SidEnumBuffer, > + PLSAPR_TRANSLATED_NAME_EX NamesBuffer, > + PLSAPR_REFERENCED_DOMAIN_LIST DomainsBuffer, > + PULONG Mapped) > +{ > + PWELL_KNOWN_SID ptr, ptr2; > + LPWSTR SidString = NULL; > ULONG DomainIndex; > ULONG i; > - ULONG Mapped = 0; > NTSTATUS Status = STATUS_SUCCESS; > > - PWELL_KNOWN_SID ptr, ptr2; > - > - SID_IDENTIFIER_AUTHORITY IdentifierAuthority = {SECURITY_NT_AUTHORITY}; > - static const UNICODE_STRING DomainName = RTL_CONSTANT_STRING(L"DOMAIN"); > - static const UNICODE_STRING AdminName = RTL_CONSTANT_STRING(L"Administrator"); > - PSID AdminsSid = NULL; > - ULONG SidLength; > - > - > - NamesBufferLength = SidEnumBuffer->Entries * sizeof(LSAPR_TRANSLATED_NAME_EX); > - NamesBuffer = MIDL_user_allocate(NamesBufferLength); > - if (NamesBuffer == NULL) > - { > - Status = STATUS_INSUFFICIENT_RESOURCES; > - goto done; > - } > - > - DomainsBuffer = MIDL_user_allocate(sizeof(LSAPR_REFERENCED_DOMAIN_LIST)); > - if (DomainsBuffer == NULL) > - { > - Status = STATUS_INSUFFICIENT_RESOURCES; > - goto done; > - } > - > - DomainsBuffer->Domains = MIDL_user_allocate(SidEnumBuffer->Entries * sizeof(LSA_TRUST_INFORMATION)); > - if (DomainsBuffer->Domains == NULL) > - { > - Status = STATUS_INSUFFICIENT_RESOURCES; > - goto done; > - } > - > - DomainsBuffer->Entries = 0; > - DomainsBuffer->MaxEntries = SidEnumBuffer->Entries; > - > - /* Initialize all name entries */ > for (i = 0; i < SidEnumBuffer->Entries; i++) > { > - NamesBuffer[i].Use = SidTypeUnknown; > - NamesBuffer[i].Name.Length = 0; > - NamesBuffer[i].Name.MaximumLength = 0; > - NamesBuffer[i].Name.Buffer = NULL; > - NamesBuffer[i].DomainIndex = -1; > - NamesBuffer[i].Flags = 0; > - } > - > - > - Status = RtlAllocateAndInitializeSid(&IdentifierAuthority, > - 2, > - SECURITY_BUILTIN_DOMAIN_RID, > - DOMAIN_ALIAS_RID_ADMINS, > - 0, 0, 0, 0, 0, 0, > - &AdminsSid); > - if (!NT_SUCCESS(Status)) > - goto done; > - > - > - SidLength = RtlLengthSid(AdminsSid); > - > - > - for (i = 0; i < SidEnumBuffer->Entries; i++) > - { > + /* Ignore SIDs which are already mapped */ > + if (NamesBuffer[i].Use != SidTypeUnknown) > + continue; > + > + ConvertSidToStringSidW(SidEnumBuffer->SidInfo[i].Sid, &SidString); > + TRACE("Unmapped SID: %S\n", SidString); > + LocalFree(SidString); > + SidString = NULL; > + > ptr = LsapLookupWellKnownSid(SidEnumBuffer->SidInfo[i].Sid); > if (ptr != NULL) > { > @@ -1106,13 +1059,83 @@ > NamesBuffer[i].DomainIndex = DomainIndex; > } > > - Mapped++; > + TRACE("Mapped to: %wZ\n", &NamesBuffer[i].Name); > + > + (*Mapped)++; > + } > + } > + > + return Status; > +} > + > + > +static NTSTATUS > +LsapLookupLocalDomainSids(PLSAPR_SID_ENUM_BUFFER SidEnumBuffer, > + PLSAPR_TRANSLATED_NAME_EX NamesBuffer, > + PLSAPR_REFERENCED_DOMAIN_LIST DomainsBuffer, > + PULONG Mapped) > +{ > + LPWSTR SidString = NULL; > + ULONG i; > + > + for (i = 0; i < SidEnumBuffer->Entries; i++) > + { > + /* Ignore SIDs which are already mapped */ > + if (NamesBuffer[i].Use != SidTypeUnknown) > continue; > - } > + > + ConvertSidToStringSidW(SidEnumBuffer->SidInfo[i].Sid, &SidString); > + TRACE("Unmapped SID: %S\n", SidString); > + LocalFree(SidString); > + SidString = NULL; > + } > + > + return STATUS_SUCCESS; > +} > + > + > +static NTSTATUS > +LsapLookupUnknownSids(PLSAPR_SID_ENUM_BUFFER SidEnumBuffer, > + PLSAPR_TRANSLATED_NAME_EX NamesBuffer, > + PLSAPR_REFERENCED_DOMAIN_LIST DomainsBuffer, > + PULONG Mapped) > +{ > + SID_IDENTIFIER_AUTHORITY IdentifierAuthority = {SECURITY_NT_AUTHORITY}; > + static const UNICODE_STRING DomainName = RTL_CONSTANT_STRING(L"DOMAIN"); > + static const UNICODE_STRING AdminName = RTL_CONSTANT_STRING(L"Administrator"); > + PSID AdminsSid = NULL; > + LPWSTR SidString = NULL; > + ULONG SidLength; > + ULONG DomainIndex; > + ULONG i; > + NTSTATUS Status; > + > + Status = RtlAllocateAndInitializeSid(&IdentifierAuthority, > + 2, > + SECURITY_BUILTIN_DOMAIN_RID, > + DOMAIN_ALIAS_RID_ADMINS, > + 0, 0, 0, 0, 0, 0, > + &AdminsSid); > + if (!NT_SUCCESS(Status)) > + goto done; > + > + SidLength = RtlLengthSid(AdminsSid); > + > + for (i = 0; i < SidEnumBuffer->Entries; i++) > + { > + /* Ignore SIDs which are already mapped */ > + if (NamesBuffer[i].Use != SidTypeUnknown) > + continue; > + > + > + ConvertSidToStringSidW(SidEnumBuffer->SidInfo[i].Sid, &SidString); > + TRACE("Unmapped SID: %S\n", SidString); > + LocalFree(SidString); > + SidString = NULL; > > > /* Hack: Map the SID to the Admin Account if it is not a well-known SID */ > - NamesBuffer[i].Use = SidTypeWellKnownGroup; > + NamesBuffer[i].Use = SidTypeUser; > NamesBuffer[i].Flags = 0; > NamesBuffer[i].Name.Length = AdminName.Length; > NamesBuffer[i].Name.MaximumLength = AdminName.MaximumLength; > @@ -1126,16 +1149,103 @@ > if (NT_SUCCESS(Status)) > NamesBuffer[i].DomainIndex = DomainIndex; > > - Mapped++; > - continue; > - > - > + TRACE("Mapped to: %wZ\n", &NamesBuffer[i].Name); > + > + (*Mapped)++; > } > > done: > if (AdminsSid != NULL) > RtlFreeSid(AdminsSid); > > + return Status; > +} > + > + > +NTSTATUS > +LsapLookupSids(PLSAPR_SID_ENUM_BUFFER SidEnumBuffer, > + PLSAPR_REFERENCED_DOMAIN_LIST *ReferencedDomains, > + PLSAPR_TRANSLATED_NAMES_EX TranslatedNames, > + LSAP_LOOKUP_LEVEL LookupLevel, > + DWORD *MappedCount, > + DWORD LookupOptions, > + DWORD ClientRevision) > +{ > + PLSAPR_REFERENCED_DOMAIN_LIST DomainsBuffer = NULL; > + PLSAPR_TRANSLATED_NAME_EX NamesBuffer = NULL; > + ULONG NamesBufferLength; > + ULONG i; > + ULONG Mapped = 0; > + NTSTATUS Status = STATUS_SUCCESS; > + > + NamesBufferLength = SidEnumBuffer->Entries * sizeof(LSAPR_TRANSLATED_NAME_EX); > + NamesBuffer = MIDL_user_allocate(NamesBufferLength); > + if (NamesBuffer == NULL) > + { > + Status = STATUS_INSUFFICIENT_RESOURCES; > + goto done; > + } > + > + DomainsBuffer = MIDL_user_allocate(sizeof(LSAPR_REFERENCED_DOMAIN_LIST)); > + if (DomainsBuffer == NULL) > + { > + Status = STATUS_INSUFFICIENT_RESOURCES; > + goto done; > + } > + > + DomainsBuffer->Domains = MIDL_user_allocate(SidEnumBuffer->Entries * sizeof(LSA_TRUST_INFORMATION)); > + if (DomainsBuffer->Domains == NULL) > + { > + Status = STATUS_INSUFFICIENT_RESOURCES; > + goto done; > + } > + > + DomainsBuffer->Entries = 0; > + DomainsBuffer->MaxEntries = SidEnumBuffer->Entries; > + > + /* Initialize all name entries */ > + for (i = 0; i < SidEnumBuffer->Entries; i++) > + { > + NamesBuffer[i].Use = SidTypeUnknown; > + NamesBuffer[i].Name.Length = 0; > + NamesBuffer[i].Name.MaximumLength = 0; > + NamesBuffer[i].Name.Buffer = NULL; > + NamesBuffer[i].DomainIndex = -1; > + NamesBuffer[i].Flags = 0; > + } > + > + /* Look-up all well-known SIDs */ > + Status = LsapLookupWellKnownSids(SidEnumBuffer, > + NamesBuffer, > + DomainsBuffer, > + &Mapped); > + if (!NT_SUCCESS(Status)) > + goto done; > + > + if (Mapped == SidEnumBuffer->Entries) > + goto done; > + > + /* Look-up all Domain SIDs */ > + Status = LsapLookupLocalDomainSids(SidEnumBuffer, > + NamesBuffer, > + DomainsBuffer, > + &Mapped); > + if (!NT_SUCCESS(Status)) > + goto done; > + > + if (Mapped == SidEnumBuffer->Entries) > + goto done; > + > + /* Map unknown SIDs */ > + Status = LsapLookupUnknownSids(SidEnumBuffer, > + NamesBuffer, > + DomainsBuffer, > + &Mapped); > + if (!NT_SUCCESS(Status)) > + goto done; > + > +done: > + TRACE("done Status: %lx Mapped: %lu\n", Status, Mapped); > > if (!NT_SUCCESS(Status)) > { > > >

2 1

Re: [ros-dev] [ros-diffs] [hbelusca] 57504: [NTOSKRNL] Rearrange the NtQuerySystemEnvironmentValue code to have successive logical checks.
by Timo Kreuzer 07 Oct '12

07 Oct '12

This changes the logic. I'm not sure how exact the previous version was, but these changes should be tested. Am 06.10.2012 21:50, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Sat Oct 6 19:50:17 2012 > New Revision: 57504 > > URL: http://svn.reactos.org/svn/reactos?rev=57504&view=rev > Log: > [NTOSKRNL] > Rearrange the NtQuerySystemEnvironmentValue code to have successive logical checks. > > Modified: > trunk/reactos/ntoskrnl/ex/sysinfo.c > > Modified: trunk/reactos/ntoskrnl/ex/sysinfo.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ex/sysinfo.c?rev=… > ============================================================================== > --- trunk/reactos/ntoskrnl/ex/sysinfo.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/ex/sysinfo.c [iso-8859-1] Sat Oct 6 19:50:17 2012 > @@ -235,44 +235,40 @@ > _SEH2_YIELD(return _SEH2_GetExceptionCode()); > } > _SEH2_END; > - > - } > - > - /* Allocate a buffer for the value */ > - AnsiValueBuffer = ExAllocatePoolWithTag(NonPagedPool, ValueBufferLength, 'pmeT'); > - if (AnsiValueBuffer == NULL) > - { > - return STATUS_INSUFFICIENT_RESOURCES; > - } > - > - /* > - * Copy the name to kernel space if necessary and convert it to ANSI. > - */ > + } > + > + /* According to NTInternals the SeSystemEnvironmentName privilege is required! */ > + if (!SeSinglePrivilegeCheck(SeSystemEnvironmentPrivilege, PreviousMode)) > + { > + DPRINT1("NtQuerySystemEnvironmentValue: Caller requires the SeSystemEnvironmentPrivilege privilege!\n"); > + return STATUS_PRIVILEGE_NOT_HELD; > + } > + > + /* Copy the name to kernel space if necessary */ > Status = ProbeAndCaptureUnicodeString(&WName, PreviousMode, VariableName); > if (!NT_SUCCESS(Status)) > { > return Status; > } > > - /* > - * according to ntinternals the SeSystemEnvironmentName privilege is required! > - */ > - if (!SeSinglePrivilegeCheck(SeSystemEnvironmentPrivilege, PreviousMode)) > - { > - ReleaseCapturedUnicodeString(&WName, PreviousMode); > - DPRINT1("NtQuerySystemEnvironmentValue: Caller requires the SeSystemEnvironmentPrivilege privilege!\n"); > - return STATUS_PRIVILEGE_NOT_HELD; > - } > - > - /* Convert the value name to ansi and release the captured unicode string */ > + /* Convert the name to ANSI and release the captured UNICODE string */ > Status = RtlUnicodeStringToAnsiString(&AName, &WName, TRUE); > ReleaseCapturedUnicodeString(&WName, PreviousMode); > if (!NT_SUCCESS(Status)) return Status; > > - /* Get the environment variable */ > + /* Allocate a buffer for the ANSI environment variable */ > + AnsiValueBuffer = ExAllocatePoolWithTag(NonPagedPool, ValueBufferLength, 'pmeT'); > + if (AnsiValueBuffer == NULL) > + { > + RtlFreeAnsiString(&AName); > + return STATUS_INSUFFICIENT_RESOURCES; > + } > + > + /* Get the environment variable and free the ANSI name */ > Result = HalGetEnvironmentVariable(AName.Buffer, > (USHORT)ValueBufferLength, > AnsiValueBuffer); > + RtlFreeAnsiString(&AName); > > /* Check if we had success */ > if (Result == ESUCCESS) > @@ -280,13 +276,13 @@ > /* Copy the result back to the caller. */ > _SEH2_TRY > { > - /* Initialize ansi string from the result */ > + /* Initialize ANSI string from the result */ > RtlInitAnsiString(&AValue, AnsiValueBuffer); > > - /* Initialize a unicode string from the callers buffer */ > + /* Initialize a UNICODE string from the callers buffer */ > RtlInitEmptyUnicodeString(&WValue, ValueBuffer, ValueBufferLength); > > - /* Convert the result to unicode */ > + /* Convert the result to UNICODE */ > Status = RtlAnsiStringToUnicodeString(&WValue, &AValue, FALSE); > > if (ReturnLength != NULL) > @@ -305,8 +301,7 @@ > Status = STATUS_UNSUCCESSFUL; > } > > - /* Cleanup allocated resources. */ > - RtlFreeAnsiString(&AName); > + /* Free the allocated ANSI value buffer */ > ExFreePoolWithTag(AnsiValueBuffer, 'pmeT'); > > return Status; > > >

2 2

Re: [ros-dev] [ros-diffs] [tfaber] 57485: [SHELL32] - Fix what might finally be the last missing "this->" instances left over from the C++ conversion (used a regex this time)
by Timo Kreuzer 05 Oct '12

05 Oct '12

Shouldn't member variables rather be prefixed with m_? Am 05.10.2012 01:46, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Thu Oct 4 23:46:59 2012 > New Revision: 57485 > > URL: http://svn.reactos.org/svn/reactos?rev=57485&view=rev > Log: > [SHELL32] > - Fix what might finally be the last missing "this->" instances left over from the C++ conversion (used a regex this time) > > Modified: > trunk/reactos/dll/win32/shell32/folders/cpanel.cpp > trunk/reactos/dll/win32/shell32/folders/mycomp.cpp > trunk/reactos/dll/win32/shell32/shlview.cpp > > Modified: trunk/reactos/dll/win32/shell32/folders/cpanel.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/… > ============================================================================== > --- trunk/reactos/dll/win32/shell32/folders/cpanel.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/folders/cpanel.cpp [iso-8859-1] Thu Oct 4 23:46:59 2012 > @@ -540,7 +540,7 @@ > // > pObj = (IContextMenu *)this; > this->apidl = apidl; > - cidl = cidl; > + this->cidl = cidl; > pObj->AddRef(); > hr = S_OK; > } else if (IsEqualIID(riid, IID_IDataObject) && (cidl >= 1)) { > > Modified: trunk/reactos/dll/win32/shell32/folders/mycomp.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/folders/… > ============================================================================== > --- trunk/reactos/dll/win32/shell32/folders/mycomp.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/folders/mycomp.cpp [iso-8859-1] Thu Oct 4 23:46:59 2012 > @@ -728,7 +728,7 @@ > > wcscpy(sName, lpName); > SHFree(sName); > - sName = sName; > + this->sName = sName; > TRACE("result %s\n", debugstr_w(sName)); > return S_OK; > } > > Modified: trunk/reactos/dll/win32/shell32/shlview.cpp > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/shell32/shlview.… > ============================================================================== > --- trunk/reactos/dll/win32/shell32/shlview.cpp [iso-8859-1] (original) > +++ trunk/reactos/dll/win32/shell32/shlview.cpp [iso-8859-1] Thu Oct 4 23:46:59 2012 > @@ -2828,7 +2828,7 @@ > FIXME("partial stub: %p %08x %08x %p\n", this, aspects, advf, pAdvSink); > > /* FIXME: we set the AdviseSink, but never use it to send any advice */ > - pAdvSink = pAdvSink; > + this->pAdvSink = pAdvSink; > dwAspects = aspects; > dwAdvf = advf; > > > >

4 3

Re: [ros-dev] [ros-diffs] [hbelusca] 57462: [REGEDIT] - WCHAR ==> TCHAR in (before a REALLY conversion of regedit into UNICODE) - Correct some mistakes in displayed strings - Improve informative / warning / error messages w...
by Timo Kreuzer 03 Oct '12

03 Oct '12

Please don't use TCHAR. Make everything WCHAR and use widechar functions explicitly. Am 03.10.2012 01:29, schrieb hbelusca(a)svn.reactos.org: > Author: hbelusca > Date: Tue Oct 2 23:29:22 2012 > New Revision: 57462 > > URL: http://svn.reactos.org/svn/reactos?rev=57462&view=rev > Log: > [REGEDIT] > - WCHAR ==> TCHAR in (before a REALLY conversion of regedit into UNICODE) > - Correct some mistakes in displayed strings > - Improve informative / warning / error messages when importing registry files > - Now, try to import each registry file specified in the command line and don't fail miserably when one of them is missing, but continue with the next one (as Windows' regedit does). > Patch by Edijs Kolesnikovičs (2/2) adapted by me. > > CORE-6239 #comment Fixed in r57462 with some adaptations. Thanks ;) #resolve > > Modified: > trunk/reactos/base/applications/regedit/regedit.c > > Modified: trunk/reactos/base/applications/regedit/regedit.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/applications/regedit/… > ============================================================================== > --- trunk/reactos/base/applications/regedit/regedit.c [iso-8859-1] (original) > +++ trunk/reactos/base/applications/regedit/regedit.c [iso-8859-1] Tue Oct 2 23:29:22 2012 > @@ -23,30 +23,31 @@ > > static const char *usage = > "Usage:\n" > - " regedit filename\n" > + " regedit filenames\n" > " regedit /E filename [regpath]\n" > " regedit /D regpath\n" > "\n" > - "filename - registry file name\n" > - "regpath - name of the registry key\n" > + "filenames - List of registry files names\n" > + "filename - Registry file name\n" > + "regpath - Name of the registry key\n" > "\n" > "When is called without any switches adds contents of the specified\n" > - "registry file to the registry\n" > + "registry files to the registry.\n" > "\n" > "Switches:\n" > - " /E - exports contents of the specified registry key to the specified\n" > - " file. Exports the whole registry if no key is specified.\n" > - " /D - deletes specified registry key\n" > - " /S - silent execution, can be used with any other switch.\n" > - " The only existing mode, exists for compatibility with Windows regedit.\n" > - " /V - advanced mode, can be used with any other switch.\n" > - " Ignored, exists for compatibility with Windows regedit.\n" > - " /L - location of system.dat file. Can be used with any other switch.\n" > - " Ignored. Exists for compatibility with Windows regedit.\n" > - " /R - location of user.dat file. Can be used with any other switch.\n" > - " Ignored. Exists for compatibility with Windows regedit.\n" > - " /? - print this help. Any other switches are ignored.\n" > - " /C - create registry from. Not implemented.\n" > + " /E - Exports contents of the specified registry key to the specified\n" > + " file. Exports the whole registry if no key is specified.\n" > + " /D - Deletes specified registry key\n" > + " /S - Silent execution, can be used with any other switch.\n" > + " The only existing mode, exists for compatibility with Windows regedit.\n" > + " /V - Advanced mode, can be used with any other switch.\n" > + " Ignored, exists for compatibility with Windows regedit.\n" > + " /L - Location of system.dat file. Can be used with any other switch.\n" > + " Ignored. Exists for compatibility with Windows regedit.\n" > + " /R - Location of user.dat file. Can be used with any other switch.\n" > + " Ignored. Exists for compatibility with Windows regedit.\n" > + " /? - Print this help. Any other switches are ignored.\n" > + " /C - Create registry from. Not implemented.\n" > "\n" > "The switches are case-insensitive, can be prefixed either by '-' or '/'.\n" > "This program is command-line compatible with Microsoft Windows\n" > @@ -74,10 +75,10 @@ > * where *s[0] is the first symbol of the file name. > * file_name - buffer to write the file name to. > */ > -void get_file_name(LPWSTR *command_line, LPWSTR file_name) > -{ > - WCHAR *s = *command_line; > - int pos = 0; /* position of pointer "s" in *command_line */ > +void get_file_name(LPTSTR *command_line, LPTSTR file_name) > +{ > + TCHAR *s = *command_line; > + int pos = 0; /* position of pointer "s" in *command_line */ > file_name[0] = 0; > > if (!s[0]) > @@ -85,11 +86,11 @@ > return; > } > > - if (s[0] == L'"') > + if (s[0] == _T('"')) > { > s++; > (*command_line)++; > - while(s[0] != L'"') > + while(s[0] != _T('"')) > { > if (!s[0]) > { > @@ -102,7 +103,7 @@ > } > else > { > - while(s[0] && !iswspace(s[0])) > + while(s[0] && !_istspace(s[0])) > { > s++; > pos++; > @@ -110,13 +111,13 @@ > } > memcpy(file_name, *command_line, pos * sizeof(WCHAR)); > /* remove the last backslash */ > - if (file_name[pos - 1] == L'\\') > - { > - file_name[pos - 1] = L'\0'; > + if (file_name[pos - 1] == _T('\\')) > + { > + file_name[pos - 1] = _T('\0'); > } > else > { > - file_name[pos] = L'\0'; > + file_name[pos] = _T('\0'); > } > > if (s[0]) > @@ -124,7 +125,7 @@ > s++; > pos++; > } > - while(s[0] && iswspace(s[0])) > + while(s[0] && _istspace(s[0])) > { > s++; > pos++; > @@ -132,88 +133,116 @@ > (*command_line) += pos; > } > > -BOOL PerformRegAction(REGEDIT_ACTION action, LPWSTR s, BOOL silent) > -{ > - TCHAR szTitle[256], szText[256]; > +BOOL PerformRegAction(REGEDIT_ACTION action, LPTSTR s, BOOL silent) > +{ > switch (action) > { > - case ACTION_ADD: > - { > - WCHAR filename[MAX_PATH]; > - FILE *fp; > - > - get_file_name(&s, filename); > - if (!filename[0]) > - { > - fprintf(stderr, "%s: No file name is specified\n", getAppName()); > - fprintf(stderr, usage); > - exit(4); > - } > - > - while(filename[0]) > - { > - fp = _wfopen(filename, L"r"); > - if (fp == NULL) > - { > - LPSTR p = GetMultiByteString(filename); > - perror(""); > - fprintf(stderr, "%s: Can't open file \"%s\"\n", getAppName(), p); > - HeapFree(GetProcessHeap(), 0, p); > - exit(5); > - } > - import_registry_file(fp); > + case ACTION_ADD: > + { > + TCHAR szTitle[512], szText[512]; > + TCHAR filename[MAX_PATH]; > + FILE *fp; > + > get_file_name(&s, filename); > + if (!filename[0]) > + { > + fprintf(stderr, "%s: No file name is specified\n", getAppName()); > + fprintf(stderr, usage); > + exit(4); > + } > + > LoadString(hInst, IDS_APP_TITLE, szTitle, COUNT_OF(szTitle)); > - LoadString(hInst, IDS_IMPORT_OK, szText, COUNT_OF(szText)); > - /* show successful import */ > - if (!silent) > - MessageBox(NULL, szText, szTitle, MB_OK); > - } > - break; > - } > - case ACTION_DELETE: > - { > - WCHAR reg_key_name[KEY_MAX_LEN]; > - get_file_name(&s, reg_key_name); > - if (!reg_key_name[0]) > - { > - fprintf(stderr, "%s: No registry key is specified for removal\n", getAppName()); > - fprintf(stderr, usage); > - exit(6); > - } > - delete_registry_key(reg_key_name); > - break; > - } > - case ACTION_EXPORT: > - { > - WCHAR filename[MAX_PATH]; > - > - filename[0] = _T('\0'); > - get_file_name(&s, filename); > - if (!filename[0]) > - { > - fprintf(stderr, "%s: No file name is specified\n", getAppName()); > - fprintf(stderr, usage); > - exit(7); > - } > - > - if (s[0]) > - { > - WCHAR reg_key_name[KEY_MAX_LEN]; > + > + while (filename[0]) > + { > + /* Request import confirmation */ > + if (!silent) > + { > + LoadString(hInst, IDS_IMPORT_PROMPT, szText, COUNT_OF(szText)); > + > + if (InfoMessageBox(NULL, MB_YESNO | MB_ICONWARNING, szTitle, szText, filename) != IDYES) > + goto cont; > + } > + > + fp = _tfopen(filename, _T("r")); > + if (fp != NULL) > + { > + import_registry_file(fp); > + > + /* Show successful import */ > + if (!silent) > + { > + LoadString(hInst, IDS_IMPORT_OK, szText, COUNT_OF(szText)); > + InfoMessageBox(NULL, MB_OK | MB_ICONINFORMATION, szTitle, szText, filename); > + } > + } > + else > + { > + LPSTR p = GetMultiByteString(filename); > + perror(""); > + fprintf(stderr, "%s: Can't open file \"%s\"\n", getAppName(), p); > + HeapFree(GetProcessHeap(), 0, p); > + > + /* Error opening the file */ > + if (!silent) > + { > + LoadString(hInst, IDS_IMPORT_ERROR, szText, COUNT_OF(szText)); > + InfoMessageBox(NULL, MB_OK | MB_ICONERROR, szTitle, szText, filename); > + } > + } > + > +cont: > + get_file_name(&s, filename); > + } > + break; > + } > + > + case ACTION_DELETE: > + { > + TCHAR reg_key_name[KEY_MAX_LEN]; > get_file_name(&s, reg_key_name); > - export_registry_key(filename, reg_key_name, REG_FORMAT_4); > - } > - else > - { > - export_registry_key(filename, NULL, REG_FORMAT_4); > - } > - break; > - } > - default: > - fprintf(stderr, "%s: Unhandled action!\n", getAppName()); > - exit(8); > - break; > - } > + if (!reg_key_name[0]) > + { > + fprintf(stderr, "%s: No registry key is specified for removal\n", getAppName()); > + fprintf(stderr, usage); > + exit(6); > + } > + delete_registry_key(reg_key_name); > + break; > + } > + > + case ACTION_EXPORT: > + { > + TCHAR filename[MAX_PATH]; > + > + filename[0] = _T('\0'); > + get_file_name(&s, filename); > + if (!filename[0]) > + { > + fprintf(stderr, "%s: No file name is specified\n", getAppName()); > + fprintf(stderr, usage); > + exit(7); > + } > + > + if (s[0]) > + { > + TCHAR reg_key_name[KEY_MAX_LEN]; > + get_file_name(&s, reg_key_name); > + export_registry_key(filename, reg_key_name, REG_FORMAT_4); > + } > + else > + { > + export_registry_key(filename, NULL, REG_FORMAT_4); > + } > + break; > + } > + > + default: > + fprintf(stderr, "%s: Unhandled action!\n", getAppName()); > + exit(8); > + break; > + } > + > return TRUE; > } > > @@ -233,35 +262,35 @@ > else > { > fprintf(stderr, "%s: Alphabetic character is expected after '%c' " > - "in swit ch specification\n", getAppName(), *(s - 1)); > + "in switch specification\n", getAppName(), *(s - 1)); > } > exit(1); > } > > -BOOL ProcessCmdLine(LPWSTR lpCmdLine) > +BOOL ProcessCmdLine(LPTSTR lpCmdLine) > { > BOOL silent = FALSE; > REGEDIT_ACTION action = ACTION_UNDEF; > - LPWSTR s = lpCmdLine; /* command line pointer */ > - WCHAR ch = *s; /* current character */ > - > - while (ch && ((ch == L'-') || (ch == L'/'))) > - { > - WCHAR chu; > - WCHAR ch2; > + LPTSTR s = lpCmdLine; /* command line pointer */ > + TCHAR ch = *s; /* current character */ > + > + while (ch && ((ch == _T('-')) || (ch == _T('/')))) > + { > + TCHAR chu; > + TCHAR ch2; > > s++; > ch = *s; > ch2 = *(s + 1); > - chu = (WCHAR)towupper(ch); > - if (!ch2 || iswspace(ch2)) > - { > - if (chu == L'S') > + chu = _totupper(ch); > + if (!ch2 || _istspace(ch2)) > + { > + if (chu == _T('S')) > { > /* Silence dialogs */ > silent = TRUE; > } > - else if (chu == L'V') > + else if (chu == _T('V')) > { > /* Ignore this switch */ > } > @@ -269,41 +298,41 @@ > { > switch (chu) > { > - case L'D': > - action = ACTION_DELETE; > - break; > - case L'E': > - action = ACTION_EXPORT; > - break; > - case L'?': > - fprintf(stderr, usage); > - exit(3); > - break; > - default: > - error_unknown_switch(chu, s); > - break; > + case _T('D'): > + action = ACTION_DELETE; > + break; > + case _T('E'): > + action = ACTION_EXPORT; > + break; > + case _T('?'): > + fprintf(stderr, usage); > + exit(3); > + break; > + default: > + error_unknown_switch(chu, s); > + break; > } > } > s++; > } > else > { > - if (ch2 == L':') > + if (ch2 == _T(':')) > { > switch (chu) > { > - case L'L': > - /* fall through */ > - case L'R': > - s += 2; > - while (*s && !iswspace(*s)) > - { > - s++; > - } > - break; > - default: > - error_unknown_switch(chu, s); > - break; > + case _T('L'): > + /* fall through */ > + case _T('R'): > + s += 2; > + while (*s && !_istspace(*s)) > + { > + s++; > + } > + break; > + default: > + error_unknown_switch(chu, s); > + break; > } > } > else > @@ -315,7 +344,7 @@ > } > /* skip spaces to the next parameter */ > ch = *s; > - while (ch && iswspace(ch)) > + while (ch && _istspace(ch)) > { > s++; > ch = *s; > @@ -323,25 +352,10 @@ > } > > if (*s && action == ACTION_UNDEF) > - { > - if (!silent) > - { > - TCHAR szTitle[256], szText[256]; > - LoadString(hInst, IDS_APP_TITLE, szTitle, COUNT_OF(szTitle)); > - LoadString(hInst, IDS_IMPORT_PROMPT, szText, COUNT_OF(szText)); > - /* request import confirmation */ > - if (MessageBox(NULL, szText, szTitle, MB_YESNO) == IDYES) > - action = ACTION_ADD; > - else > - return TRUE; > - } > - else > - { > - action = ACTION_ADD; > - } > - } > - if (action == ACTION_UNDEF) > + action = ACTION_ADD; > + > + if (action != ACTION_UNDEF) > + return PerformRegAction(action, s, silent); > + else > return FALSE; > - > - return PerformRegAction(action, s, silent); > -} > +} > > >

2 1

Everithing is down?
by Александр 02 Oct '12

02 Oct '12

3 3

General life fault
by caemyr＠myopera.com 30 Sep '12

30 Sep '12

Hiya Unfortunately, my lappy has died yesterday. I`ll RMA it this week (its just 6mo old...) but who knows how long will it take. I`ll get one as replacement from my work tomorow, but still this means no testing for me, just the web works for few next weeks. -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [hbelusca] 57400: [NTOSKRNL] Coverity code defects fixes : - Cache: CID 701441 - Config: CIDs 716570, 716669, 716760 - Dbgk: Kdbg: CIDs 716571, 515128/9, 500432 - Ex: CIDs 500156/7, 515122, 716200/...
by Pierre Schweitzer 28 Sep '12

28 Sep '12

What's the purpose of such ASSERT? > Modified: trunk/reactos/ntoskrnl/fsrtl/notify.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/fsrtl/notify.c?re… > ============================================================================== > --- trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/fsrtl/notify.c [iso-8859-1] Thu Sep 27 17:16:31 2012 > @@ -586,6 +586,13 @@ > /* Allocate new notification */ > NotifyChange = ExAllocatePoolWithTag(PagedPool | POOL_RAISE_IF_ALLOCATION_FAILURE, > sizeof(NOTIFY_CHANGE), 'FSrN'); > + > + /* > + * If NotifyChange == NULL then an > + * exception was already raised. > + */ > + ASSERT(NotifyChange != NULL); > + > RtlZeroMemory(NotifyChange, sizeof(NOTIFY_CHANGE)); > > /* Set basic information */ > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

2 2

Monthly meeting - September 2012
by Aleksey Bragin 27 Sep '12

27 Sep '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 28th of September, 19:00 UTC. The meeting will be at irc://dev.reactos.org (Port 6667, no SSL) in the channel #meeting, or as Pierre/Colin say. 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, and they are going to be different once again as they are not stored in any database. Hopefully it's not much of inconvenience. 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. As usual, Z98 is welcome to volunteer. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). With the best regards, Aleksey Bragin.

5 7

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

19 Sep '12

@Giannis - as you required: http://svn.reactos.org/svn/reactos?view=revision&revision=57330 This commit is causing the following crash in user32_apitest:desktop (reported in CORE-6682 desktop.c:83: Test failed: 3: expected error 0xc0000142 in child process got 0x0 (../../win32ss/user/ntuser/desktop.c:340) err: Failed to reference desktop WinSta0/Default PID: --! (../../win32ss/user/ntuser/main.c:333) err: Failed to assign default dekstop and winsta to process (../../win32ss/user/ntuser/main.c:374) err: UserCreateThreadInfo failed! Freeing pti 0xB09C5A70 for TID 00000590 (../../dll/ntdll/ldr/ldrinit.c:829) LDR: DLL_PROCESS_ATTACH for dll "user32.dll" (InitRoutine: 77ABADBF) failed (../../dll/ntdll/ldr/ldrinit.c:2111) LDR: LdrpProcessInitialization failed running initialization routines; status c0000142 (../../dll/ntdll/ldr/ldrinit.c:2140) LDR: Process initialization failure for C:\ReactOS\bin\user32_apitest.exe; NTSTATUS = c0000142 (../../subsystems/win32/csrss/csrsrv/api/wapi.c:1221) Exception in 59c.590. Killing... (../../win32ss/user/ntuser/desktop.c:340) err: Failed to reference desktop NonExistantDesktop PID: --! (../../win32ss/user/ntuser/main.c:333) err: Failed to assign default dekstop and winsta to process (../../win32ss/user/ntuser/main.c:374) err: UserCreateThreadInfo failed! Freeing pti 0xB097F008 for TID 00000588 (../../dll/ntdll/ldr/ldrinit.c:829) LDR: DLL_PROCESS_ATTACH for dll "user32.dll" (InitRoutine: 77ABADBF) failed (../../dll/ntdll/ldr/ldrinit.c:2111) LDR: LdrpProcessInitialization failed running initialization routines; status c0000142 (../../dll/ntdll/ldr/ldrinit.c:2140) LDR: Process initialization failure for C:\ReactOS\bin\user32_apitest.exe; NTSTATUS = c0000142 (../../subsystems/win32/csrss/csrsrv/api/wapi.c:1221) Exception in 594.588. Killing... (../../win32ss/user/ntuser/desktop.c:308) err: Failed to reference window station \Windows\WindowStations\NonExistantWinsta PID: --! (../../win32ss/user/ntuser/main.c:333) err: Failed to assign default dekstop and winsta to process (../../win32ss/user/ntuser/main.c:374) err: UserCreateThreadInfo failed! Freeing pti 0xB0A444F8 for TID 00000580 (../../dll/ntdll/ldr/ldrinit.c:829) LDR: DLL_PROCESS_ATTACH for dll "user32.dll" (InitRoutine: 77ABADBF) failed (../../dll/ntdll/ldr/ldrinit.c:2111) LDR: LdrpProcessInitialization failed running initialization routines; status c0000142 (../../dll/ntdll/ldr/ldrinit.c:2140) LDR: Process initialization failure for C:\ReactOS\bin\user32_apitest.exe; NTSTATUS = c0000142 (../../subsystems/win32/csrss/csrsrv/api/wapi.c:1221) Exception in 58c.580. Killing... (../../ntoskrnl/mm/ARM3/section.c:386) Out of system view space Assertion 'Base' failed at ../../ntoskrnl/mm/ARM3/section.c line 1041 [7h Entered debugger on embedded INT3 at 0x0008:0x8092582e. kdb:> bt Eip: <NTOSKRNL.EXE:12582f (../../lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:b773f (../../ntoskrnl/mm/ARM3/section.c:1041 (MiMapViewInSystemSpace@16))> <NTOSKRNL.EXE:b78ee (../../ntoskrnl/mm/ARM3/section.c:2655 (MmMapViewInSessionSpace@12))> <win32k.sys:148c8 (../../win32ss/user/ntuser/misc/usrheap.c:201 (UserCreateHeap))> <win32k.sys:359e1 (../../include/ddk/wdm.h:0 (UserDestroyThreadInfo@4))> <NTOSKRNL.EXE:11100e (../../ntoskrnl/ke/i386/traphdlr.c:1629 (@KiFastCallEntryHandler@8))> <NTOSKRNL.EXE:10ebfd (../../ntoskrnl/ke/i386/trap.s:150 (_KiFastCallEntry))> <ntdll.dll:b065> <user32_apitest.exe:84f2> ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Wed, 19 Sep 2012 02:32:21 +0000 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/6627 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: 57330 Blamelist: ion BUILD FAILED: failed Cleanup sincerely, -The Buildbot -- With best regards Caemyr

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 57313: * Don't use -momit-leaf-frame-pointer in debug gcc builds, it messes up stack traces. * Remove it from the amd64 gcc builds too.
by Timo Kreuzer 17 Sep '12

17 Sep '12

Amd64 doesn't need a frame pointer. Backtraces are made based on unwind tables. At least if GCC conforms to the ABI. Am 16.09.2012 14:57, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Sep 16 12:57:22 2012 > New Revision: 57313 > > URL: http://svn.reactos.org/svn/reactos?rev=57313&view=rev > Log: > * Don't use -momit-leaf-frame-pointer in debug gcc builds, it messes up stack traces. > * Remove it from the amd64 gcc builds too. > > Modified: > trunk/reactos/cmake/gcc.cmake > > Modified: trunk/reactos/cmake/gcc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/gcc.cmake?rev=57313&… > ============================================================================== > --- trunk/reactos/cmake/gcc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/gcc.cmake [iso-8859-1] Sun Sep 16 12:57:22 2012 > @@ -83,12 +83,15 @@ > if(ARCH STREQUAL "i386") > add_compile_flags("-mpreferred-stack-boundary=3 -fno-set-stack-executable -fno-optimize-sibling-calls -fno-omit-frame-pointer") > if(OPTIMIZE STREQUAL "1") > - add_compile_flags("-ftracer -momit-leaf-frame-pointer") > + add_compile_flags("-ftracer") > + if(NOT CMAKE_BUILD_TYPE STREQUAL "Debug") > + add_compile_flags("-momit-leaf-frame-pointer") > + endif() > endif() > elseif(ARCH STREQUAL "amd64") > add_compile_flags("-mpreferred-stack-boundary=4") > if(OPTIMIZE STREQUAL "1") > - add_compile_flags("-ftracer -momit-leaf-frame-pointer") > + add_compile_flags("-ftracer") > endif() > elseif(ARCH STREQUAL "arm") > if(OPTIMIZE STREQUAL "1") > > >

2 1

Re: [ros-dev] [ros-diffs] [mnordell] 57288: Add comment explaining initialization.
by Thomas Faber 16 Sep '12

16 Sep '12

On 2012-09-13 02:52, mnordell(a)svn.reactos.org wrote: > --- trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] Thu Sep 13 00:52:12 2012 > @@ -1211,7 +1211,7 @@ > BOOLEAN FirstTry; > ULONG i; > PCSR_SERVER_DLL ServerDll; > - ULONG Result = 0; > + ULONG Result = 0; /* Intentionally invalid enumeratee to silence compiler warning */ > > /* Acquire process lock */ > CsrAcquireProcessLock(); Frankly, I still don't understand it :D As I recall, this warning isn't a false positive, is it? Thus one would logically "fix", not "silence" it.

1 0

uLAN driver with ReactOS USB advances and some questions
by Pavel Pisa 16 Sep '12

16 Sep '12

Dear ReactOS developers, I follow ReactOS development for some years. I have successfully tested and reported our uLAN driver with PCI cards on ReactOS two years ago. The latest inclusion of USB VENDOR device requests in ReactOS allowed to finally run driver with our real USB hardware with QEMU KVM USB device pass-through setup. ReactOS tuned version of the uLAN driver installs and is fully functional when tested from CHROMuLAN application. But there are more issues still and I would be happy if somebody can help with these or give me hint about possible incompatibility in our driver. The tests were conducted against ReactOS 57254 build. uLAN driver is from GIT source repository http://ulan.sourceforge.net/ http://ulan.git.sourceforge.net/git/gitweb.cgi?p=ulan/ulan-drv;a=tree;f=ul_… uLAN driver was build by MS WDF VC version 15.00.30729.207 The issues: 1) the first minor one - ReactOS requires minimal transfer size for URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE/USB_CONFIGURATION_DESCRIPTOR_TYPE function (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE ulan: _usb_submit_urb : return from IoCallDriver USBD 103 ulan: _usb_submit_urb : URB status = 0 status = 0 irp status 0 uLan: _usb_submit_urb done with status:0x0 uLan: _usb_get_descriptor done with status:0x0 uLan: usb_device_descriptor done with status:0x0 uLan: usb_get_configuration uLan: _usb_get_descriptor (type=0x2,idx=0x0) ulan: _usb_submit_urb : enter (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:244) URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE Assertion 'Urb->UrbControlDescriptorRequest.TransferBufferLength >= sizeof(USB_CONFIGURATION_DESCRIPTOR)' failed at /srv/buildbot_ cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp line 1560 Entered debugger on embedded INT3 at 0x0008:0x80924c3a. Unmodified uLAN driver asks for the first four bytes descriptor bytes firest and after obtaining size of the whole descriptor it prepares full size transfer. ReactOS asserts for this shorted 4 bytes transfer. I have adapted driver to use sizeof(USB_CONFIGURATION_DESCRIPTOR) size for initial probe transfer in USB_CONFIGURATION_DESCRIPTOR_TYPE case. This makes ReactOS happy, but I would like to know which side should be updated in the future. Is there defined in some spec that initial probe for size has to be at least of sizeof(USB_CONFIGURATION_DESCRIPTOR) or the ReactOS is more strict than necessary and assert should be modified to allow truncated probes or at least 4 bytes ones in addition? The full log at http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-win-confdesc.log 2) Driver can be enabled and disabled at runtime but shutdown does not finish, is blocked somehow but system/cursor is responsive http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-enabled-at-runtime.log I have no idea what is the problem. Driver works correctly on Windows from 2k to Win7 and latest version supports even suspend and resume on all these platforms. 3) When driver and device are installed/present from boot time, boot hangs http://cmp.felk.cvut.cz/~pisa/ulan/reactos/reactos-ul-during-boot.log (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:313) [USBLIB] SCE Request B027B048 TransferBufferLength 8 Flags 3 MDL 00000000 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 0: Status 103, Change 0 (/srv/buildbot_cmake/full_cmake/build/lib/drivers/libusb/hub_controller.cpp:324) [USBLIB] Port 1: Status 100, Change 0 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbhub/pdo.c:541) uLan2usb convertor (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/pnpmgr/pnpmgr.c:4030) IRP_MN_QUERY_PNP_DEVICE_STATE failed with status 0xc00000bb (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/iorsrce.c:725) Failed opening given symbolic link! (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciide.sys at FCBF4000 with 7 pages (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\pciidex.sys at FCBEB000 with 9 pages (/srv/buildbot_cmake/full_cmake/build/drivers/bus/pci/pdo.c:1267) Enabling command flags for PCI device 0x21 on bus 0x0: [Bus master] [I/O space enable] (/srv/buildbot_cmake/full_cmake/build/drivers/storage/ide/pciidex/fdo.c:464) IRP_MJ_PNP / Unknown minor function 0x9 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:174) Loading: \SystemRoot\system32\drivers\ul_wdm.sys at FCBD9000 with 11 pages Assertion 'IsListEmpty(&Irp->ThreadListEntry)' failed at /srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/irp.c line 1524 Entered debugger on embedded INT3 at 0x0008:0x80924c3a. kdb:> ==================================================================================== Thanks for any hints in advance. I would be happy if the problems are resolved in the future. It could be interresting option to have livecd available with ReactOS, uLAN driver and CHROMuLAN for us one day. We can provide even some small funding for such achievement if it could work reliably on real hardware. Other reason why ReactOS is interresting for us is that it has cached some bugs in our driver (mismatch in memory pools tags which are not reported by Windows release builds). Yet another reasons for ReactOS is to use 64-bit ReactOS build as testbed for uLAN driver Windows 64-bit version debugging. (64-bit Linux x86 version is fully supported now same as MIPS, PPC and ARM). But 64-bit Windows are pain for its signing requirements etc. And after all I do not have any (32/64-bit) Windows installed on our computers at all so ReactOS is great target for our development even if we has to depend on users use and demand for Windows. As for CHROMuLAN and RectOS compatibility, chromatography system is functional under ReactOS except for some problem in the complex calibration files dialog which can hang the application and some harmless exception during analysis files read. Both seems to cause similar problems under Wine as well. In each case, thanks for the big pile of the work invested to the ReactOS project, Pavel Pisa e-mail: pisa(a)cmp.felk.cvut.cz www: http://cmp.felk.cvut.cz/~pisa university: http://dce.fel.cvut.cz/ company: http://www.pikron.com/

5 6

Affects Version field
by Timo Kreuzer 13 Sep '12

13 Sep '12

Can we rename the "Affects Version" field to "Affected Revision"? Noone cares for 0.3.11 bugs and TRUNK ins meaningless. Also: is it possible to automaticcally translate to the current head revision number, when TRUNK or rather HEAD is selected? Maybe when we have FishEye? Regards, Timo

2 2

Component list rewrite
by caemyr＠myopera.com 13 Sep '12

13 Sep '12

3 6

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

13 Sep '12

Test run failed due to exceeding the maximum number of restarts, Problem started with unexpected crash: Running Wine Test, Module: pdh, Test: pdh Assertion 'KiTimerTableListHead[Index].Time.QuadPart <= Timer->DueTime.QuadPart' failed at ../../ntoskrnl/ke/dpc.c line 252 [7h Entered debugger on embedded INT3 at 0x0008:0x809257d2. kdb:> bt Eip: <NTOSKRNL.EXE:1257d3 (../../lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:82a22 (../../ntoskrnl/ke/dpc.c:251 (KiTimerExpiration@16))> <NTOSKRNL.EXE:82c20 (../../ntoskrnl/ke/dpc.c:576 (@KiRetireDpcList@4))> <NTOSKRNL.EXE:10a2fa (../../ntoskrnl/ke/i386/ctxswitch.S:78 (KiRetireDpcListInDpcStack))> <HAL.DLL:a71b (../../hal/halx86/up/pic.c:1323 (@HalpDispatchInterrupt2ndEntry@4))> <HAL.DLL:a684 (../../hal/halx86/up/pic.c:1243 (HalEndSystemInterrupt@8))> <NTOSKRNL.EXE:89dbf (../../ntoskrnl/include/internal/arch/../i386/ke.h:829 (@KeUpdateSystemTime@12))> <HAL.DLL:9b6b (../../hal/halx86/generic/timer.c:172 (@HalpClockInterruptHandler@4))> <HAL.DLL:9f52 (../../hal/halx86/generic/trap.S:0 (_HalpClockInterrupt))> <rosautotest.exe:67cb> <rosautotest.exe:703d> The subsequent reboots have been asserting at startup: Boot took 33308394332 cycles! Interrupts: 1838 System Calls: 15454 Context Switches: 1688 (../../ntoskrnl/se/semgr.c:646) HACK: Should deny access for caller: granted 0x90003, desired 0x190003 (generic mapping B12893B0). (../../base/services/eventlog/eventlog.c:296) RegQueryValueEx failed: 126 (../../base/services/eventlog/eventlog.c:393) Failed to load Wine (../../base/services/wlansvc/wlansvc.c:145) wlansvc: main() started (../../base/services/wlansvc/wlansvc.c:96) ServiceMain() called (../../base/services/wlansvc/wlansvc.c:130) ServiceMain() done (../../base/system/services/rpcserver.c:1716) RNotifyBootConfigStatus(00000000 1) called Assertion 'CellBlock < RegistryHive->Storage[CellType].Length' failed at ../../lib/cmlib/hivecell.c line 32 [7h Entered debugger on embedded INT3 at 0x0008:0x809257d2. kdb:> bt Eip: <NTOSKRNL.EXE:1257d3 (../../lib/rtl/i386/debug_asm.S:35 (_DbgBreakPoint@0))> Frames: <NTOSKRNL.EXE:124087 (../../lib/cmlib/hivecell.c:32 (HvpGetCellHeader@8))> <NTOSKRNL.EXE:124119 (../../lib/cmlib/hivecell.c:74 (HvGetCell@8))> <NTOSKRNL.EXE:125318 (../../lib/cmlib/cminit.c:97 (CmpPrepareIndexOfKeys@8))> <NTOSKRNL.EXE:125407 (../../lib/cmlib/cminit.c:124 (CmpPrepareKey@8))> <NTOSKRNL.EXE:125435 (../../lib/cmlib/cminit.c:135 (CmPrepareHive@4))> <NTOSKRNL.EXE:12528e (../../lib/cmlib/hiveinit.c:506 (HvInitialize@52))> <NTOSKRNL.EXE:1dca5 (../../ntoskrnl/config/cminit.c:177 (CmpInitializeHive@40))> <NTOSKRNL.EXE:26132 (../../ntoskrnl/config/cmsysini.c:287 (CmpInitHiveFromFile@20))> <NTOSKRNL.EXE:2060d (../../ntoskrnl/config/cmlazy.c:259 (CmpCmdHiveOpen@20))> <NTOSKRNL.EXE:1548d (../../ntoskrnl/config/cmapi.c:1713 (CmLoadKey@16))> <NTOSKRNL.EXE:2928e (../../ntoskrnl/config/ntapi.c:843 (NtLoadKeyEx@16))> <NTOSKRNL.EXE:29356 (../../ntoskrnl/config/ntapi.c:791 (NtLoadKey@8))> <NTOSKRNL.EXE:110fb2 (../../ntoskrnl/ke/i386/traphdlr.c:1629 (@KiFastCallEntryHandler@8))> <NTOSKRNL.EXE:10eba1 (../../ntoskrnl/ke/i386/trap.s:150 (_KiFastCallEntry))> <ntdll.dll:b009> <userenv.dll:62a4> <winlogon.exe:2317> <winlogon.exe:3023> <user32.dll:4bb39> <user32.dll:4c188>--- Press q to abort, any other key to continue --- <user32.dll:4d37b> <winlogon.exe:4b00> ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Thu, 13 Sep 2012 01:14:24 +0000 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/6579 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: 57288 Blamelist: mnordell BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

1 0

Jira search
by Timo Kreuzer 13 Sep '12

13 Sep '12

Hi, Does anyone know how to search for issues older than 1 year or something like that? According to https://jira.atlassian.com/browse/JRA-1983 it should be possible, but Icouldn't figure out how to. Timo

3 2

Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC. No functional change, j...
by Timo Kreuzer 12 Sep '12

12 Sep '12

What was the problem with the old macros? The new ones are error-prone. if (NeedLock) SepAcquireTokenLockExclusive(Token); // <= fail! WBR, Timo Am 12.09.2012 18:29, schrieb ion(a)svn.reactos.org: > Author: ion > Date: Wed Sep 12 16:29:28 2012 > New Revision: 57284 > > URL: http://svn.reactos.org/svn/reactos?rev=57284&view=rev > Log: > [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC. > No functional change, just code cleanup. > > Modified: > trunk/reactos/ntoskrnl/include/internal/se.h > trunk/reactos/ntoskrnl/se/access.c > trunk/reactos/ntoskrnl/se/semgr.c > > Modified: trunk/reactos/ntoskrnl/include/internal/se.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/se.h [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -1,4 +1,28 @@ > #pragma once > + > +typedef struct _KNOWN_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + ULONG SidStart; > +} KNOWN_ACE, *PKNOWN_ACE; > + > +typedef struct _KNOWN_OBJECT_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + ULONG Flags; > + ULONG SidStart; > +} KNOWN_OBJECT_ACE, *PKNOWN_OBJECT_ACE; > + > +typedef struct _KNOWN_COMPOUND_ACE > +{ > + ACE_HEADER Header; > + ACCESS_MASK Mask; > + USHORT CompoundAceType; > + USHORT Reserved; > + ULONG SidStart; > +} KNOWN_COMPOUND_ACE, *PKNOWN_COMPOUND_ACE; > > PSID > FORCEINLINE > @@ -75,6 +99,8 @@ > return Descriptor->Sacl; > } > } > + > +#ifndef RTL_H > > /* SID Authorities */ > extern SID_IDENTIFIER_AUTHORITY SeNullSidAuthority; > @@ -156,6 +182,19 @@ > extern PSECURITY_DESCRIPTOR SeSystemDefaultSd; > extern PSECURITY_DESCRIPTOR SeUnrestrictedSd; > > + > +#define SepAcquireTokenLockExclusive(Token) \ > + KeEnterCriticalRegion(); \ > + ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE); \ > + > +#define SepAcquireTokenLockShared(Token) \ > + KeEnterCriticalRegion(); \ > + ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE); \ > + > +#define SepReleaseTokenLock(Token) \ > + ExReleaseResource(((PTOKEN)Token)->TokenLock); \ > + KeLeaveCriticalRegion(); \ > + > // > // Token Functions > // > @@ -434,24 +473,6 @@ > OUT PACCESS_TOKEN* NewToken > ); > > -#define SepAcquireTokenLockExclusive(Token) \ > - do { \ > - KeEnterCriticalRegion(); \ > - ExAcquireResourceExclusive(((PTOKEN)Token)->TokenLock, TRUE); \ > - while(0) > - > -#define SepAcquireTokenLockShared(Token) \ > - do { \ > - KeEnterCriticalRegion(); \ > - ExAcquireResourceShared(((PTOKEN)Token)->TokenLock, TRUE); \ > - while(0) > - > -#define SepReleaseTokenLock(Token) \ > - do { \ > - ExReleaseResource(((PTOKEN)Token)->TokenLock); \ > - KeLeaveCriticalRegion(); \ > - while(0) > - > VOID NTAPI > SeQuerySecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation, > OUT PACCESS_MASK DesiredAccess); > @@ -460,4 +481,6 @@ > SeSetSecurityAccessMask(IN SECURITY_INFORMATION SecurityInformation, > OUT PACCESS_MASK DesiredAccess); > > +#endif > + > /* EOF */ > > Modified: trunk/reactos/ntoskrnl/se/access.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/access.c?rev=5… > ============================================================================== > --- trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/se/access.c [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -130,11 +130,7 @@ > ASSERT(Sid != NULL); > > /* Lock the token if needed */ > - if (!TokenLocked) > - { > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > - } > + if (!TokenLocked) SepAcquireTokenLockShared(Token); > > /* Check if the owner SID is found, handling restricted case as well */ > Result = SepSidInToken(Token, Sid); > @@ -144,11 +140,7 @@ > } > > /* Release the lock if we had acquired it */ > - if (!TokenLocked) > - { > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > - } > + if (!TokenLocked) SepReleaseTokenLock(Token); > > /* Return the result */ > return Result; > @@ -168,15 +160,13 @@ > TokenControl->TokenSource = Token->TokenSource; > > /* Lock the token */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > + SepAcquireTokenLockShared(Token); > > /* Capture the modified it */ > TokenControl->ModifiedId = Token->ModifiedId; > > /* Unlock it */ > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(Token); > } > > NTSTATUS > @@ -327,13 +317,11 @@ > ClientToken = SubjectContext->ClientToken; > > /* Always lock the primary */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(PrimaryToken->TokenLock, TRUE); > + SepAcquireTokenLockShared(PrimaryToken); > > /* Lock the impersonation one if it's there */ > if (!ClientToken) return; > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(ClientToken->TokenLock, TRUE); > + SepAcquireTokenLockShared(ClientToken); > } > > /* > @@ -351,13 +339,11 @@ > ClientToken = SubjectContext->ClientToken; > > /* Always unlock the primary one */ > - ExReleaseResourceLite(PrimaryToken->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(PrimaryToken); > > /* Unlock the impersonation one if it's there */ > if (!ClientToken) return; > - ExReleaseResourceLite(ClientToken->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(ClientToken); > } > > /* > > Modified: trunk/reactos/ntoskrnl/se/semgr.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/se/semgr.c?rev=57… > ============================================================================== > --- trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/se/semgr.c [iso-8859-1] Wed Sep 12 16:29:28 2012 > @@ -952,8 +952,7 @@ > SeCaptureSubjectContext(&SubjectSecurityContext); > > /* Lock the token */ > - KeEnterCriticalRegion(); > - ExAcquireResourceSharedLite(Token->TokenLock, TRUE); > + SepAcquireTokenLockShared(Token); > > /* Check if the token is the owner and grant WRITE_DAC and READ_CONTROL rights */ > if (DesiredAccess & (WRITE_DAC | READ_CONTROL | MAXIMUM_ALLOWED)) > @@ -990,8 +989,7 @@ > > /* Release subject context and unlock the token */ > SeReleaseSubjectContext(&SubjectSecurityContext); > - ExReleaseResourceLite(Token->TokenLock); > - KeLeaveCriticalRegion(); > + SepReleaseTokenLock(Token); > > /* Release the captured security descriptor */ > SeReleaseSecurityDescriptor(CapturedSecurityDescriptor, > > >

3 3

Re: [ros-dev] [ros-diffs] [ion] 57284: [NTOSKRNL]: Use the token lock acquire/release macros that were already written instead of manually doing it. Also fix the macros since they didn't work in GCC. No functional change, j...
by Ged Murphy 12 Sep '12

12 Sep '12

Why the removal of the do/while loop? This breaks the macro when used without braces : +#define SepReleaseTokenLock(Token) \ + ExReleaseResource(((PTOKEN)Token)->TokenLock); \ + KeLeaveCriticalRegion(); \ + <snip> -#define SepReleaseTokenLock(Token) \ - do { \ - ExReleaseResource(((PTOKEN)Token)->TokenLock); \ - KeLeaveCriticalRegion(); \ - while(0) <snip> /* Release the lock if we had acquired it */ + if (!TokenLocked) SepReleaseTokenLock(Token);

1 0

Jira Planning
by Timo Kreuzer 12 Sep '12

12 Sep '12

Hi, I'd like to invite every developer to make use of the Jira planning feature. For those, who are not yet familiar with it here's a an explantion. In the blue Jira menu bar you'll find an item called "Agile". Click on that to get to the planning boards. First time users will be asked to either choose between Scrum or Kanban. Select Scrum. Then you will be asked to select a dashboard or create one. You can simply choose "Scrum Board" from the dropdown list, this one should be fine. You can later create your own board, if you like. Now you will see 3 buttons on the right-hand side below the menu bar: "plan", "work" and "report" First select "plan" On the top you can see the current "sprint", which is the next planned period. We currently have one sprint for September. We can create multiple sprints and periods are as we want them. I think one month is reasonable. Under the sprint you can see the issues that are selected for this sprint, i.e. supposed to be tackled in that period. Currently only project administrators can create sprints, but every developer can move items there. To remove an item from the sprint, you need to click on it, so it gets highlited, then open the menu with the gear wheel icon in the issue description on the right and select "Remove from sprint". Below you see the backlog (all open issues). Since the list is quite huge, you can limit it to your own issues, by pressing the "Only my issues" filter button. (Note this one works like a pushbutton, click it once to enable, again to disable. Maybe Amine can make them look more like that by adding a highlite color) On the righ-hand side, you see a box that shows the currently selected issue. Now you can drag and drop issues from the backlog into one of the sprints. So if you plan to work on a specific issue in September, just drag it into sprint 1. Now select "work" Here you can see the so called "swim lanes". In the default Scrum Board they are configured per Developer. So you see every developer that has active issues in the current sprint(s). You can open and close the swim lanes to see the issues. And you can again select "Only my issues". The board has 3 columns: "To do", "In Progress", "Done". All issues that you selected for the current sprint will initially be in the "To do" column. When you work on an issue, simply drag it over to the "In Progress" column. When you fixed it, drag it to "Done". When dragging them the target column will be highlited in green. The "Done" column will show you 2 fields when dragging an item there: one for resolve, one for close. When you dragged them to close, you'll see a confirmation dialog, where you can enter additional stuff and then confirm it. Have fun Timo

1 0

Re: [ros-dev] [ros-diffs] [mnordell] 57198: Silence compiler warning
by Thomas Faber 12 Sep '12

12 Sep '12

Hi, On 2012-08-29 14:28, mnordell(a)svn.reactos.org wrote: > --- trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] (original) > +++ trunk/reactos/subsystems/csr/csrsrv/process.c [iso-8859-1] Wed Aug 29 12:28:35 2012 > @@ -1211,7 +1211,7 @@ > BOOLEAN FirstTry; > ULONG i; > PCSR_SERVER_DLL ServerDll; > - ULONG Result; > + ULONG Result = 0; > > /* Acquire process lock */ > CsrAcquireProcessLock(); > > zero doesn't look like a valid value for this variable. Shouldn't it be one of CsrShutdownCsrProcess, CsrShutdownNonCsrProcess, CsrShutdownCancelled? -Thomas

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 57260: [CMAKE] * Refer to the PSEH lib using its variable.
by Timo Kreuzer 10 Sep '12

10 Sep '12

Can't we get rid of that completely? Afaicr it expands to pseh for both gcc and msvc Am 10.09.2012 01:59, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Sep 9 23:59:16 2012 > New Revision: 57260 > > URL: http://svn.reactos.org/svn/reactos?rev=57260&view=rev > Log: > [CMAKE] > * Refer to the PSEH lib using its variable. > > Modified: > trunk/reactos/base/services/eventlog/CMakeLists.txt > trunk/reactos/base/services/wlansvc/CMakeLists.txt > trunk/reactos/base/system/services/CMakeLists.txt > trunk/reactos/base/system/smss/CMakeLists.txt > > Modified: trunk/reactos/base/services/eventlog/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/eventlog/CMa… > ============================================================================== > --- trunk/reactos/base/services/eventlog/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/services/eventlog/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -17,7 +17,7 @@ > add_executable(eventlog ${SOURCE}) > > if(NOT MSVC) > - target_link_libraries(eventlog pseh) > + target_link_libraries(eventlog ${PSEH_LIB}) > endif() > > set_module_type(eventlog win32cui UNICODE) > > Modified: trunk/reactos/base/services/wlansvc/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/services/wlansvc/CMak… > ============================================================================== > --- trunk/reactos/base/services/wlansvc/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/services/wlansvc/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -10,7 +10,7 @@ > ${CMAKE_CURRENT_BINARY_DIR}/wlansvc_s.c) > > if(NOT MSVC) > - target_link_libraries(wlansvc pseh) > + target_link_libraries(wlansvc ${PSEH_LIB}) > endif() > > set_module_type(wlansvc win32cui UNICODE) > > Modified: trunk/reactos/base/system/services/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/services/CMake… > ============================================================================== > --- trunk/reactos/base/system/services/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/system/services/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -22,7 +22,7 @@ > add_executable(services ${SOURCE}) > > if(NOT MSVC) > - target_link_libraries(services pseh) > + target_link_libraries(services ${PSEH_LIB}) > endif() > > set_module_type(services win32cui UNICODE) > > Modified: trunk/reactos/base/system/smss/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/base/system/smss/CMakeList… > ============================================================================== > --- trunk/reactos/base/system/smss/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/base/system/smss/CMakeLists.txt [iso-8859-1] Sun Sep 9 23:59:16 2012 > @@ -2,23 +2,20 @@ > include_directories(${REACTOS_SOURCE_DIR}/include/reactos/subsys) > > list(APPEND SOURCE > - crashdmp.c > - pagefile.c > - sminit.c > - smloop.c > - smsbapi.c > - smsessn.c > - smsubsys.c > - smutil.c > - smss.c > - smss.rc) > + crashdmp.c > + pagefile.c > + sminit.c > + smloop.c > + smsbapi.c > + smsessn.c > + smsubsys.c > + smutil.c > + smss.c > + smss.rc) > > add_executable(smss WIN32 ${SOURCE}) > - > -target_link_libraries(smss nt pseh smlib) > - > +target_link_libraries(smss nt ${PSEH_LIB} smlib) > add_pch(smss smss.h) > - > set_module_type(smss nativecui) > add_importlibs(smss ntdll) > add_cd_file(TARGET smss DESTINATION reactos/system32 FOR all) > > >

1 0

PSEH3
by Timo Kreuzer 09 Sep '12

09 Sep '12

Hi, I am pleased to announce the long awaited (or absolutely surprising) release of PSEH3. This complete from scratch rewrite takes reactos exception handling to a new level. It comprises the following advancements: - Use of enums instead of const variables for internal trylevel counting and other mechanisms. enums can be declared in a nested manner as well and only enums are treated by gcc as full compile time constants, while const variables are treated as dynamic and are only optimized away by the compiler later. This generally results in better optimized code. - No more use of dynamic sized arrays. Those make the compiler emit a slow call to _chkstk. It could have been prevented in PSEH2, if enums had been used instead of consts. The new code uses the same registration frame for the top level and nested levels, which also simplifies the code. - No more use of nested function stack trampolines. These are small code chunks that are being dynamically put on the stack, when the address of a nested function is taken. The address of the nested function then points to this trampoline, which sets up a pointer for nested variable access (nested function can access variables in the parent frame). These were parsed by PSEH2 to calculate the neccessary nested frame pointer. PSEH3 uses a static scope table instead that contains the address of the nested function. this is only possible by first declaring the function and putting the implementation after the address is stored in the static table. This is because nested functions that do not access any variables in the parent frame do not need a stack trampoline and their addresses are thus considered compiler constants. GCC doesn't notice that a nested function uses variables of the parent frame, before the function is actually implemented, so with only a prototype, it assumes a constant address. To get the value of the parent frame pointer, PSEH2 calls the nested function 2 times: The first time with a bogus frame pointer and a parameter that tells the function to return the (assumed) address of the current registration frame. Without a proper parent frame pointer the nested function will return an offset that we can use together with the real address of the registration frame (which we know, when calling the filter of finally functions) to calculate the proper parent frame pointer. The 2nd call passes a different parameter and allows the function to do the actual work and access variables in the parent frame. - Improved performance due to use of "asm goto". This construct allows to get away with having labels, that are never accessed by any C code. The compiler doesn't remove them. So we do not need the old hack, of comparing a "volatile" 0 against 0, just to confuse GCC to not optimize away a label. Even though there is a bug/defficiency/limitation in asm goto, that would usually not allow the combination with static C jump labels, we can still do that due to some tricks that force GCC to do the right thing. More information: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840 - Improved performance due to faster registration. The new registration code is smaller and saves only esp and ebp. Due to some tricks in PSEH3, GCC is forced to assume all registers are being clobbered when the __except block is run. Filter function and __finally function don't make use of registers from the previous code. So all neccessary register save and restore is now fully done by GCC. - The trick to make GCC assume all registers are clobbered at the beginning of the __except block has one additional huge advantage. Now all variables that are accessed by the __except block will be stored in memory locations, so that modifications in the __try block will be available in the __except block, something that doesn't work with PSEH2. This does not prevent the compiler from doing constant expression elimination! So when you try to do 2 different, constant assignments to a variable in the __try block, expect that this will be reduced to only the later assignment. GCC does not know, that the execution can be interrupted in the middle of the __try block between those 2 assignments. If you need such stuff, you must use a volatile variable. - Less stack usage. PSEH3 stores much less data on the stack. No trampolines, only esp and ebp are saved, registration frames are smaller. - No more need for _SEH2_YIELD(). This macro was used to make sure the registration frames are properly unregistered, when leaving the try or except block using goto or return. This is not neccessary anymore due to the use of __attribute__((cleanup)). This attribute is attached to the registration frame and causes the cleanup function to be called automatically, whenever the variable goes out of scope. This happens when a goto or return is used in the code. - Human readable warnings, when special SEH instriniscs, like _exception_info() or _abnormal_termination() are used outside of their valid context. - Cleaner and better readable code, so you won't get braindead, when trying to figure out what's going on. Header: < 300 lines commented code, instead of 370 lines uncommented code, lib: < 250 lines of commented C code + < 70 lines commented asm code, instead of 290 lines of uncommented C code + 120 lines uncommented asm code) I also promised Amine to take a look into implementing a version that is compatible with clang. Initially I planned to include this into this release, but it turns out that clang massivley lacks features to do so and a completely different approach will probably be used for that. The new code is only compatible with GCC 4.7 and later, and it's also currently disabled (cmake option USE_PSEH3). Tesbot showed no noticable regressions. Have fun. Timo

1 0

Bugzilla outage
by Aleksey Bragin 08 Sep '12

08 Sep '12

Hello, I turned off Bugzilla now in favor of finishing the switch to JIRA. Once the work is done, I will announce either return to Bugzilla or introduce JIRA. Hopefully, it'll be the latter option. Best regards, Aleksey.

1 0

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

04 Sep '12

This commit breaks msvc compilation. Best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on CMake_x86_MSVCWin Debug Date: Tue, 04 Sep 2012 03:10:09 +0000 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/1908 Buildbot URL: http://build.reactos.org/ Buildslave for this Build: Windows_AMD64_1 Build Reason: scheduler Build Source Stamp: 57233 Blamelist: cgutman BUILD FAILED: failed building bootcd sincerely, -The Buildbot -- With best regards Caemyr

1 0

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

03 Sep '12

Currently, we experience random crashes in 2nd stage. I was unable to catch any first exception bar the one with vmware detection code (which is outdated and should be removed). After forcing build again, test run failed at Cleanup, due to previously unresolved issue of repeating whole testrun when crash occurs in APItests. On Mon, Sep 3, 2012, at 10:21 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/6496 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_2 > > Build Reason: The web-page 'force build' button was pressed by 'osiejka': > > Build Source Stamp: 57227 > Blamelist: > > BUILD FAILED: failed Cleanup > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

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

02 Sep '12

This one is caused by rev 57225: Backtrace: http://www.reactos.org/paste/index.php/10472/ Please fix ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Sun, 02 Sep 2012 22:50:06 +0000 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/6492 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: 57225 Blamelist: ion BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

1 0

Problem with dbgwin revisions from Windows builder
by caemyr＠myopera.com 02 Sep '12

02 Sep '12

Hiya R3ddr4g0n reported to me that all recent revisions uploaded to iso.reactos.org are not correct. Instead of given revision, all the builds are reporting to be rev 57150. After a quick check, i downloaded bootcd-57221-dbgwin.iso and checked its SHA1: should be 56d2190610e8a1f650faa3c6a6a8348f89d1fa1b but happened to be: f97ac4aba0e5ceed3b5beae3d7ab2bc2c7600fab - which is indeed the same checksum as for x86_CMake-57150 The possible clue from the upload script: bash: rsync: command not found rsync: connection unexpectedly closed (0 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at /home/lapo/package/rsync-3.0.8-1/src/rsync-3.0.8/io.c(601) [sender=3.0.8] * Done. * Remotely compressing bootcd-57219-dbgwin... Now, Colin may recall that i was strongly against using fancy tricks for sending the revs instead of simply archiving them locally and uploading afterwards. This way with rsync was supposed to be saving bit of bandwidth. Now we have to reupload at least all since 57150, unless you can use the fancy tricks to spot the same iso files. Great thing we can save a little bit of bandwidth but waste time to fix it afterwards. Accoring to the reporter: [21:45:37] <r3ddr4g0n> for sure from 57115 to 57221 If you still think this methode is saving us anything, please reckon that a single view of testbot log means downloading a few megabytes of text at least. I`m stopping the uploads until the problem is resolved in a way to prevent it from happening again. -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-diffs] [ion] 57215: [NTOSKRNL]: Do not return data in failure cases in NtProtectVirtualMemory. [NTOSKRNL]: No longer support non-ARM3 sections in NtProtectVirtualMemory, as the only OS calls were already ...
by Thomas Faber 02 Sep '12

02 Sep '12

Hi! On 02.09.2012 03:17, ion(a)svn.reactos.org wrote: > Modified: trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/ARM3/virtual.c… > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/ARM3/virtual.c [iso-8859-1] Sun Sep 2 01:17:42 2012 > @@ -3668,15 +3795,50 @@ > } > > // > - // Assert on the things we don't yet support > - // > - ASSERT(ZeroBits == 0); > - ASSERT((AllocationType& MEM_LARGE_PAGES) == 0); > - ASSERT((AllocationType& MEM_PHYSICAL) == 0); > - ASSERT((AllocationType& MEM_WRITE_WATCH) == 0); > - ASSERT((AllocationType& MEM_TOP_DOWN) == 0); > - ASSERT((AllocationType& MEM_RESET) == 0); > - ASSERT(Process->VmTopDown == 0); > + // Fail on the things we don't yet support > + // > + if (ZeroBits != 0) > + { > + DPRINT1("Zero bits not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_LARGE_PAGES) == 1) > + { > + DPRINT1("MEM_LARGE_PAGES not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_PHYSICAL) == 1) > + { > + DPRINT1("MEM_PHYSICAL not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_WRITE_WATCH) == 1) > + { > + DPRINT1("MEM_WRITE_WATCH not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_TOP_DOWN) == 1) > + { > + DPRINT1("MEM_TOP_DOWN not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } > + if ((AllocationType& MEM_RESET) == 1) > + { > + DPRINT1("MEM_RESET not supported\n"); > + Status = STATUS_INVALID_PARAMETER; > + goto FailPathNoLock; > + } These guys won't work, you need != 0 or == MEM_BLAH -Thomas

1 0

Monthly meeting - August 2012
by Aleksey Bragin 30 Aug '12

30 Aug '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 30th of August, 19:00 UTC. The meeting will be at irc://fezile.reactos.org (Port 6667, no SSL) in the channel #meeting, if the server works. If not, then an alternative place will be announced here. 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. As usual, Z98 is welcome to volunteer. The agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). With the best regards, Aleksey Bragin.

7 6

Re: [ros-dev] [ros-diffs] [jgardou] 57171: [MINGWEX] - mark DllMain as a weak symbol for GCC. - supply a stubbed DllMain for MSVC. - DllMain is optional, and some DLLs don't implement it. That doesn't mean that they have no...
by Timo Kreuzer 27 Aug '12

27 Aug '12

Hi, I don't agree with these changes. If we need a DllEntry in the lib, then we should use the one that is provided by mingw-w64 (all this code is 100% mingw-w64). It simply returns true (thats exactly what the one in MS CRT does) and works for gcc and MSVC. Also what's the point of DisableThreadLibraryCalls() here? As you wrote yourself, no DllMain only means "I have nothing more to initialize than the CRT". But this disables the CRT thread initializion, too. There is also no need for weak symbols, we can simply call the stub DllMain, since it doesn't (shouldn't) do anything. Regards, Timo Am 27.08.2012 01:31, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Sun Aug 26 23:31:49 2012 > New Revision: 57171 > > URL: http://svn.reactos.org/svn/reactos?rev=57171&view=rev > Log: > [MINGWEX] > - mark DllMain as a weak symbol for GCC. > - supply a stubbed DllMain for MSVC. > - DllMain is optional, and some DLLs don't implement it. That doesn't mean that they have no entry point, it means "I have nothing more to initialize than the CRT". > > Added: > trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (with props) > Modified: > trunk/reactos/lib/sdk/crt/msvcrtex.cmake > trunk/reactos/lib/sdk/crt/startup/crtdll.c > > Modified: trunk/reactos/lib/sdk/crt/msvcrtex.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/msvcrtex.cmake… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/msvcrtex.cmake [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -66,7 +66,9 @@ > endif() > > if(MSVC) > - list(APPEND MSVCRTEX_SOURCE startup/mscmain.c) > + list(APPEND MSVCRTEX_SOURCE > + startup/mscmain.c > + startup/mscdllmain.c) > else() > list(APPEND MSVCRTEX_SOURCE startup/gccmain.c) > endif() > > Modified: trunk/reactos/lib/sdk/crt/startup/crtdll.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/crtdll… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] (original) > +++ trunk/reactos/lib/sdk/crt/startup/crtdll.c [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -50,7 +50,19 @@ > > extern int mingw_app_type; > > +/* > + * It is possible that a DLL provides no DllMain entry point. > + * Mark it as a weak symbol for GCC. > + * Tests show that at link time, MSVC looks for a function first in the object files provided, and then > + * in the libraries. This means that we must provide a basic implementation in msvcrtex, which will be used > + * if none is found in the object files provided to link.exe. > + * This also means that we can't rely on a DllMain function implemented in a static library when linking a DLL. > + */ > +#ifdef __GNUC__ > +extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) __attribute__((weak)); > +#else > extern WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved); > +#endif > > extern WINBOOL WINAPI DllEntryPoint (HANDLE, DWORD, LPVOID); > > @@ -198,10 +210,12 @@ > } > if (dwReason == DLL_PROCESS_ATTACH) > __main (); > - retcode = DllMain(hDllHandle,dwReason,lpreserved); > + if(DllMain) > + retcode = DllMain(hDllHandle,dwReason,lpreserved); > if (dwReason == DLL_PROCESS_ATTACH && ! retcode) > { > - DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > + if(DllMain) > + DllMain (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > DllEntryPoint (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > _CRT_INIT (hDllHandle, DLL_PROCESS_DETACH, lpreserved); > } > > Added: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/startup/mscdll… > ============================================================================== > --- trunk/reactos/lib/sdk/crt/startup/mscdllmain.c (added) > +++ trunk/reactos/lib/sdk/crt/startup/mscdllmain.c [iso-8859-1] Sun Aug 26 23:31:49 2012 > @@ -1,0 +1,11 @@ > +#include <oscalls.h> > +#define _DECL_DLLMAIN > +#include <process.h> > + > +WINBOOL WINAPI DllMain (HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved) > +{ > + /* If the DLL provides no DllMain, then chances are that it doesn't bother with thread initialization */ > + if(dwReason == DLL_PROCESS_ATTACH) > + DisableThreadLibraryCalls(hDllHandle); > + return TRUE; > +} > > Propchange: trunk/reactos/lib/sdk/crt/startup/mscdllmain.c > ------------------------------------------------------------------------------ > svn:eol-style = native > > >

2 2

Re: [ros-dev] [ros-diffs] [tkreuzer] 57141: [FREELDR] Improve readability of sector calculation
by Timo Kreuzer 27 Aug '12

27 Aug '12

Btw, we are using a lot of hardcoded 512 values here for sector size even though there is a field in fthe Volume structure for that. Is that correct? Am 23.08.2012 14:02, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Thu Aug 23 12:02:30 2012 > New Revision: 57141 > > URL: http://svn.reactos.org/svn/reactos?rev=57141&view=rev > Log: > [FREELDR] > Improve readability of sector calculation > > Modified: > trunk/reactos/boot/freeldr/freeldr/fs/fat.c > > Modified: trunk/reactos/boot/freeldr/freeldr/fs/fat.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/freeldr/freeldr/fs/fa… > ============================================================================== > --- trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] (original) > +++ trunk/reactos/boot/freeldr/freeldr/fs/fat.c [iso-8859-1] Thu Aug 23 12:02:30 2012 > @@ -1338,8 +1338,7 @@ > // > // Seek to right position > // > - Position.HighPart = SectorNumber >> 23; > - Position.LowPart = SectorNumber << 9; > + Position.QuadPart = (ULONGLONG)SectorNumber * 512; > ret = ArcSeek(Volume->DeviceId, &Position, SeekAbsolute); > if (ret != ESUCCESS) > { > > >

3 2

Re: [ros-dev] [ros-diffs] [jgardou] 57160: [OPENGL32_WINETEST] - Sync with wine
by Thomas Faber 26 Aug '12

26 Aug '12

Hi, On 2012-08-26 11:17, jgardou(a)svn.reactos.org wrote: > Log: > [OPENGL32_WINETEST] > - Sync with wine speaking from previous experience, it'd be very nice if the commit message would allow finding the correctly matched Wine version for this easily (i.e. without tedious look-up of what was HEAD on whatever date the commit was). Thanks! Best regards, Thomas

1 0

Good bye RBuild
by Pierre Schweitzer 25 Aug '12

25 Aug '12

Hi, after having finished its 11405th build, the last official RBuild builder has gone offline, forever. The Linux CMake builder has now turned as being the official builder. Thanks RBuild, you served us well :-). Also, the other RBuild builder, the release builder has also gone offline forever. Its hardware was not able to properly handle a ReactOS build, and was hardly upgradable. Daily release builds should replace it any time soon. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

4 4

Re: [ros-dev] [ros-diffs] [akhaldi] 57151: [CMAKE/MSVC] Hermès Bélusca: * Fix a bug in the way we compiled the boot sectors on the x64 build. * Consistently set the mc compiler, like gcc builds. * Use proper variables when ...
by Timo Kreuzer 24 Aug '12

24 Aug '12

What was the bug? I can't figure it out from the changes. Am 24.08.2012 17:36, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Fri Aug 24 15:36:17 2012 > New Revision: 57151 > > URL: http://svn.reactos.org/svn/reactos?rev=57151&view=rev > Log: > [CMAKE/MSVC] > Hermès Bélusca: > * Fix a bug in the way we compiled the boot sectors on the x64 build. > * Consistently set the mc compiler, like gcc builds. > * Use proper variables when referring to the compilers. > See issue #7297 for more details. > > Modified: > trunk/reactos/cmake/msvc.cmake > trunk/reactos/toolchain-msvc.cmake > > Modified: trunk/reactos/cmake/msvc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/msvc.cmake?rev=57151… > ============================================================================== > --- trunk/reactos/cmake/msvc.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/msvc.cmake [iso-8859-1] Fri Aug 24 15:36:17 2012 > @@ -53,12 +53,12 @@ > # We may temporarily use just the global defines, but this is not a solution as some modules (minihal for example) apply additional definitions to source files, so we get an incorrect build of such targets. > get_directory_property(definitions DEFINITIONS) > set(CMAKE_ASM_COMPILE_OBJECT > - "cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> ${definitions} /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > + "<CMAKE_C_COMPILER> /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> ${definitions} /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > "<CMAKE_ASM_COMPILER> /nologo /Cp /Fo<OBJECT> /c /Ta <OBJECT>.tmp") > else() > # NMake Makefiles > set(CMAKE_ASM_COMPILE_OBJECT > - "cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> <DEFINES> /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > + "<CMAKE_C_COMPILER> /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm <FLAGS> <DEFINES> /D__ASM__ /D_USE_ML /EP /c <SOURCE> > <OBJECT>.tmp" > "<CMAKE_ASM_COMPILER> /nologo /Cp /Fo<OBJECT> /c /Ta <OBJECT>.tmp") > endif() > > @@ -67,14 +67,14 @@ > add_compile_flags("/analyze") > elseif(_PREFAST_) > message("PREFAST enabled!") > - set(CMAKE_C_COMPILE_OBJECT "prefast cl ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > + set(CMAKE_C_COMPILE_OBJECT "prefast <CMAKE_C_COMPILER> ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > "prefast LIST") > - set(CMAKE_CXX_COMPILE_OBJECT "prefast cl ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /TP /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > + set(CMAKE_CXX_COMPILE_OBJECT "prefast <CMAKE_CXX_COMPILER> ${CMAKE_START_TEMP_FILE} ${CMAKE_CL_NOLOGO} <FLAGS> <DEFINES> /TP /Fo<OBJECT> -c <SOURCE>${CMAKE_END_TEMP_FILE}" > "prefast LIST") > set(CMAKE_C_LINK_EXECUTABLE > - "cl ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > + "<CMAKE_C_COMPILER> ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > set(CMAKE_CXX_LINK_EXECUTABLE > - "cl ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > + "<CMAKE_CXX_COMPILER> ${CMAKE_CL_NOLOGO} <OBJECTS> ${CMAKE_START_TEMP_FILE} <FLAGS> /Fe<TARGET> -link /implib:<TARGET_IMPLIB> /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <LINK_LIBRARIES>${CMAKE_END_TEMP_FILE}") > endif() > > set(CMAKE_RC_CREATE_SHARED_LIBRARY ${CMAKE_C_CREATE_SHARED_LIBRARY}) > @@ -143,7 +143,7 @@ > # Compile the generated asm stub file > add_custom_command( > OUTPUT ${_asm_stubs_file}.obj > - COMMAND ml /Cp /Fo${_asm_stubs_file}.obj /c /Ta ${_asm_stubs_file} > + COMMAND ${CMAKE_ASM_COMPILER} /Cp /Fo${_asm_stubs_file}.obj /c /Ta ${_asm_stubs_file} > DEPENDS ${_asm_stubs_file}) > else() > # be clear about the "language" > @@ -202,27 +202,28 @@ > endfunction() > > macro(macro_mc FLAG FILE) > - set(COMMAND_MC mc ${FLAG} -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc) > + set(COMMAND_MC ${CMAKE_MC_COMPILER} ${FLAG} -r ${REACTOS_BINARY_DIR}/include/reactos -h ${REACTOS_BINARY_DIR}/include/reactos ${CMAKE_CURRENT_SOURCE_DIR}/${FILE}.mc) > endmacro() > > #pseh workaround > set(PSEH_LIB "pseh") > > -# Use full path for ml when using x64 VS > -if((ARCH MATCHES amd64) AND ($ENV{VCINSTALLDIR})) > +# Use a full path for the x86 version of ml when using x64 VS. > +# It's not a problem when using the DDK/WDK because, in x64 mode, > +# both the x86 and x64 versions of ml are available. > +if((ARCH MATCHES amd64) AND (DEFINED ENV{VCINSTALLDIR})) > set(CMAKE_ASM16_COMPILER $ENV{VCINSTALLDIR}/bin/ml.exe) > else() > set(CMAKE_ASM16_COMPILER ml.exe) > endif() > > function(CreateBootSectorTarget _target_name _asm_file _binary_file _base_address) > - > set(_object_file ${_binary_file}.obj) > set(_temp_file ${_binary_file}.tmp) > > add_custom_command( > OUTPUT ${_temp_file} > - COMMAND cl /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm /D__ASM__ /D_USE_ML /EP /c ${_asm_file} > ${_temp_file} > + COMMAND ${CMAKE_C_COMPILER} /nologo /X /I${REACTOS_SOURCE_DIR}/include/asm /I${REACTOS_BINARY_DIR}/include/asm /D__ASM__ /D_USE_ML /EP /c ${_asm_file} > ${_temp_file} > DEPENDS ${_asm_file}) > > add_custom_command( > > Modified: trunk/reactos/toolchain-msvc.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/toolchain-msvc.cmake?rev=5… > ============================================================================== > --- trunk/reactos/toolchain-msvc.cmake [iso-8859-1] (original) > +++ trunk/reactos/toolchain-msvc.cmake [iso-8859-1] Fri Aug 24 15:36:17 2012 > @@ -6,6 +6,7 @@ > # which compilers to use for C and C++ > set(CMAKE_C_COMPILER cl) > set(CMAKE_CXX_COMPILER cl) > +set(CMAKE_MC_COMPILER mc) > set(CMAKE_RC_COMPILER rc) > if(${ARCH} MATCHES amd64) > set(CMAKE_ASM_COMPILER ml64) > > >

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 57124: [WINED3D] - MSVC needs INFINITY and NAN from wine/port.h. It can't be included from a header Will be sent upstream
by Thomas Faber 24 Aug '12

24 Aug '12

Hi, On 2012-08-21 15:38, jgardou(a)svn.reactos.org wrote: > URL:http://svn.reactos.org/svn/reactos?rev=57124&view=rev > Log: > [WINED3D] > - MSVC needs INFINITY and NAN from wine/port.h. > It can't be included from a header > Will be sent upstream can you explain what's wrong with including it from a header? I was under the impression we had fixed the infinity/nan stuff properly on Wine's side by adding it all to port.h. Thanks! -Thomas

3 3

Re: [ros-dev] [ros-diffs] [jgardou] 57129: [WIN32K] - Use the right surface for direct DCs in DIB transfer functions It could have changed with a display settings change
by Timo Kreuzer 22 Aug '12

22 Aug '12

Hmmmmmmm.... I don't think that this is a good idea. We must call DC_vPrepareForBlit to lock the surfaces, otherwise we run into race conditions. And we should really also care for the mouse cursor, otherwise we might make it unhappy. Anyway, I don't care about this code, since I already rewrote it :D Anyway, I think it's time to ASSERT device locks. Am 22.08.2012 18:45, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Wed Aug 22 16:45:49 2012 > New Revision: 57129 > > URL: http://svn.reactos.org/svn/reactos?rev=57129&view=rev > Log: > [WIN32K] > - Use the right surface for direct DCs in DIB transfer functions > It could have changed with a display settings change > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dibobj.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dibobj.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dibobj.c [iso-8859-1] Wed Aug 22 16:45:49 2012 > @@ -447,8 +447,16 @@ > DC_UnlockDc(pDC); > goto Exit2; > } > - > - pSurf = pDC->dclevel.pSurface; > + > + /* > + * Select the right surface. > + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't > + * care about mouse, visible region or brushes in this API. > + */ > + if(pDC->dctype == DCTYPE_DIRECT) > + pSurf = pDC->ppdev->pSurface; > + else > + pSurf = pDC->dclevel.pSurface; > if (!pSurf) > { > DC_UnlockDc(pDC); > @@ -1113,7 +1121,15 @@ > goto cleanup; > } > > - psurfDst = pdc->dclevel.pSurface; > + /* > + * Select the right surface. > + * NOTE: we don't call DC_vPrepareDCsForBlit, because we don't > + * care about mouse, visible region or brushes in this API. > + */ > + if(pdc->dctype == DCTYPE_DIRECT) > + psurfDst = pdc->ppdev->pSurface; > + else > + psurfDst = pdc->dclevel.pSurface; > if (!psurfDst) > { > // CHECKME > > >

2 1

Re: [ros-dev] [ros-diffs] [fireball] 57119: [CRT] - Use wine's wctype table in CRT for iswctype() function. Previous implementation was returning incorrect information for non-Latin characters. Problem found and fixed by Se...
by Timo Kreuzer 22 Aug '12

22 Aug '12

For me it looks like _pwctype, __p__pwctype and __pwctype_func also need to be fixed. Am 20.08.2012 19:20, schrieb fireball(a)svn.reactos.org: > Author: fireball > Date: Mon Aug 20 17:20:48 2012 > New Revision: 57119 > > URL: http://svn.reactos.org/svn/reactos?rev=57119&view=rev > Log: > [CRT] > - Use wine's wctype table in CRT for iswctype() function. Previous implementation was returning incorrect information for non-Latin characters. Problem found and fixed by Sergey Shamanaev (seven_ro). > - Move wctype.c from libwine to lib/sdk/crt instead of making yet another copy of it (currently there is one more in tools/unicode). Suggested by Amine Khaldi. > See issue #5090 for more details. > > Added: > trunk/reactos/lib/sdk/crt/string/wctype.c > - copied unchanged from r57101, trunk/reactos/lib/3rdparty/libwine/wctype.c > Removed: > trunk/reactos/lib/3rdparty/libwine/wctype.c > Modified: > trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > trunk/reactos/lib/sdk/crt/crt.cmake > trunk/reactos/lib/sdk/crt/string/ctype.c > > [This mail would be too long, it was shortened to contain the URLs only.] > > Modified: trunk/reactos/lib/3rdparty/libwine/CMakeLists.txt > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/CMake… > > Removed: trunk/reactos/lib/3rdparty/libwine/wctype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/3rdparty/libwine/wctyp… > > Modified: trunk/reactos/lib/sdk/crt/crt.cmake > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/crt.cmake?rev=… > > Modified: trunk/reactos/lib/sdk/crt/string/ctype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/string/ctype.c… > > >

1 0

Re: [ros-dev] [ros-diffs] [jimtabor] 57101: [NtUser] - Stop spurious window handle errors and code fixes.
by Thomas Faber 20 Aug '12

20 Aug '12

Hey, On 2012-08-18 23:40, jimtabor(a)svn.reactos.org wrote: > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/user/ntuser/ca… > ============================================================================== > --- trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/user/ntuser/caret.c [iso-8859-1] Sat Aug 18 21:40:49 2012 > @@ -42,14 +42,17 @@ > if(!ThreadQueue || !ThreadQueue->CaretInfo) > return FALSE; > > - pWnd = UserGetWindowObject(ThreadQueue->CaretInfo->hWnd); > co_IntHideCaret(ThreadQueue->CaretInfo); > ThreadQueue->CaretInfo->Bitmap = (HBITMAP)0; > ThreadQueue->CaretInfo->hWnd = (HWND)0; > ThreadQueue->CaretInfo->Size.cx = ThreadQueue->CaretInfo->Size.cy = 0; > ThreadQueue->CaretInfo->Showing = 0; > ThreadQueue->CaretInfo->Visible = 0; > - IntNotifyWinEvent(EVENT_OBJECT_DESTROY, pWnd, OBJID_CARET, CHILDID_SELF, 0); > + if (ThreadQueue->CaretInfo->hWnd) this can never be true, as it was set to 0 above. > + { > + pWnd = UserGetWindowObject(ThreadQueue->CaretInfo->hWnd); > + IntNotifyWinEvent(EVENT_OBJECT_DESTROY, pWnd, OBJID_CARET, CHILDID_SELF, 0); > + } > return TRUE; > } > Best, Thomas

2 1

ReactOS Services partial downtime
by Pierre Schweitzer 19 Aug '12

19 Aug '12

Hi, today, many of our services encountered a long downtime due to an air conditioning issue in the datacenter their running hypervisor is located (you can find more info there: http://hetzner-status.de/ - german). A safety shutdown has been done to preserve our server hardware integrity. The other hypervisor and the other services being in other datacenters, they were not concerned by the issue. Services being concerned: - Mail - SVN - git - web - build master They are now fully back online and operational. Sorry for the inconvenience. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Bug 7247: msvcrt Should Uses SEH and crtdll Does Not
by James Tabor 18 Aug '12

18 Aug '12

Hi, Has anyone seen this bug report? James Bug 7247

1 0

Old bootcd ISO files
by caemyr＠myopera.com 16 Aug '12

16 Aug '12

Dear All Some time ago, due to lack of space on ROS servers, a large number of old ISO files for prebuilt revisions had to be deleted. I was only able to pull a limited number of them. Right now, while hunting a regression in late rev 3xxxx, i`m heavily limited due to lack of ISOs. For a long-term plan, i intend to add a legacy builder, containing all the previous, rbuild-based Build environments, allowing me to build some really old revs. Right now i need to ask for your assistance. If you have any older, OFFICIAL Bootcd ISO files, of revision earlier than 44000, please let me know, be it on irc or by forum PM. We need to compare the revisions first, to avoid duplicates, then i`ll pull them from you onto my server, which will effectively allow our Team to use them if needed. Thanks in advance. -- With best regards Caemyr

1 0

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

16 Aug '12

It seems that any crash in APITESTS on vbox testbot is causing rosautotest to redo from start. We can see this in stdio log: http://build.reactos.org/builders/Windows_AMD64_1%20VBox-Test/builds/6323/s… (just search for "restarting" word). APITESTS are repated and such log as a whole is messing up testman, which is treating it like two submissions for the same revision. It accepts the first one (incomplete due to crash) and rejects the second one, reporting a duplicate: "ERROR! submit(13111, 518, ...) - We already have a result for this test suite in this test run! "Windows_AMD64_1 VBox-Test"" As we all know, we should expect tests to fail and even crash (this is what they are designed for), hence the error is in rosautotest and testman. Rosautotest, strangely, is affected only on vbox, on kvm the apitest crash is not causing a restart of test run. Winetests, if i recall correctly, were never affected in such way. Testman should not reject a submission after its saved up and revision - blocked. I am aware that some will be tempted to comment out the test in question, but this is not a proper solution to this situation. Other apitest will crash in the future, bringing the whole thing back. Same as with regressions, lack of tests due to such issue, will bite us back in the future, when least expected and most needed. This is why I humbly request this issue to be solved properly, once and for all. With best regards ----- Original message ----- From: buildbot(a)reactos.org To: caemyr(a)myopera.com Subject: buildbot failure in ReactOS on Windows_AMD64_1 VBox-Test Date: Tue, 14 Aug 2012 00:23:24 +0000 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/6324 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: 57075 Blamelist: akhaldi BUILD FAILED: failed Cleanup sincerely, -The Buildbot -- With best regards Caemyr

4 7

(no subject)
by saeid 10 Aug '12

10 Aug '12

i cant make the code

4 3

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 hbelusca <hermes.belusca(a)sfr.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |terminedijs(a)yahoo.com -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

Re: [ros-dev] [ros-bugs] [Bug 6035] Abiword 2.8.6: confirmation messagebox without text
by thomas＠parker.iz34.com 09 Aug '12

09 Aug '12

http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 --- Comment #7 from hbelusca <hermes.belusca(a)sfr.fr> 2012-08-09 14:02:29 CET --- According to Edijs, the confirmation message box isn't in top-most position with respect to the Abiword's window : [15:57:09] <Edijus> hbelusca: When save changes dialog appears, change focus to explorer or some other window. http://www.reactos.org/bugzilla/show_bug.cgi?id=6035 [15:57:26] <Edijus> hbelusca: Save changes dialog is not top most. Report it, please. :) [15:59:47] <hbelusca> Edijus: you mean that the confirmation message box of Abiword can "disappear" (ie. go behind another window) ?! [16:00:25] <Edijus> hbelusca: Yeah. Check if it reported or not, before reporting. [16:00:32] <Edijus> Thanks. -- Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug. You are the assignee for the bug. _______________________________________________ Ros-bugs mailing list Ros-bugs(a)reactos.org http://www.reactos.org/mailman/listinfo/ros-bugs

1 0

Re: [ros-dev] [ros-diffs] [tfaber] 57044: [LIBTIFF] - Fix a warning
by Timo Kreuzer 08 Aug '12

08 Aug '12

Hmm, this is not 64 bit safe. Also I don't understand the modification. It doesn't look right. libtiff uses this differently: http://tiff.sourcearchive.com/documentation/4.0.0~beta4/fax2tiff_8c-source.… #if defined(_WIN32) && defined(USE_WIN32_FILEIO) TIFFSetClientdata(faxTIFF, (thandle_t)_get_osfhandle(fileno(in))); #else TIFFSetClientdata(faxTIFF, (thandle_t)fileno(in)); #endif And we don't even seem to use that function at all. Can anyone explain this? Am 04.08.2012 20:19, schrieb tfaber(a)svn.reactos.org: > Author: tfaber > Date: Sat Aug 4 18:19:19 2012 > New Revision: 57044 > > URL: http://svn.reactos.org/svn/reactos?rev=57044&view=rev > Log: > [LIBTIFF] > - Fix a warning > > Modified: > trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > trunk/reactos/dll/3rdparty/libtiff/tif_open.c > > Modified: trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/rosdi… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/rosdiff.patch [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -7,7 +7,7 @@ > { > thandle_t m = tif->tif_clientdata; > +#ifdef USE_WIN32_FILEIO > -+ newvalue = (thandle_t) _get_osfhandle(newvalue); > ++ newvalue = (thandle_t)_get_osfhandle((int)newvalue); > +#endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > Modified: trunk/reactos/dll/3rdparty/libtiff/tif_open.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/3rdparty/libtiff/tif_o… > ============================================================================== > --- trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] (original) > +++ trunk/reactos/dll/3rdparty/libtiff/tif_open.c [iso-8859-1] Sat Aug 4 18:19:19 2012 > @@ -517,7 +517,7 @@ > { > thandle_t m = tif->tif_clientdata; > #ifdef USE_WIN32_FILEIO > - newvalue = (thandle_t) _get_osfhandle(newvalue); > + newvalue = (thandle_t)_get_osfhandle((int)newvalue); > #endif /* USE_WIN32_FILEIO */ > tif->tif_clientdata = newvalue; > return m; > > >

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 57009: [NTOSKRNL] Try to fix crash detection in sysreg
by Timo Kreuzer 01 Aug '12

01 Aug '12

Hi I don't exactly know how testman is supposed to detect kernel crashes, by hope was that the crash detection failed, because of the strange characters at the beginning of the line, but that was obviously not the case. Can someone look into it and fix it, we are wasting a lot of testing time due to this. Thanks, Timo Am 31.07.2012 22:58, schrieb tkreuzer(a)svn.reactos.org: > Author: tkreuzer > Date: Tue Jul 31 20:58:37 2012 > New Revision: 57009 > > URL: http://svn.reactos.org/svn/reactos?rev=57009&view=rev > Log: > [NTOSKRNL] > Try to fix crash detection in sysreg > > Modified: > trunk/reactos/ntoskrnl/kdbg/kdb.c > > Modified: trunk/reactos/ntoskrnl/kdbg/kdb.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/kdbg/kdb.c?rev=57… > ============================================================================== > --- trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/kdbg/kdb.c [iso-8859-1] Tue Jul 31 20:58:37 2012 > @@ -1472,12 +1472,12 @@ > > if (BreakPoint->Type == KdbBreakPointSoftware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: EXEC 0x%04x:0x%08x\n", > KdbLastBreakPointNr, TrapFrame->SegCs & 0xffff, TrapFrame->Eip); > } > else if (BreakPoint->Type == KdbBreakPointHardware) > { > - KdbpPrint("Entered debugger on breakpoint #%d: %s 0x%08x\n", > + KdbpPrint("\nEntered debugger on breakpoint #%d: %s 0x%08x\n", > KdbLastBreakPointNr, > (BreakPoint->Data.Hw.AccessType == KdbAccessRead) ? "READ" : > ((BreakPoint->Data.Hw.AccessType == KdbAccessWrite) ? "WRITE" : > @@ -1545,7 +1545,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on unexpected debug trap!\n"); > + KdbpPrint("\nEntered debugger on unexpected debug trap!\n"); > } > } > else if (ExceptionCode == STATUS_BREAKPOINT) > @@ -1560,7 +1560,7 @@ > return kdHandleException; > } > > - KdbpPrint("Entered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > + KdbpPrint("\nEntered debugger on embedded INT3 at 0x%04x:0x%08x.\n", > TrapFrame->SegCs & 0xffff, TrapFrame->Eip - 1); > } > else > @@ -1574,7 +1574,7 @@ > return ContinueType; > } > > - KdbpPrint("Entered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > + KdbpPrint("\nEntered debugger on %s-chance exception (Exception Code: 0x%x) (%s)\n", > FirstChance ? "first" : "last", ExceptionCode, ExceptionString); > > if (ExceptionCode == STATUS_ACCESS_VIOLATION && > > >

1 0

MSVC build breakage
by caemyr＠myopera.com 31 Jul '12

31 Jul '12

Its been over a day since http://build.reactos.org/builders/CMake_x86_MSVCWin%20Debug/builds/1672 Can someone please fix it or revert the guilty revision? Thanks in advance -- With best regards Caemyr

1 0

First Contract Issued
by Zachary Gorden 31 Jul '12

31 Jul '12

The ReactOS Project is proud to announce the first of the development contracts that will be funded by the recent donation campaign. Edijs Kolesnikovics joined the ReactOS development team very recently and has been working extensively with Amine Khaldi and Olaf Siejka to create an application test suite based around the AutoHotkey (AHK) automation system. AutoHotkey is a tool for scripting keyboard and mouse actions in order to automate running of programs on Windows. While the current test suites exercise a considerable amount of functionality, the true test for ReactOS remains when it is used to run applications. As such, Edijs has been working to create tests using AHK to run a variety of applications, starting with those on the Golden Apps list. The basic framework is already in place along with a few tests, but much more can be done to expand the selection of applications tested. As such, the Foundation has elected to grant Edijs a development contract to develop additional tests. The project congratulates Edijs on a job well done so far, and would also like to thank Amine, Olaf, and the AHK developers for their help mentoring and advising Edijs. Contract Details Time: 84 hours minimum Wage: €168 Expected Duration: 1 month Objective: Within the designated time period, develop as many AHK test scripts for applications to be used with the automated regression testing as possible. The intended goal is to have at least all remaining Golden Apps testable. This project seeks to help developers catch regressions more quickly so that stabilizing ReactOS for releases becomes less time consuming. This task will be monitored by Amine Khaldi. Sidenote: Due to a variety of circumstances unrelated to the donation campaign, Edijs' contract wage is significantly lower than what would be the standard contract wage for the project.

1 0

Re: [ros-dev] [ros-diffs] [akhaldi] 56973: [CLASSPNP] * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its ...
by Timo Kreuzer 29 Jul '12

29 Jul '12

While this works for us, we should consider trying to get this feature back. When it's considered for removal, then they obviously "fixed" something now that noone needs (and that makes absolutely no sense at all), while the feature as it was before is very useful to compile 3rd party code for Windows. One possibility (since we compile gcc ourselves anyway), is finding out where they "fixed" it and revert that revision for our builds. If they completely remove it, we rename the option and send the old code in as a new feature for MSVC compatibility ;-) Am 29.07.2012 03:49, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Sun Jul 29 01:49:24 2012 > New Revision: 56973 > > URL: http://svn.reactos.org/svn/reactos?rev=56973&view=rev > Log: > [CLASSPNP] > * Explicitly mark the functions as stdcall (NTAPI).. -mrtd changes the default calling convention, but name-decoration isn't affected by this. The -mrtd feature has its origin in some older linux-code-mode, and it's considered for removal in GCC 4.8. > * Fix some warnings. > > Modified: > trunk/reactos/drivers/storage/classpnp/CMakeLists.txt > trunk/reactos/drivers/storage/classpnp/autorun.c > trunk/reactos/drivers/storage/classpnp/class.c > trunk/reactos/drivers/storage/classpnp/classp.h > trunk/reactos/drivers/storage/classpnp/classwmi.c > trunk/reactos/drivers/storage/classpnp/clntirp.c > trunk/reactos/drivers/storage/classpnp/create.c > trunk/reactos/drivers/storage/classpnp/dictlib.c > trunk/reactos/drivers/storage/classpnp/lock.c > trunk/reactos/drivers/storage/classpnp/obsolete.c > trunk/reactos/drivers/storage/classpnp/power.c > trunk/reactos/drivers/storage/classpnp/retry.c > trunk/reactos/drivers/storage/classpnp/utils.c > trunk/reactos/drivers/storage/classpnp/xferpkt.c >

2 2

Monthly meeting - July 2012
by Aleksey Bragin 26 Jul '12

26 Jul '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 26th of July, 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. As usual, volunteers are welcome. he agenda will be posted shortly before the meeting, suggestions are welcome (send them to my email as usual). With the best regards, Aleksey Bragin.

4 3

Re: [ros-dev] July Meeting- May I come?
by Ben Rossington 26 Jul '12

26 Jul '12

May I attend? I am not a developer, nor do I know the way these types of meetings take place. I would like to observe and possibly take notes for PR releases. I apologize for my late request; I just signed up for this 'dev list'. If nothing else, could someone send me the log from the meeting? Thank you in advance. :) Ben Rossington On Wed, Jul 25, 2012 at 8:00 AM, <ros-dev-request(a)reactos.org> wrote: > Send Ros-dev mailing list submissions to > ros-dev(a)reactos.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.reactos.org/mailman/listinfo/ros-dev > or, via email, send a message with subject or body 'help' to > ros-dev-request(a)reactos.org > > You can reach the person managing the list at > ros-dev-owner(a)reactos.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ros-dev digest..." > > > Today's Topics: > > 1. Re: Monthly meeting - July 2012 (Javier Agust?n Fern?ndez Arroyo) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 24 Jul 2012 20:48:25 +0200 > From: Javier Agust?n Fern?ndez Arroyo <elhoir(a)gmail.com> > To: ReactOS Development List <ros-dev(a)reactos.org> > Subject: Re: [ros-dev] Monthly meeting - July 2012 > Message-ID: > < > CAAHf8rfhEmOvydFSfJPrY1Y3ArPZU8oeAr4as0tQ_Fn1pKwenA(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > hi there > im on holydays, so i wont be at the meeting > > Sorry, > > On Tue, Jul 24, 2012 at 11:52 AM, Sylvain Petreolle <spetreolle(a)yahoo.fr > >wrote: > > > I may be unable to attend this meeting. > > I don't know if www/IRC will be available at my holidays place. > > > > Kind regards, > > Sylvain Petreolle > > > > ------------------------------ > > *De :* Aleksey Bragin <aleksey(a)reactos.org> > > *? :* ReactOS Development List <ros-dev(a)reactos.org> > > *Envoy? le :* Mardi 24 juillet 2012 11h10 > > *Objet :* [ros-dev] Monthly meeting - July 2012 > > > > Hello, > > Let me invite you to the monthly status meeting taking place last > Thursday > > of this month, 26th of July, 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. As usual, volunteers are welcome. > > > > he agenda will be posted shortly before the meeting, suggestions are > > welcome (send them to my email as usual). > > > > With the best regards, > > Aleksey Bragin. > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > > > > > > > _______________________________________________ > > Ros-dev mailing list > > Ros-dev(a)reactos.org > > http://www.reactos.org/mailman/listinfo/ros-dev > > >

3 3

Re: [ros-dev] [ros-diffs] [dreimer] 56956: Update rapps to recent versions. FF 3.6 and Thunderbird 3 is no more and thus is hosted on the same spot as the older FF versions are. Fox Audio is updated to 0.9.1 including head ...
by Pierre Schweitzer 24 Jul '12

24 Jul '12

Hi, FireFox 3.0.19 can be found here: ftp://archive.mozilla.org/pub/firefox/releases/3.0.19-real-real/win32/en-US… I definitely don't see why we should host it. This link won't change (since it's Mozilla archive). Why uploading Click-N-Type on our server while they provide a link that won't change with version upgrade: http://cnt.lakefolks.com/CNTzip.exe Once again, I definitely don't see why we should host it. Same with FireFox 3.6.28: ftp://archive.mozilla.org/pub/firefox/releases/3.6.28/win32/en-US/Firefox%2… So, there's no reason why we should host it. TotalCommander can be found on an official mirror site here: http://www.slo.ru/download/total_commander/tcm80x32.exe Since it's a shareware software, I see no reason why we should host it. Furthermore, it might cause issues with license. Finally, as for the rest, Thunderbird 3.1.20 can be found here: ftp://archive.mozilla.org/pub/thunderbird/releases/3.1.20/win32/en-US/Thund… So, I definitely don't see why we should host it. Please delete all the the files above from our server, and use the links I provided. Only host applications that we cannot find in a TRUSTED place, or applications that we ship with our own modifications. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

2 4

Re: [ros-dev] [ros-diffs] [jgardou] 56951: [WIN32SS/NTGDI] - Do not assume that DC has a valid surface attached in GreExtTextOutW
by Timo Kreuzer 23 Jul '12

23 Jul '12

I don't think it makes sense to draw text into the default bitmap :) Am 23.07.2012 17:35, schrieb jgardou(a)svn.reactos.org: > Author: jgardou > Date: Mon Jul 23 15:35:42 2012 > New Revision: 56951 > > URL: http://svn.reactos.org/svn/reactos?rev=56951&view=rev > Log: > [WIN32SS/NTGDI] > - Do not assume that DC has a valid surface attached in GreExtTextOutW > > Modified: > trunk/reactos/win32ss/gdi/ntgdi/freetype.c > > Modified: trunk/reactos/win32ss/gdi/ntgdi/freetype.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/freetype… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/freetype.c [iso-8859-1] Mon Jul 23 15:35:42 2012 > @@ -3391,6 +3391,7 @@ > DC_vPrepareDCsForBlit(dc, DummyRect, NULL, DummyRect); > > psurf = dc->dclevel.pSurface ; > + if(!psurf) psurf = psurfDefaultBitmap; > SurfObj = &psurf->SurfObj ; > > EXLATEOBJ_vInitialize(&exloRGB2Dst, &gpalRGB, psurf->ppal, 0, 0, 0); > > >

1 0

Re: [ros-dev] [ros-diffs] [jgardou] 56947: [WIN32SS/GDI]
by Jérôme Gardou 23 Jul '12

23 Jul '12

OOPS.. Sorry. Changelog should have been: [WIN32SS/NTGDI] - Associate NULL surface for newly created memory DCs. jgardou(a)svn.reactos.org a écrit : > Author: jgardou > Date: Mon Jul 23 10:12:53 2012 > New Revision: 56947 > > URL: http://svn.reactos.org/svn/reactos?rev=56947&view=rev > Log: > [WIN32SS/GDI] > > Modified: > trunk/reactos/win32ss/gdi/eng/engbrush.c > trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c > trunk/reactos/win32ss/gdi/ntgdi/dclife.c > trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > > Modified: trunk/reactos/win32ss/gdi/eng/engbrush.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/eng/engbrush.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/eng/engbrush.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -67,6 +67,9 @@ > pebo->crCurrentText = pdc->pdcattr->crForegroundClr; > > pebo->psurfTrg = pdc->dclevel.pSurface; > + /* We are initializing for a new memory DC */ > + if(!pebo->psurfTrg) > + pebo->psurfTrg = psurfDefaultBitmap; > ASSERT(pebo->psurfTrg); > ASSERT(pebo->psurfTrg->ppal); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/bitblt.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitblt.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/bitblt.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -807,9 +807,11 @@ > SURFACE *psurf; > POINTL BrushOrigin; > BOOL ret; > - PBRUSH pbrush = pebo->pbrush; > + PBRUSH pbrush; > > ASSERT(pebo); > + pbrush = pebo->pbrush; > + ASSERT(pbrush); > > FIXUP_ROP(dwRop); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/bitmaps.… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/bitmaps.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -259,6 +259,7 @@ > DIBSECTION dibs; > INT Count; > PSURFACE psurf = Dc->dclevel.pSurface; > + if(!psurf) psurf = psurfDefaultBitmap; > Count = BITMAP_GetObject(psurf, sizeof(dibs), &dibs); > > if (Count == sizeof(BITMAP)) > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dclife.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dclife.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dclife.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -180,7 +180,7 @@ > pdc->dclevel.pSurface = NULL; > > // FIXME: HACK, because our code expects a surface > - pdc->dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); > + // pdc->dclevel.pSurface = SURFACE_ShareLockSurface(StockObjects[DEFAULT_BITMAP]); > > pdc->erclBounds.left = 0; > pdc->erclBounds.top = 0; > @@ -271,12 +271,9 @@ > pdc->dclevel.ptlBrushOrigin.x = 0; > pdc->dclevel.ptlBrushOrigin.y = 0; > pdc->dcattr.ptlBrushOrigin = pdc->dclevel.ptlBrushOrigin; > - > - /* Initialize EBRUSHOBJs */ > - EBRUSHOBJ_vInit(&pdc->eboFill, pdc->dclevel.pbrFill, pdc); > - EBRUSHOBJ_vInit(&pdc->eboLine, pdc->dclevel.pbrLine, pdc); > + > + /* Init text brush */ > EBRUSHOBJ_vInit(&pdc->eboText, pbrDefaultBrush, pdc); > - EBRUSHOBJ_vInit(&pdc->eboBackground, pbrDefaultBrush, pdc); > > /* Setup fill data */ > pdc->dcattr.jROP2 = R2_COPYPEN; > @@ -424,9 +421,8 @@ > pdc->dclevel.pbrFill = BRUSH_ShareLockBrush(pdc->pdcattr->hbrush); > pdc->dclevel.pbrLine = PEN_ShareLockPen(pdc->pdcattr->hpen); > > - /* Update the EBRUSHOBJs */ > - EBRUSHOBJ_vUpdate(&pdc->eboFill, pdc->dclevel.pbrFill, pdc); > - EBRUSHOBJ_vUpdate(&pdc->eboLine, pdc->dclevel.pbrLine, pdc); > + /* Mark them as dirty */ > + pdc->pdcattr->ulDirty_ |= DIRTY_FILL|DIRTY_LINE; > > /* Allocate or free DC attribute */ > if (ulOwner == GDI_OBJ_HMGR_PUBLIC || ulOwner == GDI_OBJ_HMGR_NONE) > @@ -796,7 +792,7 @@ > DC_bAllocDcAttr(pdcNew); > > // HACK! > - DC_vSelectSurface(pdcNew, psurfDefaultBitmap); > + //DC_vSelectSurface(pdcNew, psurfDefaultBitmap); > > DC_UnlockDc(pdcNew); > > > Modified: trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c… > ============================================================================== > --- trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] (original) > +++ trunk/reactos/win32ss/gdi/ntgdi/dcobjs.c [iso-8859-1] Mon Jul 23 10:12:53 2012 > @@ -230,9 +230,10 @@ > } > > /* Is this a valid palette for this depth? */ > - if ((BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) <= 8 > - && (ppal->flFlags & PAL_INDEXED)) || > - (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) > 8)) > + if ((!pdc->dclevel.pSurface) || > + (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) <= 8 > + && (ppal->flFlags & PAL_INDEXED)) || > + (BitsPerFormat(pdc->dclevel.pSurface->SurfObj.iBitmapFormat) > 8)) > { > /* Get old palette, set new one */ > oldPal = pdc->dclevel.hpal; > @@ -383,7 +384,7 @@ > pdc->dclevel.sizl.cy = 1; > > // HACK > - psurfNew = SURFACE_ShareLockSurface(hbmp); > + //psurfNew = SURFACE_ShareLockSurface(hbmp); > } > else > { > >

1 0

Forced To Clean for Every Line Change!
by James Tabor 23 Jul '12

23 Jul '12

Hi, Around 56843 to 56917 I've been forced to do a mass clean to build the bootcd!!!! This has put a halt for me to work on ReactOS while it takes 33+ minutes to build. Example, makex XXXXX_clean does not work at all even when removing bootcd.iso! Forcing to clean in the main checkout directory! Posted this twice on IRC!

2 2

Meeting with JaixBly
by Aleksey Bragin 21 Jul '12

21 Jul '12

Hello, I want to share that I just had a pleasure to meet Jan "JaixBly" two days ago in Sweden once again. We discussed many ReactOS-related topics, and had fun with a newly delivered Raspberry Pi. We've covered future plans for ReactOS development, testing infrastructure, Samba integration, ARM processors support and many other things. A photo when we took a break from trying to get WiFi working in Raspberry Pi and went outside: http://savepic.org/2407687.jpg Best regards, Aleksey Bragin.

2 1

ReactOS and accessibility
by simon.eigeldinger＠vol.at 19 Jul '12

19 Jul '12

Hi all, My name is Simon and I am blind. I saw in the archives that there was a short subject about accessibility in ReactOS in 2010. The NVDA screenreader was tested there and wasn't working. Can someone tell me the current status of this? Maybe there could be a collaboration between ReactOS devs and NVDA devs to get accessibility in ReactOS? NVDA can be found on www.nvda-project.org. Daily snapshots can be found on http://nvda.sf.net/snapshots/.index.html Just some thoughts. Greetings from Austria, Simon

1 0

Re: [ros-dev] [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSess...
by Ged Murphy 16 Jul '12

16 Jul '12

Fantastic! Smss2 will be happy :) -----Original Message----- From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of ion(a)svn.reactos.org Sent: 16 July 2012 00:42 To: ros-diffs(a)reactos.org Subject: [ros-diffs] [ion] 56906: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSess... Author: ion Date: Sun Jul 15 23:42:27 2012 New Revision: 56906 URL: http://svn.reactos.org/svn/reactos?rev=56906&view=rev Log: [NTOSKRNL]: Implement support for session pool (not yet enabled) and session space (implemented and enabled, but nobody is calling the APIs yet). [NTOSKRNL]: Implement MmMapViewOInSessionSpace, MmUnmapViewInSessionSpace. Win32k needs to use these to we can test them. Modified: trunk/reactos/ntoskrnl/mm/ARM3/i386/init.c trunk/reactos/ntoskrnl/mm/ARM3/miarm.h trunk/reactos/ntoskrnl/mm/ARM3/pfnlist.c trunk/reactos/ntoskrnl/mm/ARM3/pool.c trunk/reactos/ntoskrnl/mm/ARM3/procsup.c trunk/reactos/ntoskrnl/mm/ARM3/section.c

1 0

ROS-Diffs fails on special characters in commit message
by Thomas Faber 12 Jul '12

12 Jul '12

Hi, I've noticed that the ROS-Diffs list (or rather the hook sending to it) consistently fails on revisions that have special chars in their commit message. E.g. there is no message for r56846, r56844, r56763, r56754 etc. (sorry Hermès :p) This goes back as far as r23711 (August 2006), for which the archive shows no message [1]. It apparently did work at some point because r20354 (December 2005) and earlier seem to have ROS-Diffs messages [2] (although possibly because special chars didn't make it into the mails' subjects). Is there a chance this could be fixed? And in the meantime, could I ask the devs to refrain from using special chars? (don't know about you, but the missing messages are quite an annoyance to me, as this is the most convenient platform for code review) Thanks! -Thomas [1] http://www.reactos.org/pipermail/ros-diffs/2006-August/thread.html [2] http://www.reactos.org/pipermail/ros-diffs/2005-December/010731.html

2 1

July 2012 Meeting A Minutes
by Zachary Gorden 10 Jul '12

10 Jul '12

July 2012 Meeting A Minutes 2012-07-05 19:00 UTC dev.reactos.org, #meeting Proceedings =========== * Meeting started at 19:16 UTC by Aleksey Bragin. * Point 0: CD/Product Store * Point 1: Update/Team Plan * Point 2: Website Update * Point 3: Internet Declaration Due to scheduling constraints by some participants, the question of a team store and sale of ReactOS CDs was moved to be the first topic. * Point 0 Ziliang Guo presented the question of CD sales and merchendise sales in general. Amine Khaldi updated the team on the work he and others have done to get storefronts up and going. The primary concern was a lack of decent designs for the stores. Ziliang was tasked with contacting graphic artists he knows in the community to see if this can be remedied. The decision of what to do with the promo CDs was left to Ziliang as well. * Point 1 Aleksey Bragin stated that he intended to help with Jira integration with the new site, which is necessary as a replacement for bugzilla. He also hopes to help with making the build environment more user friendly. Olaf Siejka reported on a variety of regressions in freeldr and the win32 subsystem that he wants fixed as they are blocking further development and testing. Other developers asked for specific reports to be assigned to them and reviewed whether they thought they knew the cause of regressions. Collaboration with the UniATA developer was also discussed, with reports that upstream patches have been accepted and suggestions on further work that can be done. * Point 2 Danny Gotte was not present so this point was skipped. * Point 3 Pierre Schweitzer presented the Internet Declaration (http://www.internetdeclaration.org/freedom), a statement of beliefs drafted by various groups that wish the internet to remain free of censorship and ensure user privacy. Many other organizations have signed onto it and Pierre asked whether the ReactOS Foundation should also do so. This was put to a vote and passed with overwhelming support. * Other Decisions Ziliang requested that all developers be added onto the public relations mailing list. This was approved. Meeting was closed at 20:38 by Aleksey Bragin Minutes were prepared by Ziliang Guo

1 0

Monthly meeting rescheduled
by Aleksey Bragin 05 Jul '12

05 Jul '12

Hello! I was away this week, so the meeting at the usual time got canceled. I propose to conduct meeting next thursday, 5th of July. If someone would not be able to make it - please email me. Regards, Aleksey Bragin.

3 3

ReactOS on ARM, working on the iPhone
by Richardo Stallmanu 05 Jul '12

05 Jul '12

Hello everyone! I just got freeldr working properly (sort of) on the iPhone 4! Currently, I use Apple's iBSS (first stage DFU bootloader), with the go command patched to always branch to 0x41000000. 0x41000000 contains the actual LLB, which is relocated to 0x42000000. The LLB will initialize the ReactOS loader console and ARM loader block, which is sent to FreeLoader, just like on Omap3/Zoom2MDK and Versatile/PB. Time to get ramdisks working. :) http://goput.it/uc5.jpg <- There's your picture. -- winocm

6 7

Meeting Thursday 7/5/2012
by Zachary Gorden 03 Jul '12

03 Jul '12

Barring any last minute hiccups, we expect to have a meeting this Thursday. I am sending out this email because we have a PR topic we need to discuss and I would like as many devs present as possible, and considering Aleksey is likely asleep by now, I felt we needed this out before "tomorrow" to give people enough heads up. Aleksey can make a more formal announcement with other agenda points if he has them. Z

2 2

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 26 Jun '12

26 Jun '12

Hi, we are currently working on the failed server to fix it definitely (we hope). I have set up a temporary solution to ensure ISOs are well stored. They cannot be downloaded though. Sorry about all that troubles. With my best regards, P. Schweitzer On Tue, 2012-06-26 at 08:43 +0000, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/998 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56807 > Blamelist: tfaber > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

7 9

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 25 Jun '12

25 Jun '12

Hi, this is unfortunately due to our entry server to network storage that has crashed once again tonight. All attempts to remotely reboot it failed. A human intervention will be required. It will not happen before several hours. The responsible person for the server has been informed. In case it was not possible to restore the server in a correct time, a workaround solution will be deployed once again. We are sorry for the caused inconvenience. With my best regards, P. Schweitzer Le dimanche 24 juin 2012 à 21:10 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/989 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56800 > Blamelist: ekohl > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 1

Newbie to ReactOS
by Lonnie Cumberland 21 Jun '12

21 Jun '12

Greetings All, I am new to ReactOS but have much experience with with Windows, Linux, etc... as well as programming mainly in C/C++. Recently, I have decided to looking into ReactOS from a learning perspective after which, once the learning curve has been completed, I may try to get involved with some of the development efforts as well as work on some additional projects. >From what I have seen, ReactOS has come a very long ways in its development and is really turning into a special OS to be recognized. I would like to review some of the documentation on the Wiki but had a question regarding an experiment that I wanted to investigate with ReactOS. The question that I wanted to answer is this. What is the absolute minimum size, as relates to booting and OS files that are needed by ReactOS to run, for example, the notepad.exe program? To caveat this, it would include leaving out all of the OS tools, Explorer, Desktop, and absolutely everything that is not clearly needed to run the notepad.exe application. Basically, I would like ReactOS to boot and go directly into the notepad application. The real point here is to investigate what "absolute" minimum files are needed to run a simple application. Sounds a bit crazy, but that is the question that I would like to answer. Any ideas or information related to this would be greatly appreciated. Thanks and have a great day, Lonnie

9 19

ReactOS and MS XP compatability
by Lonnie Cumberland 20 Jun '12

20 Jun '12

Greetings All, I have been reviewing ReactOS on the website and wiki to get a better feel for the project, which I must say is very impressive. >From what I have read, it seems that ReactOS is initially shooting for a drop-in replacement for WindowsXP and beyond which raised a question for me. The site also seems to suggest, for the most part and with the exception of a few core ReactOS files (ie. kernel plus a couple of others), that ReactOS should be 100% compatible with WindowsXP. With this in mind, I wondered this. If I had an old licensed Windows XP disk, which I do, then shouldn't it be possible to use the base core ReactOS files (ie. the minimalist ReactOS configuration like in my previous inquiry to the mailing list) and then use the WindowsXP subsystem core files? I guess what I was wondering, not to detract from the true developments of ReactOS which I like a lot, is would the WindowsXP system files function the same with the ReactOS kernel, and minimal files that were listed by Alex in a previous email. reeldr (ntldr) ntoskrnl hal bootvid kdcom fastfat ramdisk kbdclass i8042prt ntdll smss What I am getting at, is a development that is still forming, but the idea is to utilize ReactOS to allow for the development of a Super Sandbox system that is run in a specialize VM, and which would allow for each application to be run in their own ReactOS VM. Although I am still playing with the idea a lot, it is forming in such a way that would totally isolate each application in a separate VM that is composed of super minimal ReactOS kernel running. Just playing with ideas that I have had for a while, but at the moment, I am still learning about ReactOS so that I will be able to contribute to it soon. Thanks and have a great day, Lonnie

1 0

(no subject)
by Marc Piulachs 18 Jun '12

18 Jun '12

http://secondlife.zhaarteth.net/wp-content/themes/dark-wood/googles.html?fg…

4 4

Re: [ros-dev] [ros-diffs] [akhaldi] 56731: [CMAKE/MIDL] * Alter the way we handle the dlldata generation with midl. This works around the warnings we get about multiple rules to generate proxy.dlldata.c. * Brought to yo by ...
by Timo Kreuzer 16 Jun '12

16 Jun '12

Did you test dependency checking? Am 14.06.2012 13:06, schrieb akhaldi(a)svn.reactos.org: > Author: akhaldi > Date: Thu Jun 14 11:06:23 2012 > New Revision: 56731 > > URL:http://svn.reactos.org/svn/reactos?rev=56731&view=rev > Log: > [CMAKE/MIDL] > * Alter the way we handle the dlldata generation with midl. This works around the warnings we get about multiple rules to generate proxy.dlldata.c. > * Brought to yo by Peter Kummel. > > Modified: > trunk/reactos/cmake/midl-support.cmake > > Modified: trunk/reactos/cmake/midl-support.cmake > URL:http://svn.reactos.org/svn/reactos/trunk/reactos/cmake/midl-support.cma… > ============================================================================== > --- trunk/reactos/cmake/midl-support.cmake [iso-8859-1] (original) > +++ trunk/reactos/cmake/midl-support.cmake [iso-8859-1] Thu Jun 14 11:06:23 2012 > @@ -38,16 +38,17 @@ > get_includes(_includes) > get_defines(_defines) > set(_chain_dependency "") > + set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES GENERATED TRUE) > foreach(_idl_file ${ARGN}) > get_filename_component(_name_we ${_idl_file} NAME_WE) > add_custom_command( > - OUTPUT ${_name_we}_p.c ${_name_we}_p.h proxy.dlldata.c > + OUTPUT ${_name_we}_p.c ${_name_we}_p.h > COMMAND midl ${_includes} ${_defines} ${IDL_FLAGS} /client none /server none /proxy ${_name_we}_p.c /h ${_name_we}_p.h /dlldata proxy.dlldata.c ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file} > DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file} ${_chain_dependency}) > list(APPEND _chain_dependency ${CMAKE_CURRENT_BINARY_DIR}/${_name_we}_p.c) > list(APPEND _chain_dependency ${CMAKE_CURRENT_BINARY_DIR}/${_name_we}_p.h) > + set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/${_idl_file}) > endforeach() > - set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/proxy.dlldata.c PROPERTIES GENERATED TRUE) > endfunction() > > function(add_rpc_files _type) > > >

1 0

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

07 Jun '12

Looks like the crash had locked up the VM hard: loader.c:1019: Test failed: wrong section data (..\..\dll\ntdll\ldr\ldrutils.c:1322) LDR: LdrpMapDll Relocating Image Name C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ldr3C.tmp (10000000 -> 00011000) (..\..\dll\ntdll\ldr\ldrutils.c:1361) Overlapping DLL: Dynamically Allocated Memory loader.c:599: Test failed: got 0x4 != expected 0x1 loader.c:601: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY loader.c:627: Test failed: got 0x4 != expected 0x1 loader.c:629: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY loader.c:645: Test failed: got 0x4 != expected 0x1 loader.c:647: Test failed: 0x4 != PAGE_EXECUTE_WRITECOPY (..\..\ntoskrnl\mm\ARM3\expool.c:274) Entry BlockSize 2, tag fPsR. NextEntry PreviousSize 0, tag *** Fatal System Error: 0x00000019 (0x00000005,0xB0A0EB18,0x00000116,0xB0A0EB08) [7hEntered debugger on embedded INT3 at 0x0008:0x8091ba34. kdb:> bt Eip: <NTOSKRNL.EXE:11ba35 (..\..\lib\rtl\i386\debug_asm.S:46 (_RtlpBreakWithStatusInstruction@0))> Frames: <NTOSKRNL.EXE:80445 (../../ntoskrnl/ke/bug.c:1081 (KeBugCheckWithTf@24))> <NTOSKRNL.EXE:80581 (../../ntoskrnl/ke/bug.c:1405 (KeBugCheckEx@20))> <NTOSKRNL.EXE:964e2 (../../ntoskrnl/mm/ARM3/expool.c:211 (ExpCheckPoolHeader@4))> <NTOSKRNL.EXE:966d3 (../../ntoskrnl/mm/ARM3/expool.c:303 (ExpCheckPoolBlocks@4))> <NTOSKRNL.EXE:96fa5 (../../ntoskrnl/mm/ARM3/expool.c:2215 (ExFreePoolWithTag@8))> <NTOSKRNL.EXE:9755a (../../ntoskrnl/mm/ARM3/expool.c:2359 (ExFreePool@4))> <NTOSKRNL.EXE:bf8da (../../ntoskrnl/mm/freelist.c:556 (MmDereferencePage@4))> <NTOSKRNL.EXE:bf541 (../../ntoskrnl/mm/balance.c:130 (MmReleasePageMemoryConsumer@8))> <NTOSKRNL.EXE:473b (../../ntoskrnl/cc/view.c:913 (CcFreeCachePage))> <NTOSKRNL.EXE:c1501 (../../ntoskrnl/mm/marea.c:745 (MmFreeMemoryArea@16))> <NTOSKRNL.EXE:413c (../../ntoskrnl/cc/view.c:962 (CcRosInternalFreeCacheSegment))> <NTOSKRNL.EXE:6f3d (../../ntoskrnl/cc/view.c:1145 (CcRosDeleteFileCache@8))> <NTOSKRNL.EXE:755f (../../ntoskrnl/cc/view.c:1210 (CcRosDereferenceCache@4))> <NTOSKRNL.EXE:cb47c (../../ntoskrnl/mm/section.c:2672 (MmpDeleteSection@4))> <NTOSKRNL.EXE:da087 (../../ntoskrnl/ob/oblife.c:211 (ObpDeleteObject@8))> <NTOSKRNL.EXE:da11b (../../ntoskrnl/ob/oblife.c:238 (ObpReapObject@4))> <NTOSKRNL.EXE:41e42 (../../ntoskrnl/ex/work.c:162 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))>--- Press q to abort, any other key to continue --- <f88b3db8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f88b7db8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f88bbdb8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))> <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <f889bdb8> <NTOSKRNL.EXE:85cc0 (../../ntoskrnl/ke/queue.c:401 (KeRemoveQueue@12))> <NTOSKRNL.EXE:41df0 (../../ntoskrnl/ex/work.c:145 (ExpWorkerThreadEntryPoint@4))>--- Press q to abort, any other key to continue --- <NTOSKRNL.EXE:f2ca9 (../../ntoskrnl/ps/thread.c:156 (PspSystemThreadStartup@8))> <NTOSKRNL.EXE:103c27 (../../ntoskrnl/ke/i386/thrdini.c:78 (KiThreadStartup@0))> <NTOSKRNL.EXE:f2c4f (../../ntoskrnl/ps/thread.c:625 (PsCreateSystemThread@28))> <415c6d6d> Couldn't access memory at 0x5C6C6E76! kdb:> On Thu, Jun 7, 2012, at 06:23 PM, 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/5866 > > 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: 56702 > Blamelist: ekohl > > BUILD FAILED: exception test > > sincerely, > -The Buildbot > -- With best regards Caemyr

1 0

Debug log problems
by Aleksey Bragin 07 Jun '12

07 Jun '12

Hello, it's time for my periodical rant about debug log mess again. The example below is made using latest VirtualBox 3. Suggestions and questions: 1. usbohci - it's left on intentionally to better aid debugging? Allright, however I think these lines (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbohci/hardware.cpp:1199) Waiting 0 milliseconds for port power up (/srv/buildbot_cmake/full_cmake/build/drivers/usb/usbohci/hardware.cpp:1145) Enabling status change repeated 8 times is a little bit too much. Same about libusb listing statuses of all ports. Which goes on yet another time with EHCI controller. 2. What are these lines? Repeated 14 times (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:2959) ZwOpenFile failed with status 0xc000003a 3. What happened to the floppy driver? (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1579) '\Driver\FLOPPY' initialization failed, status (0xc000000e) (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:61) Deleting driver object '\Driver\FLOPPY' (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:87) HACK: Not unloading the driver image due to critical bugs! (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/io/iomgr/driver.c:1961) IopInitializeDriver() failed (Status c000000e) (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/mm/ARM3/sysldr.c:935) Leaking driver: floppy.sys Fix it? Don't enable it in trunk builds if it's buggy and not fixed? 4. These lines repeated 20 times. (/srv/buildbot_cmake/full_cmake/build/dll/ntdll/ldr/ldrapi.c:811) NtCreateSection() failed (Status 0xc0000022). Why creating section in LdrpVerifyImageMatchesChecksum() failes now? 5. Win32 stage. (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/winsta.c:208) err: Invalid window station handle (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/ntuser.c:161) err: Enter NtUserInitialize(0, 00000000, 00000000) (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/display.c:79) err: InitDisplayDriver (\Device\Video0, \Registry\Machine\System\CurrentControlSet\Hardware Profiles\Current\System\CurrentControlSet\Services\VBE\Device0); What happens here? It's a normal bootup, everyone should see this. Why is invalid window station handle being passed, why do we need NtUserInitialize to produce ERR debug print, along with InitDisplayDriver. Are those errors? If not, then why the hell are they being printed? If yes, then I don't see any info about actual errors. 6. (/srv/buildbot_cmake/full_cmake/build/win32ss/user/ntuser/window.c:2416) err: DestroyWindow AOW AOW? ORLY? 7. MASSIVE portcls spam. I won't even count lines. (/srv/buildbot_cmake/full_cmake/build/drivers/wdm/audio/backpln/portcls/undoc.cpp:281) Calling Node 16 MajorTarget B01EF750 MinorTarget 00000000 PropertySet {45ffaaa0-6e1b-11d0-bcf2-444553540000} PropertyId 4 PropertyFlags 10000200 InstanceSize 0 ValueSize 40 Handler FB24E58A PropertyRequest FF55B5F8 PropertyItemFlags 203 PropertyItemId 4 A few pages of that stuff. Is it really useful for everyone, including automated testing systems? 8. A work queue deadlock. Not a good thing at all (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/ex/work.c:351) EX: Work Queue Deadlock detected: 1 (/srv/buildbot_cmake/full_cmake/build/ntoskrnl/ex/work.c:353) Dynamic threads queued 2 9. ??? All that resulted from my desire to just compare logs attached to the bug report. New log is totally unreadable, I had to spend time figuring out where actually that Live Essentials app was started, what problems it shows, etc. Best regards, Aleksey.

8 11

ReactOS fundraising campaign
by Javier Agustìn Fernàndez Arroyo 06 Jun '12

06 Jun '12

Hello, I can see donations have slowed down too much.... so, reaching 30,000 € goal seems ... quite impossible at the short-term... So, i wanted to ask... what about hiring devs for months? i know its a short period of time, but i feel ReactOS needs it ( and them, also, speaking about devs) asap :)

4 5

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 04 Jun '12

04 Jun '12

Hi, it appears that one of our servers has decided to definitely give up today. A temporary solution has been deployed to ensure ISOs are still stored properly. But, as a side effect, for the moment: - doxygen is not reachable any longer; - cppcheck run is not reachable any longer; - ISOs are not reachable any longer. We're working to get this back as quick as possible. Sorry for the inconvenience. With my best regards, Le samedi 02 juin 2012 à 04:04 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/876 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56689 > Blamelist: jimtabor > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 2

Monthly meeting - May 2012
by Aleksey Bragin 31 May '12

31 May '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 31st of May, 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. As usual, volunteers are welcome. An agenda for the meeting is being worked on now and will be posted later. Please email me your suggestions before the meeting so that the resulting agenda could be compiled beforehand. With the best regards, Aleksey Bragin.

6 9

saeid hoveizi
by saeid 25 May '12

25 May '12

hi. I'm a software engineering student last semester. My final project is translation of an open source o/s to Persian( farsi ). i see reactos and download its source code and Introduce the project to svn buti cant build it. please help me or send some useful tutorials.

1 0

[ros-diffs] [jimtabor] 56655: - Add RegisterClassNameW to ComCtl32.
by James Tabor 24 May '12

24 May '12

Forgot to add this to the next line, patch is based on Nikolay Sivov patch, http://www.winehq.org/pipermail/wine-patches/2009-December/082963.html .

1 0

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Debug: build failed
by Pierre Schweitzer 23 May '12

23 May '12

This was due to a short outage on our side. Problem fixed and build re-queued. Sorry for the inconvenience. Le mercredi 23 mai 2012 à 20:25 +0000, buildbot(a)reactos.org a écrit : > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Debug/builds/838 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 56652 > Blamelist: jimtabor > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

Core developer
by none ofyourbussines 16 May '12

16 May '12

What does it take to be a core developer? Oh and MS-DOS® support can be very good and windows has ms-dos® support too!

9 23

Re: [ros-dev] [ros-builds] Trunk_x86_GCCLin Release: build failed
by Pierre Schweitzer 15 May '12

15 May '12

Hi, we are currently experiencing a downtime on our storage network. We are actively working to get this back as soon as possible. As a side effect, SVN is currently in read-only to prevent any further build to be lost. We are sorry for the inconvenience. With my best regards, On Tue, 2012-05-15 at 12:51 +0000, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder Trunk_x86_GCCLin Release while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/Trunk_x86_GCCLin%20Release/builds/73 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Linux_AMD64_1B > > Build Reason: The Periodic scheduler named 'release' triggered this build > Build Source Stamp: HEAD > Blamelist: > > BUILD FAILED: failed shell > > sincerely, > -The Buildbot > > -- Pierre Schweitzer <pierre(a)reactos.org> System Administrator ReactOS Foundation

1 1

Disappeared thread in forum
by Sven Barth 10 May '12

10 May '12

Hello together! Is it just me or did the complete thread "Feedback 0.3.14" (or so) on the forum by another Sven (I don't remember his full username) disappear from yesterday to today? Even in the "my posts" view my two posts that I have done in that thread aren't listed. Also it seems that the youngest "no working reinstall driver button" thread by naums disappeared as well. They don't appear to have been moved (there is no reference to a moved thread), but they are simply gone. Is this a known problem? Were they somehow hidden? Regards, Sven

3 2

Msdos support
by none ofyourbussines 08 May '12

08 May '12

Dos code skeleton: Dos equ 21h Ret Dos: ;code

1 0

[ros-diffs] [tkreuzer] 56478: [WIN32K] A pointer is not a handle.
by James Tabor 03 May '12

03 May '12

This is wrong, please read co_IntGetPeekMessage,,, @@ -1727,8 +1727,8 @@ 3: handle to the window whose messages are to be retrieved. */ if ( ( !Window || // 1 - ( Window == HWND_BOTTOM && CurrentMessage->Msg.hwnd == NULL ) || // 2 - ( Window != HWND_BOTTOM && Window->head.h == CurrentMessage->Msg.hwnd ) ) && // 3 + ( Window->head.h == HWND_BOTTOM && CurrentMessage->Msg.hwnd == NULL ) || // 2 + ( Window->head.h != HWND_BOTTOM && Window->head.h == CurrentMessage->Msg.hwnd ) ) && // 3 ( ( ( MsgFilterLow == 0 && MsgFilterHigh == 0 ) && CurrentMessage->QS_Flags & QSflags ) || ( MsgFilterLow <= CurrentMessage->Msg.message && MsgFilterHigh >= CurrentMessage->Msg.message ) ) ) { @@ -1790,8 +1790,8 @@ 3: handle to the window whose messages are to be retrieved. */ if ( ( !Window || // 1 - ( Window == HWND_BOTTOM && CurrentMessage->Msg.hwnd == NULL ) || // 2 - ( Window != HWND_BOTTOM && Window->head.h == CurrentMessage->Msg.hwnd ) ) && // 3 + ( Window->head.h == HWND_BOTTOM && CurrentMessage->Msg.hwnd == NULL ) || // 2 + ( Window->head.h != HWND_BOTTOM && Window->head.h == CurrentMessage->Msg.hwnd ) ) && // 3 ( ( ( MsgFilterLow == 0 && MsgFilterHigh == 0 ) && CurrentMessage->QS_Flags & QSflags ) || ( MsgFilterLow <= CurrentMessage->Msg.message && MsgFilterHigh >= CurrentMessage->Msg.message ) ) ) {

2 2

mail
by none ofyourbussines 30 Apr '12

30 Apr '12

My email was hacked so I got a new one reinstalled my computer operating system and got AVG® it will never happen again

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 56442: [PSEH] Fix a serious bug in PSEH that could lead to stack corruption and was causing CSRSS to crash, when large amounts of text were output on the console. Background: PSEH used _...
by Alex Ionescu 29 Apr '12

29 Apr '12

Runner-up to Arty's patch of the year. Best regards, Alex Ionescu On Sun, Apr 29, 2012 at 3:00 AM, <tkreuzer(a)svn.reactos.org> wrote: > Author: tkreuzer > Date: Sat Apr 28 20:00:09 2012 > New Revision: 56442 > > URL: http://svn.reactos.org/svn/reactos?rev=56442&view=rev > Log: > [PSEH] > Fix a serious bug in PSEH that could lead to stack corruption and was causing CSRSS to crash, when large amounts of text were output on the console. > Background: PSEH used __builtin_alloca to allocate an SEH registration frame on the stack on demand, ie only for the first try level. But there are some nasty things with __builtin_alloca: First it DOES NOT - as one might think - free the allocated memory, once the allocation "goes out of scope", like with local variables, but only on function exit. Therefore it cannot normally be used inside a loop. The trick that PSEH used to "fix" this problem, was to save the stack pointer and reset it back at the end. This is quite problematic, since the rest of the code might assume that the stack pointer is still where it was left off after the allocation. The other thing is that __builtin_alloca() can allocate the memory whenever it likes to. It can allocate everything on function entry or not allocate anything at all, when other stack variables that went out of scope have left enough space to be reused. In csrss it now happened that the allocation was done before the stack pointer was saved, > so the memory could not be freed by restoring the old stack pointer value. That lead to slowly eating up the stack since the code was inside a loop. > The allocation is now replaced with a variable sized array. The variable stays in scope until the _SEH2_END and will be automaticall cleaned up by the compiler. This also makes saving and restoring the stack pointer obsolete. > Reliability++ > > Modified: > trunk/reactos/include/reactos/libs/pseh/pseh2.h > > Modified: trunk/reactos/include/reactos/libs/pseh/pseh2.h > URL: http://svn.reactos.org/svn/reactos/trunk/reactos/include/reactos/libs/pseh/… > ============================================================================== > --- trunk/reactos/include/reactos/libs/pseh/pseh2.h [iso-8859-1] (original) > +++ trunk/reactos/include/reactos/libs/pseh/pseh2.h [iso-8859-1] Sat Apr 28 20:00:09 2012 > @@ -192,7 +192,6 @@ > if(_SEHTopTryLevel) \ > { \ > _SEH2LeaveFrame(); \ > - __asm__ __volatile__("mov %0, %%esp" : : "g" (_SEHStackPointer)); \ > } > > #define __SEH_END_SCOPE_CHAIN \ > @@ -219,16 +218,14 @@ > static const int _SEH2ScopeKind = 0; \ > volatile _SEH2TryLevel_t _SEHTryLevel; \ > volatile _SEH2HandleTryLevel_t _SEHHandleTryLevel; \ > - void * _SEHStackPointer; \ > + _SEH2Frame_t _SEH2Frame[_SEHTopTryLevel ? 1 : 0]; \ > volatile _SEH2TryLevel_t * _SEH2TryLevelP; \ > _SEH2Frame_t * const _SEH2FrameP = _SEHTopTryLevel ? \ > - ({ __asm__ __volatile__("mov %%esp, %0" : "=g" (_SEHStackPointer)); __builtin_alloca(sizeof(_SEH2Frame_t)); }) : \ > - _SEHCurFrameP; \ > + _SEH2Frame : _SEHCurFrameP; \ > \ > (void)_SEH2ScopeKind; \ > (void)_SEHTryLevel; \ > (void)_SEHHandleTryLevel; \ > - (void)_SEHStackPointer; \ > (void)_SEH2FrameP; \ > (void)_SEH2TryLevelP; \ > \ > >

1 0

Re: [ros-dev] [ros-diffs] [arty] 56441: [NTOSKRNL] Remove PAGEOPs and use the argument to pass relevant information where needed, including generally a section page table entry or a PFN_NUMBER. In its place, the code looks ...
by Alex Ionescu 28 Apr '12

28 Apr '12

Patch of the Year. Best regards, Alex Ionescu On Sat, Apr 28, 2012 at 10:56 AM, <arty(a)svn.reactos.org> wrote: > Author: arty > Date: Sat Apr 28 02:56:31 2012 > New Revision: 56441 > > URL: http://svn.reactos.org/svn/reactos?rev=56441&view=rev > Log: > [NTOSKRNL] > Remove PAGEOPs and use the argument to pass relevant information where > needed, > including generally a section page table entry or a PFN_NUMBER. > > In its place, the code looks for an MM_WAIT_ENTRY in the appropriate place > and > waits, returning STATUS_MM_RESTART_OPERATION. Rather than copying the > pagein > and CoW operations in the PAGEOP contention case, we just punt back and > restart > the operation, resulting in simpler code. > > Modified: > trunk/reactos/ntoskrnl/CMakeLists.txt > trunk/reactos/ntoskrnl/cache/section/sptab.c > trunk/reactos/ntoskrnl/include/internal/mm.h > trunk/reactos/ntoskrnl/mm/mminit.c > trunk/reactos/ntoskrnl/mm/rmap.c > trunk/reactos/ntoskrnl/mm/section.c > > Modified: trunk/reactos/ntoskrnl/CMakeLists.txt > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/CMakeLists.txt?re… > > ============================================================================== > --- trunk/reactos/ntoskrnl/CMakeLists.txt [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/CMakeLists.txt [iso-8859-1] Sat Apr 28 02:56:31 > 2012 > @@ -229,7 +229,6 @@ > mm/mmfault.c > mm/mminit.c > mm/pagefile.c > - mm/pageop.c > mm/region.c > mm/rmap.c > mm/section.c > > Modified: trunk/reactos/ntoskrnl/cache/section/sptab.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/cache/section/spt… > > ============================================================================== > --- trunk/reactos/ntoskrnl/cache/section/sptab.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/cache/section/sptab.c [iso-8859-1] Sat Apr 28 > 02:56:31 2012 > @@ -215,8 +215,9 @@ > ASSERT(!Entry || IS_SWAP_FROM_SSE(Entry)); > MmDeleteSectionAssociation(PFN_FROM_SSE(OldEntry)); > } else if (IS_SWAP_FROM_SSE(Entry)) { > - ASSERT(!IS_SWAP_FROM_SSE(OldEntry)); > - if (OldEntry) > + ASSERT(!IS_SWAP_FROM_SSE(OldEntry) || > + SWAPENTRY_FROM_SSE(OldEntry) == MM_WAIT_ENTRY); > + if (OldEntry && SWAPENTRY_FROM_SSE(OldEntry) != MM_WAIT_ENTRY) > MmDeleteSectionAssociation(PFN_FROM_SSE(OldEntry)); > } else if (IS_SWAP_FROM_SSE(OldEntry)) { > ASSERT(!IS_SWAP_FROM_SSE(Entry)); > > Modified: trunk/reactos/ntoskrnl/include/internal/mm.h > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/… > > ============================================================================== > --- trunk/reactos/ntoskrnl/include/internal/mm.h [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/include/internal/mm.h [iso-8859-1] Sat Apr 28 > 02:56:31 2012 > @@ -49,7 +49,6 @@ > struct _KTRAP_FRAME; > struct _EPROCESS; > struct _MM_RMAP_ENTRY; > -struct _MM_PAGEOP; > typedef ULONG_PTR SWAPENTRY; > > // > @@ -83,12 +82,6 @@ > #define MM_CORE_DUMP_TYPE_NONE (0x0) > #define MM_CORE_DUMP_TYPE_MINIMAL (0x1) > #define MM_CORE_DUMP_TYPE_FULL (0x2) > - > -#define MM_PAGEOP_PAGEIN (1) > -#define MM_PAGEOP_PAGEOUT (2) > -#define MM_PAGEOP_PAGESYNCH (3) > -#define MM_PAGEOP_ACCESSFAULT (4) > -#define MM_PAGEOP_CHANGEPROTECT (5) > > /* Number of list heads to use */ > #define MI_FREE_POOL_LISTS 4 > @@ -415,37 +408,6 @@ > extern MMPFNLIST MmModifiedPageListHead; > extern MMPFNLIST MmModifiedNoWritePageListHead; > > -typedef struct _MM_PAGEOP > -{ > - /* Type of operation. */ > - ULONG OpType; > - /* Number of threads interested in this operation. */ > - ULONG ReferenceCount; > - /* Event that will be set when the operation is completed. */ > - KEVENT CompletionEvent; > - /* Status of the operation once it is completed. */ > - NTSTATUS Status; > - /* TRUE if the operation was abandoned. */ > - BOOLEAN Abandoned; > - /* The memory area to be affected by the operation. */ > - PMEMORY_AREA MArea; > - ULONG Hash; > - struct _MM_PAGEOP* Next; > - struct _ETHREAD* Thread; > - /* > - * These fields are used to identify the operation if it is against a > - * virtual memory area. > - */ > - HANDLE Pid; > - PVOID Address; > - /* > - * These fields are used to identify the operation if it is against a > - * section mapping. > - */ > - PMM_SECTION_SEGMENT Segment; > - ULONGLONG Offset; > -} MM_PAGEOP, *PMM_PAGEOP; > - > typedef struct _MM_MEMORY_CONSUMER > { > ULONG PagesUsed; > @@ -937,7 +899,7 @@ > PMMSUPPORT AddressSpace, > PMEMORY_AREA MemoryArea, > PVOID Address, > - struct _MM_PAGEOP* PageOp > + PFN_NUMBER Page > ); > > NTSTATUS > @@ -973,7 +935,7 @@ > PMMSUPPORT AddressSpace, > PMEMORY_AREA MArea, > PVOID Address, > - PMM_PAGEOP PageOp > + PFN_NUMBER Page > ); > > /* kmap.c > ********************************************************************/ > @@ -1006,38 +968,6 @@ > PVOID > FASTCALL > MmSafeReadPtr(PVOID Source); > - > -/* pageop.c > ******************************************************************/ > - > -VOID > -NTAPI > -MmReleasePageOp(PMM_PAGEOP PageOp); > - > -PMM_PAGEOP > -NTAPI > -MmGetPageOp( > - PMEMORY_AREA MArea, > - HANDLE Pid, > - PVOID Address, > - PMM_SECTION_SEGMENT Segment, > - ULONGLONG Offset, > - ULONG OpType, > - BOOLEAN First > -); > - > -PMM_PAGEOP > -NTAPI > -MmCheckForPageOp( > - PMEMORY_AREA MArea, > - HANDLE Pid, > - PVOID Address, > - PMM_SECTION_SEGMENT Segment, > - ULONGLONG Offset > -); > - > -VOID > -NTAPI > -MmInitializePageOp(VOID); > > /* process.c > *****************************************************************/ > > @@ -1657,7 +1587,7 @@ > PMMSUPPORT AddressSpace, > PMEMORY_AREA MemoryArea, > PVOID Address, > - struct _MM_PAGEOP *PageOp > + ULONG_PTR Entry > ); > > NTSTATUS > > Modified: trunk/reactos/ntoskrnl/mm/mminit.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/mminit.c?rev=5… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/mminit.c [iso-8859-1] Sat Apr 28 02:56:31 > 2012 > @@ -419,7 +419,6 @@ > MiInitializeUserPfnBitmap(); > MmInitializeMemoryConsumer(MC_USER, MmTrimUserMemory); > MmInitializeRmapList(); > - MmInitializePageOp(); > MmInitSectionImplementation(); > MmInitPagingFile(); > > > Modified: trunk/reactos/ntoskrnl/mm/rmap.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/rmap.c?rev=564… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/rmap.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/rmap.c [iso-8859-1] Sat Apr 28 02:56:31 2012 > @@ -52,7 +52,6 @@ > ULONG Type; > PVOID Address; > PEPROCESS Process; > - PMM_PAGEOP PageOp; > ULONGLONG Offset; > NTSTATUS Status = STATUS_SUCCESS; > > @@ -126,17 +125,20 @@ > Type = MemoryArea->Type; > if (Type == MEMORY_AREA_SECTION_VIEW) > { > + ULONG Entry; > Offset = MemoryArea->Data.SectionData.ViewOffset.QuadPart + > ((ULONG_PTR)Address - > (ULONG_PTR)MemoryArea->StartingAddress); > + > + MmLockSectionSegment(MemoryArea->Data.SectionData.Segment); > > /* > * Get or create a pageop > */ > - PageOp = MmGetPageOp(MemoryArea, NULL, 0, > - MemoryArea->Data.SectionData.Segment, > - Offset, MM_PAGEOP_PAGEOUT, TRUE); > - if (PageOp == NULL) > - { > + Entry = MmGetPageEntrySectionSegment > + (MemoryArea->Data.SectionData.Segment, (PLARGE_INTEGER)&Offset); > + if (Entry && IS_SWAP_FROM_SSE(Entry) && SWAPENTRY_FROM_SSE(Entry) > == MM_WAIT_ENTRY) > + { > + MmUnlockSectionSegment(MemoryArea->Data.SectionData.Segment); > MmUnlockAddressSpace(AddressSpace); > if (Address < MmSystemRangeStart) > { > @@ -145,17 +147,19 @@ > } > return(STATUS_UNSUCCESSFUL); > } > + > + MmSetPageEntrySectionSegment(MemoryArea->Data.SectionData.Segment, > (PLARGE_INTEGER)&Offset, MAKE_SWAP_SSE(MM_WAIT_ENTRY)); > > /* > * Release locks now we have a page op. > */ > + MmUnlockSectionSegment(MemoryArea->Data.SectionData.Segment); > MmUnlockAddressSpace(AddressSpace); > > /* > * Do the actual page out work. > */ > - Status = MmPageOutSectionView(AddressSpace, MemoryArea, > - Address, PageOp); > + Status = MmPageOutSectionView(AddressSpace, MemoryArea, Address, > Entry); > } > else if (Type == MEMORY_AREA_CACHE) > { > > Modified: trunk/reactos/ntoskrnl/mm/section.c > URL: > http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/mm/section.c?rev=… > > ============================================================================== > --- trunk/reactos/ntoskrnl/mm/section.c [iso-8859-1] (original) > +++ trunk/reactos/ntoskrnl/mm/section.c [iso-8859-1] Sat Apr 28 02:56:31 > 2012 > @@ -127,6 +127,7 @@ > BOOLEAN WasDirty; > BOOLEAN Private; > PEPROCESS CallingProcess; > + ULONG_PTR SectionEntry; > } > MM_SECTION_PAGEOUT_CONTEXT; > > @@ -704,43 +705,6 @@ > return nStatus; > } > > -/* Note: Mmsp prefix denotes "Memory Manager Section Private". */ > - > -/* > - * FUNCTION: Waits in kernel mode up to ten seconds for an MM_PAGEOP > event. > - * ARGUMENTS: PMM_PAGEOP which event we should wait for. > - * RETURNS: Status of the wait. > - */ > -static NTSTATUS > -MmspWaitForPageOpCompletionEvent(PMM_PAGEOP PageOp) > -{ > - LARGE_INTEGER Timeout; > -#ifdef __GNUC__ /* TODO: Use other macro to check for suffix to use? */ > - > - Timeout.QuadPart = -100000000LL; // 10 sec > -#else > - > - Timeout.QuadPart = -100000000; // 10 sec > -#endif > - > - return KeWaitForSingleObject(&PageOp->CompletionEvent, 0, KernelMode, > FALSE, &Timeout); > -} > - > - > -/* > - * FUNCTION: Sets the page op completion event and releases the page op. > - * ARGUMENTS: PMM_PAGEOP. > - * RETURNS: In shorter time than it takes you to even read this > - * description, so don't even think about geting a mug of > coffee. > - */ > -static void > -MmspCompleteAndReleasePageOp(PMM_PAGEOP PageOp) > -{ > - KeSetEvent(&PageOp->CompletionEvent, IO_NO_INCREMENT, FALSE); > - MmReleasePageOp(PageOp); > -} > - > - > /* > * FUNCTION: Waits in kernel mode indefinitely for a file object lock. > * ARGUMENTS: PFILE_OBJECT to wait for. > @@ -831,12 +795,12 @@ > PMM_SECTION_SEGMENT Segment, > PLARGE_INTEGER Offset, > BOOLEAN Dirty, > - BOOLEAN PageOut) > -{ > - ULONG_PTR Entry; > + BOOLEAN PageOut, > + ULONG_PTR *InEntry) > +{ > + ULONG_PTR Entry = InEntry ? *InEntry : > MmGetPageEntrySectionSegment(Segment, Offset); > BOOLEAN IsDirectMapped = FALSE; > > - Entry = MmGetPageEntrySectionSegment(Segment, Offset); > if (Entry == 0) > { > DPRINT1("Entry == 0 for MmUnsharePageEntrySectionSegment\n"); > @@ -844,7 +808,7 @@ > } > if (SHARE_COUNT_FROM_SSE(Entry) == 0) > { > - DPRINT1("Zero share count for unshare\n"); > + DPRINT1("Zero share count for unshare (Seg %p Offset %x Page > %x)\n", Segment, Offset->LowPart, PFN_FROM_SSE(Entry)); > KeBugCheck(MEMORY_MANAGEMENT); > } > if (IS_SWAP_FROM_SSE(Entry)) > @@ -913,10 +877,14 @@ > * page without a rmap entry. > */ > MmSetPageEntrySectionSegment(Segment, Offset, Entry); > + if (InEntry) *InEntry = Entry; > + MiSetPageEvent(NULL, NULL); > } > else > { > MmSetPageEntrySectionSegment(Segment, Offset, 0); > + if (InEntry) *InEntry = 0; > + MiSetPageEvent(NULL, NULL); > if (!IsDirectMapped) > { > MmReleasePageMemoryConsumer(MC_USER, Page); > @@ -946,7 +914,9 @@ > } > } > MmSetPageEntrySectionSegment(Segment, Offset, > MAKE_SWAP_SSE(SavedSwapEntry)); > + if (InEntry) *InEntry = MAKE_SWAP_SSE(SavedSwapEntry); > MmSetSavedSwapEntryPage(Page, 0); > + MiSetPageEvent(NULL, NULL); > } > MmReleasePageMemoryConsumer(MC_USER, Page); > } > @@ -959,7 +929,10 @@ > } > else > { > - MmSetPageEntrySectionSegment(Segment, Offset, Entry); > + if (InEntry) > + *InEntry = Entry; > + else > + MmSetPageEntrySectionSegment(Segment, Offset, Entry); > } > return(SHARE_COUNT_FROM_SSE(Entry) > 0); > } > @@ -1232,7 +1205,6 @@ > ULONG_PTR Entry; > ULONG_PTR Entry1; > ULONG Attributes; > - PMM_PAGEOP PageOp; > PMM_REGION Region; > BOOLEAN HasSwapEntry; > PVOID PAddress; > @@ -1270,7 +1242,7 @@ > * Lock the segment > */ > MmLockSectionSegment(Segment); > - > + Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > /* > * Check if this page needs to be mapped COW > */ > @@ -1286,111 +1258,41 @@ > } > > /* > - * Get or create a page operation descriptor > - */ > - PageOp = MmGetPageOp(MemoryArea, NULL, 0, Segment, Offset.LowPart, > MM_PAGEOP_PAGEIN, FALSE); > - if (PageOp == NULL) > - { > - DPRINT1("MmGetPageOp failed\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - > - /* > * Check if someone else is already handling this fault, if so wait > * for them > */ > - if (PageOp->Thread != PsGetCurrentThread()) > + if (Entry && IS_SWAP_FROM_SSE(Entry) && SWAPENTRY_FROM_SSE(Entry) == > MM_WAIT_ENTRY) > { > MmUnlockSectionSegment(Segment); > MmUnlockAddressSpace(AddressSpace); > - Status = MmspWaitForPageOpCompletionEvent(PageOp); > + MiWaitForPageEvent(NULL, NULL); > + MmLockAddressSpace(AddressSpace); > + DPRINT("Address 0x%.8X\n", Address); > + return(STATUS_MM_RESTART_OPERATION); > + } > + > + HasSwapEntry = MmIsPageSwapEntry(Process, Address); > + > + if (HasSwapEntry) > + { > + SWAPENTRY SwapEntry; > /* > - * Check for various strange conditions > + * Is it a wait entry? > */ > - if (Status != STATUS_SUCCESS) > - { > - DPRINT1("Failed to wait for page op, status = %x\n", Status); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - if (PageOp->Status == STATUS_PENDING) > - { > - DPRINT1("Woke for page op before completion\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - MmLockAddressSpace(AddressSpace); > - /* > - * If this wasn't a pagein then restart the operation > - */ > - if (PageOp->OpType != MM_PAGEOP_PAGEIN) > - { > - MmspCompleteAndReleasePageOp(PageOp); > - DPRINT("Address 0x%.8X\n", Address); > - return(STATUS_MM_RESTART_OPERATION); > - } > - > - /* > - * If the thread handling this fault has failed then we don't retry > - */ > - if (!NT_SUCCESS(PageOp->Status)) > - { > - Status = PageOp->Status; > - MmspCompleteAndReleasePageOp(PageOp); > - DPRINT("Address 0x%.8X\n", Address); > - return(Status); > - } > - MmLockSectionSegment(Segment); > - /* > - * If the completed fault was for another address space then set the > - * page in this one. > - */ > - if (!MmIsPagePresent(Process, Address)) > - { > - Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > - HasSwapEntry = MmIsPageSwapEntry(Process, (PVOID)PAddress); > - > - if (PAGE_FROM_SSE(Entry) == 0 || HasSwapEntry) > - { > - /* > - * The page was a private page in another or in our address > space > - */ > - MmUnlockSectionSegment(Segment); > - MmspCompleteAndReleasePageOp(PageOp); > - return(STATUS_MM_RESTART_OPERATION); > - } > - > - Page = PFN_FROM_SSE(Entry); > - > - MmSharePageEntrySectionSegment(Segment, &Offset); > - > - /* FIXME: Should we call MmCreateVirtualMappingUnsafe if > - * (Section->AllocationAttributes & SEC_PHYSICALMEMORY) is true? > - */ > - Status = MmCreateVirtualMapping(Process, > - PAddress, > - Attributes, > - &Page, > - 1); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Unable to create virtual mapping\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - MmInsertRmap(Page, Process, Address); > - } > - MmUnlockSectionSegment(Segment); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > - DPRINT("Address 0x%.8X\n", Address); > - return(STATUS_SUCCESS); > - } > - > - HasSwapEntry = MmIsPageSwapEntry(Process, Address); > - if (HasSwapEntry) > - { > + MmGetPageFileMapping(Process, Address, &SwapEntry); > + > + if (SwapEntry == MM_WAIT_ENTRY) > + { > + MmUnlockSectionSegment(Segment); > + MmUnlockAddressSpace(AddressSpace); > + MiWaitForPageEvent(NULL, NULL); > + MmLockAddressSpace(AddressSpace); > + return STATUS_MM_RESTART_OPERATION; > + } > + > /* > * Must be private page we have swapped out. > */ > - SWAPENTRY SwapEntry; > > /* > * Sanity check > @@ -1445,8 +1347,7 @@ > /* > * Finish the operation > */ > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1476,8 +1377,7 @@ > /* > * Cleanup and release locks > */ > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1518,8 +1418,7 @@ > /* > * Cleanup and release locks > */ > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1539,6 +1438,7 @@ > /* > * Release all our locks and read in the page from disk > */ > + MmSetPageEntrySectionSegment(Segment, &Offset, > MAKE_SWAP_SSE(MM_WAIT_ENTRY)); > MmUnlockSectionSegment(Segment); > MmUnlockAddressSpace(AddressSpace); > > @@ -1573,11 +1473,64 @@ > * Cleanup and release locks > */ > MmLockAddressSpace(AddressSpace); > - PageOp->Status = Status; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(Status); > } > + > + /* > + * Mark the offset within the section as having valid, in-memory > + * data > + */ > + MmLockAddressSpace(AddressSpace); > + MmLockSectionSegment(Segment); > + Entry = MAKE_SSE(Page << PAGE_SHIFT, 1); > + MmSetPageEntrySectionSegment(Segment, &Offset, Entry); > + MmUnlockSectionSegment(Segment); > + > + Status = MmCreateVirtualMapping(Process, > + PAddress, > + Attributes, > + &Page, > + 1); > + if (!NT_SUCCESS(Status)) > + { > + DPRINT1("Unable to create virtual mapping\n"); > + KeBugCheck(MEMORY_MANAGEMENT); > + } > + MmInsertRmap(Page, Process, Address); > + > + MiSetPageEvent(Process, Address); > + DPRINT("Address 0x%.8X\n", Address); > + return(STATUS_SUCCESS); > + } > + else if (IS_SWAP_FROM_SSE(Entry)) > + { > + SWAPENTRY SwapEntry; > + > + SwapEntry = SWAPENTRY_FROM_SSE(Entry); > + > + /* > + * Release all our locks and read in the page from disk > + */ > + MmUnlockSectionSegment(Segment); > + > + MmUnlockAddressSpace(AddressSpace); > + MI_SET_USAGE(MI_USAGE_SECTION); > + if (Process) MI_SET_PROCESS2(Process->ImageFileName); > + if (!Process) MI_SET_PROCESS2("Kernel Section"); > + Status = MmRequestPageMemoryConsumer(MC_USER, TRUE, &Page); > + if (!NT_SUCCESS(Status)) > + { > + KeBugCheck(MEMORY_MANAGEMENT); > + } > + > + Status = MmReadFromSwapPage(SwapEntry, Page); > + if (!NT_SUCCESS(Status)) > + { > + KeBugCheck(MEMORY_MANAGEMENT); > + } > + > /* > * Relock the address space and segment > */ > @@ -1591,76 +1544,7 @@ > Entry1 = MmGetPageEntrySectionSegment(Segment, &Offset); > if (Entry != Entry1) > { > - DPRINT1("Someone changed ppte entry while we slept\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - > - /* > - * Mark the offset within the section as having valid, in-memory > - * data > - */ > - Entry = MAKE_SSE(Page << PAGE_SHIFT, 1); > - MmSetPageEntrySectionSegment(Segment, &Offset, Entry); > - MmUnlockSectionSegment(Segment); > - > - Status = MmCreateVirtualMapping(Process, > - PAddress, > - Attributes, > - &Page, > - 1); > - if (!NT_SUCCESS(Status)) > - { > - DPRINT1("Unable to create virtual mapping\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - MmInsertRmap(Page, Process, Address); > - > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > - DPRINT("Address 0x%.8X\n", Address); > - return(STATUS_SUCCESS); > - } > - else if (IS_SWAP_FROM_SSE(Entry)) > - { > - SWAPENTRY SwapEntry; > - > - SwapEntry = SWAPENTRY_FROM_SSE(Entry); > - > - /* > - * Release all our locks and read in the page from disk > - */ > - MmUnlockSectionSegment(Segment); > - > - MmUnlockAddressSpace(AddressSpace); > - MI_SET_USAGE(MI_USAGE_SECTION); > - if (Process) MI_SET_PROCESS2(Process->ImageFileName); > - if (!Process) MI_SET_PROCESS2("Kernel Section"); > - Status = MmRequestPageMemoryConsumer(MC_USER, TRUE, &Page); > - if (!NT_SUCCESS(Status)) > - { > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - > - Status = MmReadFromSwapPage(SwapEntry, Page); > - if (!NT_SUCCESS(Status)) > - { > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - > - /* > - * Relock the address space and segment > - */ > - MmLockAddressSpace(AddressSpace); > - MmLockSectionSegment(Segment); > - > - /* > - * Check the entry. No one should change the status of a page > - * that has a pending page-in. > - */ > - Entry1 = MmGetPageEntrySectionSegment(Segment, &Offset); > - if (Entry != Entry1) > - { > - DPRINT1("Someone changed ppte entry while we slept\n"); > + DPRINT1("Someone changed ppte entry while we slept (%x vs > %x)\n", Entry, Entry1); > KeBugCheck(MEMORY_MANAGEMENT); > } > > @@ -1687,8 +1571,7 @@ > KeBugCheck(MEMORY_MANAGEMENT); > } > MmInsertRmap(Page, Process, Address); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1715,8 +1598,7 @@ > KeBugCheck(MEMORY_MANAGEMENT); > } > MmInsertRmap(Page, Process, Address); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1735,7 +1617,6 @@ > NTSTATUS Status; > PVOID PAddress; > LARGE_INTEGER Offset; > - PMM_PAGEOP PageOp; > PMM_REGION Region; > ULONG_PTR Entry; > PEPROCESS Process = MmGetAddressSpaceOwner(AddressSpace); > @@ -1799,46 +1680,29 @@ > /* > * Get or create a pageop > */ > - PageOp = MmGetPageOp(MemoryArea, NULL, 0, Segment, Offset.LowPart, > - MM_PAGEOP_ACCESSFAULT, FALSE); > - if (PageOp == NULL) > - { > - DPRINT1("MmGetPageOp failed\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - > + MmLockSectionSegment(Segment); > + Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > + > /* > * Wait for any other operations to complete > */ > - if (PageOp->Thread != PsGetCurrentThread()) > - { > - MmUnlockAddressSpace(AddressSpace); > - Status = MmspWaitForPageOpCompletionEvent(PageOp); > - /* > - * Check for various strange conditions > - */ > - if (Status == STATUS_TIMEOUT) > - { > - DPRINT1("Failed to wait for page op, status = %x\n", Status); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - if (PageOp->Status == STATUS_PENDING) > - { > - DPRINT1("Woke for page op before completion\n"); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - /* > - * Restart the operation > - */ > - MmLockAddressSpace(AddressSpace); > - MmspCompleteAndReleasePageOp(PageOp); > - DPRINT("Address 0x%.8X\n", Address); > - return(STATUS_MM_RESTART_OPERATION); > + if (Entry == SWAPENTRY_FROM_SSE(MM_WAIT_ENTRY)) > + { > + MmUnlockSectionSegment(Segment); > + MmUnlockAddressSpace(AddressSpace); > + MiWaitForPageEvent(NULL, NULL); > + /* > + * Restart the operation > + */ > + MmLockAddressSpace(AddressSpace); > + DPRINT("Address 0x%.8X\n", Address); > + return(STATUS_MM_RESTART_OPERATION); > } > > /* > * Release locks now we have the pageop > */ > + MmUnlockSectionSegment(Segment); > MmUnlockAddressSpace(AddressSpace); > > /* > @@ -1890,11 +1754,10 @@ > MmDeleteRmap(OldPage, Process, PAddress); > MmInsertRmap(NewPage, Process, PAddress); > MmLockSectionSegment(Segment); > - MmUnsharePageEntrySectionSegment(Section, Segment, &Offset, FALSE, > FALSE); > + MmUnsharePageEntrySectionSegment(Section, Segment, &Offset, FALSE, > FALSE, NULL); > MmUnlockSectionSegment(Segment); > > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(Process, Address); > DPRINT("Address 0x%.8X\n", Address); > return(STATUS_SUCCESS); > } > @@ -1904,7 +1767,7 @@ > { > MM_SECTION_PAGEOUT_CONTEXT* PageOutContext; > BOOLEAN WasDirty; > - PFN_NUMBER Page; > + PFN_NUMBER Page = 0; > > PageOutContext = (MM_SECTION_PAGEOUT_CONTEXT*)Context; > if (Process) > @@ -1928,7 +1791,8 @@ > PageOutContext->Segment, > &PageOutContext->Offset, > PageOutContext->WasDirty, > - TRUE); > + TRUE, > + &PageOutContext->SectionEntry); > MmUnlockSectionSegment(PageOutContext->Segment); > } > if (Process) > @@ -1940,21 +1804,17 @@ > { > MmReleasePageMemoryConsumer(MC_USER, Page); > } > - > - DPRINT("PhysicalAddress %x, Address %x\n", Page << PAGE_SHIFT, > Address); > } > > NTSTATUS > NTAPI > MmPageOutSectionView(PMMSUPPORT AddressSpace, > MEMORY_AREA* MemoryArea, > - PVOID Address, > - PMM_PAGEOP PageOp) > + PVOID Address, ULONG_PTR Entry) > { > PFN_NUMBER Page; > MM_SECTION_PAGEOUT_CONTEXT Context; > SWAPENTRY SwapEntry; > - ULONG_PTR Entry; > ULONGLONG FileOffset; > NTSTATUS Status; > PFILE_OBJECT FileObject; > @@ -1973,6 +1833,7 @@ > */ > Context.Segment = MemoryArea->Data.SectionData.Segment; > Context.Section = MemoryArea->Data.SectionData.Section; > + Context.SectionEntry = Entry; > Context.CallingProcess = Process; > > Context.Offset.QuadPart = (ULONG_PTR)Address - > (ULONG_PTR)MemoryArea->StartingAddress > @@ -1983,6 +1844,8 @@ > > FileObject = Context.Section->FileObject; > DirectMapped = FALSE; > + > + MmLockSectionSegment(Context.Segment); > > #ifndef NEWCC > if (FileObject != NULL && > @@ -2035,16 +1898,14 @@ > { > DPRINT("Cannot page out locked section page: 0x%p (RefCount: %d)\n", > Page, MmGetReferenceCountPage(Page)); > - PageOp->Status = STATUS_UNSUCCESSFUL; > - MmspCompleteAndReleasePageOp(PageOp); > + MmSetPageEntrySectionSegment(Context.Segment, &Context.Offset, > Entry); > + MmUnlockSectionSegment(Context.Segment); > return STATUS_UNSUCCESSFUL; > } > > /* > * Prepare the context structure for the rmap delete call. > */ > - MmLockSectionSegment(Context.Segment); > - Entry = MmGetPageEntrySectionSegment(Context.Segment, &Context.Offset); > MmUnlockSectionSegment(Context.Segment); > Context.WasDirty = FALSE; > if (Context.Segment->Image.Characteristics & > IMAGE_SCN_CNT_UNINITIALIZED_DATA || > @@ -2077,9 +1938,12 @@ > } > > MmDeleteAllRmaps(Page, (PVOID)&Context, MmPageOutDeleteMapping); > - MmLockSectionSegment(Context.Segment); > - Entry = MmGetPageEntrySectionSegment(Context.Segment, &Context.Offset); > - MmUnlockSectionSegment(Context.Segment); > + > + /* Since we passed in a surrogate, we'll get back the page entry > + * state in our context. This is intended to make intermediate > + * decrements of share count not release the wait entry. > + */ > + Entry = Context.SectionEntry; > > /* > * If this wasn't a private page then we should have reduced the entry > to > @@ -2117,8 +1981,7 @@ > MmSetPageEntrySectionSegment(Context.Segment, &Context.Offset, > MAKE_SWAP_SSE(SwapEntry)); > MmUnlockSectionSegment(Context.Segment); > MmReleasePageMemoryConsumer(MC_USER, Page); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > } > @@ -2140,8 +2003,7 @@ > MmUnlockSectionSegment(Context.Segment); > } > MmReleasePageMemoryConsumer(MC_USER, Page); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > } > @@ -2165,8 +2027,7 @@ > KeBugCheckEx(MEMORY_MANAGEMENT, Status, (ULONG_PTR)Bcb, > (ULONG_PTR)FileOffset, (ULONG_PTR)Address); > } > #endif > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > else if (!Context.WasDirty && !DirectMapped && !Context.Private) > @@ -2178,13 +2039,12 @@ > KeBugCheckEx(MEMORY_MANAGEMENT, SwapEntry, Page, > (ULONG_PTR)Process, (ULONG_PTR)Address); > } > MmReleasePageMemoryConsumer(MC_USER, Page); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > else if (!Context.WasDirty && Context.Private && SwapEntry != 0) > { > - DPRINT1("Not dirty and private and not swapped (%p:%p)\n", Process, > Address); > + DPRINT("Not dirty and private and not swapped (%p:%p)\n", Process, > Address); > MmSetSavedSwapEntryPage(Page, 0); > MmLockAddressSpace(AddressSpace); > Status = MmCreatePageFileMapping(Process, > @@ -2197,8 +2057,7 @@ > KeBugCheckEx(MEMORY_MANAGEMENT, Status, (ULONG_PTR)Process, > (ULONG_PTR)Address, SwapEntry); > } > MmReleasePageMemoryConsumer(MC_USER, Page); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > > @@ -2253,8 +2112,7 @@ > MmUnlockSectionSegment(Context.Segment); > } > MmUnlockAddressSpace(AddressSpace); > - PageOp->Status = STATUS_UNSUCCESSFUL; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_PAGEFILE_QUOTA); > } > } > @@ -2299,8 +2157,7 @@ > MmSetPageEntrySectionSegment(Context.Segment, &Context.Offset, > Entry); > } > MmUnlockAddressSpace(AddressSpace); > - PageOp->Status = STATUS_UNSUCCESSFUL; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_UNSUCCESSFUL); > } > > @@ -2308,12 +2165,13 @@ > * Otherwise we have succeeded. > */ > DPRINT("MM: Wrote section page 0x%.8X to swap!\n", Page << PAGE_SHIFT); > - MmLockSectionSegment(Context.Segment); > MmSetSavedSwapEntryPage(Page, 0); > if (Context.Segment->Flags & MM_PAGEFILE_SEGMENT || > Context.Segment->Image.Characteristics & IMAGE_SCN_MEM_SHARED) > { > + MmLockSectionSegment(Context.Segment); > MmSetPageEntrySectionSegment(Context.Segment, &Context.Offset, > MAKE_SWAP_SSE(SwapEntry)); > + MmUnlockSectionSegment(Context.Segment); > } > else > { > @@ -2323,9 +2181,11 @@ > if (Context.Private) > { > MmLockAddressSpace(AddressSpace); > + MmLockSectionSegment(Context.Segment); > Status = MmCreatePageFileMapping(Process, > Address, > SwapEntry); > + MmUnlockSectionSegment(Context.Segment); > MmUnlockAddressSpace(AddressSpace); > if (!NT_SUCCESS(Status)) > { > @@ -2335,13 +2195,15 @@ > } > else > { > + MmLockAddressSpace(AddressSpace); > + MmLockSectionSegment(Context.Segment); > Entry = MAKE_SWAP_SSE(SwapEntry); > MmSetPageEntrySectionSegment(Context.Segment, &Context.Offset, > Entry); > - } > - > - MmUnlockSectionSegment(Context.Segment); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MmUnlockSectionSegment(Context.Segment); > + MmUnlockAddressSpace(AddressSpace); > + } > + > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > > @@ -2350,7 +2212,7 @@ > MmWritePageSectionView(PMMSUPPORT AddressSpace, > PMEMORY_AREA MemoryArea, > PVOID Address, > - PMM_PAGEOP PageOp) > + ULONG PageEntry) > { > LARGE_INTEGER Offset; > PROS_SECTION_OBJECT Section; > @@ -2447,12 +2309,16 @@ > */ > if (DirectMapped && !Private) > { > + LARGE_INTEGER SOffset; > ASSERT(SwapEntry == 0); > + SOffset.QuadPart = Offset.QuadPart + Segment->Image.FileOffset; > #ifndef NEWCC > - CcRosMarkDirtyCacheSegment(Bcb, (ULONG)(Offset.QuadPart + > Segment->Image.FileOffset)); > + CcRosMarkDirtyCacheSegment(Bcb, Offset.LowPart); > #endif > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MmLockSectionSegment(Segment); > + MmSetPageEntrySectionSegment(Segment, &Offset, PageEntry); > + MmUnlockSectionSegment(Segment); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > > @@ -2465,8 +2331,7 @@ > if (SwapEntry == 0) > { > MmSetDirtyAllRmaps(Page); > - PageOp->Status = STATUS_UNSUCCESSFUL; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_PAGEFILE_QUOTA); > } > MmSetSavedSwapEntryPage(Page, SwapEntry); > @@ -2481,8 +2346,7 @@ > DPRINT1("MM: Failed to write to swap page (Status was 0x%.8X)\n", > Status); > MmSetDirtyAllRmaps(Page); > - PageOp->Status = STATUS_UNSUCCESSFUL; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_UNSUCCESSFUL); > } > > @@ -2490,8 +2354,7 @@ > * Otherwise we have succeeded. > */ > DPRINT("MM: Wrote section page 0x%.8X to swap!\n", Page << PAGE_SHIFT); > - PageOp->Status = STATUS_SUCCESS; > - MmspCompleteAndReleasePageOp(PageOp); > + MiSetPageEvent(NULL, NULL); > return(STATUS_SUCCESS); > } > > @@ -4039,8 +3902,6 @@ > PBCB Bcb; > LARGE_INTEGER Offset; > SWAPENTRY SavedSwapEntry; > - PMM_PAGEOP PageOp; > - NTSTATUS Status; > PROS_SECTION_OBJECT Section; > PMM_SECTION_SEGMENT Segment; > PMMSUPPORT AddressSpace; > @@ -4057,27 +3918,18 @@ > Section = MemoryArea->Data.SectionData.Section; > Segment = MemoryArea->Data.SectionData.Segment; > > - PageOp = MmCheckForPageOp(MemoryArea, NULL, NULL, Segment, > Offset.LowPart); > - > - while (PageOp) > + Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > + while (Entry && IS_SWAP_FROM_SSE(Entry) && SWAPENTRY_FROM_SSE(Entry) > == MM_WAIT_ENTRY) > { > MmUnlockSectionSegment(Segment); > MmUnlockAddressSpace(AddressSpace); > > - Status = MmspWaitForPageOpCompletionEvent(PageOp); > - if (Status != STATUS_SUCCESS) > - { > - DPRINT1("Failed to wait for page op, status = %x\n", Status); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > + MiWaitForPageEvent(NULL, NULL); > > MmLockAddressSpace(AddressSpace); > MmLockSectionSegment(Segment); > - MmspCompleteAndReleasePageOp(PageOp); > - PageOp = MmCheckForPageOp(MemoryArea, NULL, NULL, Segment, > Offset.LowPart); > - } > - > - Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > + Entry = MmGetPageEntrySectionSegment(Segment, &Offset); > + } > > /* > * For a dirty, datafile, non-private page mark it as dirty in the > @@ -4136,7 +3988,7 @@ > else > { > MmDeleteRmap(Page, Process, Address); > - MmUnsharePageEntrySectionSegment(Section, Segment, &Offset, > Dirty, FALSE); > + MmUnsharePageEntrySectionSegment(Section, Segment, &Offset, > Dirty, FALSE, NULL); > } > } > } > @@ -4208,9 +4060,7 @@ > PMEMORY_AREA MemoryArea; > PMMSUPPORT AddressSpace; > PROS_SECTION_OBJECT Section; > - PMM_PAGEOP PageOp; > - ULONG_PTR Offset; > - PVOID ImageBaseAddress = 0; > + PVOID ImageBaseAddress = 0; > > DPRINT("Opening memory area Process %x BaseAddress %x\n", > Process, BaseAddress); > @@ -4232,40 +4082,6 @@ > } > > MemoryArea->DeleteInProgress = TRUE; > - > - while (MemoryArea->PageOpCount) > - { > - Offset = PAGE_ROUND_UP((ULONG_PTR)MemoryArea->EndingAddress - > (ULONG_PTR)MemoryArea->StartingAddress); > - > - while (Offset) > - { > - Offset -= PAGE_SIZE; > - PageOp = MmCheckForPageOp(MemoryArea, NULL, NULL, > - MemoryArea->Data.SectionData.Segment, > - Offset + > MemoryArea->Data.SectionData.ViewOffset.QuadPart); > - if (PageOp) > - { > - MmUnlockAddressSpace(AddressSpace); > - Status = MmspWaitForPageOpCompletionEvent(PageOp); > - if (Status != STATUS_SUCCESS) > - { > - DPRINT1("Failed to wait for page op, status = %x\n", > Status); > - KeBugCheck(MEMORY_MANAGEMENT); > - } > - MmLockAddressSpace(AddressSpace); > - MmspCompleteAndReleasePageOp(PageOp); > - MemoryArea = MmLocateMemoryAreaByAddress(AddressSpace, > - BaseAddress); > - if (MemoryArea == NULL || > - MemoryArea->Type != MEMORY_AREA_SECTION_VIEW) > - { > - MmUnlockAddressSpace(AddressSpace); > - return STATUS_NOT_MAPPED_VIEW; > - } > - break; > - } > - } > - } > > Section = MemoryArea->Data.SectionData.Section; > > > >

2 1

mail
by none ofyourbussines 27 Apr '12

27 Apr '12

To project admin: My email you said post was annoying The I looked at email records I was not online then it w as job of a hacker but it is fixed now

4 3

Monthly meeting - April 2012
by Aleksey Bragin 27 Apr '12

27 Apr '12

Hello, Let me invite you to the monthly status meeting taking place last Thursday of this month, 26th of April, 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. An agenda for the meeting will be posted when the meeting starts. Please email me your suggestions before the meeting so that the resulting agenda could be compiled beforehand. With the best regards, Aleksey Bragin.

9 13

April 2012 Meeting Minutes
by Amine Khaldi 27 Apr '12

27 Apr '12

April 2012 Meeting Minutes 2012-04-26 19:00 UTC Fezile, #meeting Proceedings =========== * Meeting started at 19:20 UTC by Amine Khaldi. * Point 1: The state of Trunk ----------------------------- * Amine Khaldi mentioned that we still have several regressions to get fixed. Olaf Siejka stressed the fact that developers should actually look into these regressions and fix them, and wondered about the optimal selection process to ensure this. * Timo Kreuzer suggested that we should assign these regressions, to increase the possibility of having them fixed. He explained that the selection should be by the guilty revision first (the revision that triggers the regression), and the author of that revision should at least take a look, and if it's *really* not his fault and he can't fix it, then he can assign it back to ros-bugs. * Amine Khaldi mentioned that at the moment there is no way to know what developers are working on exactly, until they commit, and suggested using bug reports to document the development, so that commits will mention them at the end. * Amine also suggested the following process for the regressions: We assign those regressions to the author of the guilty revision, the developer investigates the regression. If he's able to fix the bug, he changes the bug status to "Assigned" which means he now owns this bug. If he can't fix it, he will document his finding so far (a comment in the bug report) and he assigns the bug to any other developer that he thinks he can fix this, and so on. * Everyone agreed, as a result, that we should assign regressions, and that developers should look at what's assigned to them. * Point 2: Overview of the Atlassian tools ------------------------------------------ * Amine Khaldi gave an overview of what we plan to do with Atlassian products (Jira, FishEye, Crucible, Bamboo..etc) in case people didn't go to their website to read about them and watch their videos (http://www.atlassian.com/). * Olaf Siejka asked about an ETA for the Atlassian tools adoption. Aleksey Bragin mentioned that this will happen in the coming two weeks. * Point 3: Discussing a possible change in the release cycle ------------------------------------------------------------ * Alexander Rechitskiy presented some links from the KDE project about their svn guidelines, commit policy, release schedule, minor point releases...etc. * After a lengthy discussion, the team decided to continue the already started efforts to improve efficiency and minimize regressions (like leveraging Patchbot, the recent major Testman improvements...etc). * Meeting closed at 21:26 UTC by Amine Khaldi. * Minutes written by Amine Khaldi.

1 0

2nd Boot Regional Settings Crash
by James Tabor 27 Apr '12

27 Apr '12

Hi! Did anyone notices this? I think someone on IRC tried to point this out to me..... Tested: rundll32.exe shell32.dll,Control_RunDLL input.dll from the cmd line and it works. user32/windows/message.c:1441) CallWindowProcW Unicode Failed! Msg 273 WndProc 71C25AC8 Entered debugger on first-chance exception (Exception Code: 0xc0000005) (Page Fault) Memory at 0x71C2D810 could not be written: Page protection violation. kdb:> bt Eip: <kernel32.dll:ea7f> client/proc.c:2709 (CreateProcessInternalW@48) Frames: <kernel32.dll:fbd8> client/proc.c:3299 (CreateProcessW@40) <syssetup.DLL:4a9c> syssetup/wizard.c:837 (RunControlPanelApplet) <syssetup.DLL:5c4e> syssetup/wizard.c:914 (LocalePageDlgProc@16) RunControlPanelApplet(hwndDlg, L"rundll32.exe shell32.dll,Control_RunDLL input.dll,@1"); <user32.dll:4dfdc> windows/message.c:1407 (@IntCallWindowProcW@28) <user32.dll:4fd7e> windows/message.c:1747 (CallWindowProcW@20) <user32.dll:36184> windows/dialog.c:1701 (DefDlgProcW@16) <user32.dll:4dfdc> windows/message.c:1407 (@IntCallWindowProcW@28) <user32.dll:4e735> windows/message.c:1667 (IntCallMessageProc@24) <user32.dll:4ea2f> windows/message.c:2266 (SendMessageW@16) <user32.dll:3b57> controls/button.c:424 (ButtonWndProc_common@20) <user32.dll:42a2> controls/button.c:612 (ButtonWndProcW@16) <user32.dll:4dfdc> windows/message.c:1407 (@IntCallWindowProcW@28) <user32.dll:4e735> windows/message.c:1667 (IntCallMessageProc@24) <user32.dll:4fa2b> windows/message.c:1916 (DispatchMessageW@4) <user32.dll:35a65> windows/dialog.c:2591 (IsDialogMessageW@8) <syssetup.DLL:6612> syssetup/wizard.c:2408 (InstallWizard) <syssetup.DLL:2448> syssetup/install.c:957 (InstallReactOS@4) <setup.exe:10cc> <setup.exe:21dc> <setup.exe:149b>--- Press q to abort, any other key to continue --- <setup.exe:14fd> <kernel32.dll:fc4a> <00000000>

2 1

Re: [ros-dev] [ros-diffs] [tkreuzer] 56356: [NTOSKRNL] Fix SepGet*FromDescriptor, returning NULL, when the relative offset is 0. Fixes VMware tools installer.
by Ged Murphy 18 Apr '12

18 Apr '12

> Author: tkreuzer > [NTOSKRNL] > Fix SepGet*FromDescriptor, returning NULL, when the relative offset is 0. > Fixes VMware tools installer. Someone buy that man a beer!

4 3

Does CMake take longer than rbuild
by Marvin Zhang 13 Apr '12

13 Apr '12

Hi guys, I have compiled the whole project and just want to copy ntoskrnl. Here is what I execute: --------------------------------------------------------------------- D:\ReactOS\src\ReactOS-0.3.14-CLT2012>make ntoskrnl_install [COPY] Z:\ReactOS\system32\ntoskrnl.exe Total Build Time: 00:02:04 --------------------------------------------------------------------- I don't know why it takes more than 2 minutes. Is it correct? Thanks.

4 5

The ReactOS Foundation takes part in the IPv6 Launch Day
by Pierre Schweitzer 11 Apr '12

11 Apr '12

Hi, this year, the 6th of June will be once again a special day. This will be the one, the Internet Society has chosen to launch IPv6: http://www.worldipv6launch.org/. It means that starting with this day, all the participant will enable IPv6 and provide it the days, months, years after. The ReactOS Foundation will take part in this event. Currently some services and servers are already available in IPv6, but are not fully maintained. Starting with the 6th of June, major ReactOS services and servers will be available for everybody with IPv6. A roadmap for IPv6 deployment can be found on the ReactOS wiki at: https://www.reactos.org/wiki/IPv6. You will be able to follow all the progress with IPv6. This means that after the 6th of June, any ReactOS developer will be able to work with an IPv6 only on our infrastructure. The transition will be done smoothly. With my best regards, -- Pierre Schweitzer <pierre(a)reactos.org> Systems Administrator ReactOS Foundation

1 0

I'd like to hear about your plans for 0.4.0
by Brent Newland 07 Apr '12

07 Apr '12

I've posted a topic on the Forums to discuss the roadmap to 0.4.0 (whatever it may be). ReactOS has been on the 0.3.x branch for almost six years, and there's been talk of 0.4, so I'd like to hear from any developers on what plans or goals you might have for 0.4.0, whenever it comes out (within 1-2 years?) If you don't currently have any concrete goals or plans (which I've heard is a possibility), then perhaps it would be a good time to start a dialog between developers and the community so we can start to get an idea of what your (ReactOS) expectations are, and what's in store. http://www.reactos.org/forum/viewtopic.php?f=2&t=11114 It could also give you something to point people to when people ask about 0.4.

2 1

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

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

05 Mar '12

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

3 2

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

04 Mar '12

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

2 1

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

04 Mar '12

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

1 0

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

03 Mar '12

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

1 0

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

03 Mar '12

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

1 1

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

02 Mar '12

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

1 0

Cmake result differences
by Bernd Blaauw 01 Mar '12

01 Mar '12

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

5 8

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

01 Mar '12

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

1 0

Rasberry Pi
by Ged Murphy 29 Feb '12

29 Feb '12

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

18 38

KVM regtest CDs available
by Pierre Schweitzer 29 Feb '12

29 Feb '12

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

1 0

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

28 Feb '12

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

1 0

mikeos
by mikey sibert 27 Feb '12

27 Feb '12

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

2 1

February 2012 Meeting Minutes
by Amine Khaldi 27 Feb '12

27 Feb '12

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

13 19

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

25 Feb '12

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

2 1

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

24 Feb '12

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

1 0

Developer meeting
by mikey sibert 24 Feb '12

24 Feb '12

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

2 3

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

23 Feb '12

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

1 0

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

23 Feb '12

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

1 0

Monthly meeting - February
by Aleksey Bragin 23 Feb '12

23 Feb '12

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

4 3

change in email
by mikey sibert 23 Feb '12

23 Feb '12

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

5 6

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

23 Feb '12

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

1 0

system call list
by mikey sibert 23 Feb '12

23 Feb '12

can you send i list of the ones you have implemented

1 0

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

22 Feb '12

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

1 0

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

22 Feb '12

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

1 0

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

22 Feb '12

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

2 1

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

22 Feb '12

Bad pool bugcheck at 3rd stage boot, repeatable at subsequent restarts. Doesn't seem to be present when i issued retesting of that rev. Regards On Wed, Feb 22, 2012, at 12:44 AM, 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/4876 > > 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: 55800 > Blamelist: jgardou > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

1 0

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

22 Feb '12

VBox window hanged hard, at STOPPING. Sysreg could not restart it. Nothing happened even after vbox process being killed. ----- Original message ----- From: buildbot(a)reactos.org To: ros-builds(a)reactos.org Date: Tue, 21 Feb 2012 11:31:15 +0000 Subject: [ros-builds] Windows_AMD64_1 VBox-Test: build failed 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/4844 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: 55770 Blamelist: jgardou BUILD FAILED: failed test sincerely, -The Buildbot -- With best regards Caemyr

2 1

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

21 Feb '12

Yet another CM fsckup: *** Fatal System Error: 0x00000019 (0x00000005,0xE11FF880,0x000000F0,0xE11FF798) at end of 2nd stage. At subsequent reboots: Assertion 'KeyCell->Signature == CM_KEY_NODE_SIGNATURE' failed at P:\Trunk_slave\x86_CMake\build\lib\cmlib\cminit.c line 115 We really need something to fight the pool corruptions, Aleksiej. Testing will be restarted. Best regards On Tue, Feb 21, 2012, at 11:50 AM, 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/4845 > > 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: 55771 > Blamelist: jgardou > > BUILD FAILED: failed test > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

2 1

Re: [ros-dev] [ros-builds] CMake_x86_GCCWin Debug: build failed
by caemyr＠myopera.com 21 Feb '12

21 Feb '12

Another ghost: [100%] Building C object drivers/wdm/audio/sysaudio/CMakeFiles/sysaudio.dir/dispatcher.c.obj Failed to read source file: 0 mingw32-make.exe[3]: *** [boot/freeldr/freeldr/frldr16.bin] Error -4 mingw32-make.exe[2]: *** [boot/freeldr/freeldr/CMakeFiles/freeldr.dir/all] Error 2 mingw32-make.exe[2]: *** Waiting for unfinished jobs.... On Tue, Feb 21, 2012, at 11:36 AM, buildbot(a)reactos.org wrote: > The Buildbot has detected a failed build on builder CMake_x86_GCCWin > Debug while building ReactOS. > Full details are available at: > http://build.reactos.org/builders/CMake_x86_GCCWin%20Debug/builds/2729 > > Buildbot URL: http://build.reactos.org/ > > Buildslave for this Build: Windows_AMD64_1 > > Build Reason: scheduler > Build Source Stamp: 55775 > Blamelist: janderwald > > BUILD FAILED: failed building bootcd > > sincerely, > -The Buildbot > > > -- With best regards Caemyr

1 0

new
by Mikey 20 Feb '12

20 Feb '12

In 25 days I will get a netbook with windows ce 6 to view code, my pda won't edit or view code at least not fast so the new one will be better.

1 0

Re: [ros-dev] Ram/hdd
by Mikey 19 Feb '12

19 Feb '12

Ok I fixed that after sending thh last message that was me on my pda because it is ram powerd not flash powered so when it died the data went away too

1 0

Re: [ros-dev] Ram/hdd
by Mikey 19 Feb '12

19 Feb '12

1. Time machines have not been invented so that's impossible. 2. I don't live in the past so that was stupid 3. I have my date/time done perfectly fine. So next time don't say that to someone knows what they are talking about

4 3

Re: [ros-dev] Ram/hdd
by Mikey 18 Feb '12

18 Feb '12

Ok

1 0

Re: [ros-dev] Ram/hdd
by Mikey 18 Feb '12

18 Feb '12

Ok that was me on my pda I just fixed it

1 0

Re: [ros-dev] Ram/hdd
by Mikey 17 Feb '12

17 Feb '12

I am planning on running because my school pc has 1.72gb of ram but I can't put a new os on physicle disk my parents will get very mad if I install os but not if I run it on cd. Oh bye I have to go to bed in 6 minutes

2 1

Ram/hdd
by Mikey 17 Feb '12

17 Feb '12

I have taken into account the stuff you all sent about system specs since the pc will be mine at the end of my school year I am saving up for: 8gb of ram. Some new hdds of over 80gb I don't know how to add a new cpu, and they are very expensive. Mikey P.s. Will a .iso work to make a live cd or usb boot cd, I know I can do it with linux distros but not ReactOS.

3 2

Re: [ros-dev] Unused mailing lists
by Mikey 16 Feb '12

16 Feb '12

Hello I am new here what are the system minimum specs as I have old system for development. My dad says I get the old system at the ent of my school if I get good grades it has ubuntu 11.10 but it is slow I like to call it u-slow-os 1.6.

6 5

[ros-diffs] [tkreuzer] 55636: [WIN32K] - Small code improvement without functional change for rtlstr functions
by James Tabor 16 Feb '12

16 Feb '12

This should be applied to dll/win32/user32/misc/rtlstr.c,,,, what ReactOS needs is a lib/win32k/rtl/...... James

2 1

Re: [ros-dev] [ros-diffs] [jgardou] 55631: [NTOSKRNL/MM] - use ARM3 allocation for PDE pages. There is now one table for system PDEs, and their pages are not leaked anymore. Also fix bug 5857 (aka mshtml bug). Only for x86 ...
by Aleksey Bragin 16 Feb '12

16 Feb '12

Epic. On 16.02.2012 15:16, jgardou(a)svn.reactos.org wrote: > Author: jgardou > Date: Thu Feb 16 11:16:10 2012 > New Revision: 55631 > > URL: http://svn.reactos.org/svn/reactos?rev=55631&view=rev > Log: > [NTOSKRNL/MM] > - use ARM3 allocation for PDE pages. > There is now one table for system PDEs, and their pages are not leaked anymore. > Also fix bug 5857 (aka mshtml bug). > Only for x86 now. Timo, I think you should do it for amd64 as well. > Thanks for your patience, go back to testing now. > A huge congrats to Cameron and Thomas, without them I wouldn't even have dared touching this code. > > Modified: > trunk/reactos/ntoskrnl/mm/ARM3/virtual.c > trunk/reactos/ntoskrnl/mm/i386/page.c >

2 1

New ros-builds ML
by Pierre Schweitzer 16 Feb '12

16 Feb '12

Hi, due to popular request, a new ML is available (for read-only): ros-builds. This ML will receive notifications sent by buildbot in case of build breakge/tests breakage. More notifications should be added any time soon. For subscription, just go here: http://reactos.org/mailman/listinfo/ros-builds Regards, Pierre

1 0

Re: [ros-dev] Unused mailing lists
by Mikey 16 Feb '12

16 Feb '12

So it will work I got: 1ghz cpu 1gb of ram Thanks for the info

1 0

Unused mailing lists
by Aleksey Bragin 14 Feb '12

14 Feb '12

Hello, during recent discussion, a topic about mailing lists appeared. According to Pierre, we have 6 totally unused mailing lists, which are: ros-cis ros-errors ros-kernel ros-svn-diffs ros-translate ros-foundation I propose to delete all those, maybe except for ros-foundation. Any opinions? WBR, Aleksey Bragin.

3 2

[ros-diffs] [rharabien] 55576: [COMCTL32] - Sync to Wine 1.3.37
by James Tabor 14 Feb '12

14 Feb '12

Hi, Did the diff patch in ComCtl32 get into the sync? We have that 2nd stage keyboard bug again at the start of setup and when it has finished.. James

3 3

Re: [ros-dev] [ros-diffs] [cgutman] 55569: [USBDRV] - Terminate the NT4 USB driver
by Aleksey Bragin 13 Feb '12

13 Feb '12

Historical commit, deserving a nice rev number too! (hmm, 69 maybe viewed by some as nice too, but better let's focus on the "555" part ;)) On 12.02.2012 22:34, cgutman(a)svn.reactos.org wrote: > Author: cgutman > Date: Sun Feb 12 18:34:05 2012 > New Revision: 55569 > > URL: http://svn.reactos.org/svn/reactos?rev=55569&view=rev > Log: > [USBDRV] > - Terminate the NT4 USB driver > > Removed: > trunk/reactos/drivers/usb/nt4compat/ > >

2 1

Testman blacklisting
by Kamil Hornicek 12 Feb '12

12 Feb '12

Hi, as requested I added a blacklisting ability to testman. The purpose of this is to have some meaningful comparison between test runs without completely disabling randomly behaving test sets. This means that blacklisted test are still being run, logged and included in the Totals summary. They won't affect the newly added "nonblacklisted summary" only. The last thing needed before we can actually benefit from this is to go through the tests, find those that give random results and either fix them or add them to the blacklist. Please use this wiki page http://www.reactos.org/wiki/Testman_blacklist to forge the list. Anyone with web repo commit access (that includes me) can then update the config itself. WBR, Kamil

2 2

Announcement RosBE 2.0 for Windows
by Daniel Reimer 12 Feb '12

12 Feb '12

Hi, ok... last but not least, RosBE for Windows Version 2.0 is out too. This is one of the last steps to the upcoming cmake switch with dumping rbuild fully and forever. The setup files can be found here: http://www.reactos.org/wiki/Build_Environment Setup is the same good known NSIS based one for now. Just remove the old BE and let it install it over. CMAKE usage instructions are here:http://reactos.org/wiki/CMake Big thanks for this release goes to Heis and Colin from the Unix BE team, Amine for not killing me taking so long for a release and dralnix and blight_ for doing the first steps to a advanced BE years ago. Miss you, guys ^^ As for Unix one, I fully dump the support for any earlier Version of RosBE Windows starting from NOW. Best regards, Daniel

1 0

RosBE-Unix 2.0 released
by Pierre Schweitzer 10 Feb '12

10 Feb '12

Hi, finally, we are getting closer and closer to CMake switch. RosBE-2.0 release brings supports for CMake and all the changes made in the tool chain. You can find it here: https://sourceforge.net/projects/reactos/files/RosBE-Unix/2.0/ To install it, simply extract the tar.bz2, and then run the RosBE-Builder.sh script. For instructions about how to use CMake in ReactOS, have a look to that wiki page: http://reactos.org/wiki/CMake Regarding this release, I would like to thank Colin Finck who did everything for it, but who have been obliged to let me release his work due to his busy life. RosBE 1.5 is not supported any longer. And I invite everyone to switch to CMake (with RosBE2.0 Windows/Linux). Rbuild deletion is now a matter of days. The countdown for Rbuild deletion has started. Regards, Pierre

1 0

Re: [ros-dev] [ros-diffs] [tkreuzer] 55518: [FREELDR] - Enable new heap code and cleanup the heap, releasing unused memory, before starting reactos - Gives our kernel about 4MB additional memory, which - at the current leak...
by Aleksey Bragin 10 Feb '12

10 Feb '12

I must say, hpoussin proposed to get rid of bget in favor of rtl/heap.c, and I criticized his idea because I had no trust in the old heap code. Would reusing the new code be an option? Or you already invented the "mini-heap" which works good enough? WBR, Aleksey. On 10.02.2012 0:01, tkreuzer(a)svn.reactos.org wrote: > Author: tkreuzer > Date: Thu Feb 9 20:01:10 2012 > New Revision: 55518 > > URL: http://svn.reactos.org/svn/reactos?rev=55518&view=rev > Log: > [FREELDR] > - Enable new heap code and cleanup the heap, releasing unused memory, before starting reactos > - Gives our kernel about 4MB additional memory, which - at the current leak rate - means around 8 minutes longer before it runs out of memory :) > - Using the temp heap for all temporary allocations should increase the amount of saved space > > Removed: > trunk/reactos/boot/freeldr/freeldr/mm/heap.c > trunk/reactos/boot/freeldr/freeldr/rtl/bget.c >

1 0

GSoC 2012
by Colin Finck 07 Feb '12

07 Feb '12

Hi all, The Google Summer of Code 2012 project registration phase is starting in three weeks. Are we going to apply again after our success last year? Who will be available as administrators and mentors? Is anybody already collecting task ideas? Cheers, Colin

9 16

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev