Hi all!
I noticed we still have drawing issues even after fixing some gdi
code. Well, I guess we need to look at the main windowing side of the
house now. I guess, based on a stable release we can sync up wine and
patch by hand the forked code too. I know of some Delphi issues that
could use a good non static update. Bulk of our user code is from wine
and that includes the window positioning bug everyone has had a crack
at as well. I notices that most of the syncs in comdlg/controls depend
on user code updates. If Richedit breaks windowing, it could be
related to user32/win32k code not updated or based on behavior that is
wrong. Syncing and updating forked code is not fun, with both, one
needs to take into account local fixes. When you find them, mark them
like "REACTOS HACK" or "REACTOS ONLY" or "REACTOS ????" what ever.
Reading the change logs for each file should help with determining
local patches that have been applied and need to be taken into account
as well. If you have a bug report, please mark it as WINE SYNC or WINE
UPDATE, something to let us know, it's a wine sync of some kind. We
have a file in our media doc directory that holds the sync/fork
information, please include it with your updates.
Thanks,
James
Ref: README.WINE:
User32 -
reactos/dll/win32/user32/controls/button.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/combo.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/edit.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/icontitle.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/listbox.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/controls/scrollbar.c # Forked
reactos/dll/win32/user32/controls/static.c # Synced at 20071024
reactos/dll/win32/user32/misc/dde.c # Synced to wine
1.1.17 (dde_misc.c)
reactos/dll/win32/user32/misc/ddeclient.c # Synced to wine 1.1.17
reactos/dll/win32/user32/misc/ddeserver.c # Synced to wine 1.1.17
reactos/dll/win32/user32/misc/exticon.c # Last sync date unknown
reactos/dll/win32/user32/misc/resources.c # Forked?
reactos/dll/win32/user32/misc/winhelp.c # Last sync date unknown
reactos/dll/win32/user32/misc/wsprintf.c # Synced to Wine-1_1_13
reactos/dll/win32/user32/windows/defwnd.c # Forked
reactos/dll/win32/user32/windows/draw.c # Forked at
Wine-20020904 (uitools.c)
reactos/dll/win32/user32/windows/mdi.c # Synced at 20060703
reactos/dll/win32/user32/windows/menu.c # Forked
reactos/dll/win32/user32/windows/messagebox.c # Forked
reactos/dll/win32/user32/windows/rect.c # Forked (uitools.c)
reactos/dll/win32/user32/windows/text.c # Forked (lstr.c)
reactos/dll/win32/user32/windows/winpos.c # Forked
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
Ok before you go on in this area, I am currently working on a complete
rewrite of sysparams stuff. It should hopefully be ready this week and
should fix almost all winetests and additional tests in this area.
Regards,
Timo
dchapyshev(a)svn.reactos.org schrieb:
> Author: dchapyshev
> Date: Mon May 25 17:08:57 2009
> New Revision: 41115
>
> URL: http://svn.reactos.org/svn/reactos?rev=41115&view=rev
> Log:
> - Stubimplement SPI_GETFONTSMOOTHINGTYPE/SPI_SETFONTSMOOTHINGTYPE
>
> Modified:
> trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
>
> Modified: trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
> ==============================================================================
> --- trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] (original)
> +++ trunk/reactos/subsystems/win32/win32k/ntuser/sysparams.c [iso-8859-1] Mon May 25 17:08:57 2009
> @@ -699,6 +699,22 @@
> {
> ASSERT(pvParam);
> *((BOOL*)pvParam) = IntIsFontRenderingEnabled();
> + break;
> + }
> + case SPI_SETFONTSMOOTHINGTYPE:
> + {
> + if (*((UINT*)pvParam) == FE_FONTSMOOTHINGCLEARTYPE)
> + {
> + DPRINT1("ReactOS does not support ClearType smoothing but it is returned TRUE\n");
> + }
> + bChanged = TRUE;
> + break;
> + }
> + case SPI_GETFONTSMOOTHINGTYPE:
> + {
> + /* We do not support ClearType. Only standard smoothing */
> + DPRINT1("ReactOS does not support ClearType smoothing. Returned FE_FONTSMOOTHINGSTANDARD\n");
> + *((UINT*)pvParam) = FE_FONTSMOOTHINGSTANDARD;
> break;
> }
> case SPI_GETICONTITLELOGFONT:
>
>
>