Hi All!
(subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 6010078
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x2d80000
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 6010078
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 6010078
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1020000
(subsystems\win32\win32k\ntuser\windc.c:156) FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> 14010092
(subsystems\win32\win32k\objects\dc.c:2549) DC_FreeDC DC_ATTR 0x1030000
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:551) ENTER!!!!!! DCX_CACHE!!!!!! hDC-> 14010092
(subsystems\win32\win32k\ntuser\windc.c:272) Exit!!!!! DCX_CACHE!!!!!! hDC-> 14010092
Problem, Two Window DCE with DC objects are created and used through out the whole system and the
ownership was passed to NULL for both DC objects. The dcattr, allocated and ownership belongs to the
original process. So when testing the dcattr in user mode, creates user exception faults.
DC object one: 6010078 and object two: 14010092.
The Fix:
First, I free the "non owned window (DCX_CACHE) DCE DC" dcattr before the DC is placed in
"inaccessible mode" so the ownership of the dcattr is not lost. All traces of ownership comes from
the DC handle information. Once it is set NULL it is lost.
Second, I display the "Enter" (GetDCx) and "Exit" (ReleaseDC) for non owned window DCE DC. I'm doing
this so I can trace it out.
and,,,....
For DCX_CACHE DCE: ENTER "Get" allocate a new dcattr for the current process. EXIT "Release" free
the dcattr for that process. Windows does something similar to this.
Here is the patches,,, The test is: click on the time clock at the bottom right. Click on adjust
time and date. There you go.... the Gdi patch allows access to the dcattr pen for the DCE DC now.
It works,,,,, Thanks, James
subsystems/win32/win32k:
Index: ntuser/windc.c
===================================================================
--- ntuser/windc.c (revision 29544)
+++ ntuser/windc.c (working copy)
@@ -153,6 +153,8 @@
}
else
{
+ DPRINT1("FREE DCATTR!!!! NOT DCE_WINDOW_DC!!!!! hDC-> %x\n", pDce->hDC);
+ DC_FreeDcAttr(pDce->hDC, NULL); // Free the dcattr!
DC_SetOwnership(pDce->hDC, NULL); // This hDC is inaccessible!
}
@@ -267,6 +269,9 @@
dce->DCXFlags |= DCX_DCEEMPTY;
}
}
+ DPRINT1("Exit!!!!! DCX_CACHE!!!!!! hDC-> %x \n", dce->hDC);
+ DC_FreeDcAttr(dce->hDC, NULL); // Free the dcattr!
+ DC_SetOwnership(dce->hDC, NULL);
}
return 1;
}
@@ -543,6 +548,14 @@
DceUpdateVisRgn(Dce, Window, Flags);
}
+ if (Dce->DCXFlags & DCX_CACHE)
+ {
+ DPRINT1("ENTER!!!!!! DCX_CACHE!!!!!! hDC-> %x\n", Dce->hDC);
+ DC_SetOwnership( Dce->hDC, PsGetCurrentProcess());
+ DC_AllocateDcAttr( Dce->hDC, NULL);
+ DCU_SynchDcAttrtoUser( Dce->hDC, -1); // Copy data from dc to dcattr
+// Dce->pProcess = PsGetCurrentProcess();
+ }
return(Dce->hDC);
}
dll/win32/gdi32:
Index: dc.c
===================================================================
--- dc.c (revision 29544)
+++ dc.c (working copy)
@@ -320,7 +320,7 @@
STDCALL
GetDCObject( HDC hDC, INT iType)
{
-#if 0
+//#if 0
if((iType == GDI_OBJECT_TYPE_BRUSH) ||
(iType == GDI_OBJECT_TYPE_EXTPEN)||
(iType == GDI_OBJECT_TYPE_PEN) ||
@@ -348,7 +348,7 @@
}
return hGO;
}
-#endif
+//#endif
return NtGdiGetDCObject( hDC, iType );
}
Hi,
what I can tell right away, is that it's a very interesting, suitable
for diploma thesis work, but it's a challenge. You should posses
general knowledge about operating systems development, and more
specific knowledge about NT-based kernels, L4, and Linux.
The only problem may be
> I am not very experienced in C or assembler programming but am
> motivated to learn. But before i start working on that topic i have
but that could be compensated by outstanding OS dev skills /
architecture knowledge.
From the side of ReactOS Development Team, I'm sure you will have
support in terms of either visiting the irc-channel #reactos on
freenode or asking questions in this mailing list.
WBR,
Aleksey Bragin.
On Oct 10, 2007, at 3:08 PM, Henning Schild wrote:
> Hi there,
>
> i am thinking of porting ros to the L4 micro-kernel as topic for my
> diploma thesis. The operating systems group in Dresden already ported
> Linux to L4 (http://os.inf.tu-dresden.de/L4/LinuxOnL4/) and proofed
> that L4 offers all that is needed to run an operating system in
> userspace on top of it.
>
> The goal of the work would be to be able to run windows applications
> next to miro-kernel applications. And to compare the performance with
> that of pure ros, L4Linux/wine and windows. A comparison between the
> port and L4Linux could also be part of the work. (mapping processes to
> L4 tasks, memory management, interrupt-handling and so on)
>
> I am not very experienced in C or assembler programming but am
> motivated to learn. But before i start working on that topic i have
> some questions on the portability of ros.
>
> In svn and on the ros website i found that there is a ppc port of ros.
> And on irc someone told me that there is ongoing work on a ros
> usermode
> port. I also read about a xen port. But i did not yet find working
> copies of the any of that ports. I built ros for i386 on my
> machine and was able to boot it in vmware. I also tried building the
> latest svn version with ROS_ARCH=powerpc but that did not succeed.
>
> 1. Did anyone ever finish a port to another arch?
> 2. How portable is ros in general? Meaning how much code would have to
> be changed. I hope there are abstractions and only 10-15% of the
> kernel
> would have to be changed.
> 3. Do you believe that one person new to ros can finish that kind of
> work in 6 months? I know that might be hard to answer but how long did
> any of you need to learn ros in detail?
> 4. If there are working ports, how long did it take to implement
> them?
> If there are not, what are the reasons they where never finished? I am
> thinking of lots of assembler and i386 hacks.
>
> 5. Finally, what do think of the idea itself?
>
> I hope you take the time to answer my questions. I am still on the way
> to determine whether i really want to do that and whether i can do
> this
> in 6 months.
>
> regards,
> Henning Schild
Why was I added to this?
Ask first! I can not do it all!
B^|
James
ReactOS.Bugzilla(a)www.reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=2081
>
>
> amine48rz <amine48rz(a)gmail.com> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> AssignedTo|ros-bugs(a)reactos.org |jimtabor@adsl-64-217-116-
> | |74.dsl.hstntx.swbell.net
>
>
>
>
Hi!
ReactOS.Bugzilla(a)www.reactos.org wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=1172
> ------- Comment #16 From hpoussin 2007-10-08 10:44:44 CET -------
>
> The device has been detected by PCI bus, and (as you didn't had any popup for
> it), its driver has been found and probably installed.
> I fixed a bug in driver installation in r29441, maybe it will help.
> If it still doesn't work, can you enable debug output in
> dll/win32/setupapi/devinst.c and dll/win32/netcfgx/netcfgx.c?
>
Okay! Will do!
Since the bug report is closed, I guess we can work on the ML. I'll post my tests
results.
Thanks,
James
Ok, that's good then, no need to delete it. But moving to rosapps may
be a not bad idea (still including into the build).
WBR,
Aleksey Bragin.
On Oct 9, 2007, at 3:50 PM, Ged wrote:
> Aleksey Bragin wrote:
>> Is there a reason to keep the wordpad we have? Is it better,
>> worse, differences mergeable, etc?
>
> Our wordpad code is a great framework to build a much better, MDI
> implementation of Wordpad.
>
> I added it in the hope that any potential 'would-be' developers
> could use it
> as a learning project into the world of Win32. As it is no one has
> yet taken
> it up, which is a bit of shame.
>
> It can be taken out of the build and even moved to ros-apps, but it
> would be
> a shame to delete it completley, as someone might one day take up the
> challenge.
>
> Ged.
Is there a reason to keep the wordpad we have? Is it better, worse,
differences mergeable, etc?
WBR,
Aleksey Bragin.
On Oct 9, 2007, at 1:00 PM, gedmurphy(a)svn.reactos.org wrote:
> Author: gedmurphy
> Date: Tue Oct 9 13:00:56 2007
> New Revision: 29469
>
> URL: http://svn.reactos.org/svn/reactos?rev=29469&view=rev
> Log:
> add wine's wordpad as the default
Yes.
Either reverse engineer and write docs (which can be used by ReactOS
developers, provided they contain no source code derived from
disassembly), or reverse engineer and write test cases.
The latter method is [presumably] used by Wine developers, and it
provides a very good legal ground.
With the best regards,
Aleksey Bragin.
On Oct 9, 2007, at 5:12 AM, Josh H. wrote:
> Is it okay to reverse through disassembly as long as clean room
> methods
> are used(only writeing docs, not implementing it yourself)?
>
> http://www.computerworld.com/softwaretopics/software/appdev/story/
> 0,10801,65532,00.html
> http://en.wikipedia.org/wiki/Clean_room_design
Anyone wants to comment on this?
_____
From: Marc Piulachs [mailto:marc.piulachs@codexchange.net]
Sent: Saturday, October 06, 2007 10:24 PM
To: 'ros-dev(a)reactos.org'
Subject: rbuild problems/suggestions
Having worked with rbuild for a few weeks I have identified some problems
that would like to share. I also would like to hear the developers' opinions
about all of these issues because I want to start working to solving them.
A) The behavior of the "include" + "directory" tags are inconsistent when an
"include" is placed inside a "directory" for
example:
Correct: (expected : ke/i386/boot.S)
<directory name="ke">
<if property="ARCH" value="i386">
<directory name="i386">
<file
first="true">boot.S</file>
Incorrect: (expected : reactos/reactos.rbuild
real : reactos/reactos/reactos.rbuild)
<directory name="reactos">
<xi:include
href="reactos/reactos.rbuild" />
</directory>
should be:
<directory name="reactos">
<xi:include href="reactos.rbuild" />
</directory>
B) The "oldcrt" attribute is no longer used and can be removed.
C) The module types "Iso" , "LiveIso" , "IsoRegTest" and "LiveIsoRegTest"
are IMHO hacks introduced to be able use the makefile generation code.
rbuild is C++ so with a small code refactor they can be easly removed.
D) Any module is using the "EmbeddedTypeLib" module type , is really needed
or can be removed?
E) IMHO the "ElfExecutable" is incorrect . I posted my reasons some time
ago:
http://www.reactos.org/archives/public/ros-dev/2007-September/009770.htmlhttp://www.reactos.org/archives/public/ros-dev/2007-September/009771.htmlhttp://www.reactos.org/archives/public/ros-dev/2007-September/009779.html
F) The module type "alias" is only used for HAL related modules and IMHO it
isn't requiered because the problem it tries to
solve can be easly solved using "if" tags and conditional compilation.
http://www.reactos.org/archives/public/ros-dev/2007-September/009798.html
There are several reasons for this change:
- Currently every platform requires 3 new HAL modules. In the
future if new platforms are supported for example (X86 , XBOX , PPC , AMD64
, MIPS , IA64 , ARM ... ) 3 x 7 = 21 modules .. see what I'm saying?
- It simplifies backends work. No need to include logic for
alias handling.
- Conceptually wrong . every module represents a particular
functionality when you compile the module it should just reconfigure itself
to produce the appropriate image for the configured architecture .It a good
idea to have a true componentized operating system.
Regarding the ModuleType IMHO they should be used to provide information
that describes the module output/target not the build process! Iso , LiveIso
, Alias , ... all of them are meaningless they are not true metadata.
Long term enhancements:
X) tags like "linkerflag" or "compilerflag" are gcc/mingw specific and
should be replaced with other tags that provide the
equivalent functionality using a more abstract aproach so other
backends/compilers could benefit from it. rbuild files should
only describe the source code and the compilation process without including
specific information.
/Marc
