Why was this done? Having these bugs listed as blockers to 399 allows
devs to find the old bugs easier in case of regressions. I don't see
any downsize to keeping them listed.
On 12/28/05, ReactOS.Bugzilla(a)reactos.org <ReactOS.Bugzilla(a)reactos.org> wrote:
> http://www.reactos.org/bugzilla/show_bug.cgi?id=399
>
>
> greatlord(a)reactos.com changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> BugsThisDependsOn|398, 400, 937 |
>
>
>
>
> ------- Additional Comments From greatlord(a)reactos.com 2005-12-28 17:54 CET -------
> Bug 398 are fixed, Bug 400 are fixed, Bug 937 are fixed
> I remove tuse from Bug depends on.
>
>
>
> --
> Configure bugmail: http://www.reactos.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug, or are watching the assignee.
> You are the QA contact for the bug, or are watching the QA contact.
> _______________________________________________
> Ros-bugs mailing list
> Ros-bugs(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-bugs
>
WD
--
<Russell> argh
<Russell> iterator shenanigans :/
ion(a)svn.reactos.com wrote:
> - Major Win32k Header Cleanup: Add ntgdi.h based on latest Platform SDK Public header. It contains the official definitions for NtGdi APIs.
> - Added ntgdityps.h for structures needed to use the header (which were sadly not publically shipped).
> - Removed internal win32k header data from public headers and put it to internal win32k headers.
> - Fixed ntuser.h STDCALL->WINAPI.
> - Added ntgdihdl.h for shared GDI Handle information between gdi32/win32k
> - Added ntusrtyp.h for some shared NtUser types.
> - Added ntgdibad.h which contains all non-compatible NtGdi prototypes, along with a detailed comment for each, and information on how to fix it. I had a 20 000+ line patch fixing all these issues, but it contained many bugs and I scrapped it in place for this approach, which while dirtier at first, simplifies the number of changes needed so that others can work on it as well.
> - Fixed some gdi32/win32k/user32 header issues.
>
>
This change breaks running ros on qemu and real hardware. I don't see a
mouse cursor after the gui is started. If I move the mouse, ros does
crash. If I don't move the mouse, ros starts up to the first device
install dialog. After this ros terminates itself and does switch off the
computer.
- Hartmut
(ntoskrnl\mm\mm.c:317) Address: 87dcf974
Unhandled exception
ExceptionCode: c0000005
Faulting Address: 87dcf974
Address: 77e9238b C:\ReactOS\system32\user32.dll
CS:EIP 1b:77e9238b
DS 23 ES 23 FS 3b GS 0
EAX: 87dcf974 EBX: 0144fdec ECX: 0144ffb4
EDX: f000ff53 EBP: 0144fb6c ESI: 00000000 ESP: 0144fb24
EDI: 00000000 EFLAGS: 00000246
Frames:
77e50000+2f461 C:\ReactOS\system32\user32.dll
77e50000+2fdf6 C:\ReactOS\system32\user32.dll
77e50000+31fb6 C:\ReactOS\system32\user32.dll
10000000+72cf C:\ReactOS\system32\win32csr.dll
77e50000+52657 C:\ReactOS\system32\user32.dll
77e50000+53a52 C:\ReactOS\system32\user32.dll
7c900000+a15b C:\ReactOS\system32\ntdll.dll
10000000+764e C:\ReactOS\system32\win32csr.dll
7c800000+2fe1d C:\ReactOS\system32\kernel32.dll
(./subsys/win32k/ntuser/window.c:581) thread cleanup: while destroy
wnds, wnd=0x870d11a4
(subsys\win32k\main\dllmain.c:281) thread clean: remove reference obj
0x870d11a4
(subsys\win32k\main\dllmain.c:281) thread clean: remove reference obj
0x870d11a4
KeBugCheckWithTf at ntoskrnl\ke\i386\exp.c:1242
A problem has been detected and ReactOS has been shut down to prevent
damage to your computer.
The problem seems to be caused by the following file: win32k.sys
Technical information:
*** STOP: 0x0000001E (0xc0000005,0x9da2ba1f,0x00000000,0xfffffff4)
*** win32k.sys - Address 0x9da2ba1f base at 0x9d99b000, DateStamp 0x0
Page Fault Exception: 14(0)
Processor: 0 CS:EIP 8:9da2ba1f <win32k.sys:90a1f
(./subsys/win32k/ntuser/msgqueue.c:271 (co_MsqTranslateMouseMessage))>
cr2 fffffff4 cr3 f58c000 Proc: 80ac2050 Pid: 7c <csrss.exe> Thrd:
80c6d220 Tid: b4
DS 23 ES 23 FS 30 GS 0
EAX: fffffff4 EBX: 80c6d5f8 ECX: 00000000
EDX: 9da883d0 EBP: 9e194a8c ESI: 0164fe24 ESP: 9e1949f0
EDI: 9e194d64 EFLAGS: 00000297 kESP 9e1949f0 kernel stack base 9e192000
Frames:
<win32k.sys:9170b (./subsys/win32k/ntuser/msgqueue.c:621
(co_MsqPeekHardwareMessage))>
<win32k.sys:92bfa (./subsys/win32k/ntuser/msgqueue.c:1259
(co_MsqFindMessage))>
<win32k.sys:88626 (./subsys/win32k/ntuser/message.c:731
(co_IntPeekMessage))>
<win32k.sys:890a3 (./subsys/win32k/ntuser/message.c:941
(co_IntWaitMessage))>
<win32k.sys:893d2 (./subsys/win32k/ntuser/message.c:1051
(NtUserGetMessage))>
<ntoskrnl.exe:9a8ea (ntoskrnl\ke\i386\syscall.S:372 (KiSystemService))>
<user32.dll:52bd3 (lib/user32/windows/message.c:1166 (GetMessageW))>
>From the way ROS tends to hamng up when running CPU-intense processes,
I'm starting to suspect ROS is in fact not pre-emptively multitasking.
And this seems to have gotten worse from 0.2.8 to 0.2.9. Any thoughts?
/nitro2k01
--
The blog of nitro2k01: <http://soundandcomplete.blogspot.com/>
Saliga äro de som kan stava till 2k01!
hpoussin(a)svn.reactos.com wrote:
> Replace implementation of QueryServiceConfigW by a stub (like in pre-20255), as rpcrt4 throws sometimes an exception and breaks PnP manager
>
>
LOL!
That was no surprise! Sounds like Wine need to fix their broken code.
I had a patch but I'm still ban from sending email to wine-patch! So~
rm * the patch!
James
Hi,
I am pleased to announce that with Ge's patch to fix Exception
handling and Brandon and Thomas's work on the pagefile it is now
possible to install Office 2000 on the trunk. You will get quite a few
errrors at the end of the install due to missing dlls from MDAC/ADO
that Office2000 expects a Windows 2000 system to ship with, which we
of course do not have stubbed at this time. Thanks to Eric Kohls work
on services msiexec is mostly happy installing Office2000 if started
from the command line like the following
msiexec /i data1.msi
There is still issues with setup.exe properly working althogh I think
this is more due to version numbers we report.
We are still unable to run Office applications at this time due to
unhandled exceptions which look like they are due to COM errors as
well as some problems due to the amount of memory we are reporting.
Both Winword and Access display message boxes saying that there is not
enough memory to run the application. Also even if we do get those
issues fixed we are currently blocked by the registry instablity.
--
Steven Edwards - ReactOS and Wine developer
"There is one thing stronger than all the armies in the world, and
that is an idea whose time has come." - Victor Hugo
ReactOS on LinuxTag 2006
From 3. till 6. May 2006 over 15000 guests will visit the LinuxTag in
Wiesbaden (Germany).
They provide free stands on the expo for open source projects.
I think ReactOS could be there too. Wiesbaden is not far from where I
live and if some of
the developers are interrested we could talk about making a stand.
Best Regards,
dom
I have found some problems running Allegro programs in ReactOS. When I
have tested it they started up and the mouse moves the upper right hand
corner of the screen and ReactOS apparently hangs. I'm curious why is
this happening; although, I think it is possibly some bugs (or bug) that
is causing it, or it is caused by an unimplemented feature. It is most
like located in the DirectX and OpenGL components. This realtes to bug
1112.
