- Ros-dev - ReactOS.org

by Ge van Geldorp

I think having to debug Alex's latest breakage (bugcheck at the end of 2nd stage setup) so I can continue debugging one of his earlier breakages (bug 1263) is asking just a bit too much. I'll go do something non-ReactOS related for the next couple of days. GvG

19 years, 8 months

3
5
0 0

Another bug...

by Richard

I think it's time for me to hit up bugzilla, anyways, Firefox setup from mozilla.com no longer works, it just dies, and the 'get firefox' link results in an access denied in the middle of FF setup. Every 3rd or 4th boot ROS also does not have a mouse pointer. It may be frozen, i can't tell. Regressions...Regressions...Regressions... Richard

19 years, 8 months

1
0
0 0

uhhh...

by Richard

When you click 'view GPL' for second stage setup, a license agreement comes up for something called Gnomovision. This should not be the case. I would change it myself but i don't have my svn password handy. Richard

19 years, 8 months

1
0
0 0

Strange Stretch Problem

by James Tabor

Hi all, Can anyone see the problem with this picture? Every time I move the window, it looks like back behind the window, it gets redrawn. Thanks, James

19 years, 8 months

4
8
0 0

Bug in KiFastCallEntry

by Hartmut Birr

Hi, it seems we have a little bug in KiFastCallEntry. It is initialized a trap frame on the stack. It is a trap frame without the v86 segment registers. ESP points to TSS->ESP0 - sizeof(KTRAP_FRAME) + 16. 16 for the missing v86 segment register. ESP is compared with KTHREAD->InitialStack - 0x29c. 0x29c is equal to sizeof(FX_SAVE_AREA) + sizeof(KTRAP_FRAME). If the compare operation fails, it is called BadStack which results in a v86 invalid opcode exception. To bypass this bug, there is added a value of 0x10 to TSS->ESP0 in Ke386InitThreadWithContext. A friend of me has looked to WinXp. He has found a piece of code which is an exact copy of BadStack and he has found a piece of code which looks like this: _KiFastCallEntry: ... /* Use the thread's stack */ mov ebp, [esi+KTHREAD_INITIAL_STACK] ... /* Make space for us on the stack */ sub ebp, 0x29C /* Write the previous mode */ mov byte ptr [esi+KTHREAD_PREVIOUS_MODE], UserMode /* Sanity check */ cmp ebp, esp jnz BadStack ... - Hartmut

19 years, 8 months

1
0
0 0

WMF Bug / SetAbortProc

by M Bealby

In case you've had you're head in the sand recently I'm sure you must know about the recent WMF bug found in all recent versions of Windows. The vulnerable function is in SetAbortProc and can be called from a malicious WMF file as they include executable code by definition. Windows automatically runs this a WMF file when previewing / displaying - including from a web page! WINE is also vulnerable, and still is. However, from a brief look at my svn repo I think ReactOS is safe. SetAbortProc is in gdi32.dll, and our version is well out of sync with WINE. I'm not sure if this is intentional (I don't know which dll's we share directly), but whoever implements this function must be very careful. More info at: http://www.microsoft.com/technet/security/bulletin/ms06-001.mspx They also have a patch there so anyone running Windows on their machine is recommended to patch it immediately. Cheers, Martin

19 years, 8 months

4
3
0 0

Re: [ros-diffs] [ion] 20911: - Fix some nasty context switch bugs:

by Hartmut Birr

