I don't know how many times I need to send the same link here but let's say that this is the last time:
this is a post about wpf but in the middle there is a paragraph about how win32k in windows processes mouse messages:
http://blogs.msdn.com/b/dwayneneed/archive/2008/09/08/transparent-windows-i…
And here is the important part:
Which HWND is the mouse over?
The operating system must respond very quickly to mouse movement. Windows uses a dedicated Raw Input Thread (RIT), running in the kernel, to handle the signals from the mouse hardware. The RIT quickly scans over the HWND hierarchy to see which window the mouse is over. Because the system must be responsive, no application code is invoked. For normal windows, the RIT checks the mouse position against the window's rectangle (or region, if one is set). But for layered windows, the RIT looks in the bitmap that specifies the content for the window and checks the effective transparency at that location (which can be affected by the constant opacity setting, the color key setting, or the per-pixel alpha channel). If the pixel is 100% transparent, the RIT skips the window and keeps looking. Once a window has been located, the mouse move flag is set on the thread that owns the window. This will cause the thread to receive a WM_MOUSEMOVE message the next time it calls GetMessage() and there are no other higher-priority messages.
Now let me explain why a flag is needed. The window manager needs to coalesce mouse move messages. If the mouse moves over a window and the system registers 10 positions over it, if the window doesn't process messages fast enough the unprocessed positions are dropped and only the last is kept. Even if another message gets between these mouse move messages get lost.
That's why the last mouse position is not stored in a message queue but in a field in the thread info. That's how the window manager worked the last 20 years in windows.
I'm sick and tired to see readable and correct code to be rewritten by shitty code, that is not readable and has obvious bugs without any reason why the previous implementation was wrong. I just give up. Do whatever you like with this shitty project of yours. I don't care anymore.
On 2014-11-15 13:34, dquintana(a)svn.reactos.org wrote:
> [SHELL32]
> * Commit the folder location fixes. They are mostly untested due to being unable to boot to desktop, but looking at the contents of the HDD after syssetup runs seems that the shortcuts are all created in their rightful place. If anyone is able to boot, feel free to test.
>
> Modified:
> branches/shell-experiments/dll/win32/shell32/wine/shellpath.c
So which is it; to Wine or not to Wine? If we need to fork this then
let's put it in another file? Or at least #ifdef __REACTOS__?
On 2014-09-29 19.00, ros-dev-request(a)reactos.org wrote:
> w0000t
> natively? via an emulator???
> what the....
> \o/
@ Javier
I just stumbled by and saw it..
Выглядит безумно, но я установил и запустил ReactOS через обертку
Qemu - Limbo ARM 7 на своем Samsung Galaxy S III mini.
It looks crazy, but I installed and started the ReactOS through wrapper
Qemu - Limbo ARM 7 on your Samsung Galaxy S III mini.
//
It might be interesting to try wedging an ARM build into the S3 though.
I was mulling over the possibility to squeeze it into an Maple Native..
Love
I saw an article on heise online (German-language website)
http://www.heise.de/newsticker/
on
ReactOS liest NTFS
http://www.heise.de/newsticker/meldung/ReactOS-liest-NTFS-2442615.html
Date is 05.11.2014, meaning just yesterday.
I subsequently looked on reactos.org and couldn't find any reference to this article.
So far, this is only for reading NTFS on ReactOS; writing ability stil has to be worked on.
This is the first article I've seen on this subject: looks like progress.
Some ReactOS developers must be familiar with this?
Tom
tcpip.c:264
/* Keep this list sorted */
InsertHeadList(ListEntry, &OutInstance->ListEntry);
This should probably be InsertTailList(), since you want to insert
before the current ListEntry
Am 12.11.2014 12:39, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Wed Nov 12 11:39:13 2014
> New Revision: 65388
>
> URL: http://svn.reactos.org/svn/reactos?rev=65388&view=rev
> Log:
> [TCPIP]
> - Comment out an optimisation which doesn't work.
> Reviews of why would be most appreciated.
>
> Modified:
> branches/tcpip_revolution/drivers/network/tcpip/entities.c
>
> Modified: branches/tcpip_revolution/drivers/network/tcpip/entities.c
> URL: http://svn.reactos.org/svn/reactos/branches/tcpip_revolution/drivers/networ…
> ==============================================================================
> --- branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] (original)
> +++ branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] Wed Nov 12 11:39:13 2014
> @@ -309,9 +309,11 @@
> return STATUS_SUCCESS;
> }
>
> +#if 0
> /* The list is sorted, so we can cut the loop a bit */
> if (ID.tei_instance < Instance->InstanceId.tei_instance)
> break;
> +#endif
>
> ListEntry = ListEntry->Flink;
> }
>
>
>
Let me make a simple arrogant comment:
Don't try to fix hacks that I spent years trying to fix (and failed). They
just can't be fixed :P
Best regards,
Alex Ionescu
On Mon, Nov 10, 2014 at 1:45 AM, <pschweitzer(a)svn.reactos.org> wrote:
> Author: pschweitzer
> Date: Mon Nov 10 09:45:43 2014
> New Revision: 65352
>
> URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
> Log:
> [NTOSKRNL]
> So... Because actual ReactOS mood is to worship hacks instead of looking
> for proper fixes to have decent behavior: reenable the IopParseDevice hack.
>
> But, so far, only reenable it for the 1st stage: the most intensive
> storage stack stage (unless you start playing with partitions & formating
> in 3rd stage).
>
> CORE-8732 #resolve #comment Bug is now properly hidden with r65352
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/file.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10
> 09:45:43 2014
> @@ -404,6 +404,27 @@
> /* Check if we can simply use a dummy file */
> UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly));
>
> + /* FIXME: Small hack still exists, have to check why...
> + * This is triggered multiple times by usetup and then once per boot.
> + */
> + if (ExpInTextModeSetup &&
> + !(DirectOpen) &&
> + !(RemainingName->Length) &&
> + !(OpenPacket->RelatedFileObject) &&
> + ((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
> + (wcsstr(CompleteName->Buffer, L"Floppy"))) &&
> + !(UseDummyFile))
> + {
> + DPRINT1("Using IopParseDevice() hack. Requested invalid
> attributes: %lx\n",
> + DesiredAccess & ~(SYNCHRONIZE |
> + FILE_READ_ATTRIBUTES |
> + READ_CONTROL |
> + ACCESS_SYSTEM_SECURITY |
> + WRITE_OWNER |
> + WRITE_DAC));
> + DirectOpen = TRUE;
> + }
> +
> /* Check if this is a direct open */
> if (!(RemainingName->Length) &&
> !(OpenPacket->RelatedFileObject) &&
>
>
>
Hi,
> + if (Sector->BytesPerSector * Sector->SectorsPerCluster > 32 * 1024)
> + {
> + return FALSE;
> + }
FAT supports cluster sizes until 64KB ;-) At least the WinNT series can
work with them.
Best regards,
Michael Fritscher
Thank you for working on this hack (partial) removal!
After all, having it only in the 1st stage is a win over having it
enabled all the time.
Regards,
Aleksey
On 10.11.2014 12:45, pschweitzer(a)svn.reactos.org wrote:
> Author: pschweitzer
> Date: Mon Nov 10 09:45:43 2014
> New Revision: 65352
>
> URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
> Log:
> [NTOSKRNL]
> So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack.
>
> But, so far, only reenable it for the 1st stage: the most intensive storage stack stage (unless you start playing with partitions & formating in 3rd stage).
>
> CORE-8732 #resolve #comment Bug is now properly hidden with r65352
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/file.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 09:45:43 2014
> @@ -404,6 +404,27 @@
> /* Check if we can simply use a dummy file */
> UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly));
>
> + /* FIXME: Small hack still exists, have to check why...
> + * This is triggered multiple times by usetup and then once per boot.
> + */
> + if (ExpInTextModeSetup &&
> + !(DirectOpen) &&
> + !(RemainingName->Length) &&
> + !(OpenPacket->RelatedFileObject) &&
> + ((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
> + (wcsstr(CompleteName->Buffer, L"Floppy"))) &&
> + !(UseDummyFile))
> + {
> + DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n",
> + DesiredAccess & ~(SYNCHRONIZE |
> + FILE_READ_ATTRIBUTES |
> + READ_CONTROL |
> + ACCESS_SYSTEM_SECURITY |
> + WRITE_OWNER |
> + WRITE_DAC));
> + DirectOpen = TRUE;
> + }
> +
> /* Check if this is a direct open */
> if (!(RemainingName->Length) &&
> !(OpenPacket->RelatedFileObject) &&
>
>