Win32/Gdi32 rewrite

[James Tabor]

Hi all,
I'm giving in to the idea of having two dc_attrs.

From, Windows Graphics Programming Win32 GDI and DirectDraw -> 3.8 GDI KERNEL MODE DATA STRUCTURE -> 
Device Context in the GDI Engine, second to the last paragraph:

Field pdcattr points to the DC_ATTR structure for that device context in user mode address space, 
which contains most device context settings. The DCOBJ structure has a duplication of it in its 
dcAttr field. It's possible the GDI designers want setting DC attributes to be efficient, with as 
little kernel mode code involvement as possible. This requires a DC_ATTR structure in user mode. But 
they also want to be able to access it easily in kernel mode, which requires a copy of DC_ATTR in 
kernel mode. Certain flags may be used to synchronize the two copies of DC_ATTR.

typedef struct
{
// ......snip......
void * pdcattr; // point to user mode DCATTR
DCLEVEL dcLevel; // 0x030 0x1B8(440) bytes
DC_ATTR dcAttr; // 0x1C8(456) bytes
// ......snip......
} DCOBJ;

I did set up Ros DC structure to have the dc_attr pointer stored. I guess it's time to move the old 
WIN_DC_INFO stuff over to the new kernel mode dc_attr and use the dirty flags for synchronizing. 
This will fix my memory access problems too. I did an experiment to test the idea of just copy if it 
was dirty and all my problems went away.

FYI,
James

[Magnus Olsen]

Hi
It is good idea doing it.

I am thinking we should using  the internal document structs for win32k that
he did for directx
instead using my home mades ones. It does not redures the overheade,

Next issue I got is the EDD_SURFACE  (see  Windows Graphics Programming
Win32 GDI and DirectDraw  chapther  3.9 )
it contain value for iVisRgnUniqueness, but this value are share memory with
gdi32.dll, Here is why we need implement it to
gdi share memory or some other way it is done ?.

Todo a DirectDraw/D3D/DirectX graphicing drawing/D3D we need always rest the
iVisRgnUniqueness
before we calling DdBlt or other graphice drawing api if we whant it show on
the screen. other wise nothing will show or happen.
This is not true for few graphice cards drivers, But it is true for ATI, S3
and allot other  but not for few other, driver.
The iVisRgnUniqueness are global in win32k, I meaing it is same for all
surface. so it change very often in DirectX, and causing
allot of context switch if we should using the NtGdiDdResetVisrgn.
Microsoft known  they self it is madess doing extra context switch
for it.  that so they decide doing it in user mode,

The question is, are this value really in gdi32 share memory or do they
doing it some other way. And I have not figout
that out, only it is done in user mode in windows nt all version.  The Yang
book  Windows Graphics Programming Win32
GDI and DirectDraw does not mentor this either.

----- Original Message ----- 
From: "James Tabor" [e-mail]
To: "ReactOS Development List" [e-mail]
Sent: Friday, July 27, 2007 9:10 PM
Subject: [ros-dev] Win32/Gdi32 rewrite
> Hi all,
> I'm giving in to the idea of having two dc_attrs.
>
> From, Windows Graphics Programming Win32 GDI and DirectDraw -> 3.8 GDI

KERNEL MODE DATA STRUCTURE ->
> Device Context in the GDI Engine, second to the last paragraph:
>
> Field pdcattr points to the DC_ATTR structure for that device context in

user mode address space,
> which contains most device context settings. The DCOBJ structure has a

duplication of it in its
> dcAttr field. It's possible the GDI designers want setting DC attributes

to be efficient, with as
> little kernel mode code involvement as possible. This requires a DC_ATTR

structure in user mode. But
> they also want to be able to access it easily in kernel mode, which

requires a copy of DC_ATTR in
> kernel mode. Certain flags may be used to synchronize the two copies of

DC_ATTR.
> typedef struct
> {
> // ......snip......
> void * pdcattr; // point to user mode DCATTR
> DCLEVEL dcLevel; // 0x030 0x1B8(440) bytes
> DC_ATTR dcAttr; // 0x1C8(456) bytes
> // ......snip......
> } DCOBJ;
>
> I did set up Ros DC structure to have the dc_attr pointer stored. I guess

it's time to move the old
> WIN_DC_INFO stuff over to the new kernel mode dc_attr and use the dirty

flags for synchronizing.
> This will fix my memory access problems too. I did an experiment to test

the idea of just copy if it
> was dirty and all my problems went away.
>
> FYI,
> James
>
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

[Gabriel ilardi]

Dear devs,

There's a current limitation in xp, setup can format hds in fat32 at maximum 
32gb, this is a setup format limitation, I've found an open source utilty to 
format fat32 with its native limitation (2tb).
Hope it can be be of use to reactos.

http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm

WBR,

Gabriel ilardi
gabriel_it

