> Modified: branches/arty-stable/reactos/ntoskrnl/ps/process.c
> URL: http://svn.reactos.org/svn/reactos/branches/arty-stable/reactos/ntoskrnl/ps…
> ==============================================================================
> --- branches/arty-stable/reactos/ntoskrnl/ps/process.c (original)
> +++ branches/arty-stable/reactos/ntoskrnl/ps/process.c Sun Dec 3 13:42:35 2006
> @@ -560,6 +560,8 @@
> /* Create or Clone the Handle Table */
> ObpCreateHandleTable(Parent, Process);
>
> + memset(&Process->VadRoot, 0, sizeof(Process->VadRoot));
> +
> /* Set Process's Directory Base */
> MmCopyMmInfo(Parent ? Parent : PsInitialSystemProcess,
> Process,
>
>
>
Please use RtlZeroMemory in the kernel.
Please keep in mind the compartmentalization of the kernel for large
objects. Such a line should go somewhere like MmInitailizeXxx for the
process.
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
Hello guys. Sorry for bothering you again but can someone pls commit my Greek keyboard layout file? I want it to be included to version 0.3.1 - which I suppose will be available soon - so that we can have a true Greek character support with punctuation issues and other stuff.
The link is the following
http://www.reactos.org/bugzilla/show_bug.cgi?id=1831
And a screenshot with proof of it in action is here
http://img148.imageshack.us/my.php?image=greekku9.jpg
Thnx in advance!
Hi,
Recently I have started reading Feng Yuan - Windows Graphics Programming
Win32 GDI and found that this is a very interesting part of Windows /
ReactOS I'd like to take a closer look to.
I started to have a look at this when I noticed 2 things, that made my
desk.cpl don't work correctly in ROS:
1.) SetDCPenColor is not implemented (I am currently working on a
usermode implemenatation, I have finished GetDCPenColor, GetDCBrushColor
is the same, Set... will follow soon.)
2.) Polygon() didn't work as expected. I used it to draw a tiny triangle
on a button, but it doesn't look correct. I first thought it was because
the triangle was simply too small (didn't show the lowest pixel), but it
was because it is redirected to NtGdiPolygon. (instead of calling
NtGdiPolyPolyDraw, wich is the way it works in windows. NtGdiPolygon
doesn't seem to exist in Windows, so it seems it's currently only a
Kernelmode implementation of Polygon and NtGdiPolyPolyDraw seems not to
be implemented in ROS yet).
Polygon is exspected to automatically close the polygon, but
NtGdiPolygon doesn't do this. I will have a closer look on this later
and hope I can fix this. My questions:
Is there a reason it doesn't do it? Should the closing of the Polygon
(simply by adding the first coordinates at the end?) be done in the
usermode function (wich is not existing yet) or in the current
implementation in win32k?
Looking at the gdi code I found out that some things (handle validation
for example) seem to be different than in windows. F.e. the reuse
counter seems to be ignored. I have written a small GdiTest app to
analyse the diffences between Win and ROS (General app is ready, I will
write test functions soon, maybe tomorrow) . I'll start by writing some
test cases, that I think might fail on ROS. If there's someone who likes
to help me writing tests I'd really appreaciate that, just let me know.
Then there's another thing that I thought about: Windows has one list of
gdiobjects shared between kernel and all processes, although handles are
only valid for the process that has created them (only Stockobjects are
global). That seems to be a bad idea, I didn't try it yet, but what if a
usermode app zeroes out the complete gdi handle table? I guess Windows
would crash. And there might be more dangoerous risks, because of that.
So why is the table not implemented locally?
Some thoughts:
Global handle list:
+ less memory needed
- big chance of crashing windows by usermode apps
Local handle list
- more memory needed
+ better chance of paging the memory (global list would never be paged
as it is always in use)
+ no chance for a user app to crash windows or crash other apps by
messing up the handle table
+ no more need to veryfy the process member in the handle table entry
A shared memory section seems to be a real risky thing. It's big enough
to put binary data there and it might be possible to make another
process with higher privaliges execute that code.I first thought of the
DC's AbortProc, but that is probaly handled by the kernel to not exceed
user limits(?).
Implementing the handle table locally would not beak any APIs. Only some
system apps that use the GdiQueryTable and directly use the table would
experience a slightly different behaviour: Only locally created handles
would be accessable. Would there be a problem doing that?
At last my usermode implementation of GetDCPenColor, I would like some
feedback:
#define GDI_HANDLE_UPPER_MASK 0xffff0000
#define GDI_HANDLE_GET_UPPER(h) \
(((ULONG_PTR)(h)) & GDI_HANDLE_UPPER_MASK)
COLORREF
GetDCPenColor(HDC hDC)
{
PGDI_TABLE_ENTRY pEntry = GdiHandleTable + GDI_HANDLE_GET_INDEX(hGdiObj);
if(pEntry->KernelData != NULL)
{
ULONG Upper = GDI_HANDLE_GET_UPPER(hGdiObj)
if ( Upper == GDI_HANDLE_GET_UPPER(pEntry->Type)
&& GDI_HANDLE_GET_TYPE(Upper) == GDI_OBJECT_TYPE_DC )
{
if((HANDLE)((ULONG_PTR)pEntry->ProcessId & ~0x1) ==
CurrentProcessId)
{
DC_ATTR* pDCData = (DC_ATTR*)pEntry->UserData
if(pDCData)
{
return pDCData->crPenClr;
}
}
}
}
return CLR_INVALID;
}
Thanks, adding this value set to x86 made the WinPcap installer start.
I wonder where we should set this.
Since ReactOS has only x86 for now,
I guess we can add it to the default registry set (hivesys.inf)
Kind regards,
Sylvain Petreolle (aka Usurp)
--- --- --- --- --- --- --- --- --- --- --- --- ---
Run your favorite Windows apps with free ReactOS : http://www.reactos.org
Listen to non-DRMised Music: http://www.jamendo.com
Hi guys. Can anyone take care of the resource files we have added to bugzilla? It's been long time since a commit was made for these ones.
Thnx in advance
I have been an active member of the ReactOS community for some time
now. I discovered this project a few months before the 0.2.9 release
and was instantly amazed by the smart people and amount of hard work
that has gone into this project now spanning a decade.
Everyone knows me in #reactos by the name "encoded".
Qualifications:
- I compile and test ros almost every day, report bugs and participate
in developer discussions.
- I'm an amature coder, student of computer engineering(www.pupr.edu)
- I like to program(a lot), so I understand what's going on pretty well.
- I also know a bit of HTML.
Goals for the newsletter:
Not just the "there where commits about this and that this week" type
of publication, I want to write articles about how foo.dll and bar
feature work in windows, their current state in ROS.
I want to create a medium which gives people outside the close nit
ReactOS community a sense of belonging, that sparks the interest of
coders and people in general. A medium that actually reflects the
current state of affairs in ros, tips, tricks, how tos and even recent
bugs and regressions!
Note:
-I am a full time student and also have a job, so I would prefer a
bi-weekly newsletter, but could also work in a weekly time frame if
needed.
-Those nice little articles about foo.dll and bar features will be
dependant(specially the ros side of it) on devs helping out in writing
them.
-I LOVE REACTOS!!!
fireball(a)svn.reactos.org wrote:
> Author: fireball
> Date: Mon Nov 27 00:46:45 2006
> New Revision: 24848
>
> URL: http://svn.reactos.org/svn/reactos?rev=24848&view=rev
> Log:
> i386BootDrive and i386BootPartition are ULONGs, and before saving a byte value they must be zeroed.
Ever heard of movzx?
--
Best regards,
Alex Ionescu
Project Lead, TinyKRNL
Kernel-Mode Software Design Engineer, ReactOS
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.