[GDI32]
- Remove the old SetDIBBits, it severed us well.... Hold on to the win32k call.
- Tested, Area.exe, wine gdi32 bitmaps test, AbiWord 2.8.6, OOo 2.4.3,
SM 2.0.11 and ReactOS applications.
- Aimp 2.61.583 (FULL, painted okay), CoolPlayer 219, winamp 0.98d and
winamp 2.95 (not FUll). The rest have drawing issue with DIB. See bug
5886.
The sound applications have the same issue with revision 50933+
(region unassociated with the DC owner), except CoolPlayer and winamp
0.98d. There is also an issue with vbrun60spX too. I'm not sure how to
move on and start compressed bitmaps.
Thanks,
James
Hmm...
I remember I added it to enable the possibility for backtraces in 1st
stage for sysreg. Why does it now cause the opposite? And why is there
an inconsistency? In 2nd stage there is an option for debug mode, in 1st
stage there is none, so using kdserial (which imo is appropriate way to
do it, I always select it) as default is as consistent as using "normal"
debug, getting the input from the keyboard driver.
Just my 0,002 ct/kb
Timo
Am 04.03.2011 17:57, schrieb fireball(a)svn.reactos.org:
> Author: fireball
> Date: Fri Mar 4 16:57:56 2011
> New Revision: 50967
>
> URL: http://svn.reactos.org/svn/reactos?rev=50967&view=rev
> Log:
> - Revert 47615. Please fix actual sysreg instead of adding inconsistency between 1st, 2nd and 3rd stages debugging connections. This should fix sysreg3's inability to do backtraces.
> See issue #5811 for more details.
>
> Modified:
> trunk/reactos/boot/bootdata/txtsetup.sif
>
> Modified: trunk/reactos/boot/bootdata/txtsetup.sif
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/boot/bootdata/txtsetup.sif…
> ==============================================================================
> --- trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] (original)
> +++ trunk/reactos/boot/bootdata/txtsetup.sif [iso-8859-1] Fri Mar 4 16:57:56 2011
> @@ -59,7 +59,7 @@
> [SetupData]
> DefaultPath = \ReactOS
> OsLoadOptions = "/NOGUIBOOT /NODEBUG"
> -DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE /KDSERIAL"
> +DbgOsLoadOptions = "/NOGUIBOOT /DEBUGPORT=COM1 /FIRSTCHANCE"
> ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=SCREEN"
> ;OsLoadOptions = "/NOGUIBOOT /DEBUGPORT=BOCHS"
>
>
>
>
Hi all,
im testing ROS right now in real hardware... As i cannot log into IRC (via
webchat.freenode.net, i cant even reach the page, i dont know why), let me
post this in ML
The think is, i have installed RealTek´s official driver for the NIC, and
hardware is recognized... but, dhcp dont get any IP...
any idea?
log is attached
btw, in the log there are many errors ("xxxx failed") about ndis.......
tkreuzer(a)svn.reactos.org wrote:
> Do raster operation on 4 bytes instead of only 3.
Quoting jgardou's commit before:
> - When applying raster operation, do so only on 24 bits, we don't
> support alpha channel in win32k
I have no idea about DIB code, but just from the commit message I
presume that this change to 24 bits has happened deliberately.
- Colin
Hi all,
I finished implementing main features of a special mechanism for
monitoring uesrmode heap allocations in ReactOS. This mechanism is
called Debug Page Heap, after the very similar mechanism present in
recent versions of Microsoft Windows NT.
Explaining the heap manager, the "usual" heap allocator (the one I
also developed earlier) also contains a heap corruption detector, but
it works post-factum, only after the respective block is freed its
patterns are checked (if such heap flags are specified) and if they
are damaged the block is reported. This makes debugging problematic,
because a lot of code is executed between the moment the corruption
occured and moment when the corrupted block is freed. Also it may be
so that block's patterns are untouched, but internal heap structures
are damaged. The usual heap allocator won't be able to catch this,
but will crash with undetermined exception.
Debug page heap (DPH) comes to solve this problem. Simply speaking it
guards every block with a no-access page either after or before the
block, so that when a badly written app wants to write beyond the
allowed area, an exception occurs showing exactly the faulty
instruction.
Not so simply speaking, it's a rather complicated debugging tool with
abilities to catch access-after-free cases also when they happen, and
do some other nice tricks too. If you want to read more about it,
look for "debug page heap" in MSDN and also visit URLs specified as
references in rtl/heappage.c.
How to use it? The best way is to use Microsoft's utility gflags.exe
which is part of the Debugging package of WDK. To make long things
short, just copy gflags.exe to C:\ReactOS\system32, boot your ReactOS
installation, fire up cmd prompt and type:
gflags /p /enable name.exe /full
Now, when you run your app called name.exe, it will use the DPH heap
allocator.
Detailed information about gflags.exe could be found here: http://
msdn.microsoft.com/en-us/library/ff549557%28VS.85%29.aspx
Also, I suggest looking in MSDN for page heap explanation (I provided
some references in heappage.c too).
Have fun!
Aleksey.
ReactOS Urgent Meeting
Preamble
=========
The following people which are generally considered as ReactOS-related
people have called for an urgent project meeting. They agree with the
meeting agenda and the rules for this meeting:
* Giannis Adamopoulos
* Johannes Anderwald
* Maciej Białas
* Aleksey Bragin
* Colin Finck
* Ziliang Guo
* Kamil Hornicek
* Amine Khaldi
* Timo Kreuzer
* Victor Martinez
* Roel Messiant
* Sylvain Petreolle
* Pierre Schweitzer
* Olaf Siejka
* James Tabor
* Art Yerkes
As we have not established any general rules for meetings yet, we
consider these demands enough to justify the need for such an urgent
meeting.
Based on the experiences Colin has from formal ReactOS Deutschland e.V.
foundation meetings, we need at least a discussion leader and a minute
taker to get an organized meeting done over IRC.
General Information
====================
* Date and Time: Tuesday, 22nd February, 2011 - 20:00 UTC
* Place: #reactos-meeting on Freenode
* Meeting leader: Colin Finck
* Minute taker: Amine Khaldi
* Allowed Participants
The following people are allowed to participate in the discussion
on that channel. This list is taken from the people which were
recently active on the #reactos-dev IRC channel. Others are not
included as they don’t have a chance to know about the recent
developments. If you consider yourself a ReactOS-related person,
you may still ask Colin Finck to put you on this list. Apart from
this, everybody may join as an observer.
o Giannis Adamopoulos (smiley1_)
o Johannes Anderwald (janderwald)
o Maciej Białas (niski)
o Aleksey Bragin (abragin)
o Colin Finck (Colin_Finck)
o Danny Götte (dangerground)
o Ziliang Guo (ZWabbit)
o Amine Khaldi (AmineKhaldi)
o Timo Kreuzer (rosdude)
o Matthias Kupfer (Collibri)
o Victor Martinez (vicmarcal)
o Roel Messiant (Mephisto)
o Ged Murphy (GedMurphy)
o Sylvain Petreolle (Usurp)
o Daniel Reimer (dreimer)
o Pierre Schweitzer (HeisSpiter)
o Samuel Serapion (encoded)
o Olaf Siejka (Caemyr)
o James Tabor (jimtabor)
o Art Yerkes (arty)
Meeting Agenda
===============
1. Agree on a preliminary definition for the term "ReactOS Team
Member".
To create a basis for the next regular meeting, we need to know
who may participate and who may not. As we need to focus on the
release right now, this definition should only be preliminary and
is subject to change in a future meeting.
Some participants will present proposals for such a definition.
2. Establish regular meetings every month.
This is the only chance to ensure discussions among a broad range
of ReactOS Team members with binding decisions. These meetings
should follow the rules of typical meetings, including meeting
leaders and minute takers. In contrast to this meeting, all team
members should be able to participate. Minutes should also be
published on the website.
Such regular meetings should begin after CLT2011 (after 20th
March) due to the time it takes to prepare this event.
3. Set up binding 0.3.13 Release Plans.
The CLT2011 event is a big PR chance for a new ReactOS release,
so we should look forward to get a release ready by then. This
point includes:
1. Getting information about the most annoying bugs and
regressions.
Victor Martinez and Olaf Siejka will report on this.
2. Building teams to care about each bug.
As soon as a bug is fixed, a team has to report back about
this to one of the release engineers. They will then add
you to another team. Of course, you may also suggest stuff
you want to work on afterwards.
3. Setting deadlines for the bugs.
We need to determine what bugs can be realistically fixed
in the given time. If a bug is not fixed by then, the
appropriate team has to report back about this to one of
the release engineers. They are then responsible for
finding a solution.
We believe that other topics, especially the ones discussed in the
"ReactOS Reaction" document should be covered in the first regular
meeting, so that we can focus on 0.3.13 right now.
Hi,
this debug wasn't supposed to be silent as it highlights a quite crappy situation in ReactOS. And that's even what one would call: "a hack".
That way, you could also silence IopParseDevice hack debug...
At least, you could have asked the author, I'm not that unreachable ;-).
Regards,
P. Schweitzer
I noticed this everywhere,
(subsystems/win32/win32k/objects/gdiobj.c:249) GDIOBJ_LockObj:
Attempted to lock object 0x10064, wrong reuse counter (Handle: 0x0,
Entry: 0x8)
(subsystems/win32/win32k/objects/dclife.c:726) Could not lock source DC 00010064
(subsystems/win32/win32k/ntuser/simplecall.c:349) Calling invalid
routine number 0x10 in NtUserCallOneParam(), Param=0x31
CallOneParam? Looks like a stack issue.