ion(a)svn.reactos.org wrote: > - Fix some nasty context switch bugs: > * We did not update the KPCR's stacklimit/initialstack with the new thread's stacklimit/initialstack. > * We always assumed V86 frame bias in KeInitializeThreadContext. > * We did not properly update ESP0 during context switch, to make space for the NPX frame and V86 bias. > * We did not update fs:18h to point to the new TEB. > * We did not clear out GS when switching processes, nor update the TSS's cr3. > * If a new LDT was being updated, we over-wrote EBP (which was supposed to point to the TSS) by the GDT pointer. > * We used a push/pop esp0 hack which hid the fact we never updated esp0. > Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S > Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/ke/i386/ctxswitch.S* > @@ -114,10 +114,6 @@ > > *--*/ > .globl @KiSwapContextInternal@0 > @KiSwapContextInternal@0: > > -#ifdef KDBG > - //jmp SaveTrapFrameForKDB > -SaveTrapFrameForKDB_Return: > -#endif > > > /* Get the PCR. It's faster to use ebx+offset then fs:offset */ > mov ebx, [fs:KPCR_SELF] > @@ -132,24 +128,36 @@ > > cli > > /* Save the initial stack in EAX */ > > - mov eax, [edi+KTHREAD_INITIAL_STACK] > > + mov eax, [esi+KTHREAD_INITIAL_STACK] > Now eax points to the trap frame of the thread we will switch to. > > > + /* Save the stack limit in ecx */ > + mov ecx, [esi+KTHREAD_STACK_LIMIT] > + > + /* Make space for the NPX Frame */ > + sub eax, NPX_FRAME_LENGTH > + > + /* Set the KPCR stack values */ > + mov [ebx+KPCR_INITIAL_STACK], eax > + mov [ebx+KPCR_STACK_LIMIT], ecx > + > > #ifdef CONFIG_SMP > /* Save FPU state if the thread has used it. */ > > + mov ecx, [edi+KTHREAD_INITIAL_STACK] > + sub ecx, NPX_FRAME_LENGTH > > mov dword ptr [ebx+KPCR_NPX_THREAD], 0 > test byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_DIRTY > jz 3f > cmp dword ptr _KeI386FxsrPresent, 0 > je 1f > > - fxsave [eax-SIZEOF_FX_SAVE_AREA] > > + fxsave [ecx] > > jmp 2f > 1: > > - fnsave [eax-SIZEOF_FX_SAVE_AREA] > > + fnsave [ecx] > > 2: > mov byte ptr [edi+KTHREAD_NPX_STATE], NPX_STATE_VALID > 3: > #endif /* CONFIG_SMP */ > > - > > + > > /* Save the stack pointer in this processors TSS */ > mov ebp, [ebx+KPCR_TSS] > > @@ -158,12 +166,17 @@ > > jnz NoAdjust > The compare operation uses eax which points to the thread we will switch to. We must use the trap frame from the thread we will switch from. > /* Bias esp */ > > - //sub dword ptr ss:[ebp+KTSS_ESP0], KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS > > + sub eax, KTRAP_FRAME_V86_GS - KTRAP_FRAME_SS > Eax points to the wrong stack. See above. > > NoAdjust: > > - /* Push ESP0 Value */ > - push ss:[ebp+KTSS_ESP0] > > > > + /* Set new ESP0 */ > + mov [ebp+KTSS_ESP0], eax > Now, we are using the wrong kernel stack on the next exception. - Hartmut

19 years, 8 months

1
0
0 0

Revision 20911 Boot Problems

by James Tabor

