It's not UserDrawIconEx which is hacky, it's just the code you added for detecting alpha pixels
Ged.
-----Original Message-----
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of mkupfer(a)svn.reactos.org
Sent: 13 March 2009 00:21
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [mkupfer] 39997: - Add a hackfix comment for issue #4243 due to several requests.
Author: mkupfer
Date: Fri Mar 13 03:20:48 2009
New Revision: 39997
URL: http://svn.reactos.org/svn/reactos?rev=39997&view=rev
Log:
- Add a hackfix comment for issue #4243 due to several requests.
Modified:
trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c
Modified: trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/subsystems/win32/win32k/nt…
==============================================================================
--- trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] (original)
+++ trunk/reactos/subsystems/win32/win32k/ntuser/cursoricon.c [iso-8859-1] Fri Mar 13 03:20:48 2009
@@ -1389,6 +1389,7 @@
}
+/* FIXME: ReactOS specific hack */
BOOL
UserDrawIconEx(
HDC hDc,
The only things I have habitually used in rosapps are ctm, ncftp, and
download. I'd hate to see these go away. OTOH, there are quite a few
things that l would consider "tests" in rosapps that could be moved. I
think the argument that rosapps to long to build is crap. If you want to
reduce the build time, ditch explorer.
On Mar 12, 2009 11:02 AM, "Ged" <gedmurphy(a)gmail.com> wrote:
I prefer this idea.
I'd like to see rosapps removed completely and have all non essential stuff
in trunk built via an rbuild variable (turned off by default)
Ged.
-----Original Message----- From: ros-dev-bounces(a)reactos.org [mailto:
ros-dev-bounces(a)reactos.org] ...
Behalf Of Thomas Bluemel Sent: 12 March 2009 14:17 To: ReactOS Development
List Subject: Re: [ros-de...
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack
of overall structure. Currently ReactOS is loosely compatible with
NT, 2000, XP, and even Vista. However, I believe that in order to
achieve true stability and compatibility some changes should be
implemented. I'm offering my opinion as a suggestion of how to
structure things. While I believe that everyone should be allowed to
have fun developing a great project, I believe that we can still do
this, while maintaining a little more structure. Please feel free to
comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed
that ROS is suffering from moving target syndrome. Microsoft
continually releases new versions of Windows each year, and ROS
struggles to keep up. driver compatibility, app compatibility, etc.
are all affected by this. Development is all over the place. If
someone knows how to implement a vista API call, they do it. XP?
Same, etc. The problem is this can cause compatibility issues with
drivers and apps that do DLL hooking, as well as other oddball
scenarios. In order to have truely 100% compatibility, we need to
find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003,
to serve as the trunk (I currently recommend Windows XP since it is
compatible with nearly everything out there.) All core development
will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and
Windows Vista specific code. Any platform specific code will go into
this branch. Any code that is no longer valid will be removed from
this branch. This allows multiple versions of Windows to be targetted
at the same time.
The trunk will continue on it's path until a) It is 90-100%
compatible with most apps/drivers or b) XP/2003 become so old and out
of date they aren't used by anyone anymore, similar to the way
98/NT4/2000 are now. If either of those scenarios happen, we vote to
switch to a different branch. We should avoid switching to the most
cutting edge version of windows, however, and instead focus on the
most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
Both of these are very bad practices. Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list. For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework. Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN. If we all write tests,
This will help identify bugs in ROS vs Windows. Low level tests are
ESPECIALLY needed. Our driver compatibility currently sucks, and it's
getting worse every day. Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in
userland. This process should be avoided. All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope
that we can work on getting at least some of these opinions
implemented so that we may build a truly great Microsoft Windows
Compatible Alternative!
Thanks,
Richard Campbell
Restructuring ReactOS
Hi Guys,
One of the big issues I'm seeing with regards to ReactOS is the lack
of overall structure. Currently ReactOS is loosely compatible with
NT, 2000, XP, and even Vista. However, I believe that in order to
achieve true stability and compatibility some changes should be
implemented. I'm offering my opinion as a suggestion of how to
structure things. While I believe that everyone should be allowed to
have fun developing a great project, I believe that we can still do
this, while maintaining a little more structure. Please feel free to
comment on this email.
First Issue: Moving Target
Every since I first started watching ReactOS in 2001, I've noticed
that ROS is suffering from moving target syndrome. Microsoft
continually releases new versions of Windows each year, and ROS
struggles to keep up. driver compatibility, app compatibility, etc.
are all affected by this. Development is all over the place. If
someone knows how to implement a vista API call, they do it. XP?
Same, etc. The problem is this can cause compatibility issues with
drivers and apps that do DLL hooking, as well as other oddball
scenarios. In order to have truely 100% compatibility, we need to
find a way to deal with this type of development.
I propose picking a single target, Either Windows XP or Windows 2003,
to serve as the trunk (I currently recommend Windows XP since it is
compatible with nearly everything out there.) All core development
will be based around this. Our releases will be based around this.
Branches will be created for Windows 7, Windows Server 2008, and
Windows Vista specific code. Any platform specific code will go into
this branch. Any code that is no longer valid will be removed from
this branch. This allows multiple versions of Windows to be targetted
at the same time.
The trunk will continue on it's path until a) It is 90-100%
compatible with most apps/drivers or b) XP/2003 become so old and out
of date they aren't used by anyone anymore, similar to the way
98/NT4/2000 are now. If either of those scenarios happen, we vote to
switch to a different branch. We should avoid switching to the most
cutting edge version of windows, however, and instead focus on the
most widely used version at the time.
Second Issue: ROS Hacks
I've noticed that a lot of times, people implement app specific hacks
in ROS, or worse, they implement ROS specific hacks in different apps.
Both of these are very bad practices. Instead of doing either of
these, I'd recommend discussing the problems you find with the other
developers over the mailing list. For instance, if app XYZ is
working, rather than submitting a hackish patch to get it to work,
find the root cause of the issue, and solve it there or ask for help
to solve it.
Third Issue: Unit Tests
While there are winetests as well as other small tests, ReactOS (That
i know of, unless it's in a seperate repo) does not have an official
testing framework. Each developer here should take some time out and
write a test for every api currently supported by windows, make it
pass on Windows, and then commit it to SVN. If we all write tests,
This will help identify bugs in ROS vs Windows. Low level tests are
ESPECIALLY needed. Our driver compatibility currently sucks, and it's
getting worse every day. Unit testing for driver specific APIs and
the HAL would help improve ROS dramatically.
Final Issue: Stop mixing user and kernel mode code.
On occasion i see developers use ReactOS specific kernel mode code in
userland. This process should be avoided. All ROS apps should work
on both Windows and ROS, and should not contain any ROS specific
checks,etc. This goes back to the second issue.
I look forward to hearing your responses to my opinion, and I hope
that we can work on getting at least some of these opinions
implemented so that we may build a truly great Microsoft Windows
Compatible Alternative!
Thanks,
Richard Campbell
Hi,
Qemu w Head:
(subsystems/win32/win32k/ntuser/desktop.c:612) RtlQueryRegistryValues
failed for PaintDesktopVersion (c0000034)
err:(base/system/winlogon/screensaver.c:86) ImpersonateLoggedOnUser()
failed with error 5
(ntoskrnl/se/semgr.c:613) Denying access for caller: granted 0x600e8,
desired 0xf01ff (generic mapping 80F290E8)
Assertion 'PointerPte->u.Hard.Valid == 0' failed at
ntoskrnl/mm/hypermap.c line 100
Entered debugger on embedded INT3 at 0x0008:0x808c1e7e.
kdb:> bt
Eip:
<NTOSKRNL.EXE:c1e7f>
Frames:
<NTOSKRNL.EXE:7c608>
<NTOSKRNL.EXE:7615f>
On Tue, Mar 10, 2009 at 4:53 AM, Aleksey Bragin <aleksey(a)reactos.org> wrote:
> Boot is broken for me in VMWare, with an assert being hit in
> hypermap.c:178.
>
>
> WBR,
> Aleksey Bragin.
>
Boot is broken for me in VMWare, with an assert being hit in
hypermap.c:178.
WBR,
Aleksey Bragin.
On Mar 10, 2009, at 3:31 AM, ros-arm-bringup(a)svn.reactos.org wrote:
> Author: ros-arm-bringup
> Date: Tue Mar 10 03:31:14 2009
> New Revision: 39925
>
> URL: http://svn.reactos.org/svn/reactos?rev=39925&view=rev
> Log:
> - Implement a new Hyperspace Mapping Interface:
> - The new interface is portable and much faster than before.
> For example, unmapping a hyperpage is almost a one-line operation.
> - The new interface is also thread-safe and uses the EPROCESS
> hyperspace spinlock.
> - However, in order to isolate from React Mm internals, the
> Hyper IRQL and Process are stored as globals, so this will not work
> on SMP.
> - For now, mapping vs. zero PTEs are not treated differently,
> but the two interfaces have been separated pending future work.
> - Performance tests with _rdtsc resulted in an improvement of
> over 300% compared to the old interface.
> - Hyperspace mappings are frequent, so the improvement is
> noticeable during startup (3/10ths of a second).
> - This also fixes incorrect initializtion of hyperspace --
> pages were zeroed out (which requires hyperspace) before hyperspace
> was created.
Hi,
I notice that in Windows Vista - and also Windows XP - there seems to
be an undocumented field in PEB.
>From Windbg, I found some below fields in PEB structure'
...
+0x064 NumberOfProcessors : Uint4B
+0x068 NtGlobalFlag : Uint4B
+0x070 CriticalSectionTimeout : _LARGE_INTEGER
...
We can see that NtGlobalFlag is at offset 0x68, and is 4 bytes field.
So the next field should be at 0x6C. However, CriticalSectionTimeout
is at 0x70.
- So the question is why that happens? I suspect that there is an
undocumented field after NtGlobalFlag, which is removed from the
debugging data. Any idea?
- Another thing: ReactOS now faithfully declares the PEB structure
like above, without that secret 4 bytes hole. As a result, the
ReactOS's PEB size is 4 bytes short than PEB structure in Windows. Do
we need to care about that? Or not?
Thanks,
J
