This looks like ultra-hax. Can you explain why this should be correct?
It would mean DrvSetPixelFormat would be passed a SURFACE rather than a
SURFOBJ.
jimtabor(a)svn.reactos.org schrieb:
> Author: jimtabor
> Date: Tue Jun 2 10:50:36 2009
> New Revision: 41250
>
> URL: http://svn.reactos.org/svn/reactos?rev=41250&view=rev
> Log:
> - Hax-implement NtGdiSetPixelFormat and add a support function UserGethWnd with some code cleanup.
>
> Modified:
> [...]
> + /*
> + Based on some rules! InfoDC to DC or, based on wiki information!
> + All pointers, it's a "must be!", (CONTAINING_RECORD +10h = SURFOBJ), the
> + pointer will start at SURFOBJ of the SURFACE structure.
> + */
> + pso = (SURFOBJ *)pdc->dclevel.pSurface;
> + if (!pso) pso = pdc->pSurfInfo;
> + if (!pso) pso = ppdev->pSurface;
> + }
> +
> + if (ppdev->flFlags & PDEV_META_DEVICE)
> + {
> + UNIMPLEMENTED;
> + goto Exit;
> + }
> +
> + if (ppdev->DriverFunctions.SetPixelFormat)
> + {
> + Ret = ppdev->DriverFunctions.SetPixelFormat(
> + pso,
> + ipfd,
> + hWnd);
> + }
>
I find the defination of CHECKPOINT
#define CHECKPOINT do { DbgPrint("%s:%d\n",__FILE__,__LINE__); ExAllocatePool(NonPagedPool,0); } while(0);
I don't know why alloc memory with 0 byte
I must say that I protest to all the recent I/O changes, and in my
opinion, they are all wrong and badly researched, and have hacked what
was once good code.
Best regards,
Alex Ionescu
On Wed, Jun 3, 2009 at 2:48 AM, <mjmartin(a)svn.reactos.org> wrote:
> Author: mjmartin
> Date: Wed Jun 3 13:48:33 2009
> New Revision: 41269
>
> URL: http://svn.reactos.org/svn/reactos?rev=41269&view=rev
> Log:
> - IopCreateDriver: Change MajorFunction routines back to internal function IopInvalidDeviceRequest for ones that were set to NULL in the Drivers DriverEntry. Windows does it and so shall we.
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/driver.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/driver.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/driver.c…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/driver.c [iso-8859-1] Wed Jun 3 13:48:33 2009
> @@ -1302,7 +1302,7 @@
> RtlZeroMemory(DriverObject, ObjectSize);
> DriverObject->Type = IO_TYPE_DRIVER;
> DriverObject->Size = sizeof(DRIVER_OBJECT);
> - DriverObject->Flags = DRVO_BUILTIN_DRIVER;
> + DriverObject->Flags = DRVO_LEGACY_DRIVER;//DRVO_BUILTIN_DRIVER;
> DriverObject->DriverExtension = (PDRIVER_EXTENSION)(DriverObject + 1);
> DriverObject->DriverExtension->DriverObject = DriverObject;
> DriverObject->DriverInit = InitializationFunction;
> @@ -1398,6 +1398,14 @@
> {
> /* Returns to caller the object */
> *pDriverObject = DriverObject;
> + }
> +
> + /* Loop all Major Functions */
> + for (i = 0; i <= IRP_MJ_MAXIMUM_FUNCTION; i++)
> + {
> + /* Set each function that was set to NULL to internal routine */
> + if (!DriverObject->MajorFunction[i])
> + DriverObject->MajorFunction[i] = IopInvalidDeviceRequest;
> }
>
> /* Return the Status */
>
>
There's nothing ugly about this -- this is exactly what the field is for.
Best regards,
Alex Ionescu
On Sat, May 30, 2009 at 4:07 PM, <cgutman(a)svn.reactos.org> wrote:
> Author: cgutman
> Date: Sun May 31 03:07:13 2009
> New Revision: 41213
>
> URL: http://svn.reactos.org/svn/reactos?rev=41213&view=rev
> Log:
> - Export and hackplement NdisSetTimerEx
> - Implementation is #ifed out currently but I may enable it later
> - Hopefully somebody can think of a better way to do it than the current code
>
> Modified:
> trunk/reactos/drivers/network/ndis/ndis.def
> trunk/reactos/drivers/network/ndis/ndis/time.c
>
> Modified: trunk/reactos/drivers/network/ndis/ndis.def
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis.…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis.def [iso-8859-1] Sun May 31 03:07:13 2009
> @@ -257,6 +257,7 @@
> NdisSetPacketPoolProtocolId@8
> ;NdisSetProtocolFilter ?
> NdisSetTimer@8
> +NdisSetTimerEx@12
> NdisSetupDmaTransfer@24
> NdisSystemProcessorCount@0
> NdisTerminateWrapper@8
>
> Modified: trunk/reactos/drivers/network/ndis/ndis/time.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/network/ndis/ndis/…
> ==============================================================================
> --- trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/network/ndis/ndis/time.c [iso-8859-1] Sun May 31 03:07:13 2009
> @@ -243,5 +243,26 @@
> KeSetTimer (&Timer->Timer, Timeout, &Timer->Dpc);
> }
>
> +VOID
> +EXPORT
> +NdisSetTimerEx(
> + IN PNDIS_TIMER Timer,
> + IN UINT MillisecondsToDelay,
> + IN PVOID FunctionContext)
> +{
> +#if 0
> + /* FIXME: I'm not sure how to this in a nice way
> + * We can't store the function context anywhere in NDIS_TIMER
> + * so I'm forced to do this
> + */
> +
> + Timer->Dpc.DeferredContext = FunctionContext;
> +
> + NdisSetTimer(Timer, MillisecondsToDelay);
> +#else
> + UNIMPLEMENTED
> +#endif
> +}
> +
> /* EOF */
>
>
>
Hi
I download a very early edtion of reactos(0.0.21), I think it would be
easy to understand for me. I disable the NDEBUG macro, so I can catch the
debug info. By default, I use the /DEBUGPORT=SCREEN, and the log info is
printed on the screen. Then I changed to /DEBUGPORT=BOCHS, but there is no
any info on the bochs console.
Could you tell me how to catch the log on the bochs?
Fan Zhang