I wish Magnus would mention that this commit ALSO includes patch from
bug #1837.
WBR,
Aleksey Bragin.
On Nov 26, 2006, at 1:39 PM, greatlrd(a)svn.reactos.org wrote:
> Author: greatlrd
> Date: Sun Nov 26 13:39:50 2006
> New Revision: 24834
>
> URL: http://svn.reactos.org/svn/reactos?rev=24834&view=rev
> Log:
> 1. revers 24831 to 24833 userenv.h does not exists in ms psdk and
> shall move to folder include/ndk or include/reactos
> 2. do not create new private header, we already have one, but it is
> in wrong folder.
> 3. This header should have been move long time ago.
> 4. do not doing #include "userenv-priv.h" it will not found the
> header in syssetup/install
>
>
> Removed:
> trunk/reactos/dll/win32/userenv/userenv-priv.h
> Modified:
> trunk/reactos/dll/win32/syssetup/install.c
> trunk/reactos/dll/win32/syssetup/syssetup.rbuild
> trunk/reactos/dll/win32/userenv/precomp.h
> trunk/reactos/dll/win32/userenv/userenv.rbuild
> trunk/reactos/drivers/input/i8042prt/mouse.c
> trunk/reactos/include/psdk/userenv.h
>
> Modified: trunk/reactos/drivers/input/i8042prt/mouse.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/drivers/input/
> i8042prt/mouse.c?rev=24834&r1=24833&r2=24834&view=diff
> ======================================================================
> ========
> --- trunk/reactos/drivers/input/i8042prt/mouse.c (original)
> +++ trunk/reactos/drivers/input/i8042prt/mouse.c Sun Nov 26
> 13:39:50 2006
> @@ -903,6 +903,9 @@
> UCHAR Value;
> UCHAR ExpectedReply[] = { 0xFA, 0xAA, 0x00 };
> unsigned ReplyByte;
> + ULONG Counter;
> +
> + I8042Flush();
>
> if (! I8042Write(DevExt, I8042_CTRL_PORT, 0xD4) ||
> ! I8042Write(DevExt, I8042_DATA_PORT, 0xFF))
> @@ -915,7 +918,12 @@
> ReplyByte < sizeof(ExpectedReply) / sizeof(ExpectedReply[0])
> && Ok;
> ReplyByte++)
> {
> - Status = I8042ReadDataWait(DevExt, &Value);
> + Counter = 200;
> +
> + do {
> + Status = I8042ReadDataWait(DevExt, &Value);
> + } while (Status == STATUS_IO_TIMEOUT && Counter--);
> +
> if (! NT_SUCCESS(Status))
> {
> DPRINT1("No ACK after mouse reset, status 0x%08x\n",
>
I have been following the ReactOS project for a while now, and would like to
write your newsletters for you.
Qualifications:
- I have enough time to write the newsletter once a week.
- English is my first language, and I can write fairly well.
- I like to program in my free time, so I understand what's going on pretty
well.
- I don't know if I can do the IRC, though.
- I also know HTML.
If I am not picked, that's alright, I just wanted to help you guys out... I
would help out with the actual project, but I don't think my programming
skill is that advanced.
ekohl(a)svn.reactos.org wrote:
> Author: ekohl
> Date: Mon Nov 20 00:17:42 2006
> New Revision: 24792
>
> URL: http://svn.reactos.org/svn/reactos?rev=24792&view=rev
> Log:
> Remove the obsolete STDCALL decorations from .def files.
I love you? I was JUST talking to Aleksey on how MSVC builds won't be
linkable if this doesn't work.
Please do this to every single .def file if you have time.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
ion(a)svn.reactos.org wrote:
> - Please remember that you NEED the WDK 6000 RTM installed to
> use MSVC for building ReactOS. Don't change global build
> settings just because you were too lazy to download it and
> think that because your Win32 app doesn't need it, it's ok to
> break other people's native/system/kernel/hal builds. Change
> it locally if you're lazy, but don't revert these changes again.
I highly dissagree that we should break building of usermode code in MSVC
just because someone doesn't have 1 header file which is included with the
WDK.
If it effects the building of HAL etc so much, then it should be a
requirement for those components only, not for wingui/win32dll code.
Maybe including a similar header into our own code is a more viable option.
Ged.
ion(a)svn.reactos.org wrote:
> Author: ion
> Date: Thu Nov 16 10:09:37 2006
> New Revision: 24767
>
> URL: http://svn.reactos.org/svn/reactos?rev=24767&view=rev
> Log:
> - Purposefully add 6 debug prints to RtlpGetRegistryHandle, which, while ndis.sys is initializing, should BSOD the system. I have seen this "RtlpGetRegistryHandle" BSOD randomly during boot (But always with the same stack trace), and a local HAL patch managed to cause it 100% of the time. I know that the problem had nothing to do with the HAL or registry paths, because it came up before too when I added debug prints to fstub. These 6 prints 100% reproduce the problem on my machine with GCC 3.4.5. It is my hope it will do the same for everyone. This is a nasty bug, either stack related or some critical structure is being damaged. I am breaking trunk because it's been here for a long time, but now I found a way to repro it so that we can work together to try finding it. In a way, trunk was always broken, but this patch should force a freeze. Please help.
>
> Modified:
> trunk/reactos/lib/rtl/registry.c
>
> Modified: trunk/reactos/lib/rtl/registry.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/lib/rtl/registry.c?rev=247…
> ==============================================================================
> --- trunk/reactos/lib/rtl/registry.c (original)
> +++ trunk/reactos/lib/rtl/registry.c Thu Nov 16 10:09:37 2006
> @@ -94,6 +94,11 @@
> }
>
> /* And now append the path */
> + DPRINT1("I'm about to crash due to an overwrite problem, Alex thinks\n");
> + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n");
> + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n");
> + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n");
> + DPRINT1("I'm about to crash due to a overwrite problem, Alex thinks\n");
> if (Path[0] == L'\\' && RelativeTo != RTL_REGISTRY_ABSOLUTE) Path++; // HACK!
> Status = RtlAppendUnicodeToString(&KeyName, Path);
> if (!NT_SUCCESS(Status)) return Status;
>
Where's # 6? I only see 5..
LOL
Hello,
trunk is frozen from any commits except for fixing that error
mentioned in the last commit message ("ndis"-bug).
Thanks for understanding,
Aleksey Bragin.
Hi,
Some time ago, I have done a small fix to make the freetype chache work.
It still had the display bug with the original author (tinus) already
experienced. I have fixed it now. As far as I have tested it is working
correctly. And it speeds up text output by about 300%. Maybe someone
should take a look at it.
Bugzilla #511
Greetings,
Timo
Aleksey Bragin wrote:
> There is an undecided problem: should we rebranch 0.3.1 or release it
> as it is. I prefer rebranching from trunk, but that involves heavy
> bugfixing of trunk, which I want to see any way.
I don't know the state of 0.3.1 at the moment, but from what I remember it
was quite stable.
Why don't we just spend a day testing it to be sure and then release RC1.
0.3.2 could be branched directly after the 0.3.1 release.
Ged.