Hi all, WaxDragon gets this, (lib/setupapi/devinst.c:3167) Flags 0x800000 ignored (./lib/advapi32/service/scm.c:2035) dwBufSize: 0 (subsys/system/services/rpcserver.c:1759) ScmrStartServiceW() called (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was cf) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xf000e739 could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65a69 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65d92 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a1f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cb1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00000c33> kdb:> I get this, (lib/ntdll/ldr/utils.c:1190) LdrGetExportByName(): failed to find mxdMessage (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'msacm.drv' (Status c0000135) (lib/ntdll/ldr/utils.c:2015) Failed to create or open dll section of 'midimap.dr v' (Status c0000135) (./subsys/win32k/ntuser/class.c:137) Failed to lookup class atom (ClassName 'SHE LLDLL_DefView')! (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ec) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xdeadbeef could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00003443> <00000000> kdb:> Second reboot it worked after booting linux than reboot warm, third reboot by power on reset, (ntoskrnl/ke/i386/v86m.c:678) V86GPF unhandled (was ee) Entered debugger on last-chance exception number 14 (Page Fault) Memory at 0xdeadbeef could not be written: Page not present. kdb:> bt Eip: <ntoskrnl.exe:65aa9 (ntoskrnl/ke/i386/v86m.c:383 (KeV86GPF))> Frames: <ntoskrnl.exe:65dd2 (ntoskrnl/ke/i386/v86m.c:791 (KeV86Exception))> <ntoskrnl.exe:62a5f (ntoskrnl/ke/i386/exp.c:514 (KiTrapHandler))> <ntoskrnl.exe:64cf1 (ntoskrnl/ke/i386/trap.s:151 (KiTrapProlog2))> <00002eee> <00000000> kdb:> I can repeat this over and over with real hardware, Thanks, James

19 years, 8 months

3
2
0 0

Listing function prototypes

by M Bealby

Hey everyone, just a quick question. Does anyone know of an existing application that will accept a bunch of header files as input and output a list of function prototypes? It would really help with my code auditing as I'm spending a long time assembling them by hand and it takes a long while. Cheers, Martin

19 years, 8 months

3
3
0 0

Re: [ros-svn] [weiden] 20891: disable starting lsass.exe for now

by Thomas Weidenmueller

weiden(a)svn.reactos.org wrote: > disable starting lsass.exe for now It seems that rpcrt4.dll has a bug that massively leaks threads in an rpc server. It seems that it leaks one thread per request. - Thomas

19 years, 8 months

2
1
0 0

Re: [ros-diffs] [ion] 20887: - Update KeContextToTrapFrame to support separate ContextFlags parameters in the scenario where we want to convert more then the Context's flag specify

by Thomas Weidenmueller

ion(a)svn.reactos.org wrote: > + Context->ContextFlags &= (~CONTEXT_EXTENDED_REGISTERS) | CONTEXT_i386; This looks a bit strange... - Thomas

19 years, 8 months

2
1
0 0

Re: [ros-diffs] [weiden] 20864: make the initial kernel_stack large enough to have enough space for the fx savings area

by Hartmut Birr

weiden(a)svn.reactos.org wrote: > make the initial kernel_stack large enough to have enough space for the fx savings area > Modified: trunk/reactos/ntoskrnl/ke/i386/main_asm.S > Modified: trunk/reactos/ntoskrnl/ke/i386/thread.c > Modified: trunk/reactos/ntoskrnl/ke/main.c > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/ntoskrnl/ke/i386/main_asm.S* > --- trunk/reactos/ntoskrnl/ke/i386/main_asm.S 2006-01-14 19:45:50 UTC (rev 20863) > +++ trunk/reactos/ntoskrnl/ke/i386/main_asm.S 2006-01-14 20:36:01 UTC (rev 20864) > @@ -35,7 +35,7 @@ > .m1: > /* Load the initial kernel stack */ > lea _kernel_stack, %eax > > - add $0x1000, %eax > > + add $0x2000, %eax > > and $0xFFFFE000, %eax > add $(0x3000 - SIZEOF_FX_SAVE_AREA), %eax > movl %eax, %esp > > ------------------------------------------------------------------------ I think the change in all 3 files is wrong. There was a bug in main_asm.S. The code to align the stack must be: .m1: lea _kernel_stack, %eax test $0xFFF, %eax jz .m2 and $0xFFFFF000, %eax add $0x1000, %eax .m2: add $(0x3000 - SIZEOF_FX_SAVE_AREA), %eax movl %eax, %esp - Hartmut

19 years, 8 months

2
1
0 0

New Diff, adds more debug print outs.

by Jerry

I made a diff to add more debug print outs. I hope this group finds it usefull. Index: ntoskrnl/ldr/loader.c =================================================================== --- ntoskrnl/ldr/loader.c (revision 20851) +++ ntoskrnl/ldr/loader.c (working copy) @@ -331,6 +331,7 @@ /* Hook for KDB on loading a driver. */ KDB_LOADDRIVER_HOOK(Filename, Module); + CPRINT("Driver Load Success: %wZ\n", Filename); return(STATUS_SUCCESS); } Index: drivers/net/ndis/ndis/miniport.c =================================================================== --- drivers/net/ndis/ndis/miniport.c (revision 20851) +++ drivers/net/ndis/ndis/miniport.c (working copy) @@ -1414,7 +1414,8 @@ if (NdisStatus != NDIS_STATUS_SUCCESS || SelectedMediumIndex >= MEDIA_ARRAY_SIZE) { - NDIS_DbgPrint(MIN_TRACE, ("MiniportInitialize() failed for an adapter.\n" )); + NDIS_DbgPrint(MIN_TRACE, ("MiniportInitialize() failed for an adapter. NdisStatus = 0x%00000000x; %d >= %d \n", + NdisStatus, SelectedMediumIndex, MEDIA_ARRAY_SIZE)); return (NTSTATUS)NdisStatus; }

19 years, 8 months

1
0
0 0

Re: [ros-svn] [gedmurphy] 20836: some new toolbar icons

by Martin Fuchs

Hello Ged, > some new toolbar icons > > Updated files: > trunk/reactos/subsys/system/explorer/res/toolbar.bmp Please use only toolbar bitmaps with 15 pixels height, not 16 ! Regards, Martin

19 years, 8 months

1
0
0 0

internal compiler error

by Hartmut Birr