_________________________________________________________________
C'è una nuova amica su Messenger… E' Doretta! 
http://www.doretta82.it/banner/index.html

[CK Raju]

Gabriel ilardi [e-mail] wrote: Dear devs,

There's a current limitation in xp, setup can format hds in fat32 at maximum 
32gb, this is a setup format limitation, I've found an open source utilty to 
format fat32 with its native limitation (2tb).
Hope it can be be of use to reactos.

http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm

I would like to inform that a group of developers here has succeeded in cross-installing GNU Hurd with an installer based on 2.4 Linux kernel. That was with LX installer for GNU Hurd, released last week.

In most of the installations, its disturbing to find that existing partitions are disturbed when attempted in the native way with ReactOS.

If the developers are not against a cross-installation method, then we can have that *unstable* part (however limited it may be) converted to a stable part - as 2.4 Linux kernel is capable of handling the current requirements with quite ease.

CK Raju
MES College of Engineering, Kuttippuram
India

---------------------------------
 5, 50, 500, 5000. Store N number of mails in your inbox. Click here.

[Magnus Olsen]

Hi
The problem is reactos booting process are very simluare to NT 
it only exists one bootloader for reactos it is freeldr to booting 
reactos with, freeldr can booting NT4, Alesky demostarted we 
can boot nt4 with freeldr.

----- Original Message ----- 
  From: CK Raju 
  To: ReactOS Development List 
  Sent: Monday, July 30, 2007 12:09 PM
  Subject: Re: [ros-dev] setup's fat32 format

Gabriel ilardi [e-mail] wrote:
    Dear devs,

There's a current limitation in xp, setup can format hds in fat32 at maximum 
    32gb, this is a setup format limitation, I've found an open source utilty to 
    format fat32 with its native limitation (2tb).
    Hope it can be be of use to reactos.

http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm

I would like to inform that a group of developers here has succeeded in cross-installing GNU Hurd with an installer based on 2.4 Linux kernel. That was with LX installer for GNU Hurd, released last week.

In most of the installations, its disturbing to find that existing partitions are disturbed when attempted in the native way with ReactOS.

If the developers are not against a cross-installation method, then we can have that *unstable* part (however limited it may be) converted to a stable part - as 2.4 Linux kernel is capable of handling the current requirements with quite ease.

CK Raju
  MES College of Engineering, Kuttippuram
  India

------------------------------------------------------------------------------
  5, 50, 500, 5000. Store N number of mails in your inbox. Click here.

------------------------------------------------------------------------------

_______________________________________________
  Ros-dev mailing list
  [e-mail]
  http://www.reactos.org/mailman/listinfo/ros-dev

[CK Raju]

But is the process of recognising other partitions
stable ? Can ReactOS be installed in extended
partitions ? Does it recognise extended partitions now
? These are the questions that will be eliminated with
adoption of a cross-installer.
CK Raju
--- Magnus Olsen [e-mail] wrote:
> Hi
> The problem is reactos booting process are very
> simluare to NT 
> it only exists one bootloader for reactos it is
> freeldr to booting 
> reactos with, freeldr can booting NT4, Alesky
> demostarted we 
> can boot nt4 with freeldr.
>
> ----- Original Message ----- 
>   From: CK Raju 
>   To: ReactOS Development List 
>   Sent: Monday, July 30, 2007 12:09 PM
>   Subject: Re: [ros-dev] setup's fat32 format
>
> Gabriel ilardi [e-mail] wrote:
>     Dear devs,
> There's a current limitation in xp, setup can
>
> format hds in fat32 at maximum 
>     32gb, this is a setup format limitation, I've
> found an open source utilty to 
>     format fat32 with its native limitation (2tb).
>     Hope it can be be of use to reactos.

http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm
> I would like to inform that a group of developers
> here has succeeded in cross-installing GNU Hurd with
> an installer based on 2.4 Linux kernel. That was
> with LX installer for GNU Hurd, released last week.
>
> In most of the installations, its disturbing to
> find that existing partitions are disturbed when
> attempted in the native way with ReactOS.
>
> If the developers are not against a
> cross-installation method, then we can have that
> *unstable* part (however limited it may be)
> converted to a stable part - as 2.4 Linux kernel is
> capable of handling the current requirements with
> quite ease.
>
> CK Raju
>   MES College of Engineering, Kuttippuram
>   India

------------------------------------------------------------------------------
> 5, 50, 500, 5000. Store N number of mails in your
> inbox. Click here.

------------------------------------------------------------------------------
> Ros-dev mailing list
>   [e-mail]
>   http://www.reactos.org/mailman/listinfo/ros-dev%3E

_______________________________________________
> Ros-dev mailing list
> [e-mail]
> http://www.reactos.org/mailman/listinfo/ros-dev

Why delete messages? Unlimited storage is just a click away. Go to http://help.yahoo.com/l/in/yahoo/mail/yahoomail/tools/tools-08.html