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
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" jimtabor@adsl-64-217-116-74.dsl.hstntx.swbell.net To: "ReactOS Development List" ros-dev@reactos.org 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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
Gabriel ilardi gabrielilardi@hotmail.it 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.
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 gabrielilardi@hotmail.it 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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 magnus@greatlord.com 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 gabrielilardi@hotmail.it wrote: Dear devs,
There's a current limitation in xp, setup canformat 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 Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev%3E
_______________________________________________
Ros-dev mailing list Ros-dev@reactos.org 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