Hi, Does somebody see this error? - Hartmut gcc -c hal\halx86\mp\processor_mp.c -o .\up\obj-i386\hal\halx86\mp\processor_mp.o -Ihal\halx86\include -Intoskrnl\include -D_DISABLE_TIDENTSSMP -D_NTHAL_ -D__USE_W32API -I. -Iinclude -Iinclude\reactos -Iinclude\libs -Iinclude\drivers -Iinclude\subsys -Iinclude\ndk -Iw32api\includ\include\crt -Iw32api\include\ddk -D_M_IX86 -D_X86_ -D__i386__ -D_REACTOS_ -DDBG -DKDBG -Wall -Wno-strict-aliasing -ftracer -momit-leaf-fram-mpreferred-stack-boundary=2 -Wpointer-arith -g -pipe -Werror -D_SEH_NO_NATIVE_NLG hal\halx86\mp\mpconfig.c: In function `HaliScanForMPConfigTable': hal\halx86\mp\mpconfig.c:563: internal compiler error: in cfg_layout_merge_blocks, at cfgrtl.c:2631 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. _make: *** [.\up\obj-i386\hal\halx86\mp\mpconfig.o] Error 1 _make: *** Waiting for unfinished jobs.... gcc (GCC) 3.4.2 (mingw-special) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

19 years, 8 months

4
4
0 0

Screen Shot for Real Hardware Was: [ros-kernel] David Recent Video Card Support Changes

by James Tabor

Hi All! It is time to Implement Screen Shot for real hardware! Who is up to it? 8^D James Oldies but Gold'ies Filip Navara wrote: 03/08/04 20:44 > James Tabor wrote: > >> Filip Navara wrote: >> >>> I cheated, because I used virtual machine with emulated S3 card, but >>> it looks same on real HW. If you need a screenshot feature, I'll try >>> find on of my old patches that saves screenshots to files and adapt >>> it for the current CVS. >>> >>> Regards, >>> Filip >>> >> Ya! A good work around hack is good! If you can do so. >> Thank, >> James > > > Here it is. Few notes: > 1) Beware, it's hack! > 2) It's a not little hack, it's a big hack! > 3) Saves the screenshot to c:\reactos\screenshot.bmp. > 4) Press ALT-PRINTSCREEN in any usual window (not console) to take the > screenshot. > > - Filip > > > ------------------------------------------------------------------------ > > Index: drivers/video/videoprt/videoprt.c > Index: lib/user32/windows/defwnd.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/lib/user32/windows/defwnd.c,v > retrieving revision 1.124 > diff -u -r1.124 defwnd.c > --- lib/user32/windows/defwnd.c 22 Feb 2004 23:40:58 -0000 1.124 > +++ lib/user32/windows/defwnd.c 8 Mar 2004 20:26:40 -0000 > @@ -949,10 +949,205 @@ > return GetSysColorBrush(COLOR_WINDOW); > } > > +/* > + * CreateBitmapInfoStructure > + * > + * Creates a bitmap info structure for saving a bitmap into a file. > + */ > + > +PBITMAPINFO FASTCALL > +CreateBitmapInfoStructure(HDC hDC, HBITMAP hBmp) > +{ > + BITMAP bmp; > + PBITMAPINFO pbmi; > + WORD cClrBits; > + > + /* Get the width, height and the colordepth of the image. */ > + if (!GetObjectW(hBmp, sizeof(BITMAP), (LPSTR)&bmp)) > + { > + return NULL; > + } > + > + /* Convert the color format to a count of bits. */ > + cClrBits = (WORD)(bmp.bmPlanes * bmp.bmBitsPixel); > + > + /* > + * Allocate memory for the BITMAPINFO-structure. This structure > + * contains a BITMAPINFOHEADER-structure and an array of RGBQUAD > + * datastructures. > + */ > + if (cClrBits <= 8) > + pbmi = (PBITMAPINFO)LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER) + sizeof(RGBQUAD) * (1 << cClrBits)); > + else > + pbmi = (PBITMAPINFO)LocalAlloc(LPTR, sizeof(BITMAPINFOHEADER)); > + > + > + /* Initialize the fields in the BITMAPINFO-structure. */ > + pbmi->bmiHeader.biSize = sizeof(BITMAPINFOHEADER); > + pbmi->bmiHeader.biWidth = bmp.bmWidth; > + pbmi->bmiHeader.biHeight = bmp.bmHeight; > + pbmi->bmiHeader.biPlanes = bmp.bmPlanes; > + pbmi->bmiHeader.biBitCount = bmp.bmBitsPixel; > + > + if (cClrBits <= 8) > + pbmi->bmiHeader.biClrUsed = 1 << cClrBits; > + > + pbmi->bmiHeader.biCompression = BI_RGB; > + > + /* > + * Compute the number of bytes in the array of color indices > + * and store the result in biSizeImage. > + */ > + > + pbmi->bmiHeader.biSizeImage = (pbmi->bmiHeader.biWidth + 7) / 8 * pbmi->bmiHeader.biHeight * cClrBits; > + > + /* > + * Set biClrImportant to 0 to indicate that all of the device > + * colors are important. > + */ > + > + pbmi->bmiHeader.biClrImportant = 0; > + > + /* And finally return the info-structure. */ > + return pbmi; > +} > + > +/* > + * SaveBitmap > + * > + * Saves a bitmap to a specified file. > + */ > + > +HRESULT FASTCALL > +SaveBitmap(PWCHAR strFileName, HDC hDC, HBITMAP hBMP) > +{ > + HANDLE hf; > + BITMAPFILEHEADER hdr; > + PBITMAPINFOHEADER pbih; > + LPBYTE lpBits; > + DWORD dwTotal; > + DWORD cb; > + BYTE *hp; > + DWORD dwTmp; > + PBITMAPINFO pbi; > + > + pbi = CreateBitmapInfoStructure(hDC, hBMP); > + if (pbi == NULL) > + { > + return E_FAIL; > + } > + > + pbih = (PBITMAPINFOHEADER)pbi; > + lpBits = (LPBYTE)GlobalAlloc(GMEM_FIXED, pbih->biSizeImage); > + > + if (!lpBits) > + { > + return E_FAIL; > + } > + > + /* > + * Retrieve the colortable (RGBQUAD-array) and the bits > + * (array of palette indices) from the DIB. > + */ > + > + if (!GetDIBits(hDC, hBMP, 0, (WORD)pbih->biHeight, lpBits, pbi, DIB_RGB_COLORS)) > + { > + return E_FAIL; > + } > + > + > + /* Create the .BMP file. */ > + > + hf = CreateFileW( > + strFileName, > + GENERIC_READ | GENERIC_WRITE, > + (DWORD)0, > + NULL, > + CREATE_ALWAYS, > + FILE_ATTRIBUTE_NORMAL, > + (HANDLE)NULL); > + > + if (hf == INVALID_HANDLE_VALUE) > + { > + return E_FAIL; > + } > + > + hdr.bfType = 0x4D42; /* 0x42 = "B", 0x4D = "M" */ > + > + /* Compute the size of the entire file. */ > + hdr.bfSize = (DWORD)(sizeof(BITMAPFILEHEADER) + pbih->biSize + pbih->biClrUsed * sizeof(RGBQUAD) + pbih->biSizeImage); > + hdr.bfReserved1 = 0; > + hdr.bfReserved2 = 0; > + > + /* Compute the offset to the array of color indices. */ > + hdr.bfOffBits = ( DWORD ) sizeof( BITMAPFILEHEADER ) + pbih->biSize + pbih->biClrUsed * sizeof( RGBQUAD ); > + > + /* Copy the BITMAPFILEHEADER into the .BMP file. */ > + if (!WriteFile(hf, (LPVOID)&hdr, sizeof(BITMAPFILEHEADER), (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Copy the BITMAPINFOHEADER and RGBQUAD array into the file. */ > + if (!WriteFile(hf, > + (LPVOID)pbih, > + sizeof(BITMAPINFOHEADER) + pbih->biClrUsed * sizeof(RGBQUAD), > + (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Copy the array of color indices into the .BMP file. */ > + dwTotal = cb = pbih->biSizeImage; > + hp = lpBits; > + > + if (!WriteFile(hf, (LPSTR)hp, (int)cb, (LPDWORD)&dwTmp, NULL)) > + { > + return E_FAIL; > + } > + > + > + /* Now close the .BMP file. */ > + if (!CloseHandle(hf)) > + { > + return E_FAIL; > + } > + > + /* Free the memory reserved. */ > + GlobalFree((HGLOBAL)lpBits); > + > + return S_OK; > +} > + > VOID FASTCALL > DefWndScreenshot(HWND hWnd) > { > - > + HDC hScreenDC = GetDC(0), hDC; > + HBITMAP hBmp, hSaveBmp; > + > + DbgPrint("Screenshot\n"); > + hBmp = CreateCompatibleBitmap( > + hScreenDC, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN)); > + hDC = CreateCompatibleDC(hScreenDC); > + hSaveBmp = SelectObject(hDC, hBmp); > + BitBlt( > + hDC, > + 0, > + 0, > + GetSystemMetrics(SM_CXSCREEN), > + GetSystemMetrics(SM_CYSCREEN), > + hScreenDC, > + 0, > + 0, > + SRCCOPY); > + SaveBitmap(L"c:\\reactos\\screenshot.bmp", hDC, hBmp); > + SelectObject(hDC, hSaveBmp); > + DeleteObject(hBmp); > + DeleteDC(hDC); > } > > LRESULT STDCALL > Index: subsys/win32k/objects/dib.c > =================================================================== > RCS file: /CVS/ReactOS/reactos/subsys/win32k/objects/dib.c,v > retrieving revision 1.42 > diff -u -r1.42 dib.c > --- subsys/win32k/objects/dib.c 19 Feb 2004 21:12:10 -0000 1.42 > +++ subsys/win32k/objects/dib.c 8 Mar 2004 20:27:00 -0000 > @@ -23,6 +23,7 @@ > #include <windows.h> > #include <stdlib.h> > #include <win32k/bitmaps.h> > +#include <win32k/color.h> > #include <win32k/debug.h> > #include "../eng/handle.h" > #include <ntos/minmax.h> > @@ -259,7 +260,7 @@ > } > > // Converts a device-dependent bitmap to a DIB > -#if 0 > +#if 1 > INT STDCALL NtGdiGetDIBits(HDC hDC, > HBITMAP hBitmap, > UINT StartScan, > @@ -278,7 +279,7 @@ > UINT coloruse) /* [in] RGB or palette index */ > #endif > { > -#if 0 > +#if 1 > BITMAPINFO Info; > BITMAPCOREHEADER *Core; > PBITMAPOBJ BitmapObj; > @@ -377,8 +378,7 @@ > Info.bmiHeader.biWidth == BitmapObj->bitmap.bmWidth && > Info.bmiHeader.biHeight == BitmapObj->bitmap.bmHeight && > Info.bmiHeader.biPlanes == BitmapObj->bitmap.bmPlanes && > - Info.bmiHeader.biBitCount == BitmapObj->bitmap.bmBitsPixel && > - 8 < Info.bmiHeader.biBitCount) > + Info.bmiHeader.biBitCount == BitmapObj->bitmap.bmBitsPixel) > { > Info.bmiHeader.biSizeImage = BitmapObj->bitmap.bmHeight * BitmapObj->bitmap.bmWidthBytes; > Status = MmCopyToCaller(Bits, BitmapObj->bitmap.bmBits, Info.bmiHeader.biSizeImage); > @@ -390,7 +390,7 @@ > } > RtlZeroMemory(&InfoWithBitFields, sizeof(InfoWithBitFields)); > RtlCopyMemory(&(InfoWithBitFields.Info), &Info, sizeof(BITMAPINFO)); > - if (BI_BITFIELDS == Info.bmiHeader.biCompression) > + if (Info.bmiHeader.biCompression == BI_BITFIELDS) > { > DCObj = DC_LockDc(hDC); > if (NULL == DCObj) > @@ -419,6 +419,22 @@ > BITMAPOBJ_UnlockBitmap(hBitmap); > return 0; > } > + if (Info.bmiHeader.biBitCount <= 8) > + { > + DCObj = DC_LockDc(hDC); > + if (NULL == DCObj) > + { > + SetLastWin32Error(ERROR_INVALID_HANDLE); > + BITMAPOBJ_UnlockBitmap(hBitmap); > + return 0; > + } > + NtGdiGetPaletteEntries( > + DCObj->w.hPalette, > + 0, > + 1 << Info.bmiHeader.biBitCount, > + (LPPALETTEENTRY)&UnsafeInfo->bmiColors); > + DC_UnlockDc(hDC); > + } > } > else > { > @@ -516,7 +532,7 @@ > if (bits && lines) > { > /* If the bitmap object already have a dib section that contains image data, get the bits from it */ > - if(bmp->dib && bmp->dib->dsBm.bmBitsPixel >= 15 && info->bmiHeader.biBitCount >= 15) > + if(bmp->dib) > { > /*FIXME: Only RGB dibs supported for now */ > unsigned int srcwidth = bmp->dib->dsBm.bmWidth, srcwidthb = bmp->dib->dsBm.bmWidthBytes; > @@ -702,6 +718,44 @@ > } > break; > > + case 8: /* 8 bpp dstDIB */ > + { > + switch(bmp->dib->dsBm.bmBitsPixel) { > + case 8: /* 8 bpp srcDIB -> 8 bpp dstDIB */ > + { > + /* FIXME: BI_BITFIELDS not supported yet */ > + for (y = 0; y < lines; y++, dbits+=dstwidthb, sbits+=srcwidthb) > + memcpy(dbits, sbits, srcwidthb); > + } > + break; > + > + default: /* ? bit bmp -> 8 bit DIB */ > + DPRINT1("FIXME: 8 bit DIB %d bit bitmap\n", > + bmp->bitmap.bmBitsPixel); > + break; > + } > + } > + break; > + > + case 4: /* 4 bpp dstDIB */ > + { > + switch(bmp->dib->dsBm.bmBitsPixel) { > + case 4: /* 4 bpp srcDIB -> 4 bpp dstDIB */ > + { > + /* FIXME: BI_BITFIELDS not supported yet */ > + for (y = 0; y < lines; y++, dbits+=dstwidthb, sbits+=srcwidthb) > + memcpy(dbits, sbits, srcwidthb); > + } > + break; > + > + default: /* ? bit bmp -> 4 bit DIB */ > + DPRINT1("FIXME: 4 bit DIB %d bit bitmap\n", > + bmp->bitmap.bmBitsPixel); > + break; > + } > + } > + break; > + > default: /* ? bit DIB */ > DPRINT1("FIXME: Unsupported DIB depth %d\n", info->bmiHeader.biBitCount); > break;

19 years, 8 months

1
0
0 0

Re: [ros-dev] Patent on FAT

by James Tabor

Hi all, I think this is important to share to the discussion. From one of the developers with FreeDOS, Eric Auer. Thanks, James -------- Original Message -------- Subject: [Freedos-user] re: FAT and other file systems Date: Fri, 13 Jan 2006 17:16:34 +0100 (MET) From: Eric Auer <eric(a)coli.uni-sb.de> Reply-To: freedos-user(a)lists.sourceforge.net To: freedos-user(a)lists.sourceforge.net Hi James, > > And I think it is not more difficult to write HFS or FFS in the kernel > > of FreeDOS than ReiserFS or XFS or all the other candidates. I would like to comment this as follows: The Linux kernel modules for ext3+jbd take 131+59k of memory. Reiserfs takes 243k (243*1000 bytes, too lazy to convert to units of 1024 bytes). On the other hand, FAT core takes 38k and you use it with either MSDOS (8k) or VFAT (13k) implementations. Only the VFAT (long file name enabled) module of Linux is affected by the 3 MS patents mentioned on the MS homepage. > There is no way around this, unless someone will write a disclaimer, "Before > you install FreeDos, do you want to enable Fat32 Patented Features"? Microsoft WANTS you to believe that they patented FAT32. Actually they patented their clever but twisted way to store short and long filenames in the same directory, in a way which allows LFN-unaware operating systems to use the drive without getting confused by the LFN data and usually also without damaging the LFN data either. But you already point that out yourself: > We are > facing the same issue with Ros. When I use FreeDos, I use the basic 8.3 > file system, so I don't see that as a major problem. The point here is the > patent is about LFN, basic 8.3 is not effected. So the disclaimer would only be displayed when you install the DOSLFN package: "Install DOSLFN, which might have patent issues?". FreeDOS as a DOS operating system itself is not affected by that problem. Plus MS does have a disclaimer about their licensing, too: http://www.microsoft.com/whdc/hwdev/download/hardware/fatgen103.pdf which is more than 5 years old by now... allows you to be compatible to all their FAT (including LFN) stuff for the purpose of booting, OS installation, diagnosis, firmware, similar things. They also tell that making/installing operating systems may use all aspects of FAT. You could see this in a pessimist way (you are allowed to develop and compile your OS on a LFN enabled host system) or in a more optimistic way (your operating system itself is allowed to use LFN because it simply is an operating system). MS is targetting two groups at the moment: Vendors of USB sticks who preinstall files on their sticks, and vendors of cams and mp3 players and similar devices. FreeDOS is neither of those. But I did notice that my hardware mp3 player does not support LFN. It only shows the id3 text, if available, as "long song name", and is limited to showing the SHORT file name as song name otherwise. Looks like the vendor of the player did not want to pay MS for each device. Digicams have similar issues - they usually generate filenames like dsc0815 dot jpg and store all extra "title/name" information inside the file (jpeg comment, EXIF data...?). Eric PS: I assume that you mean ReactOS, the free open WinNT clone, when you mention Ros. ReactOS without LFN would not be the same... ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Freedos-user mailing list Freedos-user(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user

19 years, 8 months

3
2
0 0

Patent on FAT

by Murphy, Ged (Bolton)

I'm reading reports of a US patent on FAT. What's going on and how will this effect us? The US patent rules are seriously out of control :( Ged ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 8 months

15
22
0 0

MS's patent claims for FAT

by Wierd_w

I have found the full texts for the patents for FAT. The links are very long, so I expect them to get clipped. Regardless, here it goes anyway. http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=… Those are all three patents listed by the MS FAT patent notification page at MS. I note how their claims arent specific about what kind of 'memory storage' the FAT structure is located in--- MS is being really paranoid about it. Still, IANAL, but I would say this is grounds for an equitable estoppel. MS has allowed royalty free use of FAT for how many years now? How many industries rely on FAT support, as a De-Facto standard for floppies and flash media? Sounds like a textbook case for Equitable Estoppel. http://www.nolo.com/definition.cfm/Term/7F1E56D5-7EC1-4CEB-86B3943F6990FF77… (First item) I would bring this to the FSF's attention. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

19 years, 8 months

1
0
0 0

RE: [ros-dev] Patent on FAT

by Murphy, Ged (Bolton)

Another twist in the tale : http://www.linux-watch.com/news/NS2809681376.html Ged. ************************************************************************ The information contained in this message or any of its attachments is confidential and is intended for the exclusive use of the addressee. The information may also be legally privileged. The views expressed may not be company policy, but the personal views of the originator. If you are not the addressee, any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited. If you have received this message in error, please contact postmaster(a)exideuk.co.uk <mailto:postmaster@exideuk.co.uk> and then delete this message. Exide Technologies is an industrial and transportation battery producer and recycler with operations in 89 countries. Further information can be found at www.exide.com

19 years, 8 months

1
0
0 0

Compilation Units - Dealing with the lack of PCH in Wine

by Steven Edwards

Hi, I have manually made a compilation unit and a patch with a 1 line diff for uuid+shell32 and took my build from 30+ secs down to 9 on gcc. Alex reported a drop from 22 to 1 on msvc. We need to create a master source file for each Wine dll like the one attached and add some hacks for the errors that popup. I have not tested the resulting shell32.dll but it should work the same. I do not think we can automate generation of the compilation unit sources for the Wine code due to the hacks we will need to add like in the attached file. -- Steven Edwards - ReactOS and Wine developer "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

19 years, 8 months

2
1
0 0

trunk is broken

by Hartmut Birr

Hi, I'm not able to install ros from the current trunk on real hardware. At the end of the second stage setup I see a reset, which seems to be a triple fault. After the reset, I'm again on the second stage setup. - Hartmut

19 years, 8 months

2
2
0 0

Broken Message Dispatching in Win32k

by Alex Ionescu

Hi, After applying my user-mode callback patch, I sometimes see a bugcheck caused by my debugging code. It seems that we do user-mode callbacks with Kernel APCs disabled (just like we also did them with PreviousMode == KernelMode, thank God that I had to "break" HEAD to find this huge bug... but that's another story). The old code "worked" because it did not check for this serious mistake. Normally, I've noticed that messages are sent through co_IntSendMessage which is called with KernelApcDisable == -1. That function calls some unlocking functions and then does the Callback, which is called with KernelApcDisable == 0, which is good. However, co_IntSendMessage is sometimes being called from co_MsqPeekHardwareMessage. DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); WaitObjects[1] = MessageQueue->NewMessages; WaitObjects[0] = &HardwareMessageQueueLock; do { UserLeaveCo(); WaitStatus = KeWaitForMultipleObjects(2, WaitObjects, WaitAny, UserRequest, UserMode, FALSE, NULL, NULL); UserEnterCo(); DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); while (co_MsqDispatchOneSentMessage(MessageQueue)) { DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } DPRINT1("ApcState: %x\n", KeGetCurrentThread()->KernelApcDisable); } while (NT_SUCCESS(WaitStatus) && STATUS_WAIT_0 != WaitStatus); In this loop, the first KernelApcState is -1. After the wait, it becomes -2. Now normally there is nothing to dispatch, so the function continues, and the -2 later becomes a -3 after another lock, then gradually goes down to -2, then back to -1. So the function enters with -1 and exits with -1, which is normal. However, if the Message Queue *does* have a message on it, then co_MsqDispatchOneSentMessage ends up being called. Remember that after the wait we're now at -2. So that function will then call co_IntSendMessage at -2, which will lower ir it to -1 before the callback. But now the callback runs at -1, which means Kernel APCs are disabled... so we bugcheck. I have absolutely NO knowledge of Win32k Message Queues/MesssageSending, but something defintely seems wrong to me here...can anyone help please? Best regards, Alex Ionescu

19 years, 8 months

2
1
0 0

Re: [ros-svn] [hbirr] 20793: - We cannot access the OwnerTable without locking the resource.

by Hartmut Birr

hbirr(a)svn.reactos.org wrote: > - We cannot access the OwnerTable without locking the resource. > - The shared waiters may wait also on the semaphore. It makes no sense to boost a waiting thread. > - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, > possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. > > > > Updated files: > trunk/reactos/ntoskrnl/ex/resource.c > > _______________________________________________ > Ros-svn mailing list > Ros-svn(a)reactos.org > http://www.reactos.org/mailman/listinfo/ros-svn > > Oops, I've copied the wrong commit message. The correct is: - We cannot access the OnerTable without locking the resource. - The shared waiters may wait also on the semaphore. It makes no sence to boost a waiting thread. - The thread header is initialized like KeWaitForSingleObject (?, ?, ?, TRUE, ?). During the boost, possible the dispatcher lock is released but the thread block (WaitNext) isn't changed. - Hartmut

19 years, 8 months

1
1
0 0

Bug Check in Marea.c

by James Tabor

Hi all, With real hardware and revision 20802, At the end of first stage and after hitting the Finish button, I can reproduce this every time too, KeBugCheck at ./ntoskrnl/mm/marea.c:901 A problem has been detected and ReactOS has been shut down to prevent damage to your computer. Technical information: *** STOP: 0x00000000 (0x00000000,0x00000000,0x00000000,0x00000000) Frames: <ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))> <ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())> <ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())> <ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))> <ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())> <ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))> <ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())> Entered debugger on embedded INT3 at 0x0008:0x80073b86. kdb:> bt Eip: <ntoskrnl.exe:73b87 (lib/rtl/i386/debug_asm.S:28 (DbgBreakPointWithStatus))> Frames: <ntoskrnl.exe:1676 (./ntoskrnl/ke/bug.c:483 (KeBugCheckEx))> <ntoskrnl.exe:168d (./ntoskrnl/ke/bug.c:504 (KeBugCheck))> <ntoskrnl.exe:4342b (./ntoskrnl/mm/marea.c:0 ())> <ntoskrnl.exe:434c4 (./ntoskrnl/mm/process.c:0 ())> <ntoskrnl.exe:55c12 (./ntoskrnl/ps/kill.c:200 (PspDeleteThread))> <ntoskrnl.exe:50cdd (./ntoskrnl/ob/object.c:0 ())> <ntoskrnl.exe:518ce (./ntoskrnl/ob/handle.c:254 (ObpDeleteHandle))> <ntoskrnl.exe:51a0b (./ntoskrnl/ob/handle.c:1112 (NtClose))> <ntoskrnl.exe:6440c (ntoskrnl/ke/i386/syscall.S:372 (KiSystemService))> <KERNEL32.dll:a697 (./lib/kernel32/misc/handle.c:0 ())> <winlogon.exe:1ae2> <winlogon.exe:20f6> <winlogon.exe:339a> <winlogon.exe:11e7> <winlogon.exe:1258> <00000000> kdb:> I go into ntoskrnl/mm/marea.c and at line 891 I change DPRINT to DPRINT1, now the system reboots and runs normal. I even have Abiword running with Winefile. Thanks, James

19 years, 8 months

1
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev