Ros-dev December 2006

ros-dev@reactos.org

26 participants
17 discussions

Re: [ros-dev] [ros-diffs] [fireball] 25049: [AUDIT] Change name everywhere back to Ariadne because real person could not be contacted. Non-working email address removed. If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation.
by Thomas Weidenmueller 05 Dec '06

05 Dec '06

> If this person doesn't contact me before finish of the audit, the copyright will be transferred to ReactOS Foundation. There's no way such a transfer could be legally backed if the person who owns the copyright doesn't agree with it. - Thomas

3 2

Re: [ros-dev] [ros-diffs] [mist] 25062: ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil. == A20 Gate and the Keyboard Controller == In order to turn on the A20 gate, the keyboard controller has to be emptied. This is done in freeldr by reading bytes until the keyboard controller signals it's empty. Intel Macs don't have PS/2 keyboard controller and the status register always reads back 0xFF, so the "there is data" bit will never be cleared. (The same problem has been in GRUB as well as i
by Aleksey Bragin 04 Dec '06

04 Dec '06

Thanks to these bugfixes, ReactOS now boots on Intel Macs (I tested it on Intel Core Duo MacMini), and in Parallels virtual machine. With the best regards, Aleksey Bragin. On Dec 4, 2006, at 6:00 PM, mist(a)svn.reactos.org wrote: > Author: mist > Date: Mon Dec 4 18:00:11 2006 > New Revision: 25062 > > URL: http://svn.reactos.org/svn/reactos?rev=25062&view=rev > Log: > ReactOS Intel Mac compatibility commits, part 1/2, by Michael Steil.

2 1

Re: [ros-dev] [ros-diffs] [gedmurphy] 25001: allow the Americans their incorrect spellings and add a correct UK resource file ; )
by Alex Ionescu 04 Dec '06

04 Dec '06

gedmurphy(a)svn.reactos.org wrote: > Author: gedmurphy > Date: Thu Nov 30 22:23:19 2006 > New Revision: 25001 > > URL: http://svn.reactos.org/svn/reactos?rev=25001&view=rev > Log: > allow the Americans their incorrect spellings and add a correct UK resource file ;) > We (Canadians) also know how to spell properly :) en-CA please! -- Best regards, Alex Ionescu Project Lead, TinyKRNL Kernel-Mode Software Design Engineer, ReactOS

9 11

04 Dec '06

On 12/4/06, Thomas Weidenmueller <w3seek(a)reactos.com> wrote: > > > If this person doesn't contact me before finish of the audit, the > copyright will be transferred to ReactOS Foundation. > > There's no way such a transfer could be legally backed if the person who > owns the copyright doesn't agree with it. I'm glad you said that, I was thinking the exact same thing but was gonna check before I posted anything. Ged.

1 0

Re: [ros-dev] [ros-diffs] [arty] 25028: Partially unregress python 2.4 installer.
by Alex Ionescu 03 Dec '06

03 Dec '06

> 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

2 1

Greek keyboard layout
by stud1281＠freemail.gr 01 Dec '06

01 Dec '06

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!

1 0

Gdi function Polygon
by Timo Kreuzer 01 Dec '06

01 Dec '06

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; }

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev December 2006