Hi,
I's like to suggest a workaround to the problem that we have to deal
with both RECT and RECTL structures in win32k and as they
are incompatible need to typecast in a lot of places.
RECTL is what the DDI interface uses (almost) exclusively. While the
NtGdi Interface and a lot of User structures also use RECT.
Both structures are equal, but not compatible when it comes to assigning
one to another, So we need to do all these nasty typecasts.
My suggestion is adding some defines after the inclusion of windef.h:
#define RECT RECTL
#define PRECT PRECTL
#define LPRECT LPRECTL
#define LPCRECT LPCRECTL
same for POINT and POINTL
I'd like to hear your opinion on that.
Thanks,
Timo
Looking at the patch only this looks wrong to me.
Assuming this is radio button it should use the marlett font.
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: 04 March 2009 16:30
To: ros-diffs(a)reactos.org
Subject: [ros-diffs] [mkupfer] 39871: Sascha Clausen <r4v3r AT hotmail DOT de> - Draw bullet for menu radio group. - See issue #4193 for details.
Author: mkupfer
Date: Wed Mar 4 19:29:57 2009
New Revision: 39871
URL: http://svn.reactos.org/svn/reactos?rev=39871&view=rev
Log:
Sascha Clausen <r4v3r AT hotmail DOT de>
- Draw bullet for menu radio group.
- See issue #4193 for details.
Modified:
trunk/reactos/dll/win32/user32/windows/draw.c
Modified: trunk/reactos/dll/win32/user32/windows/draw.c
URL: http://svn.reactos.org/svn/reactos/trunk/reactos/dll/win32/user32/windows/d…
==============================================================================
--- trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] (original)
+++ trunk/reactos/dll/win32/user32/windows/draw.c [iso-8859-1] Wed Mar 4 19:29:57 2009
@@ -1276,11 +1276,12 @@
yc = myr.top + SmallDiam - SmallDiam/2;
i = 234*SmallDiam/750;
i = i < 1 ? 1 : i;
- myr.left = xc - i+i/2;
+ myr.left = xc - i/2;
myr.right = xc + i/2;
- myr.top = yc - i+i/2;
+ myr.top = yc - i/2;
myr.bottom = yc + i/2;
- Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye, xe, ye);
+ // if the start and the end point are equal, Pie() only draws a single line, so start one pixel lower
+ Pie(dc, myr.left, myr.top, myr.right, myr.bottom, xe, ye+1, xe, ye);
break;
case DFCS_MENUCHECK:
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.
>