Hi,
if I use the cirrus driver in qemu, I get always wrong colors. After the
first double click to the cmd icon, ros crashs in
DIB_16BPP_BitBltSrcCopy. I've add the following code:
Index: subsys/win32k/dib/dib16bpp.c
===================================================================
--- subsys/win32k/dib/dib16bpp.c (Revision 15885)
+++ subsys/win32k/dib/dib16bpp.c (Arbeitskopie)
@@ -228,6 +228,8 @@
}
else
{
+ DPRINT1("%d %d %d\n", BltInfo->SourceSurface->lDelta,
BltInfo->SourcePoint.x, BltInfo->SourcePoint.y);
+ DPRINT1("%d %d %d %d %d\n", BltInfo->DestSurface->lDelta,
BltInfo->DestRect.left, BltInfo->DestRect.top, BltInfo->DestRect.right,
BltInfo->DestRect.bottom);
I see often negative values for the source surface:
...
(subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69
(subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0
(subsys\win32k\dib\dib16bpp.c:231) -1120 -69 -69
(subsys\win32k\dib\dib16bpp.c:232) 1600 0 0 0 0
(subsys\win32k\dib\dib16bpp.c:231) -1120 0 13
(subsys\win32k\dib\dib16bpp.c:232) 1600 69 69 629 87
KeBugCheckWithTf at ntoskrnl\ke\catch.c:222
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
...
I seems that win32k doesn't handle the negative values. I doesn't know
what they mean.
- Hartmut
Joseph Miller wrote:
> So I am currently working on making my Visual GWin++
> project work under ReactOS.
If it works under windows, it should work under ROS.
If it doesn't, it's likely there is some missing functionality or bugs in
ROS at the moment.
You shouldn't modify your program to work under ROS if it breaks Windows
functionality, as it's likely to be fixed in the future.
If it works under Windows but not ROS, try to establish why and report it.
This would be a more productive way for both projects.
Regards,
Ged.
************************************************************************
The information contained in this message or any of its
attachments is confidential and is intended for the exclusive
use of the addressee. The information may also be legally
privileged. The views expressed may not be company policy,
but the personal views of the originator. If you are not the
addressee, any disclosure, reproduction, distribution or other
dissemination or use of this communication is strictly prohibited.
If you have received this message in error, please contact
postmaster(a)exideuk.co.uk
<mailto:postmaster@exideuk.co.uk> and then delete this message.
Exide Technologies is an industrial and transportation battery
producer and recycler with operations in 89 countries.
Further information can be found at www.exide.com
> revert back to 15869 for current change break 32 / 8 bpp for
> vbe drv, and vmware drv the mouse did not redaw some dialog
> box was wrong. and alot more
Can you show me how to reproduce the problems. It seems to work fine for me
in VMware with 8/16/32 bpp and in Qemu with 8/16/24 bpp (all with VBE
driver).
Gé van Geldorp.
-------- Original Message --------
Subject: Re: [ros-diffs] [greatlrd] 15879: fix bug in color fill inline
asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not
align. Clean up inline asm code.
Date: Sun, 12 Jun 2005 22:44:48 +0200
From: Hartmut Birr <hartmut.birr(a)gmx.de>
Reply-To: ReactOS Diffs List <ros-diffs(a)reactos.com>
To: ReactOS Diffs List <ros-diffs(a)reactos.com>
References: <000001c56f84$4a6757a0$6b01a8c0@PENELOPE>
greatlrd(a)svn.reactos.com wrote:
>fix bug in color fill inline asm code. Did crash cirrus drv, vmware 5 drv and if the buffer was not align. Clean up inline asm code.
>
>Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c
>
>
> ------------------------------------------------------------------------
> *Modified: trunk/reactos/subsys/win32k/dib/dib16bpp.c*
>
>--- trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:06:38 UTC (rev 15878)
>+++ trunk/reactos/subsys/win32k/dib/dib16bpp.c 2005-06-12 19:23:40 UTC (rev 15879)
>
>@@ -454,31 +436,34 @@
>
>
> ULONG delta = DestSurface->lDelta;
> ULONG width = (DestRect->right - DestRect->left) ;
> PULONG pos = (PULONG) (DestSurface->pvScan0 + DestRect->top * delta + (DestRect->left<<1));
>
>
>- color = (color<<16)|(color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */
>
>
>+ color = (color&0xffff); /* If the color value is "abcd", put "abcdabcd" into color */
>+ color += (color<<16);
>
>
>
> for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++)
>
>
>- {
>- int d0, d1, d2;
>
>
>+ {
>
>
> __asm__ __volatile__ (
> " cld\n"
>
>
>+ " mov %0,%%eax\n"
>+ " mov %1,%%ebx\n"
>
>
> " test $0x03, %%edi\n" /* Align to fullword boundary */
> " jz .FL1\n"
> " stosw\n"
>
>
>- " dec %4\n"
>
>
>+ " dec %%ebx\n"
>
>
> " jz .FL2\n"
> ".FL1:\n"
>
>
>- " mov %4,%%ecx\n" /* Setup count of fullwords to fill */
>
>
>+ " mov %%ebx,%%ecx\n" /* Setup count of fullwords to fill */
>
>
> " shr $1,%%ecx\n"
> " rep stosl\n" /* The actual fill */
>
>
>- " test $0x01, %4\n" /* One left to do at the right side? */
>
>
>+ " test $0x01, %%ebx\n" /* One left to do at the right side? */
>
>
> " jz .FL2\n"
> " stosw\n"
> ".FL2:\n"
>
>
>- : "=&A" (d0), "=&r" (d1), "=&D" (d2)
>- : "0"(color), "1"(width), "2"(pos)
>- : "%ecx");
>
>
>+ :
>+ : "r" (color), "r" (width), "D" (pos)
>+ : "%eax", "%ecx","%ebx");
>
>
> pos =(PULONG)((ULONG_PTR)pos + delta);
> }
>
>
>+
>
>
> #else /* _M_IX86 */
>
> for (DestY = DestRect->top; DestY< DestRect->bottom; DestY++)
>
>
What was wrong with the inline code from rev 15869? Previous my changes
(rev 15858), the width value was only load in the first loop. This has
crashed the vbe driver on real hardware. I've no problems with the
current and the last revision, and with normal and optimized builds. The
only difference is, that your changes needs two registers more on
optimized builds and gcc uses the stack to store some values. There
exist one problem in your changes, gcc doesn't know that edi is changed.
On other optimisation as the current one, it is possible that gcc uses
edi to recalculate the pos value. With optimized build, I mean the
optimisation, if DBG is 0.
- Hartmut
Hello list,
I am new to ReactOS, but very interested in Win32 programming. I am
also very new to Win32 and C++, but I began a project about a year ago
to develop and open source Visual C++ IDE for Win32 because I had not
found an open source one yet. Well, it was one of my first attempts at
Win32 and at C++, but I managed to create a very basic IDE and I have
successfully created several programs for both work and other projects.
Everything is based on a class called GWin. I feel like the GWin code
is very stable, even at this point, but much of the API will probably
still change as I learn about Win32. Unfortunately, the IDE code is
pretty dang crappy because I did not understand some very basic
programming concepts. To make a long story short, the IDE has been
developed to a usable point, and the code in the GWin class is worth
continuing. The IDE itself is undergoing a major rewrite for better
functionality and structure.
Yesterday I installed ReactOS for the very first time on my computer. I
was impressed with the number of programs that actually work at this
stage of development. Even Scite (an excellent, code-highlighting
editor) works! So I am currently working on making my Visual GWin++
project work under ReactOS. I have managed to get it running and
compile a test program under ReactOS, so with a little more testing, I
will release a version just for ROS. I will also be working on a
tutorial for how to get started with it. Visual GWin++ currently has
support for windows, edit controls, static controls, listbox controls,
MDI clients (limited), tabcontrols, and scrollbars (limited). The
program can load and save projects in an XML file format using libxml.
The current version is v0.02-pre-alpha. You can see the Windows version
at http://www.calcmaster.net/visual-c++/ . When the ROS version is
ready, I will release it. I would like some feedback on what you guys
think about this project and whether or not you think it will be a
benefit to ROS.
BTW, I came across some message handling bugs in ROS and I guess this is
the mailing list to report it? I will try to download the source and
look it over, but I wanted to let you guys know first. I had a handler
set up for EN_KILLFOCUS on one of my edit controls. The function was
supposed to modify another window and then return. I'm assuming what
happened was that as my function was modifying the other window, ROS
kept assuming that it needed to send more EN_KILLFOCUS messages to me to
let me know my control had lost focus. I had to add a hack to make sure
that after the handler is called the first time, it is not called again
until it has completed what it needs to do. I had a similar problem
with LBN_SELCHANGE when I tried to kill the control's parent window.
ROS assumed that this meant it needed to tell me that the selection had
changed and sent LBN_SELCHANGE. This caused the same type of loop that
I described above. Where do I look to correct this?
-Joseph
Hello,
is there some native czech speaker?
I have attached two different czech resource files of winefile: one
from WINE, and the other from ReactOS. Perhaps some one can compare
the two files and search the better alternatives where the strings
differ.
Thanks,
Martin
hbirr(a)svn.reactos.com wrote:
>Print more informations on a BSOD by enabling the debug prints to the screen.
>
>
>
>Updated files:
>trunk/reactos/ntoskrnl/ke/bug.c
>
>
>
Hi...
Erm...I don't understand this change. BSOD data is already printed on
screen during a crash.
The only thing that's not printed is ROS-Specific Debug Data, because
that's part of "debug output" and not of an official BSOD.
At least that's how it's fundamentaly defined... I really don't like
this hack, although I know you'll probably say you want the debug data
on screen, but my question is why don't you use /DEBUGPORT=SCREEN for
this? You're hacking the kernel to display debug data when debugging is
off... And I hate the #if 0 #else #endif stuff you've added, it makes
this hack even nastier! If you *really* want to bypass the debuging
design and force debug-data to be printed when it shouldn't, at least
make a nicer hack please (ie, modify KeDumpStackFrames to use
InbvDisplayString). I'm sorry but this patch is unacceptable to me...it
makes the code look like shit.
Best regards,
Alex Ionescu