Ros-dev

ros-dev@reactos.org

5790 discussions

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev